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

首先是性能，我们内部有这样一个压测页面，我们同学把benchmark放在Playground，大家如果下载是能够看到的。在我们内部做压测的时候调到三千个节点，大概10屏，一屏有三个卡片，一个卡片有100个节点左右。我们看一下数据，第一个性能对比是我们的加载时间，同样一个页面1300、1600，也不算特别大，20%左右，帧率大概差开一帧，scroller差不多，内存这块会好一点，因为我们这边用了recycle view，会好一些。再往下是CPU，静默CPU消耗，还有运行过程中CPU的峰值。静默CPU接近0点几，我们不做16毫秒的轮循，如果做16毫秒轮循CPU会更高一些。

这是一个真实业务数据，3月份页面上线之后我们看了一下，这张页面是一个活动，3月份新风尚的活动，这个活动页面没有用List，没有特别做内存对比，这两个设备定义为低端机，帧率差压比较明显，无论是数据还是实际中的体验，流畅性大概是这样的差距。我们说性能往往都会提到帧率、加载时间，但往往会忽略一个事情，Native UI开发中通常没有JS资源在服务端加载，Weex以及类似动态化方案有一个副作用，我们有一个JS必须从服务端下载，我们把JS内置到客户端里，免除下载的问题，这里涉及到一整套的策略。我们内部有一套机制，之后会把这套机制作为独立的技术产品开放出来。

下一个是我们的兼容性。兼容性不只是对Weex，对偏内核型项目都会有这个问题，举一个Weex例子，第一排是我们的业务代码，再往下看，上面两次变迁，一直到客户端，整个场景会变成N的立方。举一个具体数字，我的业务代码改了三个版本，（英文）三个版本，最后会有三的立方27个场景。兼容性是我们一直重视的问题。我们做了几件事情，首先单测保证，包括JS和H5的单测，保证最最基础的UT本身带来的含义。第二个是JS单测环境，我们一般会将（英文）跑在（英文环境下，但和JS安全还是有差异。再往下是自动化工作，这块工作细分也可以分成两块：一块是我们针对截图比对，比如我们同学会说我们设置了很多各种各样细节属性，怎么说你渲染出来的就是你实际想要的，通过API级别的效果不是很好。所以这种我们会通过截图，将最终产生的结果和我们意料中的结果进行图形比对，比较老的成熟的内核上面做的比较成熟，也会有一些借鉴。另外是layout results，相当一部分，包括model，包括其他的布局类的，其实我们完全可以通过一个元素，最终它的宽高，左上角的点，通过基本的信息，让它完成测试的过程。所以我们经过这两块工作，一旦成熟，我们会尽快放到上面。

再就是扩展性，我们先回顾一下这张图，前面也有提到，目前Weex给大家直观的感觉是可以用Weex写很多页面，有一个路由机制，内部叫导航，帮助你将页面进行串连，我们提供很多features，由这样的形式构成Weex大家所看到的一个结构。细分来看，如果你扩展一个component，特定的一些方法，使用anotation标识输入输出参数。这是一个module，在DSL上看到的是API，底层就是module。如果扩展module也是一样的，这是很简单的跳转，基本信息带上去，实现业务功能，一个module就完成了，很简单。

这是路由，整个路由在APP Framework中只是一个环节，所以接下来的规划还是有许多东西需要做的，单独看components这块，包括前面两个，再往下是lifecycle考虑，再是动画跟手势，这块我们觉得都是最基础的东西。再往下是全局的多个Weex容器之间通信机制，数据存储、网络，包括下面涉及到的一堆传感器，包括基础的FS，还有偏业务类的东西，整个东西都有同步在做，但现在的工作集中是在这块。回到刚才的老问题，如果我们开放一个module，上层提供API，中间提供adapter，如果提供自由实现就将默认的覆盖掉，比如手淘里面（TBxxx），把默认页面覆盖掉（WXxxx），对大家来说在已有能力增强，或者是增加新的组件，或者是新的module上，目前已经达到这个状态。

最后是我们的可用性，前面说的比较多，这块秀几张图就好了。这是我们的工具链，红色代表完成的，黄色是五月份、六月份就会完成，在六月正式开源之前。剩下一些东西是我们内部正在讨论以及会安排时间逐步完成的东西，这些都是工具。我们首先给大家提供一个playground，可以扫码，也有自带的examples。第二个是调试工具，chrome dev tools常见的功能里面都有。再是脚手架，大家如果只是玩玩的话用playground就可以了，如果自己做一个独立的APP，你要用Weex做的话我们也会给你提供脚手架。我们的规划中独立项目，不是最终的名字，最终会有一个类似APPHub的工具。包括信息察看，在界面上展示结构。这是刚才提到的例子，这个是playground里面的，虽然截图是iphone效果和android是完全一样的，已经用Weex现有功能做出比较好玩的组件库。然后是我们的文档，包括项目guide、reference、toolchain，细节我不多说了，大家可以去看看。

Weex的集成方式

目前Weex有三种集成方式：

全页模式 

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

Native Component模式 

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

o 这也涉及到如何让Native同学快速上手“准Web”开发，有意思的话题，大家多给些建议。

H5 Component模式 

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

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

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

最后是我们过去双十一到现在大概五个多月时间做的一些事情。首先我们做了原型版本，再将原型版本独立出独立客户端可使用的SDK，扩展样式和布局，将基础的component做了扩展，这两个月集中在工具，还有open source上的工作，最后是六月底就会开放出来。

阿里百川（baichuan.taobao.com)是阿里巴巴集团“云”+“端”的核心战略是阿里巴巴集团无线开放平台，基于世界级的后端服务和成熟的商业组件，通过“技术、商业及大数据”的开放，为移动创业者提供可快速搭建App、商业化APP并提升用户体验的解决方案；同时提供多元化的创业服务-物理空间、孵化运营、创业投资等，为移动创业者提供全面保障。

（编辑：PHP编程网 - 湛江站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!