无线动态化解决方案总结：从WeApp到Weex

2021-09-27 11:55:05

前言

入职阿里的两年时间，有幸一直从事无线动态化解决方案。从最初的WeApp，到现在的Weex，经历了WeApp的从无到有，从“辉煌”到没落，见证了Weex的崛起，在双十一主会场大放光彩。最近，工作方向有所变化，所以从技术角度谈谈个人对无线动态化的理解，同时也算是对我这两年工作的总结。

无线动态化

业务上的变化根本等不及发版解决，这也是出现动态化方案的根本原因。一套优秀的动态化解决方案应该具备:

  • 简单、友好、强大的DSL
  • 强大的开发工具
  1. Debug tool
  2. Native 强大的动态能力和高性能
  3. 跨平台write once，run anywhere(Android、IOS、H5 …)
  4. 完备的发布平台
  5. 规范的开发文档
    ...

native动态化主要做的事情是：

  • 模板动态化和逻辑动态化
  1. 加载性能
  2. 滑动性能
  3. 水平扩展
  4. 接入简单
  5. 无侵入性

...

WeApp

WeApp是一套基于json作为描述语言的跨平台多终端渲染sdk，孵化于无线卖家的业务中。现在回头来看WeApp，有了更深的体会：
在正确的时间做了恰当的事情，采用私有协议进行描述，快速落地，但是做了一年没有调整方向（没有转换成标准协议，没有彻底解决逻辑动态性），最终没落。究其原因：

  • 技术视野，当初的技术视野受限
  1. 被业务侵入严重，积重难返
  2. 架构缺陷，native做的太重（自己写了不太好用的condition等），动态性弱
  3. 没有解决“写”的问题，json作描述语言，很难编写和维护
  4. 渲染性能，往往实现一个复杂点的组件需要10几层的view，导致滑动性能下降
  5. 没有好的开发工具

直到react native的出现才恍然大悟，原来还可以这么玩，把动态性玩的这么彻底，长恭老板的破而后立，这才有了后面的Weex———欲练此功，必先自宫（葵花宝典就是这么练成的）
最后说一句，WeApp是历史时代的产物，它在当时也支撑了很多业务发展，同时也踩过很多坑，积累了大量无线动态化的经验。

Weex

Weex本身不是新的技术，而是集大家之所长，react native思想和设计（非常关键）、flexbox布局、v8引擎、vue.js和mvvm的思想组成了最终的Weex主体结构。Weex从最初的所有的方案设计都会拿WeApp的痛点作为参考.
Weex native总体架构（以手淘为例）

  • SDK:专注渲染，只依赖fastjson
  1. UI Kit：native的一些通用业务组件，如跑马灯，电梯头等
  2. Adapter：三方App的适配器，接入自己app的网络层、埋点工具、导航系统，图片库等

  3. Bundle：包含页面容器，拦截规则，模板缓存等
    无线动态化解决方案总结：从WeApp到Weex

                                                     Weex总体架构图

Weex 渲染机制（同步和异步）

同步机制

原理：同步机制原理比较简单，JS Framework一次性创建所有的Dom树，完成渲染。

不足：当进入A(Weex页面)后，快速进入B（Weex页面），A页面没法响应点击操作，返回也不能停止渲染，导致JS Thread 一直渲染脏数据。

适用场景：Native局部使用Weex instance，并且DOM节点较少（不超过100）

异步机制

原理：采用流式渲染和离屏渲染。

流式渲染:即JS Framework每创建一个节点，立即发送给native，同时等待native的next tick命令的触发才能继续执行，这样就有效的解决了页面回退仍然在渲染，事件不能响应的问题。

离屏渲染:，即用户在浏览页面的过程中，后台Dom线程继续渲染更新页面，将所有addDom、updateSytle等操作都以最小颗粒度拆分，保证所有的操作都在16ms内完成，大大提升首屏的加载性能以及滑动的流畅度。
无线动态化解决方案总结：从WeApp到Weex
异步渲染机制（摘自Weex首架@伊耆）

踩过的坑：

  • json解析。同步渲染中，会将DOM数据一次性发送至native，过大的json数据解析会大大降低加载性能（30kb数据解析需要150ms，手工加入asm后会提升20%～30%性能）
  1. 懒加载坑（潜在风险）。页面加载只加载1屏高度的页面，当用户滑动底部加载下一页数据，当用户不滑动时，JS将某个组件给remove掉，导致不满一屏高度，页面滑不动。
  2. duktape引擎。最初由于包体积的问题，我们用的不是v8（arm zip1.6M，x86 zip 2M）这是一个标准的轻量级的js引擎，但是3000个节点压测，JS执行需要8s。
  3. 滑动流畅度。懒加载会导致加载下一页时的大幅度丢帧，因为这一操作没办法在16ms内完成
  4. 首屏加载体验。首屏加载的体验很大程度受到节点数的影响
    最终的优化方案都是通过一个个坑踩出来的。

动态JS

Weex除了做渲染之外，还可以通过注册Module的方式，执行动态JS逻辑，比如通过JS动态规则下发等逻辑动态性，此处有潜在风险，由于Weex全局只有一个Context，所以最好不要写全局的function，防止影响到Weex相关数据（这个很危险，有可能导致整个Weex不可用，问题还很难查）,真要用的话，最好写到某个Object中，如var mapping = Weitao.mapping(){}。

结尾

最后，期待@勾股和@鬼道将Weex继续搞大，唱响全球。

Weex总体介绍有技术细节，请参考Weex总架前端大牛@勾股的三篇连载，或者直接骚扰他也行。附上链接

上一篇：SpringIoC&DI


下一篇：前端路由传参，参数乱码不能刷新