阅读 724

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运行稳定,性能优异,在做好监控降级机制之后,可以放心的投入到生产。

我今天的分享就到这里,感谢聆听!


关注下面的标签,发现更多相似文章
评论