Weex 在饿了么前端的实践

内容来源：2017年4月8日，饿了么前端资深工程师在“第二届中国前端开发者大会-高效前端开发实践和创新”进行《Weex 在饿了么前端的实践》演讲分享。IT大咖说做为独家视频合做方，经主办方和讲者审阅受权发布。
阅读字数：1888 | 3分钟阅读

摘要

Weex方案轻量，高性能，可扩展的特性可以提高饿了么一些业务的体验。于是咱们作了些尝试和积累，给你们分享饿了么在 Weex方面的开发，文档，缓存，监控相关的经验。

嘉宾演讲视频及PPT地址：t.cn/R0wvUjj

饿了么前端场景

大量的在WebView中使用页面，Vue开发者多于React开发者。页面中和店铺页面、活动页面相关的比较多，并且活动更新会比店铺更新多一点。

移动端业务中大多追求页面的轻量与流畅，HTML5的性能瓶颈为人诟病已久，最为明显的问题是加载性能。

React Native?

在“蜂鸟配送”等APP中使用React Native来快速更新APP，积累经验。

对于咱们的场景来讲，React Native的列表占用内存过大，没有复用机制，会占用愈来愈多的资源。

ReactNative不一样版本之间的breaking change太多，后期维护成本太高，并不适用于饿了么这个体量的APP。

Weex

Weex的构架主要是有一个JavaScript Runtime，底层是iOS、Andriod和H5的渲染引擎，经过JavaScript Runtime和Native渲染引擎之间发生事件进行通讯。

上层是JS Bundle，经过webpack打包出来的JavaScript代码。在前面开发者编写的主要是Vue语法。

Weex是一套构建高性能、可扩展的原生应用跨平台开发方案。它的特色是轻量、可扩展和高性能。

Weex的体积小、语法简单、易于掌握是经过Vue来达成的。还能够利用Native代码经过编写Native组件在JavaScript中调用扩展定制原生组件和功能。加载时间和资源占用的深度优化对listview的优化和启动页面的速度会比较明显，总体来讲它的体验会相对来讲好一些。

开发Weex页面

咱们通过一些探索后开始尝试把原来用H5作的一个WebView页面替换成Weex页面。

Weex试验页面

Weex的页面相对来讲简单一些，交互量比较少，访问量大，便于咱们收集反馈。由于这个页面原来是基于Vue写的，迁移比较方便。

具体工做

业务的实现：基于Vue版本，投入一我的，用时3天左右。

Weex的报错和性能监控：前端和APP方配合，大概须要两周左右。

Weex的降级策略：这个是咱们和APP方讨论后得出降级方案，主要由APP方来实现。

当时整个过程从立项到上线大概花了三周的时间。从效果来看，发现页的Weex版本性能很是优异，相对原来H5版本，页面打开速度变得很是快。后面咱们也有计划逐步接入更多页面。

Weex开发体验

由于Weex是基于Web技术，学习门槛相对原生开发要低不少。

Weex仅有Flexbox布局，text没法嵌套，难以实现长文当中样式的混合。

NoCookies.只能用storage来完成对应信息的存储。

三端一致性不彻底，特别是HTML5支持不完善。

CSS和Web当中存在差别。

DevTools的成熟度不够，热替换不够强大。

相对Web而言组件的丰富度不够。

整体的来讲就是Weex有不少Web开发中的习惯，但在不少方面只是支持了一些子集或本身强化过的部分。

Weex页面性能

{ “JSLibInitTime”：“157”, “JSTemplateSize”：“65”, “SDKInitInvokeTime”：“7”, “SDKInitTime”：“231”, “communicateTime”：“146”, “networkTime”：“0”, “totalTime”：“184”, “fromCache”：true }

SDKInitInvokeTime也是SDK初始化方法调用时间，初始化时是异步进行的，因此SDKInitTime会比较大。

SDKInitTime是SDK启动初始化时间，应该是一次性的开销，不是每一个Weex instance的开销，第一次启动执行。

communicateTime是Weex实例的建立时间，如今的用法每次新建页面都会建立新的实例。

screenRenderTime是首屏渲染时间。

TotalTime是完整渲染时间。

NetworkTime网络消耗时间（本身实现）。

FromCache代码是否来自缓存（本身实现）。

在Android平台上渲染时间大体在450ms，在iOS上的性能更好一些，页面也相对简单，渲染时间只须要160ms。

降级方案

咱们的降级方案是在APP里进行控制的。咱们会给一个APP提供一个配置文件，而后它根据这个配置文件决定这个页面是否经过Weex来显示。

为了保证不影响用户的使用，咱们采起的灰度策略是在支持Weex的APP灰度发版以后，咱们在业务低峰期的时候开启这个开关。

经过咱们接入的监控平台，，咱们能够及时对Weex页面的错误进行监控，若是出现大规模报错，则会当即把支持Weex的开关关闭。

开关配置文件

{  “url”： “https://www.example.com/discover/index.html”, “weex-url”：“https://www.example.com/discover/weex.js”,  “weex-enabled”：true,  “weex-minimal-version”：“0.8.0” }

url：Windows使用的Web页面的地址，当weex-enabled为false的时候，会使用这个地址打开一个WebView。

Weex-url：Weex资源所在的位置，正常状况下使用此URL下载Weex使用的JavaScript文件。

Weex-enabled：boolean类型，默认为false，当此属性为true的时候，才会使用weex-url加载一个WeexView。

Weex-minimal-version：字符串类型，表明了加载weex-url须要使用的Weex的最低版本，此属性必填，若是不填则weex-enabled不生效。当APP中的Weex SDK版本比这个版本低的时候，则会fallback到WebView的形式。

Weex的版本兼容性优异，咱们从0.8.0升级到0.10.0的过程当中，尚未出现须要降级的状况。

在学习成本上，React Native比H5和Weex要高；

测试方面，React Native和Weex的弱交互性能比较好。可是在强交互方面，React Native性能最佳；H5能实现，性能差；Weex则还存在一些相对较弱的方面，部分拖动的相关效果没法实现。

ReactNative在兼容性方面并无那么好。

使用React Native须要熟悉React全家桶，这个学习成本比Vue高很多。

Github上有一个用React Native高仿Eleme APP的实现，大部分效果都能实现；基于咱们对Weex的理解，Weex实现拖动部分交互很是困难，甚至目前的版本不可能实现。

关于React Native的Breaking Changes，能够经过Google搜索“React Native放弃”，能够搜到大量的文章。

从咱们的实践上看，Weex运行稳定，性能优异，在作好监控降级机制以后，能够放心的投入到生产。

我今天的分享就到这里，感谢聆听！

推荐文章

• 面向前端开发者的V8性能优化
  

• 百度外卖如何作到前端开发配置化
  

近期活动

• 直播 | 博学实践日：DevOps与高可用架构最佳实践之路
  

• 直播 | LiveVideoStackCon 2017 音视频技术大趴就要开始了

• 直播 | 将来密码——从互联网传输协议到后量子时代的密码学

• 直播 | 沪江技术沙龙 - 不断演变的架构实践