移动动态化方案在蜂鸟的架构演进(含React Native与Weex比拟) 架构&设计

来源:互联网 / 作者:SKY / 2017-11-11 13:14 / 点击:
当下,移动动态化已经成为各大公司都回避不了的题目,产物的快速迭代对技能提出了更高的要求,而移动端的动态化方案也是层出不穷:Hybrid、布局化 Native View、
Tech Neo技能沙龙 | 11月25号,九州云/ZStack与您一路切磋云期间收集界线打点实践

【51CTO.com原创稿件】当下,移动动态化已经成为各大公司都回避不了的题目,产物的快速迭代对技能提出了更高的要求,而移动端的动态化方案也是层出不穷:Hypid、布局化 Native View、React Native、Weex,什么样的方案才是得当本身团队的呢?本文将分享饿了么蜂鸟团队在已往两年多营业快速增添进程中,移动动态化方面的实践和试探。

什么是移动动态化?

移动指的是移动端,包罗安卓、iOS。动态化则是动态陈设和逻辑下发到客户端的手段。移动动态最好的状态就是让移动应用和 Web 一样,想发就发!

为什么移动端要强替换态化的手段?

缘故起因有如下三大点:

    营业迭代太快。当下大部门团队都是火速开拓的模式,纵然两周做一次迭代,产物周期照旧会认为长,有些应用不能实时上线。

    应用市场考核慢。安卓根基当天发应用市场,当天就可以或许有更新。但 iOS 必要约 3-4 天来考核。假设有些成果必要按时上线,iOS 考核时刻必必要思量进去。

    用户进级周期长。统计表白,每一个安卓版本宣布,一周内会有 70% 的用户更新,一个月别的用户才气延续完成更新。

移动动态化方案共性,有如下三点:

    跨平台。

    机关。约定 DSL,担保渲染机能。

    逻辑。Android 和 iOS 必需共用表明器。

蜂鸟团队的近况与营业特点

蜂鸟团队近况

蜂鸟团队于 2014 年创立,初志是为了承接饿了么的物流营业。跟着时刻推移,订单量从逐日几千单到百万单,配速员也到达百万数目,处事品类涉及外卖、商超、鲜花、蛋糕、文件等,蜂鸟提供全时段配送,配送处事包围世界 1200 多个都市。

蜂鸟团队的营业特点

蜂鸟团队的营业首要有离散性和突发性两大特点,如下图:

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

从营业曲线可以看到两个很明明的波峰,这是午、晚用餐时刻。同时,假如运营方面设置一些勾当,会导致这两个波峰徒增。以是,动态方案要想把这两个时刻段处事好,必必要思量流量陡增下的机能压力。

蜂鸟团队的技能特点和挑衅

蜂鸟团队的技能特点和挑衅,我首要分享重度依靠、收集情形伟大、重度行使和 28 定律这四个方面。

重度依靠

当前蜂鸟有众包、团队和送送三部门营业,右侧是一些成果展示,如下图:

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

这样的器材型应用,必要对 APP 有更强的节制、监控等手段。须要时还要做到逼迫更新。

对应到动态方案的话,节制手段就必要动态方案必需具备动态降级的手段、监控手段,及时的机能监控和营业埋点监控。逼迫更新方面,动态方案必需做到用户无感知的热更新。

收集情形伟大

饿了么小哥,天天穿梭在大街小巷、地下商超,他们的收集情形很是不不变。据统计,有近 25% 的用户哀求还来自非 4G 情形。

整体来说的收集情形伟大、信号差和 DNS 污染,那么动态方案就要办理 DNS 拦截、弱网情形下资源下发等题目。

重度行使

无论是下雨、下雪,照旧发大水各人城市叫饿了么。

配送员在岑岭期的行为曲线,如下图:

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

面临这样分秒必争的准时达压力,假如动态方案不给力,会导致应用呈现瓦解或卡顿,骑手一定不会有好的体验,乃至影响送餐时刻。以是我们的动态方案必然要担保机能和不变性。

28定律

信托许多公司的应用都切合相同 28 定律,蜂鸟也不破例。

如下图,蜂鸟的 28 定律

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

可以从图中看出,大部门骑手一般行使的主流层面,可以回收 Native 来开拓,这部门重度行使的占比约 20%,别的 80% 的成果都可以思量动态化方案(H5)。

蜂鸟团队的动态化架构演进

蜂鸟的动态方案颠末 Hypid、React Native 和 Weex 三个首要阶段。

第一阶段:Hypid

在 Hypid 方案上,以 H5 的动态性为基本,通过 Jspidge 做桥梁,与 Native 举办通讯,之后通过 URL Router 举办跳转,架构如下图:

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

这套动态方案的利益显而易见,这里首要先容开拓服从、更新体验和跨平台三方面:

    开拓服从。Web 颠末多年的应用实践,已经拥有完备的开拓流程和开拓器材,开拓一个 H5 页面很是快速。开拓服从这一身分不能忽略,由于初期产物的设法和落地速率会直接影响产物的运气。

    如蜂鸟送送,初期没有原生的资源去支撑,就用原生包壳,内部所有效 H5,这样的环境僵持了两月阁下,为蜂鸟送送前期的方案验证做了很大的孝顺。

    更新体验。因 H5 和原生耦合只有扩展的 Native API,只要把这些 API 维护足够全,开拓的营业成果就可以在完全不消更新 APK 的环境下,做到热更新。且用户下一次打开应用是最新的,这和 Native 的进级体验对比的确是一天一地。

跨平台。之前安卓和 iOS 代码必要开拓两次,此刻一个成果抉择用 H5 后,由一个工程师来开拓一套代码即可。

这套动态方案很大的弱点就是用户体验差,当用 H5 做一些伟大的成果或动画时,也许会卡顿的和 PPT 一样。由于 H5 的体验题目,蜂鸟的原则是常常更新的且成果不伟大的页面会选择用 H5。

第二阶段:React Native

这个动态方案完全离开了以 H5 为基本的 Hypid 方案,通过自界说 DSL 将 UI 渲染成原生控件,这样一来, RN 的页面就担保了原生的体验和 Web 的服从。

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

除了上一点,尚有组件化开拓、复用率高、Android 和 iOS 95% 的代码共用和测试服从高档利益。

鉴于这些利益,蜂鸟在 React Native 上做了许多工作,如 Crash 优化、基本控件沉淀、Bundle+ 图片热更新、首屏加载优化和 Redux 单项数据流等。

合法享受 React Native 带来的开拓体验和应用体验晋升时,蜂鸟碰着 RN 的一些痛点,如 ScrollView 机能、Bundle 包过大、许多优化都必要修改源码和 peaking change 等。

第三阶段:WEEX

面临如上这些痛点,不知怎样应对时,WEEX 来了。官方宣传的轻量、可扩展和高机能等特点,让蜂鸟团队面前一亮。

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

经深入研究后,蜂鸟发明 WEEX 和 React Native 千篇一致,那么为什么要选择相同的方案呢?

我们队 WEEX 和 React Native 两者基于 JS 引擎、语法、数据流、机能、开拓体验及热更新等维度举办了比拟。

如下图,是 WEEX 和 React Native JS 引擎比拟

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

React Native 在安卓和 iOS 行使的都是 JsCore,WEEX 在安卓端行使的是 UC 精简版 V8。如上图中的图表可以看出,V8 对比 JsCore 要胜一筹。

WEEX 和 React Native 语法比拟。语法方面,React Native 行使的是 React,WEEX 行使的是 Vue。固然两套方案都实现了如相应式,组件化、状态打点等成果。

如下图,是两者简朴 Demo 的实践:

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

实践发明,WEEX 对比 React Native 要优雅一些,是由于 Vue 有许多自界说标签,当在做一些 UI 和逻辑交杂在一路时,会让代码简捷许多。

 WEEX 和 React Native 的数据流比拟,React Native 行使 Redux,而 WEEX 行使 Vuex,不是 WEEX 不能行使 Redux,而是 Vuex 更得当 WEEX。

如下图,是两者的数据流,大同小异:

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

但 Vuex 在实现一些计较属性时,能在更细的颗粒度去更新 UI,而 Redux 只能实现到组件的级别,这样的点许多的话会带来机能上的差别。

如下图,是 WEEX 和 React Native 的机能比拟,左侧是 WEEX 官方给出的与 React Native 在机能方面的比拟图:

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

在渲染时刻和内存占用方面 WEEX 要优于 React Native,在 CPU 占用方面两者相差不大,FPS 上 WEEX 要稍逊于 React Native。

在 ListView Android 方面,React Native 今朝回收 ScrollView,WEEX 行使 Recyclerview 实现,机能稍好。

同时 WEEX 在加强开拓、指定线程、首屏渲染和机能监控等方面也做了优化。

如下图,是 WEEX 和 React Native 的开拓体验比拟

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

和 React Native 对比,WEEX 在打包、监控机能、跨平台等方面都有必然上风。总体来说,React Native 更像是一个技能框架,WEEX 更像是一个营业框架。

如下图,是 WEEX 和 React Native 的热更新比拟:

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

React Native 与 WEEX 官方都暗示支持热更新,但他们的实现方法差异。在 React Native 上可通过把图片打包下发到当地来实现更新。

WEEX 有两个要领,一是选择当地资源加载,二是像网页一样直接加载页面。

如下图,是 React Native 与 WEEX 的比拟总结

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

React Native 更像一个先驱者,拥有超强的社区人气,但也因开源社区维护代码的缘故起因处于一个蛮横发展的状态。而 WEEX 是站在 React Native 的肩膀上,做了各类微创新,实现更多知心的小细节。

基于 WEEX 机能、不变性等方面都比 React Native 高,蜂鸟抉择把动态化方案往 WEEX 上迁徙,固然它此刻尚有不敷,有些轮子照旧要本身去做。

蜂鸟团队 WEEX 实践

依附之前 React Native 相干的实践履历,基于 WEEX 做了一套更完备的动态方案。涉及以下几个方面,如下图:

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

同一的pidge 

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

在 Android & iOS 端,约定沟通的要领名、参数,在 JS 层抹平平台差别以及同一分类打点袒露给营业的 API。

把这样的同一 pidge 方案提供应营业部分,他们只需体谅袒露的 API,而不必要体谅下一层平台的兼容,大大晋升开拓服从。

加载更新计策

加载更新方面,我们约定了一套自有协议,有 Page、URL 和 Tag,通过封装的 Router,就可以做到页面级的跳转。

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

这样一来,我们很轻松地做到了页面的跳转、解耦和页面的降级。当页面呈现题目,只必要把 URL 改成降级之后的 H5 页面下发即可,用户触及到的就是修复之后的 H5 页面了。

如下图,是预加载计策

移动动态化方案在蜂鸟的架构演进(含React Native与Weex相比)

阅读延展

1
3