微信小程序的原生框架和taro对比

微信小程序的原生框架和taro对比

小程序历史（为何会出现？）

2007年 iPhone H5

你们知道如今手机端主要是iOS、Android两大系统，实际上在早期有3大系统竞争，还有一个就是诺基亚的Meego系统，MeeGo 采用 C + HTML5 的双模应用生态策略，然而 C 的开发难度太大，HTML5 体验又不行，因此后来 MeeGo就掉队了；与之对应，Android 依靠 Java 技术生态，在竞争中脱颖而出。

因而在移动互联网初期，应用生态被定了基调 —— 原生开发。

在那个时候，硬件不行，也没有其余办法，原生开发才能在低配硬件上带来商用体验。

可是 ：你们都在怀念 HTML

- HTML 优势：无需安装更新、即点即用，直达二级页面的特色，一直让人迷恋

- HTML缺点：不止是功能不足，性能体验是它更严重的问题，而体验问题，不是简单地扩展 JS 能力能搞定的。

2013 百度轻应用

方式是经过给 WebView 扩展原生能力，补充 JS API，让 HTML5 应用能够实现更多功能

2015 微信 JS SDK

国内事实上最大的手机浏览器，微信为它的浏览器内核扩充了大量 JS API，让开发者能够用 JS 调用微信支付、扫码等众多 HTML5 作不到的功能。
但每次点击要等半天白屏,让人用着很痛苦

Hybrid 应用

经过工具、引擎优化、开发模式调整，让开发者能够经过 JS 写出更接近原生 App 体验的应用。

Hybrid 应用和普通的轻应用相比，还有一个巨大的差异：一个是 Client/Server，一个是 **Browser/Server。**简单来讲，Hybrid 应用是 JS 编写的须要安装的 App，而轻应用是在线网页。

C/S 的应用在每次页面加载时，仅须要联网获取 JSON 数据；而 B/S 应用除了 JSON 数据外，还须要每次从服务器加载页面 DOM、样式、逻辑代码，因此 B/S 应用的页面加载很慢，体验不好。

但是这样的 C/S 应用虽然体验好，却失去了 HTML5 的动态性，仍然须要安装、更新，没法即点即用、直达二级页面。

那么 C/S 应用的动态性是否能够解决呢？

流应用概念，把以前 Hybrid 应用里的运行于客户端的 JS 代码，先打包发布到服务器，制定流式加载协议，手机端引擎动态下载这些 JS 代码到本地，而且为了第一次加载速度更快，实现了应用的边下载边运行。

就像流媒体的边下边播同样，应用也能够实现边用边下。

2015 第一个小程序 360 称之为 360 微应用

2016 微信小程序，最初的名字其实是微信应用号，以后更名为小程序

再以后阿里巴巴、手机厂商联盟、百度、今日头条，陆续推出了本身的小程序平台，小程序时代滚滚而来

2018年9月，微信率先推出云开发

小程序架构

这是一个比较通用的小程序架构，目前几家小程序架构设计大体都是这样的（快应用的区别是视图层只有原生渲染）

你们知道小程序是一个逻辑、视图层分离的架构。

网页开发渲染线程和脚本线程是互斥的，这也是为何长时间的脚本运行可能会致使页面失去响应，而在小程序中，两者是分开的，分别运行在不一样的线程中。

架构引起的性能坑点

小程序这种架构，最大的好处是新页面加载能够并行，让页面加载更快，且不卡转场动画；但同时也引起了部分性能坑点，今天主要介绍 3 点：

逻辑 视图层 通信阻塞

数据 、组件 的差量更新

同层渲染 和 混合渲染

逻辑层/视图层通信阻塞

咱们从swipeaction这个例子讲起，需求是用户在列表项上向左滑动，右侧隐藏的菜单跟随用户手势平滑移动

若想在小程序架构上实现流畅的跟手滑动，是很困难的，为何？

咱们再回顾一下上面的小程序架构，小程序的运行环境分为逻辑层和视图层，分别由2个线程管理，小程序在视图层与逻辑层两个线程间提供了数据传输和事件系统。这样的分离设计，带来了显而易见的好处：

环境隔离，既保证了安全性，同时也是一种性能提高的手段，逻辑和视图分离，即便业务逻辑计算很是繁忙，也不会阻塞渲染和用户在视图层上的交互

但同时也带来了明显的坏处：

• 视图层（webview）中不能运行JS，而逻辑层JS又没法直接修改页面DOM，数据更新及事件系统只能靠线程间通信，但跨线程通讯的成本极高，特别是须要频繁通讯的场景

基于这样的架构设计，咱们回到swipeaction，分析一次touchmove的操做，小程序内部的响应过程：

• 用户拖动列表项，视图层触发touchmove 事件，经Native层中转通知逻辑层（逻辑层、视图层不是直接通信的，需Native中转），即下图中的⓵、⓶两步

• 逻辑层计算需移动的位置，而后再经过 setData 传递位置数据到视图层，中间一样会由微信客户端（Native）作中转，即下图中的⓷、⓸两步

实际上，用户滑动过程当中，touchmove的回调触发是很是频繁的，每次回调都须要4个步骤的通信过程，高频率回调致使通信成本大幅增长，极有可能致使页面卡顿或抖动。为何会卡顿，由于通信太过频繁，视图层没法在16毫秒内完成UI更新。

为解决这种通信阻塞的问题，各家小程序都在逐步提供对应的解决方案，好比微信的WXS、支付宝的SJS、百度的Filter，但每家小程序支持状况不一样，详细见下表。

另外，微信的关键帧动画、百度的animation-view Lottie动画，也是为减小频繁通信的一种变动方式。

小程序代码构成

• JSON 配置
• WXML 模板
• WXSS 样式
• JS 逻辑交互

目前各小程序都有对主包的大小进行限制，微信小程序限制为 2M。这是由于初次进入的速度对于用户的体验很是地关键，而主包体积越大下载的时间就最长。所以小程序框架的大小也成为了开发前框架选型的重要参考指标之一，假若框架体积过大，就会压缩业务逻辑的可用空间。

数据/组件差量更新

小程序架构存在通信阻塞问题，厂商为解决这个问题，创造了wxs脚本语言及关键帧动画等方式，但这些都是厂商维度的优化方案。咱们做为小程序开发者，在性能优化方面，又能作哪些工做呢？

小程序开发性能优化，核心就是setData的调用，你能作只有两件事情：

• 尽可能少调用setData
• 每次调用setData，传递尽量少的数据量，即数据差量更新

减小setData调用次数

假设咱们有更改多个变量值的需求，示例以下：

change:function(){
    this.setData({a:1});
    ... //其它业务逻辑
    this.setData({b:2});
    ... //其它业务逻辑
    this.setData({c:3});
    ... //其它业务逻辑
    this.setData({d:4});
}
​
复制代码

如上4次调用setData，会引起4次逻辑层、视图层数据通信。这种场景，开发者需意识到setData有极高的调用代价，本身需手动调整代码，合并数据，减小数据通信次数。

部分小程序三方框架已内置数据合并的能力，开发者无需关注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。

组件差量更新

下图是一个微博列表截图：

假设当前有200条微博，用户对某条微博点赞，需实时变动其点赞数据（状态）；在传统模式下，一条微博的点赞状态变动，会将整个页面(Page)的数据所有经过setData传递过去，这个消耗是很是高的；而即便经过以前介绍，经过差量计算的方式获取变动数据，这个 Diff 遍历范围也很大，计算效率极低。

如何实现更高性能的微博点赞？这其实就是组件更新的典型场景。

合适的方式应该是，将每条微博封装成一个组件，用户点赞后，仅在当前组件范围内计算差量数据（可理解为Diff范围缩小为原来的1/200），这样效率才是最高的。

提醒你们注意，并非全部小程序三方框架都已实现自定义组件，只有在基于自定义组件模式封装的框架，性能才会大幅提高；若是三方框架是基于老的template模板封装的组件开发，则性能并不会有明显改善，其 Diff 对比范围依然是Page页面级的。

框架性能 PK (平均值)

包大小：

原生 < Wepy < Taro < Mpvue < Uni-app < Chameleon

微信小程序的性能：

Taro > Mpvue > Uni-app > Wepy > Chamelon > 未优化过的原生代码

框架使用后比原生的性能更好，这简直逆天了，后来研究发现：

微信原生框架耗时主要在 setData 调用上，开发者若不单独优化，则每次都会传递大量数据；而 Uni-app、Taro 等都在调用 setData 以前自动作 diff 计算，每次仅传递变更的数据。

生态

小程序

小程序的逻辑层和渲染层是分开的，逻辑层运行在 JSCore 中，并无一个完整浏览器对象，于是缺乏相关的DOM API和BOM API。这一区别致使了前端开发很是熟悉的一些库，例如 jQuery、 Zepto 等，在小程序中是没法运行的。同时 JSCore 的环境同 NodeJS 环境也是不尽相同，因此一些 NPM 的包在小程序中也是没法运行的。

Taro

中不但能自由引用 npm 包，并且还大量支持 React 社区中沉淀的优秀工具和库，如 react-redux、mobx-react 等。

到这里你们可能会问，Taro 性能真的优于原生吗？其实并否则，针对每一个场景，咱们均可以用原生写出性能最佳的代码。可是这样作工做量太大，实际项目开发中须要掌握效率与优化之间的平衡。Taro 的优点在于能让咱们在书写更有效率的代码、拥有更丰富的生态的同时，还带来了不错的性能。