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

前言

入职阿里的两年时间,有幸一直从事无线动态化解决方案。从最初的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


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