基于React Native的58 APP开发实践

React Native在iOS界早就炒的火热了，随着2015年末Android端推出后，一套代码能运行于双平台上，真正拥有了Hybrid框架的全部优点。再加上Native的优秀性能，让愈来愈多的公司在实际项目中一探究竟。58同城APP发布模块年代久远，一直计划进行重构以适应日益苛刻的用户体验，这个需求与咱们在React Native上一探究竟的意愿一碰撞，就产生了React Native在58APP的开发实践。

 

本文重点介绍的是实践过程当中的技术架构和Native组建层以及热更新平台的基本状况，以期能对React Native的从零到深刻有一个总体的把握。

 

1.工欲善其事，必先利其器

React Native是一项全新的技术，不一样公司使用有不一样的体验，好坏众说纷纭。基于此，必须根据自身的状况进行摸底调研。58APP的调研过程从2015年6月就开始了，那时候android还没推出，仅调研了iOS的相关状况。真正的全面调研展开是在2016年3月开始的，由宁老板亲自点将并监督进度。整个过程持续到5月初结束。下面分三个阶段介绍一下58APP调研的具体历程。

 

 

1.1 iOS RN调研（2015.6）

React Native确切的说从2015年开始在国内火起来的。墙外开花，墙内结果，国外技术研发，国内炒的火热。阿里天猫在这一方面走的比较靠前，但这时候Android部分尚未推出，仅有iOS。应庆春分配的任务，我负责了这方面的调研。

当时是拿二手车的列表页进行的试验，主要测试用RN实现的列表页和用Native实现的列表页在性能上的差异，当时得出的调研结论以下：

 

（1）集成React Native须要从iOS7.0开始，在7.0如下会因私有API问题在审核过程当中被拒；

（2）性能方面，经过对ListView的针对性分析，在数据量不大的状况（50条左右），内存和CPU的差异在iphone4s以上的设备上能够接受；当数据量比较多，好比试验过程当中的150条，内存比较大，在低端设备（4s／5c）上随着业务的扩展，性能会有瓶颈。

（3）开发学习成本上，上手会比较快。但在开发的过程当中遇到一些复杂的业务逻辑，得基于现有的框架扩展组件；还有在崩溃的收集上会比较麻烦，只能定位到OC层的代码，对于JS的运行时崩溃，目前的崩溃收集系统还没法采集。

 

固然，ReactNative的理念是比较好的，既能拥有native的良好用户体验，又能具有web的快速发布和迭代的功能。若是android后续能很好推出，还能实现跨平台的一处编写，多处运行的效果。不管集成与否，后续要持续关注，保持前沿技术的敏感性。对应ListView性能问题，RN官方一直没有一个很好的解决方案，咱们最近也在作一些调研和组件的从新封装，指望能从根本上解决这个问题。

 

 

1.2 双平台RN基础调研（2016.3）

在2015年末，React Native就推出了Android版本，而后就有不少公司在开始尝试了。春节流量高峰一过，上面就在筹划RN上开发尝试的事了。大致方向是以APP中的发布模块作为试点，而后咱们调研的技术偏向于发布模块的相关功能实现。调研由宁老板点将，iOS 笔者负责，Android 萌阳负责，JS那端天翔负责，成立了调研三人组，每周汇报进度。3月份的调研主要面向的是RN基础调研，摘取了其中的一些调研细节：

（1）Android／iOS 如何将RN集成到当前项目中？

（2）如何用RN提供的原生组件实现发布界面？

（3）写完的JS如何打包给Native使用？

（4）因为是集成到已有项目，如何处理项目中的统一导航和RN提供的导航？

（5）发布表单中图片区域如何处理？Native封装的组件粒度如何？

（6）发布页面的UI是用ScrollView控制仍是ListView控制？

 

3月份的调研，在RN的应用层面作到了一个心中有数，为后期的技术工做开展奠基了一个很好的基础。至于基础调研过程当中的问题，限于篇幅问题，就不一一展开叙述了，有兴趣的同窗能够私下交流。

 

 

1.3 RN 热更新调研(2016.4)

热更新调研是整个调研最最关键的一环，由于官方并无热更新的成熟方案。整个4月份一直在进行热更新的调研，直到5月8号结束。热更新调研主要涉及的主题为：

（1）热更新Native端的流程？如何控制热更新包的大小及内置的资源大小？

（2）Server端热更新diff文件存储方案及更新方案？

（3）Native端如何获取文件的更新？

（4）异常回滚机制？

（5）是基于二进制算法的diff仍是基于文件算法的diff？

热更新中涉及的细节真的不少，上面只是列出其中的一些。咱们的调研过程，也是内部一遍遍技术评审／修改／再评审的过程。在下一章节会对这里提到的主要问题进行分析和解释。

 

 

2. 万事具有，水滴石穿

5月份PM已经陆续把需求整理完成了，而后成立了项目组，加入了发布业务的FE及Server。项目代号为“水滴”，无线FE同窗的创意。水滴，源自于三体，多维空间武器，经过量子纠缠进行超远距离通信和控制。React Native如同水滴，对JS-Native通信和控制。另外，寓意水滴石穿，坚持不懈，终能成功！

 

2.1基于RN的移动APP开发架构

首先从总体上了解一下基于RN的APP开发架构。架构共分为五个部分：Native组件／API层、JS中间层、JS业务层、视图载体页、热更新平台。JS业务层、JS中间层、Native组件／API层三者运行于视图载体页中，且JS业务层和JS中间层的代码更新是经过热更新平台更新到用户手机应用中的。Native组件／API层是整个装置的基石，JS业务层经过JS中间层调用Native组件与API。

 

Native组件／API层与JS中间层是无状态，能够被复用的，它们被不一样业务调用和组装，能造成不一样的业务功能。在这里，一切业务都是基于组件的，任何业务的造成，都是调用Native组件及API来的。尤为是引入了JS中间层，不只抹平了在不一样平台（iOS／Android）上调用组件的差别性，还解耦了JS业务层与Native组件层。若是没有JS中间层，Native一个组件或者API的变更，都须要通知全部的业务方去进行修改，在业务到达必定量的状况下，这种改动不只费时费力还具备风险，会影响线上功能。引入了JS中间层以后，Native组件及API的变更，都在JS中间层进行处理，JS业务层毫无感知。

 

下面对这五个部分进行分别介绍：

 

2.2  Native组件／API层

Native组件／API层是在整个架构的最底层，也是整个装置的基础。

在这一层，除了React Native自己提供的原生组件外，咱们还对没有覆盖到的组件进行了封装。React Native提供的组件有Image、ListView、Picker、Text、TextInput、ScrollView等，具体可从React Native官方网站（http://facebook.github.io/react-native/docs/getting-started.html）上查询。本发明扩展的组件有：支付、语音、弹窗、单选选择器、多选无联动选择器、登陆等。

在React Native中，除了组件，还有API。官方提供的API有ClipBoard、AsyncStorage、AppRegistry、Alert等，更多完备的API可从ReactNative官方网站上查询。本发明扩展的API有：跳转、定位、埋点、初始化参数等。

这些扩展的组件和API使得用React Native，来实现本地化的业务成为了可能，也是本发明重要的组成部分。固然随着业务的逐步扩大，还会不断丰富组件／API库，以适应业务的特殊性和多样性。具体自定义组件状况以下图：

 

以弹窗dialog组件为例，native与js交互的协议为：

 

JS调用的示例为：

 

2.3 JS中间层

JS中间层是很是关键的一层，是为上文中扩展的Native组件／API来服务的。JS中间层如上文所述，不只能抹平在不一样平台上调用Native组件／API的差别，还解耦了JS业务层与Native组件／API层。

 

上图所示的是在自定义弹窗组件（Dialog）中的代码片断，从代码的95行到102行，所作的是处理iOS／Android两个平台上弹窗界面肯定按钮放置的位置不一样而作的差别化处理。相似这些平台差别化的内容在实际开发中会有不少，若是这些差别都有业务方去作，不只代码可复用性差，并且耗时耗力，每个新接入方都要从新开发调试。

 

至于JS业务层与Native组件／API层之间的耦合关系，能够试想，若是没有中间层的封装，以上文的dialog组件为例，在业务层中，将会执行下图中所示的调用，其中WBCustomDialogManager是Native的组件标识别，还有show函数的相关参数。这些与native相关的内容若是发生变化，则全部与这个组件相关的业务都要更改。而引入了中间层以后，业务调用方，将再也不关注这些细节，中间层在其中作了解藕。即便native发生了变更，也会最大限度下降业务层的变更。

 

2.4 JS业务层

JS业务层主要专一了业务的实现，包括视图的渲染，组件的串联，UI样式的设置，Server API接口的调用与数据的处理。JS业务层在改装置中是最终代码的落地，视图载体页加载的视图以及热更新系统更新的代码都是直接针对JS业务层的，只是这时业务层引用了JS中间层的代码来实现对Native组件的调用。

 

2.5 视图载体页

视图载体页在这里扮演了很重要的角色，是全部业务的一个统一载体。以58同城APP为例，里面有大类页／列表页／详情页／发布等不一样形态的各类业务。通用的作法每个业务一个载体页。由于载体页是Native代码写的，这使得当须要扩展一个业务线的时候，必须依赖发版。而统一了载体页后，只须要经过热更新平台将JS代码更新到APP本地便可实现。

 

视图载体页单一载体功能的实现，很关键的部分在于跳转到载体页跳转协议的设计。因为跳转协议与具体的业务关联较大，咱们的跳转协议中有一个重要的参数pagetype，在这里咱们将pagetype设置为RN，而不是list(列表页)／detail（详情页）等与业务相关的类型。其中bundleid指向的是下文热更新平台将JS业务层及其引用的代码编译link好的jsbundle文件。

 

跳转协议在不一样的APP中，实现思路不一样，有不少APP采用的url形式来实现，但具体思路与上文描述的JSON形式相同。

 

3. 热更新平台

热更新平台是整个框架的核心。热更新平台的主要功能是将JS业务层及其引用的代码编译link好的jsbundle下载到native app中。在此过程当中，须要控制更新文件的大小以及失败状况的处理。

 

热更新平台涉及JSBundle资源管理系统（Server）、JSBundle数据接口层（Server）、JSBundle Native更新及管理层（Native）。JSBundle资源管理系统负责将相关JS业务层代码编译link成JSBundle文件，并将相关更新写到一个数据缓存中心（例如redis或者memcached）。当Native经过JSBundle数据接口层提供的接口获取对应的JSBundle的信息时，数据接口层将从数据缓存中心查询数据并返回给native端。Native端为了提升用户体验，会对JSBundle进行缓存，用户访问相关页面的时候，先展现缓存，再访问接口，看是否有更新。

 

热更新这块，在这里我从另一个角度来阐述，即咱们为何不用现有市面上的方案，而要本身搞一套。下面的三个章节来慢慢叙述。

 

3.1 热更新的三个主要问题

热更新如今公开的两个方案是微软的CodePush和React Native中文网中的react-native-pushy。这两种方案实现思路其实差很少，以react-native-pushy为例，咱们发现它有如下缺点：

（1）  内置资源体积过大，致使整个应用包的大小过大，致使过多占用用户手机容量以及下载应用耗时超长。

在APP提交给应用商店审核时，会将RN集成编译后的jsbundle打进内置资源里面去，而一个完整的jsbundle在区分平台（iOS／Android）以及js压缩的前提下，体积有600K左右。若是随着业务的快速扩展，假设有100个jsbundle的内置资源，那么大小就会到达60M。而应用商店的app大小，以58APP为例，大小才87M。内置资源过大，致使整个应用包的体积过大，一是占用用户手机容量，另外一个每次下载应用耗时超长。这在必定程度上是很难接受的。

 

（2）  计算增量的基准文件不惟一，平均合并的diff个数过多，增长了服务器处理增量的复杂度和下降了app端合并diff性能。

react-native-pushy在利用bsdiff算法计算增量时，是相邻两个版本文件的diff。如今假设用户本地app文件版本是1.0，而服务器最新文件版本是4.0，则服务器须要返回app3个diff（1.0至2.0一个diff，2.0至3.0一个diff，3.0至4.0一个diff）。因此，因为bsdiff算法计算增量的基准文件不惟一，致使平均需合并的diff个数过多。这不只增长了服务器处理增量的复杂度，还下降了app端合并diff的性能，合并时间多长，阻塞用户操做。

 

（3）  将整个app的全部JSBundle文件打包进行更新，不区分业务。致使若是一个业务的JSBundle有问题，会影响其余业务JSBundle的正常运行。

react-native-pushy作的是一个通用的热更新平台，一个app有一个key，文件更新以此key为标识，全部文件在一个zip包里面，不区分业务。当前稍微大的互联网公司，都是以业务线划分职能的，在技术架构上，各业务线业务应该作到相互不干扰。react-native-pushy这种不区分业务的更新模式，会致使若是一个业务的JSBundle有问题，会影响其余业务JSBundle的正常更新，形成业务的相互干扰。

 

基于对上面的分析，咱们得出了热更新须要解决的三个问题：

（1）    既要控制更新包的大小，又要控制内资资源的大小；

（2）    下降服务器处理增量复杂度和提升APP端合并diff性能；

（3）    Diff更新以JSBundle文件为单位，业务Diff之间相互不干扰。

 

3.2 热更新的解决方案

基于上面的三个问题，咱们有以下的解决方案：

 

3.2.1 JSBundle拆分及公共部分生成

在介绍diff生成及合并算法以前，先介绍一下一个关键性要点。即咱们重点关注React Native中JSBundle的内容的特殊性，发现打包编译后的一个JSBundle能够拆成一个稳定的公共部分加上差别部分。如上图所示，针对一个入口文件pageIndex.jsbundle, 能够拆分红稳定的commonPart.jsbundle以及差别部分diffPart.jsbundle。其中，commonPart.jsbundle与具体业务无关，是React Native中一些公用的js库。

 

 

commonPart.jsbundle生成的方法为(以iOS为例，Android的原理相同)：

 

（1）新建一个blank.ios.js文件，在文件中仅需引入react及react-native,注意不要包含任何业务代码，具体代码以下截图：

 

（2）经过curl命令将blank.ios.js文件编译成common.ios.jsbundle。笔者在本地的执行命令为：

curl'http://localhost:8081/blank.ios.bundle?minify=true&dev=false' -ocommon.ios.jsbundle。获得的common.ios.jsbundle结果以下图所示：

 

 

须要补充的是，由于commonPart.jsbundle依赖Native代码，因此commonPart.jsbundle的更新是跟着APP发版走的。

 

3.2.2 Diff的生成与合并

基于上文对jsbundle的拆分，咱们选择了google-diff-match-patch算法生成diff 及合并diff。在计算diff时，以commonPart.jsbundle为基准，计算当前版本的pageIndex.jsbundle与commonPart.jsbundle之间的文本差别，而后APP端拿到文本差别描述后，再利用google-diff-match-patch算法将文本差别合并到本地的commonPart.jsbundle中去。

 

生成diff调用google-diff-match-patch的API为（iOS端为例，其余端可找到对应API）：

合并diff调用google-diff-match-patch的API为（iOS端为例，其余端可找到对应API）：

3.2.3 热更新流程

 

热更新流程如上图所示。图中载体页是指native加载React Native代码的一个载体。RN是React Native的缩写。下面对上述流程进行叙述：

 

(1)进入载体页，判断是否有缓存。

进入载体页以后，会先判断是否有RN缓存，若是有缓存，则直接进行下一步。若是没有缓存，则去服务器下载对应的RN资源（RN资源指的RN代码文件）。

 

(2)展现RN页面

根据RN资源，载体页渲染出对应的页面。

 

(3)后台请求当前页面最新信息

在展现完RN页面后，新起子线程在后台向服务器请求当前页面的最新信息数据。

 

(4)根据最新信息进行更新操做

根据上一步服务器返回的数据，进行分支操做：若是是强制更新，则弹窗提示用户须要强制刷新当前页面才能继续操做；若是是通常的非强制更新，则程序在后台更新数据，用户下次进入此页面后更新生效；若是没有更新，则不作任何操做，流程结束。

 

针对上述流程有一个补充：在APP启动的时候向服务器请求预加载数据，提早对一些重要的RN资源进行加载，这样在上述流程的第一步就能够直接利用RN缓存快速进入页面，用户体验会更好。

 

 

3.3 结果分析

基于上述方案，可解决上述提到的三个问题：

 

（1）在内置资源的时候，只需内置一分commonPart.jsbundle和相应入口页面对应的diffPart.jsbundle。在一般状况下，commonPart.jsbundle占整个jsbundle近2/3的大小，这相比基于react-native-pushy而内置的资源节省了近2/3的大小。另外，针对业务迭代过程的更新包，都只是业务代码的更新，包的大小也获得了很好的控制。

 

（2）服务器计算diff包的时候，因为只需对commonPart.jsbundle进行比较，因此计算增量的复杂度相比react-native-pushy降到了最低。APP端在合成diff的时候，只须要将一个common.jsbundle与一个diff.jsbundle进行合并便可，合并性能相比react-native-pushy平均要合并多个，获得了很大的提升。

 

（3）本方案计算的更新，以某一个入口页面对于的pageIndex.jsbundle为单位来操做，是以具体业务为单位的。每个pageIndex.jsbundle对应的更新都是相互独立的，即便一个业务更新出错，也不会影响到其余业务的更新。

 

 

4. 产品顺利上线，幸有PM烧高香

通过两个多月的研发，Native端，FE中间层，FE业务层，业务Server，热更新平台全部功能所有上线了，多亏PM上线前烧了高香，整个过程是很曲折的，但结果是美好的。但老板说了，RN这个东西历来没上过，万一上线以后出了重大问题怎么办？经过发版解决周期太长，速度太慢。因而乎只能经过Server端来控制了。

 

经过Server控制线上出现问题的风险，咱们称为降级策略。即用RN以前，58APP使用的Hybrid框架来作的发布页面。若是线上的RN出了问题，经过Server端控制跳转协议，让跳转到web的发布页面上。等待RN问题解决了，再行切换。

 

产品上线后，产品层面最关注的就是加载速度了。针对发布功能来讲，从Hybrid切换到React Native，为的就是加载速度。因为RN有热更新，基本上用户是在90%的状况下进入有缓存的界面的。下图是由QA组王琪同窗提供的双平台在加载时间上的性能测试结果（有缓存的状况下）。

 

上图中的Web页面加载时间是在网络情况良好的状况下的数据。从图中能够看出，RN页面基本上是秒进，这让从点击发布按钮到展现发布页面期间的用户流失基本降到了最低。

 

通过项目组成员的辛苦努力，React Native在58APP上算是迈出了第一步，官方SDK如今是一个星期一个版本的更新节奏，后期开发中确定还会有好多坑，跃坑的过程确定很精彩！

本文摘自：58无线技术

http://mp.weixin.qq.com/s?__biz=MzI2NzI4MTEwNA==&mid=2247483942&idx=1&sn=a273257814626bd902c3d04d0e7f8d4f&chksm=ea807599ddf7fc8ffc9ba840a8f64e2e285151c837eeae57ef32528e73af8f073a19c0a60007&scene=4#wechat_redirect