Weex详解：移动端高性能动态化方案

Posted 2021-04-29 移动开发前线

在4月份的QCon北京2016上，阿里巴巴资深总监，淘宝移动平台及新业务事业部、阿里百川负责人庄卓然（花名南天）宣布阿里移动端跨平台开发框架Weex开始内测，并将于6月份开源。在大会第二天，阿里技术专家徐凯（花名鬼道）和阿里前端开发专家赵锦江（花名勾股）向参会者做了《Weex——灵活的移动端高性能动态化方案》的演讲，对这一技术方案进行了详细的剖析。

对于Weex不了解的同学可以先看看。

以下为演讲内容的整理：

Weex早在2015年底即对外宣布，大家都很想看看它的真容，仅一天的时间，申请内测用户突破1400人，显示大家对它感兴趣的程度。

在淘宝无线团队对移动开发最佳实践的思考中，他们认为移动开发的未来一定是性能和动态性兼得。并且，和PC端一样一定是开放互联的。移动互联网将来将基于更大众化的技术体系，没有android、ios等平台之间的隔阂，简单直接易用，这是开发者所希望看到的。基于这些设想，淘宝无线团队开发了Weex方案。

Weex从去年双十一的时候第一次在正式产品中使用，承载了双十一主会场的工作。除此之外，从去年双十一到现在，Weex在阿里内网做开源内测活动，大家贡献了很多内容，包括南天在QCon Keynote演示的僵尸动画、扫雷、计算器等等，Weex适用于各种多变的场景，不仅仅是做电商主会场的技术方案。

移动端开发模型最佳实践

下面介绍的是Weex团队对移动端开发模型的理解。

今天很多移动App在架构的演进中，逐渐形成这样一个最佳实践，即首先把移动端所有界面拆分成各个Page，中间有一个路由的控制逻辑。同时需要移动端各种各样丰富的能力，这些可以通过API的形式提供给开发者。这是他们认为一个比较理想的开发模型，也将这个模型用到了Weex当中。

从开发模型来讲，Weex团队倾向于使用标准化的一些东西，包括html、CSS、JS这些前端快速易用好学的语法作为一个开发体验，提供给开发者。它们的语法设计尊重了Web标准，包括核心源代码都是从Vue.js——一个非常优秀的MVVM前端框架来的。最近Vue.js 2.0发布，其中就专门提到了Weex。

Weex的组件化与DSL语法

编写Weex应用，首先需要熟悉的是它的DSL语法。Weex编写的页面天然的支持组件化，首先，一个复杂界面可以分成多个组件，每个组件都可以看成是一段template，style，script，放到模型里，对应界面的结构，样式细节，行为定义。在View里面Weex倾向于把数据和视图当中需要展示和需要有动态变化的部分做一个数据绑定，绑定之后如果想更改界面的话，通过改变数据就可以做到。这就是MVVM，是从Model到View非常顺畅的控制逻辑和代码方式，也算是Weex上层语法设计的基础。

如果做的界面比较复杂，可能有更多细节，或者做更多分解，需要从整体上对整个界面以模块为单位作为拆解，对每个模块做定义，如果界面足够复杂，可以先拆成组件，再把每个组件具体内容进行定义。定义方式就是通过结构、样式和行为角度对它进行定义，通过有机方式把这些组件结合起来，最终完成页面开发。

上面是Weex的关键语法简述。首先看看template，大概有几个元素。首先是virtual DOM tree虚拟DOM节点树，包括事件绑定，组件跟组件之间可以嵌套，以及子元素。再往下是style，一方面可以把共用样式抽样出来，另一方面可以让template结构更加清晰，不至于陷入到整个具体样式描述当中去。Weex在这里相对传统CSS做了一些削减，只支持了单个class的selector写法，这主要是处于性能的考虑：传统的CSS可以理解为是一个N对N的数据库，匹配过程非常复杂，性能也得不到非常好的保证，把selector约定在单个class，性能可以得到保证。

另外，Weex的样式天然默认的就是scoped（即作用域位于组件内部），可以放心定义各种各样的classname，不用担心和其他组件相冲突。全局冲突是CSS“七宗罪”中的一个，Weex团队在设计的时候非常重视这个，所以在实践上把它定义为默认scoped。

通过DSL可以把一些常用的组件封装起来，方便开发者调用，目前Weex已经支持的组件包括：

• <div>：容器组件
  

• <scroller> ：滚动条组件
  

• <list> & <cell>：可以自动做内存与资源管理的列表组件

• <text>：文本组件

• <image>：图片组件

• <slider>：一个性能比较好的滑块组件

• <input>：实验性支持的输入组件
  

这些组件都是可扩展的，业务方可以编写自己的组件，也可以定制内置的组件。

样式部分Weex支持flexbox，这是非常灵活通用便捷的布局方式，有了flexbox，只要你的界面可以拆分成豆腐块的，都可以用flexbox来做。同时Weex团队还支持了fixed和sticky两个特殊布局，sticky意思是如果有一个列表分类，比如联系人ABC字母滚到屏幕外，会停在最上面，那个效果就是sticky，当你划走它就会跟着走，在各种应用中是一个比较常见的样式。

对于事件的支持，Weex支持click、appear、disappear、change等事件。click是基础事件，change在表单的值改变和滑快的第几帧改变时都会有，同时加入了appear和disappear，当组件通过任意操作进入屏幕区域内，会触发appear事件，退出屏幕区域会触发disappear事件，非常适合用在一些lazyload之类的逻辑场景。这些事件也可以在各自组件中做横向扩展。

最后是Weex DSL中最重要的<script>组件，负责绑定数据与视图，同时给组件添加事件和方法。其中最主要的是data和methods，值修改之后相应数据绑定的值也会发生改变。除此之外提供了生命周期的方法，如创建时（init），数据监听完成时（created），渲染完成时（ready），这三个方法同样写在data和methods下面。

另外，Weex也提供了一些原生API，可以直接调用系统UI组件。

利用DSL和各种组件，我们可以搭建复杂页面。通过定义子组件，比如一个foo组件，通过foo标签就可以把foo嵌入到别的组件中来，数据传递的话就可以在foo组件中写a和b，foo元素就可以通过这种方式传递给子元素，然后进行处理。再是组件中间的通信，也是事件机制，每个组件可以通过$on和$off，对自定义事件进行监听和解绑定，想触发事件也有三个方法：$emit只传给自己、$dispatch向上冒泡给所有父组件、$broadcast广播给所有子组件，这些设计和Vue非常相近的，做到组件之间的通信。

除了刚才介绍的这些特性，Weex未来还会提供更丰富的场景，如表单、动画、手势。另外，Weex还在完善更多的资源、工具以及更好的开发体验，提供给所有开发者。

Weex的工作原理

上面这张图展示了Weex的工作原理。最上面是DSL，往下到Virtual DOM和Render层，可以同时渲染成Android、iOS和H5三个平台的UI。

把刚才这张图再稍微展开一下，最上面是DSL，一般叫Weex文件，通过transformer转换为JS Bundle，部署到Server，服务端就完成了。由于转换在服务端就已经完成，不用担心这个转换在客户端是不是有性能问题。

到了客户端，第一层是JS Framework，包括JS引擎与JS-Native的桥接，最后到 RenderRengine，即Weex的工作流程。

有人可能好奇JS Bundle是什么样的，它其实就是将DSL中的template类型和子节点都用JSON表示出来，将classList转化成基本语法约定，而script脚本则基本不变。

Weex的性能、扩展以及可用性

Weex的性能到底如何，是大家关注的热点之一。Weex团队内部做了与React Native对比的一些基准测试和压测，下面是测试结果。

首先是性能，Weex内部有这样一个压测页面，包括3000个节点的渲染，大概10屏，一屏有三个卡片，一个卡片有100个节点左右。第一个性能对比是加载时间，同样一个页面1300、 1600，也不算特别大，20%左右，帧率大概差开一帧，scroller差不多，内存因为Weex用了RecycleView，内存占用会好一些。再往下是CPU，静默CPU消耗，还有运行过程中CPU的峰值。静默CPU接近0点几，这里没有做16毫秒的轮循，如果做16毫秒轮循CPU会更高一些。

这是一个真实业务数据，是一个活动页面，3月份新风尚的活动，这个活动页面没有用List，没有特别做内存对比，这两个设备定义为低端机，帧率差压比较明显，无论是数据还是实际中的体验，流畅性大概是这样的差距。Native UI开发中通常没有JS资源在服务端加载，Weex以及类似动态化方案有一个副作用，有一个JS必须从服务端下载，把JS内置到客户端里，免除下载的问题，这里涉及到一整套的策略，开发起来还是比较复杂的，后面Weex会把这套策略开放出来。

下一个是兼容性。Weex的API尽量向后兼容，避免升级框架导致的兼容性问题。

再就是扩展性，Weex的组件、模块都支持扩展，官方也提供了扩展的示例代码，不过编写扩展需要一些原生开发能力。

这是Weex的核心模块之一App Framework的架构示意图，App Framework对各种底层模块进行封装，同时提供硬件和一些第三方的开发功能，给开发者提供尽量方便的开发体验。淘宝实现的API统一命名为TBxxx，开发者也可以使用自己或者第三方API覆盖掉默认实现。

最后是可用性。红色代表完成的，黄色是在6月正式开源前会完成，剩下是内部正在讨论以及会安排时间逐步完成的东西，这些都是工具。第一个是在Weex官网上提供的一个playground，有自带的examples。第二个是调试工具，chrome dev tools常见的功能里面都有。再是脚手架，大家如果只是玩玩的话用playground就可以了，如果自己做一个独立的App，用脚手架会方便很多，包括各种一键生成工具。后面的不多介绍了。

Weex的集成方式

目前Weex有三种集成方式：

1. 全页模式

   目前支持单页使用或整个app使用weex开发（还不完善，需要开发router和生命周期管理）这是主推的模式，可以类比RN。

2. Native Component模式

   把weex当作一个iOS/Android组件来使用，类比ImageView。这类需求遍布手淘主链路，如首页、主搜结果、交易组件化等，Weex团队和业务同学沟通下来这类Native页面主体已经很稳定，但是局部动态化需求旺盛导致频繁发版，解决这类问题也是Weex的重点。

   这也涉及到如何让Native同学快速上手“准Web”开发，欢迎大家多给些建议。

3. H5 Component模式

   在H5种使用Weex，类比WVC。一些较复杂或特殊的H5页面短期内无法完全转为Weex全页模式（或RN），比如猫超、互动类页面、一些复杂频道页 等。针对这个痛点我发起过WVC项目，并在实际业务中验证了这样的想法：在现有的H5页面上做微调，引入Native解决长列表内存暴增、滚动不流畅、动 画/手势体验差等问题。

   WVC将会融入到Weex中，成为Weex的H5 Components模式。
   

这3种模式几乎涵盖了淘系业务上的动态化需求（针对Native）或体验提升需求（针对H5）。更有趣的是这3种模式的技术基础是一致的，这非常重要，意味着：业务方可以使用Native或H5 Component模式解决实际的业务痛点，同时平滑过渡到Weex全页模式。

由InfoQ主办的GMTC全球移动技术大会将于6月24日在北京召开。来自淘宝Weex开发团队，负责Weex AppFramework架构设计的技术专家宁栗（凝砺）老师将向参会者分享《Weex AppFramework架构设计和独立App构建实战》！目前8折优惠期间，多人团购更多优惠，欲购从速！

点击阅读原文可进入大会官网购票。