基于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