共计 3129 个字符，预计需要花费 8 分钟才能阅读完成。
- 概述
开发者在应用 YonBuilder 挪动开发 技术，创立新我的项目的时候，通常都会有一个是否应用 AVM 的选项，见下图
在 Web 网站控制台中创立利用的截图
很多老手开发者可能都会有这样一个疑难，到底要不要应用 AVM？这个 AVM 是什么？应用与不应用对于开发这个我的项目有什么区别和影响？
针对以上容易让老手开发者产生纳闷的问题点，本文简略剖析了一下 应用 AVM 和 不应用 AVM 的一些区别，以期可能帮忙开发者敌人在面对不同的我的项目场景需要时，可能做出更加精确的判断抉择。
- 对于 YonBuilder 挪动开发的两种模式
YonBuilder 挪动开发 反对应用 javascript 去开发利用我的项目，其中包有两种开发模式，这两种开发模式我集体形容为：混合开发模式(HyBird Mode) 和 多端开发模式(Mutiple Mode)。
第一局部截图中的 应用 AVM 的选项，对应的就是这两种模式。不应用 AVM（默认），则我的项目应用 HyBird Mode 混合开发模式，如 应用 AVM 则我的项目对应应用(Mutiple Mode 多端开发模式, 上面咱们简略介绍一下这两种模式。
2.1 HyBird Mode: 混合开发模式
混合开发模式（HyBird Mode），就是 YonBuilder 挪动开发技术提供的，一种反对应用 Web 前端开发开发语言（HTML、CSS、JavaScript），并联合原生 API 对象和原生插件去实现利用我的项目开发的编程开发模式。一次开发，反对生成 Harmony、android、iOS 和 H5 多种类型的客户端利用。
值得一提的是，与市场常见的套壳 web 利用开发不同，YonBuilder 挪动开发技术提供的混合开发模式，内置了一套封装有原生挪动零碎性能的 API 函数 和应用原生语言封装的、可开箱即用的、功能丰富的原生插件。原生插件的引入，能够解决了 web 页面在简单场景下页面卡顿、性能不晦涩等痛点问题。
混合开发模式的实现准则是简略界面（偏内容展现、页面数据中等、交互绝对简略）应用 HTML、CSS、JS 形式去实现，简单页面（数据宏大、交互频繁）去应用原生插件去实现（如果官网的插件库没有匹配的插件，还反对上传用户自定义原生插件），或者两者混合应用。通过这种编程机制，YonBuilder 挪动开发的混合开发模式能够保障让开发者开发出高性能高质量的客户端利用。
2.2 Mutiple Mode: 多端开发模式
多端开发模式（Mutiple Mode），反对开发者一次开发，同时生成多个利用客户端，目前反对 Harmony、android、iOS、H5 和小程序。也就是说它比下面的混合开发模式多进去一个小程序的多端反对。须要特地指出，在多端模式下，开发者须要应用官网提供的 AVM 多端开发框架（以下简称 AVM）去进行我的项目的利用开发。
AVM 的全称是 Application-View-Model , 去除所有文字上的润饰形容，简略来说 AVM 就是一个反对应用 javascript 去编写我的项目代码的多端技术框架。AVM 有一套本人定义的 UI 组件，开发者须要应用这些 AVM 定义好的组件去进行页面开发。AVM 采纳了一品种 vue 的语法结构去进行页面编码开发，它有本人的生命周期事件和编程规定。它的底层是将开发者编写的编码内容，通过 AVM 框架内置的编译机制，以工程化形式对代码进行编译，将编写好的 js 编代码转化为对应平台的原生语音编码，而后通过平台提供的编译打包性能，最终生成一个实在的 Native App。对于最终的 App 产物来说，AVM 生成的利用与应用 Native 原生语音去开发的利用，在实质上并没有区别。
- 应用 AVM 与不应用 AVM 的区别剖析
基于下面的剖析，创立利用时如果采纳默认选项，即 不应用 AVM，则我的项目应用的是 HyBird Mode 混合开发模式；如切换到 应用 AVM，则我的项目对应应用的是 Mutiple Mode 多端开发模式。
下列简表，针对两种模式进行了一下简略的比照剖析。
小结：
混合开发模式：主打挪动客户端的端开发，学习门槛低，上手容易，编程开发敌对，没有特地限度，是一门特地适宜 web 前端开发的同学作为横向扩大去学习的技术。
多端开发模式：主打多端，反对低代码拖拽生成页面，须要应用 AVM 多端框架去开发实现页面和性能，有一套本人定义的组件和语法规定，须要开发者去专门学习。因为框架要兼容多端，所以在编程上有肯定的限度，及必须遵循 AVM 框架的开发规定，同时因为要思考翻译成原生的 navtive 款式，所以在 CSS 的应用上也有肯定的兼容性限度要求，具体须要参照官网的 AVM 开发文档
- 是否抉择 AVM 的一点倡议
4.1 一、依据我的项目场景去抉择
如果仅须要生成挪动端利用，并不需要生成小程序的话，倡议应用混合开发模式，老手敌对（强烈推荐！）
如果须要生成小程序我的项目，能够思考抉择应用 AVM
4.2 二、依据本身的技术栈去抉择
如果对于 Web 前端技术曾经有肯定理解，并不想额定再破费肯定工夫去学习一门新的框架语言，那就抉择混合开发模式，仅须要 Web 前端常识，联合理解一下官网的 API 对象性能，就能够上手 App 我的项目开发了。
4.3 三、依据我的项目复杂度去抉择
如果我的项目绝对简单，那就倡议应用混合开发模式，反对丰盛的 DIY 开发。AVM 因为要思考多端的兼容性，因而对于很多非 惯例的款式和交互的反对力度会稍差一些，另外很多时候遇到与 AVM 框架相干的问题，须要反馈给相干的技术人员去解决解决，在流程上会须要肯定的工夫。混合开发模式曾经有超过 5 年的技术实际了，技术十分成熟，对于一些工期比拟紧急的我的项目，稳当起见，倡议应用混合开发模式去开发我的项目。
对于简单我的项目的判断形容：
UI 层面：UI 款式很离奇奇异，不是市场上常见的布局构造和组件款式；
原型交互：交互逻辑比较复杂，有拖拽、有缩放，有动画特效等、非凡字体等；
额定多说一点
小程序利用和挪动端利用因为零碎底层提供 API 性能的不同和产品利用方向上的差别，两者的利用场景还是有所区别的。小程序平台重展现，轻交互，主打轻量化利用；而挪动端底层提供的性能更为全面，对于利用的体积限度也比拟小，能够满足各式各样的用户需要，适宜那些交互逻辑更重一些的我的项目。
集体认识，能够把小程序利用作为引流的伎俩，重点展现性能和疾速入口，将用户吸引进来，而后通过 App 客户端提供更全面、更深刻的性能体验，成为积淀用户的主体客户端。如果不思考平台个性，强行一刀切，将多个平台客户端对立成一个版本，则没法完满施展各个平台的本身劣势。例如一些页面性能交互太重的利用，小程序端是实现不了的。而如果为了兼容小程序，把我的项目设计的绝对简略通用一些，则又没法齐全施展出挪动端的性能劣势，这样的后果就很容易把利用我的项目变成一款平庸的产品。所以对于一些简单我的项目，倡议从原型阶段就依据小程序平台的个性和挪动端的个性去做辨别，做成两个内容不同的版本，离开去实现，这样能充分发挥开释出不同平台的个性，也出现给用户最好的客户端体验。
- 结语
咱们在开发后期进行技术栈框架抉择的时候，往往会很关注这个框架编译生成后的利用性能体验，集体认为这个性能体验其实是一个受综合因素影响的后果，技术框架只是其中的因素之一，很多时候开发者本身的技术水平才是最终决定一个利用体验好坏的基本。所以专一编码逻辑优化、异常情况的边界解决，理解和施展框架、平台个性，才是开发出一个高质量、高体验利用的要害。
————————————————
版权申明：本文为 CSDN 博主「什么都什么」的原创文章，遵循 CC 4.0 BY-SA 版权协定，转载请附上原文出处链接及本申明。
原文链接：https://blog.csdn.net/SMDOUSM/article/details/129369261