Weex：满足万物互联的移动端技术解决方案

吴志华(阿里花名天施)，阿里巴巴资深无线技术专家，淘宝移动平台基础平台部负责人，国内较早投身移动浪潮的老司机，参与业界多个超级 App 架构和研发工作，2014年底加入阿里巴巴，目前负责阿里移动基础技术平台、Weex 项目、百川移动云等研发建设工作。Archsummit深圳2015移动专题优秀出品人、QCon上海2016 移动专题出品人。

Weex项目是以Web的方式来开发Native APP，遵循Write once, run everywhere的原则。它在阿里内部，已经从一个技术项目变成一种技术生态，由多个部门一起来完成。吴老师所在团队负责Weex内核、前端JSFramework，包括工具体系和下层的V8引擎，Weex内核研发机制可以比肩主流浏览器的内核机制，这是Weex跟同类竞品的最大区别。因为同行没有做世界级浏览器的经验，可能不能很好保证内核的稳定性等，而这块Weex和 UC 浏览器有很好的合作。除了前端的JS&Web框架，他们团队的成员还在做UI库，就是基于SUI有一个Weex版本NEXT，上面有轻量级的框架，对于一些商家会提供企业级的解决方案。还有就是移动端实现互动的能力，游戏的能力、3D的能力，VR的能力等。

基于这些方面，阿里巴巴已经初步形成了一个技术生态，从数据上来看，当他们4月21日宣布开源内测的当天就有大量的开发者涌入，两周内就有5000多开发者申请。到6月30日正式开源时，Weex当天登上github trending榜榜首，开源第一周都在trending榜上。截止8.26已经达到5500多个STAR。另外，整个项目从来自外部的PR来看，数据上500的PR，来自外部占到1/5的比例。开发者与项目组成员经常在issue里讨论技术需求，有些已经在公司的业务正式用上Weex并业务并上线。这些都说明Weex的开源已经初步形成一个健康的生态体系。

谈到Weex项目与竞品特点的区别时，吴老师主要谈到如下五点：

第一，他们坚持在中国的互联网环境下，让一份代码在三个端(Android、iOS和H5)的运行体验一致，帮助创业者节省成本。

第二，真正做到浏览器内核级的稳定性和研发机制，最终实现可收敛。

第三，实现高性能和持续稳定性的运行保障机制。

第四，是在中国场景下，Weex支持灵活的嵌入方式。它可以是一个页面，也可以构建一个APP，也可以成为一个内核APP的界面。Weex团队坚信在中国，先把页面做好，再做好整个APP，对开发者工程体系和新的框架影响将非常大，这也是他们的最大优势。

最后一点是阿里巴巴是全世界范围内最大规模复杂业务场景下，应用移动客户端动态化技术的公司，无论是手淘航母还是集团APP正处于业务逐步Weex化的阶段，今年手淘、天猫的大促会场基本也都是由Weex来承载。经过这半年的实践，不断地尝试和放大应用范围、复杂度，Weex项目团队已经探到了并解决了在大规模复杂应用场景的一系列技术难题，发现了不少同类竞品没有发现和解决的问题。

阿里淘宝的双十一大促，面对流量瞬发、网络拥堵和商户的需求，特别是在移动端购物行为的养成过程中，如何更好地满足用户的购物体验?

吴老师讲到双十一是一个大事件，从大的层面上来讲，这两年比较关注的是异地多活，多机房，就是一个机房怎么切换到另一个机房。举例来说，2015年，吴老师主持的阿里统一网络接入的ACCS项目，从技术层面上分为几个方面：第一个是在部署层面的容灾、异地多活。针对交易的单元化和非交易业务的容灾，防止极端情况的出现。第二个，支持十亿级设备接入的网络统一接入层和对突发流量设置防刷限流机制，防止流量顺发和恶意请求。第三是客户端层面的灵活请求策略和云端一体的控制能力，在极端情况可以对客户端请求频率和策略进行控制，在尽量保证高优先级请求的前提下进行柔性处理。

还有移动端购物这块，今年他们尝试比较多，目的是通过一个新的互动形式让大家有不一样的互动购物体验，使人和人之间的距离拉得更近，既可以看到主播展示商品，跟大家互动，又在内部通过很多技术实现来保证用户购物的顺畅体验。具体涉及的技术有：

1.保证购物过程的性能和稳定性，相关指标有启动到首页渲染完成的时间分布占比、Crash率、页面打开的耗时、内存、帧率。

2.网络传输1秒钟法则和请求成功率持续优化，保障网络传输的可靠必达。

3.H5和Weex的秒开，提供用户体验和提高速度。

4.多媒体和直播等内容升级、buy+等创新探索，带给用户不一样的购物体验。

5.最后就是淘宝谈得比较多的社区化和内容化，让消费者在购物的同时购物决策更多样化。

在Weex项目的开发过程中，Weex项目遇到的重要技术更新包括：

1.性能迭代优化。持续一年的性能迭代，纬度细化到启动、首屏渲染、滚动帧率、内存及增量、CPU峰值/均值/静默，同时针对 Android/iOS的低/中/高端机不同机型多次迭代优化性能，确保即使在Android 低端机上也能拥有接近native的体验。

2.前端语法的持续迭代。语法糖和能力更丰富，更方便开发者，新增支持inline event、基于WebPack的loader机制、computedproperty、repeat语法扩展等。

3.页面级导航方案。通过Weex Navigator组件，支持大规模线上活动间的跳转;通过TabBar提升页面切换的体验。

4.调试工具Devtool：通过 Chrome Devtool直接调试 Weex Android/iOS代码，支持 Element(BoxModel/NativeView)、Console log、Network、ScreenCast;同时支持多设备和多 APP 同时调试，支持JS代码断点调试。

同时，吴老师详细分享了其中一个重要的技术解决方案：页面级导航方案

初始选择：在单页多视图导航和多页面导航之间，项目组选择优先实现多页面导航，更加符合大规模应用的场景，减少页面间的耦合，提升整体的稳定性。

技术方案包括：

1.导航控制器

(1)NavigationBar:栈式导航，支持 push/pop，可定制的NavigationBar样式。

(2)TabBar:引入embed组件，支持内嵌多级Weex container instance(以下简称 instance)，实现可由前端自定义的TabBar组件，且instance之间可相互通讯;TabBar具有高度的可定制性，多级tab页面对应的源文件分离并可按需加载。

2.应用生命周期

(1)从页面的维度考虑，基本可分为init、ready、viewappear、viewdisappear和destroy几个关键时间节点。

(2)从应用角度考虑，又会融入前后台相关foreground、background以及内存相关memoryWarning等，需要暴露以上注册接口给前端来做必要的操作。

3. 数据通讯

(1)通过消息分发的方式，建立消息监听模式，优点是隔离性比较好，无需关注对象的上下文，比较适合多级页面之间进行通讯。

(2)建立 instance 之间上下文之间的关系，适合内嵌instance的场景。

Weex项目很大的技术难点是大规模复杂场景下的性能和稳定性保障、持续的三端体验一致的保障机制，尤其是双十一场景下Weex的稳定性。

这个其实是一个复杂的系统工程问题，从V8/JSCore引擎的优化，从native层性能调优再到上层的JSFrm框架的性能和易用性，配套CI和自动化测试机制。项目组希望建立一套类似Webkit内核的性能稳定性保障机制，保障三端体验一致的机制(渲染、排版体验一致，提供图形化自动对比能力)、前端框架配套的Profile、Lint、内存泄露排查工具，在Weex建立起来一套自动化的平台研发保障机制。这样才能保障Weex类似WebKit一样能够持续交付稳定可靠的版本，这个也是Weex跟竞品在理念上的大差异，可以走的更稳健一些。

Weex项目的发展目标分为两个方面，对内和对外，对内的一个基本目标是在8-12月，阿里巴巴移动业务全部实现Weex化。希望Weex能力不仅仅局限在手机端，也能够拓展到万物互联多个设备端。对外来看，Weex能不能成为业界真正值得信赖，真正被开发者认可的移动端跨平台的解决方案，这个挑战也很大。实现过程是把过去前端优秀的基础能力、工程体系完全继承到移动端，把整个一套方案开源开放给业界，和业界开发者一起来共建，追踪并过渡成业界，最终将Weex建设成为大家信赖的万物互联设备的技术解决方案。