京东小程序 Taro 开发对比原生开发测评

Taro 已经 100% 支持转换京东小程序，受到了不少同窗的关注。当中有欢呼雀跃的声音：“一键转换为京东小程序，终于能够准时下班啦”。也有对 Taro 不太了解的同窗提出了一些疑问：“转换的效果如何？”、“转换后代码的性能是否达标？” 等等。

针对各类疑问，咱们从性能与开发体验的角度切入，把京东小程序原生开发与 Taro 开发进行了一番对比。

性能对比

针对性能的问题，咱们分别测试了 Taro 空项目的包大小和 Taro 在长列表中的表现。由于包大小会影响小程序的首次加载速度，而长列表则是经常出现性能瓶颈的场景。

Taro 空项目包大小

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

下列图片分别是 Taro 运行时框架压缩先后的大小，能够看到压缩后仅为84k，对主包空间的影响十分小。

压缩前：

压缩后：

长列表渲染表现

benchmark 介绍

咱们参照 js-framework-benchmark 编写了一份 benchmark，测试对比了 Taro 代码与原生代码在长列表场景下的渲染表现。

测速指标

• 初始化：从进入页面开始到完成 40 个商品的渲染。

• 建立：页面 onLoad 后建立 40 个商品。

• 增长：往已建立了 40 个商品的列表中每次增长 20 个商品。

• 部分更新：在 400 个商品中更新每第 10 个商品的名称。

• 交换：在 400 个商品中交换其中两个商品的位置。

• 选中：点击商品图片，改变商品名称的字体颜色。

计时点

Taro：

开始：事件响应函数的顶部。

结束：setState 回调函数的顶部。

原生小程序：

开始：事件响应函数的顶部。

结束：setData 回调函数的顶部。

其它

benchmark 仓库：Github

Taro 版本：1.3.21

测试机型：魅蓝 note

测试方法：每组测试 10 条数据，去除其中最大值与最小值后求平均值

测试结果

由于在京东小程序与微信小程序中，setData 的 callback 的触发时机稍有不一样，因此分开列出。

操做	Taro jd	原生京东小程序
初始化	150	123
建立	87	85
部分更新	125	235
交换	140	213
选中	131	155

操做	Taro weapp	原生微信小程序
初始化	1155	1223
建立	500	408
部分更新	167	307
交换	252	309
选中	193	178

经测试发现，列表的长度会对增长操做的耗时产生影响：列表越长，增长操做的耗时越久。所以不能简单地对 N 次增长操做求平均增长耗时。这里咱们选择使用折线图来展示出随增长操做次数的变化，渲染耗时的变化趋势。

测试结论

建立

在建立时，Taro 会对数据作一些处理，所以会比原生稍慢。

初始化

初始化与建立相比，差异是引入了页面构造耗时。即初始化耗时 = 页面构造耗时 + 建立操做耗时。

Taro 在页面初始化、建立操做时都会对数据进行处理，所以整个初始化耗时会比原生稍慢。

那为何微信小程序中 Taro 初始化耗时更短呢？在 benchmark 中 Taro 和原生分别在 componentWillMount 和 onLoad 渲染列表，而 Taro 使用 Component 构造页面，componentWillMount 实际上是在 attached 生命周期中触发。由于在微信小程序中 attached 比 onLoad 早触发得多，因此会出现如此现象。

选中

由于 Taro 只是把回调函数包装了一层，处理了事件参数和 this 等，因此和原生的速度至关。

部分更新、交换、增长

Taro 的速度会优于原生。缘由是 Taro 会先对将要 setData 的数据和当前 data 的数据作一次 diff，这可以大大减小 setData 的数据量，加快渲染速度。对比两个折线图能够得知，数据量越大，diff 的优化收益也越大。

Taro 对小程序的性能优化

setData

在小程序中，性能的问题主要在于单次 setData 数据量过大和频繁调用 setData 上。Taro 利用 diff 解决了单次 setData 数据量过大的问题，而对于频繁调用 setData 也有解决的办法。

Taro 的 setState 遵循 React 规范，不一样于 setData 的同步更新，它会异步地去更新视图。所以假设开发者在单次事件循环中屡次调用 setState，最后也只会在下一个事件循环中进行一次 setData。

跳转预加载

小程序由 A 页面跳转到 B 页面的过程当中，从 A 页面发起跳转到 B 页面触发 onLoad，有着 300~400 毫秒的延时。Taro 提供了 componentWillPreload 钩子，钩子会在发起跳转后当即执行。开发者能够尽早地在钩子里作一些数据拉取的工做，相比在 onLoad 触发后再去拉取数据就可以节省 300~400 毫秒的延时。

shouldComponentUpdate & Taro.PureComponent

开发者的 Class Component 能够继承 Taro.PureComponent，这样组件在更新前会对新旧 props 和新旧 state 各作一次浅对比，避免没必要要的更新。固然开发者能够本身实现 shouldComponentUpdate，经过手动控制新旧 props 和新旧 state 的对比，决定是否更新组件。

Taro.memo

若是开发者书写的是函数式组件，则能够利用 Taro.memo 实现 shouldComponentUpdate 的相同功能。

开发体验对比

语法

京东小程序的原生语法和微信小程序相仿，都是类 MVVM 语法，没有接触太小程序的开发者有必定学习成本。另外样式语法为 css 的子集，其中自适应尺寸单位为 rpx，这样意味着若是咱们须要 css 预处理器时须要手动配置工做流，而且在编写样式时到处注意尺寸单位的转换。

目前 Taro 遵循 React 语法（未来会支持全部 Web 前端框架），JSX 令咱们的代码更加灵活。所以拥有 React 开发经验的开发者能够立刻上手 Taro 的开发工做。在样式方面 Taro 支持在建立项目时选择是否使用 css 预处理器，选择后会自动配置相应的工做流。对于样式单位 Taro 也会把用户编写的 px 数值自动转换成对应的 rpx 数值，开发者无需再分心处理各平台的样式单位。

项目结构

原生开发中，页面和组件各由4个文件（js、jxml、jxss、json）所组成，代码管理相对麻烦。

Taro 中页面和组件均由一份 js 文件和一份样式文件组成，建立与维护十分容易。

开发生态

微信小程序通过不断迭代，相继推出了插件系统和支持引用 npm 包的功能。但京东小程序暂不支持前二者，京东小程序社区也还没打造起来，开发生态资源十分匮乏。

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

开发辅助

京东小程序原生开发不支持 Typescript，只能在 IDE 的编辑器中有自动补全功能，编码效率不高，同时也容易出错。

Taro 完美支持 Typescript，自带代码智能提示和代码实时检查功能，能让开发效率大大提高。

写在最后

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

最后，欢迎你们来使用 Taro 开发各端应用，有任何开发问题或合做意愿请联系 taro@jd.com，咱们会第一时间回复。

相关连接

Taro 官方网站

Taro 文档

Taro 论坛