大略先容一下我自己，中年码农，跨平台开拓领域的老兵。在那个翻盖摩托罗拉手机代表着前辈和时髦的年代，我就开始参与 “window mobile/j2me/symbain” 等系统的跨平台研发管理事情，可能很多同学都没见过那些手机。到后来的移动互联网时期及当下的小程序时期，我也一贯在深度参与个中，持续输出“Hybrid App”引擎、前端 UI 库（mui）及小程序跨端开拓框架（uni-app）。目前在 DCloud 任职 CTO，同时兼 “uni-app” 产品卖力人。
罗马不是一天建成的，小程序也不是一天发明的。小程序这种介于 H5 和 Native App 之间的分外运用形态，从探索到成熟，经历了哪些过程？我们首先带大家回顾梳理一下。然后，从现有技能架构出发，剖析小程序当下几个紧张性能坑点。各家小程序引擎为办理这些坑点，做了哪些完善事情。比如，大家知道小程序因此 Web 渲染为主、原生渲染为辅，那引入原生渲染后，引发了哪些新的问题？为办理这些问题，微信提出了同层渲染的方案，同层渲染在技能层面上又是如何实现的？末了从当前已知问题出发，对付小程序未来的技能更迭，抛出一些我们认为的可能方向，供大家参考。
一、小程序历史
HTML5 于 2007 年在 W3C 立项，与 iPhone 发布同年。
乔布斯曾期待 HTML5 能帮助 iPhone 打造起运用生态系统。但 HTML5 的发展速率并不如预期，虽然它成功地冲破了 IE+Flash 垄断的局势，却没有达到承载精良的移动互联网体验的地步。
苹果公司在 iPhone 站稳脚跟后，紧接着发布了自己的 App Store，开启了移动互联网的原生运用时期。
大家知道现在手机端紧张是 iOS、Android 两大系统，实际上在早期有 3 大系统竞争，还有一个便是诺基亚的 MeeGo 系统，MeeGo 采取 C + HTML5 的双模运用生态策略。然而，C 的开拓难度太大，HTML5 体验又弗成，所往后来 MeeGo 就掉队了；与之对应，Android 依赖 Java 技能生态，在竞争中脱颖而出。
于是在移动互联网初期，运用生态被定了基调 —— 原生开拓。
海内有一批做浏览器的厂商，考试测验去改进 HTML5。比如，百度在 2013 年的百度天下大会上发布了轻运用，通过给 WebView 扩展原生能力，补充 JS API，让 HTML5 运用可以实现更多功能。
这类业务发展的顶峰，是微信在 2015 年初发布的微信 JS SDK，作为海内事实上最大的手机浏览器，微信为它的浏览器内核扩充了大量 JS API，让开发者可以用 JS 调用微信支付、扫码等浩瀚 HTML5 做不到的功能。
不过这类业务没有取获胜利，HTML5 的问题不止是功能不敷，性能体验是更严重的问题。而体验问题，不是大略地扩展 JS 能力能搞定的。
与浏览器不同，Hybrid 运用是另一个细分领域，开拓者利用 JS 编写运用，为了让 JS 运用更靠近原生运用的功能体验，这个行业的从业者做出了很多考试测验。我们 DCloud 公司是业内主流 Hybrid App 引擎供应方之一，我们提出了改进 HTML5 的“性能功能”障碍的办理方案 —— 通过工具、引擎优化、开拓模式调度，让开发者可以通过 JS 写出更靠近原生 App 体验的运用。
多 WebView 模式，原生接管转场动画、下拉刷新、Tab 分页，预载 WebView……各种优化技能一直迭代，终于让 Hybrid 运用取得了性能体验的打破。
Hybrid 运用和轻运用、微信 JS SDK 等基于浏览器增加方案比较，还有一个巨大的差别：一个是 Client/Server，一个是 Browser/Server。大略来说，Hybrid 运用是 JS 编写的须要安装的 App，而轻运用是在线网页。
C/S 的运用在每次页面加载时，仅须要联网获取 JSON 数据；而 B/S 运用除了 JSON 数据外，还须要每次从做事器加载页面 DOM、样式、逻辑代码，以是 B/S 运用的页面加载很慢，体验很差。
可是这样的 C/S 运用虽然体验好，却失落去了 HTML5 的动态性，仍旧须要安装、更新，无法即点即用、直达二级页面。
那么 C/S 运用的动态性是否可以办理呢？对此， DCloud 率先提出了“流运用”观点，把之前 Hybrid 运用里的运行于客户真个 JS 代码，先打包发布到做事器，制订流式加载协议，手机端引擎动态下载这些 JS 代码到本地，并且为了第一次加载速率更快，实现了运用的边下载边运行。
就像流媒体的边下边播一样，运用也可以实现边用边下。
在这套方案的保障下，终于办理了之前的各种难题：让 JS 运用功能体验达到原生，并且可即点即用、直达二级页面。
接着便是微信小程序，最初的名字实际上是微信运用号，之后改名为小程序，2016 年 9 月份内测，2017 年 1 月正式发行，再之后阿里巴巴、手机厂商同盟、百度、今日头条，陆续推出了自己的小程序平台，小程序时期滚滚而来。
2018 年 9 月，微信推出云开拓，这个功能我们认为是小程序发展历史上的一个主要节点，它可以让前端工程师从前到后将所有业务闭环实现，减少前后真个沟通本钱、人力本钱、运维本钱，属于开拓模式的重大升级。与之前的前端同学既可通过 JS/CSS 编写前端 UI，又可通过 “Node.js” 写后端业务，这种所谓全栈开拓模式比较，云开拓有更好的上风，由于前端同学对付 DB 优化、弹性扩容、攻击防护、灾备处理等方面还是有履历欠缺的，但云开拓将这些都封装好了，真正做到仅专注业务实现，其它都委托云厂商做事。
二、小程序架构这是一个比较通用的小程序架构，目前几家小程序架构设计大致都是这样的（快运用的差异是视图层只有原生渲染）。
大家知道小程序是一个逻辑、视图层分离的架构。
逻辑层便是上图左上角这块，小程序中开拓的所有页面 JS 代码，末了都会打包合并到逻辑层，逻辑层除了实行开拓者的业务 JS 代码外，还需处理小程序框架的内置逻辑，比如 App 生命周期管理。
视图层便是上图右上角这块，用户可见的 UI 效果、可触发的交互事宜在视图层完成，视图层包含 Web 组件、原生组件两种，也便是小程序是原生 +Web 稠浊渲染的模式，这块后面会详细讲。
逻辑层末了运行在 JS CORE 或 V8 环境中；JS CORE 既不是 DOM 环境，也不是 Node 环境，你是无法利用 JS 中的 DOM 或 BOM 工具的，你能调用的仅仅是 ECMAScript 标准规范中所给出的方法。
那如果你要发送网络要求怎么办？window.XMLHttpRequest 是无法利用的（当然纵然可以调用，在 iOS 的 WKWebView 中也存在更严格的跨域限定，会有问题）。这时候，网络要求就须要通过原生的网络模块来发送，JS CORE 和原生之间呢，就须要这个 JS Bridge 来通讯。
三、架构引发的性能坑点小程序这种架构，最大的好处是新页面加载可以并行，让页面加载更快，且不卡转场动画；但同时也引发了部分性能坑点，今天主要先容 3 点：
1. 逻辑层 / 视图层通讯壅塞
我们从“swipeaction”这个例子讲起，需求是用户在列表项上向左滑动，右侧隐蔽的菜单跟随用户手势平滑移动。
若想在小程序架构上实现流畅的跟手滑动，是很困难的，为什么？
回顾一下小程序架构，小程序的运行环境分为逻辑层和视图层，分别由 2 个线程管理，小程序在视图层与逻辑层两个线程间供应了数据传输和事宜系统。这样的分离设计，带来了显而易见的好处：
环境隔离，既担保了安全性，同时也是一种性能提升的手段，逻辑和视图分离，纵然业务逻辑打算非常繁忙，也不会壅塞渲染和用户在视图层上的交互。
但同时也带来了明显的坏处：
视图层（WebView）中不能运行 JS，而逻辑层 JS 又无法直接修正页面 DOM，数据更新及事宜系统只能靠线程间通讯，但跨线程通信的本钱极高，特殊是须要频繁通信的场景。
基于这样的架构设计，我们回到“swipeaction”，剖析一次 touchmove 的操作，小程序内部的相应过程：
（1）用户拖动列表项，视图层触发 touchmove 事宜，经 Native 层中转关照逻辑层（逻辑层、视图层不是直接通讯的，需 Native 中转），即下图中的⓵、⓶两步；
（2）逻辑层打算需移动的位置，然后再通过 setData 通报位置数据到视图层，中间同样会由微信客户端（Native）做中转，即下图中的⓷、⓸两步。
实际上，用户滑动过程中，touchmove 的回调触发是非常频繁的，每次回调都须要 4 个步骤的通讯过程，高频率回调导致通讯本钱大幅增加，极有可能导致页面卡顿或抖动。为什么会卡顿，由于通讯太过频繁，视图层无法在 16ms 内完成 UI 更新。
为办理这种通讯壅塞的问题，各家小程序都在逐步供应对应的办理方案，比如微信的 WXS、支付宝的 SJS、百度的 Filter，但每家小程序支持情形不同，详细见下表。
其余，微信的“关键帧动画”、百度的“animation-view” Lottie 动画，也是为减少频繁通讯的一种变更办法。
实在，通讯壅塞是业界普遍存在的一个问题，不止小程序，“React Native”“Weex”等同样存在通讯壅塞的问题。只不过“React Native”“Weex”的视图层是原生渲染，而小程序是 Web 渲染。我们下面以“Weex”为例来解释。
大家知道，“Weex”底层利用的 JS-Native Bridge，这个 Bridge 使得 JS 和 Native 之间的通信会有固定的性能损耗。
连续以上述“swipeaction”为例，要实现列表项菜单的跟手滑动，大致需经如下流程：
（1）在 UI 视图上绑定 touch 事宜（或 pan 事宜）;
（2）当手势触发时， Native UI 层将手势事宜通过 Bridge 通报给 JS 逻辑层 , 这产生了一次 Native UI 到 JS 逻辑的通信，即下图中的⓵、⓶两步 ;
（3）JS 逻辑在吸收到事宜后，根据手指移动的偏移量驱动界面变革，这又会产生一次 JS 到 Native UI 的通信，即下图中的⓷、⓸两步。
同样，手势回调事宜触发的频率是非常高的，频繁的的通信带来的韶光本钱很可能导致界面无法在 16ms 中完成绘制，卡顿也就产生了。
“Weex”为办理通讯壅塞，供应了“BindingX”办理方案，这是一种称之为“Expression Binding”的机制，简要先容一下：
（1）吸罢手势事宜的视图，在移动过程中的偏移量以“x，y”两个变量表示；
（2）期望改变（跟随移动）的视图，变革的属性为“translateX”和“translateY”，对应变革的偏移量以“f(x)，f(y)”表达式表示；
（3）将”交互行为 " 以表达式的办法描述，并提前预置到 Native UI 层；
（4）交互触发时，Native UI 根据其内置的表达式解析引擎，去实行表达式，并根据表达式实行的结果驱动视图变换，这个过程无需和 JS 逻辑通讯。
伪代码 - 摘录自 Weex 官网
复制代码
{ anchor: foo_view.ref // ----> 这是 " 产生手势的视图 " 的引用 props: [ { element: foo_view.ref, // ----> 这是 " 期望改变的视图 " 的引用 expression: f(x) = x, // ----> 这是详细的表达式 property: translateX // ----> 这是期望改变的属性 }, { element: foo_view.ref, expression: f(y) = y, // ----> y 属性 property: translateY } ]}
“React Native”同样存在类似问题，为避免频繁的通信，“React Native”生态也有对应方案，比如“Animated”组件及 Lottie 动画支持。以 “Animated”组件为例，为实现流畅的动画效果，该组件采取了声明式的 API，在 JS 端仅定义了输入与输出以及详细的 transform 行为，而真正的动画是通过 Native Driver 在 Native 层实行，这样就避免了频繁的通信。然而，声明式的办法能够定义的行为有限，无法胜任交互场景。
“uni-app”在 App 端同样面临通讯壅塞的问题，我们目前的方案是采取类似微信 WXS 的机制（内部叫“renderjs”），但放开了 WXS 中无法获取页面 DOM 元素的限定，比如下图中多个小球同时移动的 canvas 动画，“uni-app”在 App 真个实现方案是：
（1）renderjs 中获取 canvas 工具；
（2）基于 web 的 canvas 绘制动画，而非原生 canvas 绘制。
Tips：大家须要把稳，并不是所有场景都是原生性能更好，小程序架构下，如上多球同时移动的动画，原生 canvas 并不如在 WXS（renderjs）中直接调用 Web canvas
下表总结了跨端框架在通讯壅塞方面的办理方案：
2. 数据 / 组件差量更新
小程序架构存在通讯壅塞问题，厂商为办理这个问题，创造了“WXS”脚本措辞及关键帧动画等办法，但这些都是厂商维度的优化方案。我们作为小程序开拓者，在性能优化方面，又能做哪些事情呢？
小程序开拓性能优化，核心便是“setData”的调用，你能做只有两件事情：
只管即便少调用“setData”；每次调用“setData”，通报尽可能少的数据量，即数据差量更新。（1）减少 setData 调用次数
假设我们有变动多个变量值的需求，示例如下：
change:function(){ this.setData({a:1}); ... // 其它业务逻辑 this.setData({b:2}); ... // 其它业务逻辑 this.setData({c:3}); ... // 其它业务逻辑 this.setData({d:4});}
如上，4 次调用“setData”，会引发 4 次逻辑层、视图层数据通讯。这种场景，开拓者需意识到“setData”有极高的调用代价，自己需手动调度代码，合并数据，减少数据通讯次数。
部分小程序三方框架已内置数据合并的能力，比如“uni-app”在 Vue runtime 上进行了深度定制，开拓者无需关注“setData”的调用代价，可放心编写如下代码：
change:function(){ this.a = 1; ... // 其它业务逻辑 this.b = 2; ... // 其它业务逻辑 this.c = 3; ... // 其它业务逻辑 this.d = 4;}
如上 4 次赋值，uni-app 运行时会自动合并成“{“a”:1,“b”:2,“c”:3,“d”:4}”一条记录，调用一次“setData”完成所有数据通报，大幅降落 setData 的调用频次，结果如下图：
减少“setData”调用次数，还有个把稳点：后台页面（用户不可见的页面）应避免调用“setData”。
（2）数据差量更新
假设我们有一个 “列表页 + 上拉加载” 的场景，初始化列表项为 “item1 ~ item4”，用户上拉后要向列表追加 4 条新记录 “item5 ~ item8”，小程序代码如下：
page({ data:{ list:['item1','item2','item3','item4'] }, change:function(){ let newData = ['item5','item6','item7','item8']; this.data.list.push(...newData); // 列表项新增记录 this.setData({ list:this.data.list }) }})
如上代码，change 方法实行时，会将 list 中的 “item1 ~ item8”8 个列表项通过“setData”全部传输过去，而实际上变革的数据只有“item5 ~ item8”。
开拓者在这种场景下，应通过差量打算，仅通过“setData”通报变革的数据，如下是一个示例代码：
page({ data:{ list:['item1','item2','item3','item4'] }, change:function(){ // 通过长度获取下一次渲染的索引 let index = this.data.list.length; let newData = ['item5','item6','item7','item8']; let newDataObj = {};// 变革的数据 newData.forEach((item) => { newDataObj['list[' + (index++) + ']'] = item;// 通过 list 下尺度确掌握变更内容 }); this.setData(newDataObj) // 设置差量数据 }})
每次都手动打算差量变更数据是繁琐的，新手不理解小程序事理的话，也随意马虎忽略这些性能点，给 App 埋下性能坑点。
此处，建议开拓者选择成熟的第三方小程序框架，这些框架已经自动封装差量数据打算，对开拓者更友好。比如，“uni-app”借鉴了 “westore JSON Diff”库，在调用 setData 之前，会先比对历史数据，精确高效打算出有变革的差量数据，然后再调用 setData，仅传输变革的数据，这样可实现通报数据量的最小化，提升通讯性能。如下，是一个示例代码：
export default{ data(){ return { list:['item1','item2','item3','item4'] } }, methods:{ change:function(){ let newData = ['item5','item6','item7','item8']; this.list.push(...newData) // 直接赋值，框架会自动打算差量数据 } }}
Tips：如上 change 方法实行时，仅会将 list 中的 “item5 ~ item8”4 个新增列表项传输过去，实现了 setData 传输量的极简化。
（3）组件差量更新
下图是一个微博列表截图：
假设当前有 200 条微博，用户对某条微博点赞，需实时变更其点赞数据（状态）；在传统模式下，一条微博的点赞状态变更，会将全体页面 (Page) 的数据全部通过 setData 通报过去，这个花费是非常高的；而纵然通过之前先容，通过差量打算的办法获取变更数据，这个 Diff 遍历范围也很大，打算效率极低。
如何实现更高性能的微博点赞？这实在便是组件更新的范例场景。
得当的办法该当是，将每条微博封装成一个组件，用户点赞后，仅在当前组件范围内打算差量数据（可理解为 Diff 范围缩小为原来的 1/200），这样效率才是最高的。
提醒大家把稳，并不是所有小程序三方框架都已实现自定义组件，只有在基于自定义组件模式封装的框架中，性能才会大幅提升；如果三方框架是基于老的“template”模板封装的组件开拓，则性能并不会有明显改进，其 Diff 比拟范围依然是 Page 页面级的。
3. 稠浊渲染大家知道，小程序当中有一类分外的内置组件——原生组件，这类组件有别于 WebView 渲染的内置组件，他们是由原生客户端渲染的。
小程序中的原生组件，从利用办法上来说，紧张分为三类：
通过配置项创建的：选项卡、导航栏，还有下拉刷新；通过组件名称创建的，比如：camera、canvas、input、live-player、live-pusher、map、textarea、video；通过 API 接口创建的，比如：showModal、showActionSheet 等。除了上面提到的这些之外，其它基本都是 Web 渲染。以是说，小程序是稠浊渲染模式，Web 渲染为主，原生渲染为辅。
（1）为什么要引入稠浊渲染
接下来的问题，为什么要引入原生渲染？以及为什么仅针对这几个组件供应了原生增强？其他组件为什么没有做原生实现？
这就须要我们针对每个组件单独进行剖析思考，这里举了几个例子：
tabs/navigationbar：避免切换页面白屏，提升新窗口进入时的用户体验。虽然不该用原生的 tabbar 和导航栏，可以做出更灵巧的界面，但在切换页面那短短 300ms 内，想担保页面不白屏，还是须要利用渲染更快的原生 tabbar 和导航栏；video：全屏后的滑动掌握（声音、进度、亮度等）；map：更流畅的双指缩放、位置拖动；input：Web 真个 input，键盘弹出时，只有“完成”按钮，无法让键盘显示“发送”“下一个”这样的按键。提到“input”控件的原生化，可以轻微发散一下。
小程序中原生 input 控件的通用做法是，未获取焦点时以 Web 控件显示，但在获取焦点时，绘制一个原生 input，盖在 Web input 上方，此时，用户瞥见的键盘即为原生 input 所对应的键盘，原生弹出键盘是可自定义按钮（如上图中下一步、send 按钮）。这种做法存在一个毛病： Web 和原生，毕竟不同渲染引擎，在键盘弹出和关闭时，对应 input 的“placeholder”会闪烁。
在 Android 平台，还有一种做法是基于 WebKit 改造，定制弹出键盘样式；这种方案，在键盘弹出和关闭时，input 控件都是 Web 实现的，故不存在“placeholder”闪烁的问题。
（2）稠浊渲染引发的问题
原生组件虽然带来了更丰富的特性及更好的性能，但同时也引入了一些新的问题，比如：
层级问题：原生永久在最高层，无法通过“z-index”设置不同元素的层级，无法与 view、image 等内置组件相互覆盖，不支持在“picker-view”“scroll-view”“swiper”等组件中利用；通讯问题：比如一个长列表中内嵌视频组件，页面滚动时，需关照原生的视频组件一起滚动，通讯壅塞，可能导致组件抖动或拖影；字体问题：在 Android 手机上，调度系统主题字体，所有原生渲染的控件的字体都会变革，而 Web 渲染的字体则不会变革。如下图，系统 rom 字体为一款“你的名字”的三方字体，设置后，小程序顶部标题字体变了，底部选项卡字体也变了，但小程序中间内容区字体不变，这便是比较尴尬的一种情形，一个页面，两种字体。当然，并不是所有小程序都存在这种问题，部分小程序通过修正自带的 WebView 内核，实现了 WebView 也可以利用 rom 主题字体，比如微信、QQ、支付宝；其他小程序（百度、头条），WebView 仍旧无法渲染为 rom 主题字体。
（3） 稠浊渲染改进方案
既然稠浊渲染有这些问题，对应就会有办理方案，目前已有的方案如下。
方案⓵：创造层级更高的组件既然其它组件无法覆盖到原生组件上，那就创造出一种新的组件，让这个新组件可以覆盖到 video 或 map 上。“cover-view/cover-image”便是基于这种需求创造出来的新组件；实在它们也是原生组件，只不过层级略高，可以覆盖在 map、video、canvas、camera 等原生组件上。
目前除了字节跳动外，其它几家小程序均已支持“cover-view/cover-image”。
cover-view/cover-image 在一定程度上缓解了分层覆盖的问题，但也有部分限定，比如严格的嵌套顺序。
方案⓶：肃清分层，同层渲染既然分层有问题，那就肃清分层，从 2 层变成 1 层，所有组件都在一个层中，“z-index”岂不就可生效了？
这个小目标提及来大略，详细实现还是很繁芜的。
4. 同层渲染抛开小程序当前架构实现，办理稠浊渲染最直接的方案，该当改换渲染引擎，全部基于原生渲染，video/map 和 image/view 均为原生控件，层级相同，层级遮盖问题自然消逝。这正是“uni-app”在 App 真个推举方案。
当前 Web 渲染为主、原生渲染为辅的主流小程序现状，如何实现同层渲染？
基于我们的剖析研究，这里大略讲解一下同层渲染实现的方案，和微信真实实现可能会有出入（目前仅微信一家实现了同层渲染）。
（1） iOS 平台
小程序在 iOS 端利用 WKWebView 进行渲染，WKWebView 在内部采取的是分层渲染，一样平常会将多个 DOM 节点，合并到一个层上进行渲染。因此，DOM 节点和层之间不存在逐一对应关系。但是，一旦将一个 DOM 节点的 CSS 属性设置为 “overflow: scroll” 后，WKWebView 便会为其天生一个 WKChildScrollView，且 WebKit 内核已经处理了 WKChildScrollView 与其他 DOM 节点之间的层级关系，这时 DOM 节点就和层之间有逐一对应关系了。
小程序 iOS 真个同层渲染可基于 WKChildScrollView 实现，紧张流程如下：
创建一个 DOM 节点并设置其 CSS 属性为 overflow: scroll；关照原生层查找到该 DOM 节点对应的原生 WKChildScrollView 组件；将原生组件挂载到该 WKChildScrollView 节点上作为其子 View。（2）Android 平台
小程序在 Android 端采取 Chromium 作为 WebView 渲染层，和 iOS 的 WKWebView 不同，是统一渲染的，不会分层渲染。但 Chromium 支持 WebPlugin 机制，WebPlugin 是浏览器内核的一个插件机制，可用来解析“< embed >”。Android 真个同层渲染可基于 “< embed >”加 Chromium 内核扩展来实现，大致流程如下：
原生层创建一个原生组件（如 video）；WebView 创建一个 “< embed >”节点并指定其类型为 video；Chromium 内核创建一个 WebPlugin 实例 并天生一个 RenderLayer；原生层将原生组件的画面绘制到 RenderLayer 所绑定的 SurfaceTexture 上；Chromium 渲染该 RenderLayer。这个流程相称于给 WebView 添加了一个外置插件，且“< embed >”节点是真正的 DOM 节点，可将更多的样式浸染于该节点上。
四、未来可能如果要磋商小程序接下来的技能升级方向，我们认为该当在用户体验、开拓效率两个方向上努力。
1. 更精良的用户体验先说用户体验的问题，紧张也是两个方面：
办理现有的性能坑点，比如前面剖析的这几项，通讯壅塞、分层限定等，这里不再赘述；支持更多 App 的体验，更自由灵巧的配置，比如，高斯模糊。如果你也想快速搭建的自己的小程序引擎，并更优的办理如上体验问题，该怎么办？
uni-app 发行到 App 端，实际上便是一个完全的小程序引擎，DCloud 会在近期将这个引擎完全开源，欢迎大家基于 uni-app 小程序 SDK 快速打造自己的小程序平台。
uni-app 小程序 SDK 具备如下几个特色：
性能：支持 Native 渲染，扩展 WXS，更高的通讯性能；开放性：更灵巧的配置，支持更多 App 的体验；开源不受限：无需签订任何协议，拿走就用；生态丰富：支持微信小程序自定义组件，支持所有“uni-app”插件，且其插件市场目前已有上千款成熟插件。2. 开拓效率开拓效率该当从跨端、跨云两个维度进行剖析。
（1）跨端开拓目前的小程序都带有明显的厂家属性，每个厂家各不相同。比如，阿里内部有多套小程序（支付宝、淘宝、钉钉等），幸好阿里内部目前已基本统一。但腾讯体系下，微信和 QQ 小程序依然是两队人马，两套规范。
小程序之前是手机真个，2019 年 360 出了 PC 端小程序。
接下来，会不会还有其它厂家推出自己的小程序？会不会有新的真个涌现？比如，面向电视的小程序、面向车载的小程序？
统统皆有可能。
逐水草而居是人类的本能，追求流量依然是互联网的制胜法宝。当前的小程序宿主，都是亿级流量入口，且各家流量政策不同。比如，微信的流量虽然很大，但有各种限定；百度和头条是支持广告投放的，通过广告投放，可以快速得到大量较为精准的用户；百度小程序还有个 Web 化的功能，可以将 Web 的搜索流量，转化成小程序的流量。
面对浩瀚小程序平台及各自巨大的入口流量，开拓者如何应对？
等待 W3C 的小程序标准统一，短期不太现实。当下，若想将业务快速触达多家小程序，借助跨端框架该当是唯一可行的方案。
（2）跨云开拓开拓商借助“uni-app”或其它跨端框架，虽然已可以开拓所有前端运用。但仍旧须要雇佣 PHP 或 Java 等后台开拓职员，既有后端职员本钱，又有前 / 后端沟通本钱。
腾讯、阿里、百度小程序虽陆续上线了云开拓，但它们均只支持自己的小程序，无法跨端，分散的做事器对开拓商更不可取。
故我们认为跨厂商的 Serverless 是接下来的一个重点需求，开拓者在一个云端存储所有业务数据及后端逻辑，然后将前端小程序发行到各家小程序平台，也便是“一云多端”模式。
五、小结基于小程序的现状，我们也容许以总结一下小程序技能上的可能方向：
其它小程序拉齐与微信的差距，让开发者可以做出足够高性能的运用做事；所有小程序应拉齐和 App 的体验差距，虽然功能 API 方面仍有不敷，但操作性能和交互体验，不应该弱于 App；跨端框架 + Serverless，让开发者更轻松，让企业更高效。作者先容：崔红保，DCloud CTO，Uni-App 团队卖力人，开拓了 2 个 Github Star 上万的盛行项目。有 10 年以上研发管理履历，在跨平台引擎、前端 UI、小程序性能优化等方面有丰富的实践履历。
