一、诞生背景
1.无线开发的痛点
React Native最近两三年之内整个框架在业界应该说是非常热门，很多团队、大公司都在做RN的一些研究开发工作。先一起回想下在React Native框架出现之前，互联网APP开发是一种什么样的模式。最初，大多数同学应该是用原生开发Android或者iOS，再加上HTML5内嵌的方式，即Web APP。之后又衍生出了Hybrid APP，基于PhoneGap/Cordova框架实现了WebView的能力强化。不知道大家在做这种开发的时候，有没有遇到过一些瓶颈或者一些痛点，反正我们的团队是遇到了很多。这里总结一下之前传统的方式有哪些问题。
第一，效率低下。因为无论是Android还是iOS，使用传统的原生开发都有一定的开发门槛。而且代码上不能复用，这意味着任何一个业务要在Android和iOS各做一次开发，测试和业务开发工作都不能复用。
第二，性能比较差。用传统的H5开发方式，受限于 WebView 容器的一些瓶颈，导致无论在页面加载还是用户体验上，相比原生应用有比较大的差距。
第三，灵活性不够。因为传统原生开发意味着任何改动都需要发版，在Android上因为像国内应用商店非常多，而且涉及到各种不同的渠道包，所以发版成本很大；在iOS则受限于苹果的审核机制。对我们来讲，任何这种线上问题处理起来都非常痛苦。
最后，接入困难。因为Android和iOS平台有差异，所以任何一种垂直业务接入APP的成本非常高，很多业务代码和业务流程并不能复用，造成业务团队的开发、接入成本非常高。
2.React Native登场
说了这么多痛点，我们也在反思到底需要一种什么样的框架来解决这些问题。非常幸运，我们在2015年的时候注意到Facebook发布了非常具有颠覆性的RN框架。简单来说，这是一种跨平台的移动应用开发框架。在当时它非常有颠覆性，因为它最大的特点就是完全用JavaScript进行应用的开发，但是最终会渲染成原生的组件。对开发者来说，这意味着你拥有了Web开发的效率，同时兼顾了原生的性能。这对我们当时业务的吸引力非常大，这个框架一经推出，国内外很多公司都在用，像Facebook自己也在用。在国内，手机百度、手机QQ、京东APP也很早就进行了开发。RN对我们团队来讲都有哪些优点，或者说为什么要用它，这里大概总结了以下四个原因。
第一，学习成本低。因为它的开发基于JavaScript，JS语言本身在开发者当中有非常良好的群众基础，任何一个有经验的前端团队可以快速地上手RN开发。
第二，多端代码复用。因为所有的业务都用JavaScript开发完之后只有一份代码，然后通过编译打包机制直接部署到不同的平台，如Android、iOS甚至Windows平台。
第三，接近原生的性能。开发者使用JavaScript进行RN框架开发，开发完之后在再通过中间的虚拟DOM。这个实际上是它核心所在，传统的H5的应用是跑在Web View的容器当中，容器中需要维护一个真实的DOM，而真实的DOM上每一次操作都会有回流(reflow)和重绘(repaint)，效率并不高。Facebook最有颠覆性的一点就是提出了一个虚拟DOM的概念，把整个DOM放在内存当中，然后通过高效的diff算法来计算比较哪些UI组件需要更新，最终只对这些需要更新的组件进行真实操作。经过测试，采用RN框架，无论是加载性能还是页面滑动性的用户体验上，都比原来H5的方式要好很多。
最后，社区活跃。除了Facebook之外，GitHub上有很多第三方的团队、个人、公司开发贡献了很多非常优秀的第三方组件，它的社区是非常健康、非常活跃的。
3.React Native的局限
不过现实是残酷的，即便确定了用RN框架做业务开发，在实际的开发当中也发现了RN的一些不足。对我们的业务来讲，最不能接受的主要是以下四个方面。
第一点，RN框架原生并不支持Web端。这意味着如果一个业务需要同时上Android、iOS和H5页面的话，那除了用RN之外，还需要用传统的H5或用ReactJS框架再做一次开发，这样效率是非常低的。
第二点，RN框架官方并不支持热更新。虽然现在有很多第三方方案，比如微软的CodePush，但是官方并不原生支持热更新，而热更新对我们的业务来说也是非常重要。
第三点，Facebook给出的官方RN API不能完全满足业务快速的发展。它只给了一些很基础的API，但业务中经常会用到的一些多媒体，比如录音、录像、视频播放文件以及文件上传、压缩、加密等等，这些都没有提供。
最后，前面提到RN框架性能非常不错，比H5好很多。实际上经过真正的业务开发后，发现90%的场景下RN的性能非常棒，可以满足我们的业务需求；但是在另外的10%的场景下，特别是一些交互非常复杂、页面非常复杂、需要频繁的更新、需要一些手势交互的场景，RN仍有些内存跟性能的瓶颈。
4.解决方案：JDReact三端融合平台
既然RN有优点也有缺点，那怎么办？
我们的解决方案是基于RN框架进行了深度定制和二次开发，逐步打造了符合京东业务的JDReact三端融合平台，主要的工作是以下四大方面：
第一，把RN的核心Base库拿来做裁剪和二次开发，把不需要的功能删减掉，把性能、兼容性、稳定性的问题修复，包括也支持了拆分打包。
第二，在后端搭建了一个功能支撑平台，帮RN框架增加了灰度更新升级、数据监控以及降级容灾功能，这些对业务来说是非常重要的。
第三，基于整个RN框架，结合京东的一些业务特点，封装了一套自己的业务组件，包括UI公共组件库。目的是为了让垂直业务开发者可以很快地使用框架进行业务开发，完全不用关心设计的样式跟交互，可以快速接入业务。
第四，打通Web端，实现了一套RN框架向ReactJS转换的工具。可以做到一次代码编写，直接部署到Android、iOS跟Web三端。
二、JDReact三端融合平台全解析
1.整体架构
下图所示就是整个JDReact三端融合平台的架构图。
最下面是一个后端接入平台，包含刚刚提到的灰度更新、降级容灾、数据采集和持续集成，这些是由服务端提供的一套服务。中间这一层是提供给内部开发者的一套完整的SDK开发工具，里面除了一些API之外，也封装了大量的京东定制功能组件，包括UI公共组件。其中还有一块是Web转换工具，提供了一套RN转换的脚本。业务开发者完全不需要关注这些细节，只要关心他自己的业务逻辑，就可以直接开发出覆盖三端的应用。最上面的业务层就是京东APP所有使用三端融合平台开发的业务，这些都可以直接部署到Android、iOS和Web。
2.改进和优化实践
前面主要介绍了整体的平台架构，现在开始来分享一些干货，就是我们在开发过程当中团队遇到的RN的一些问题，包括如何改进跟优化的一些实践。我列了一些功能点跟大家一起分享。
功能裁剪
有同学抱怨过RN库太大了，所以拿到RN的第一件事就是裁剪。对Android平台来讲，除了把RN的基础库裁剪以外，很重要一点就是要把方法数减少。因为Android平台dex有方法数限制，一旦超过65K就需要拆分成多个dex，整个应用的安装跟加载都会有性能问题。所以，要对Android方法数进行严格控制，我们的做法就是根据业务情况，把一些用不到的组件方案中的功能组件删除。其中最重要改动就是把Android中support-v7和stetho库依赖给去掉，去掉之后不仅大小减小了很多，而且方法数减少了将近7000。除了移除这个功能库，很重要一点，因为不是一个全新的RN应用，需要跟现有的体量很大的APP做集成整合，所以尽量让一些依赖库复用主站中依赖库，比如fresco、okhttp等。一来缩减包的大小，二来避免包的冲突。但是主站中的版本很可能跟RN中引用的版本有差异，需要中间做一层适配层，把这些差异尽量抹平，保证这些功能和方法都能工作。
加载性能优化
虽然说RN框架号称比H5的加载性能快很多，但实际开发中发现在Android的一些低端机型上，加载速度还是达不到原生体验，极端情况下甚至会出现白屏。主要原因是业务jsbundle比较大，RN框架在加载jsbundle和通过JSCore解析jsbundle时耗时太长。当用户看到真正业务页面之前会出现长时间的空白页面。
当时提出了两个解决方案，第一种方式是实现一套预加载机制。预加载机制就是在用户真正进入业务之前，把jsbundle提前加载解析，提前把RootView生成。简单来说就是用空间换时间。但这样做并不是所有的业务都适合，因为会带来一些内存增长，所以一般在很核心很重要的业务采取预加载机制。第二种方式是修改了RN框架底层库，在RN框架开始加载jsbundle文件时，显示一个loading的进度提示用户正在做加载的动作。当JS文件加载并且解析渲染完成之后，把进度条去掉，最终被页面展现给用户。这样虽然等待时间并没有减少，但是用户体验会好很多，整体的时间从收到的反馈来看还是比H5要好很多，这是我们做的一个优化点。
内存优化
我们还做了一件很重要的事情，就是内存优化。在RN框架开发中碰到的最大的坑就是内存这块，因为业务中会经常碰到ListView的使用，根据这些业务的需要，可能要加载很多页，两页、三页、甚至可能会无限加载。这种方式在早期的RN版本当中肯定会引起OOM（OutOfMemory）崩溃，原因是在RN的早期版本当中并没有对ListView做内存复用。这意味着ListView滚多少，图片都会在内存中，当页面加载地越多，出现OOM崩溃的几率也越大，这是一个非常不能接受的问题。
在RN的早期版本，我们团队在JS层实现了一套内存回收。它的原理跟原生当中的原理也差不多，就是当页面划出两个屏幕之后，会强制把图片和内容进行回收，用一个空白的View替换。当内容划到用户可见的屏幕范围之后，再把图片给加载出来，这也是原生常用的一种内存回收的方式。修改后的效果很好，无论页面加载再多，都不会出现卡顿和OOM崩溃。在RN的新版本（0.43之后），引入了一个新的FlatList组件。这个组件完全解决了ListView的内存回收问题。它的实现机制和我们的方案类似也是在JS层中做内存回收的动作。所以给大家建议，如果开发中碰到类似的问题，完全可以升级到最新的RN Base 0.43以上使用FlatList组件。如果版本比较低的话，那就需要自己实现这套机制。
第二个比较大的内存问题就是图片，iOS平台可能相对好一些，在Android问题会相对多一些。RN的底层图片框架库用的是Fresco，而我们主App中用的也是Fresco底层库，这里就会有些问题。第一个就是重复初始化，这也是当时业务开发当中碰到的问题。当主App中的Fresco进行初始化之后，如果RN中也进行一次初始化，实际上之前那部分内存并没有被释放，会出现内存泄漏。我们做了专门的检测，避免RN重复初始化的问题。第二个也是跟RN框架里面的实现有关系，因为它采用的图片编解码用的是ARGB_8888，这种方式支持Alpha通道。但实际上大部分情况下可以采用RGB_565编码，虽然丢失了Alpha通道，但是图片在内存当中的大小可以减少50%。不过有些业务可能也真的需要一些透明的背景，需要Alpha通道，所以也提供了一些API来针对特殊图片，让它采用ARGB_8888进行编解码。这样既解决内存问题，也满足了业务的需求。
最后一个经验就是在所有的RN页面退出之前，建议强制调用Fresco框架的clearMemoryCache方法，通知Fresco清除内存缓存。可以保证GC及时地把这些图片内存给回收掉，避免整个APP的内存占用过高，经过实践验证这也很有效地解决了内存问题。
拆分打包
关于拆分包，因为目前我们采取的方式是每一个业务打成一个jsbundle文件，这意味着业务越多，jsbundle文件会越大。而这些jsbundle文件当中，业务的代码其实占比很小。百分之七八十都是Facebook提供的一些公共组件库。我们的做法是在编译打包之前，把这些公共组件库先抽取出来，放在一个common jsbundle里面，然后业务只保留业务相关的一些jsbundle文件。最终在真正的加载之前，做一个简单的合并动作，这样业务越多，这种优化的效果就越好，可以有效减缓jsbundle文件大小的增长速度。
性能优化
除了内存之外，最关心的就是性能。前面也提了RN的性能其实比H5要好很多，可以满足我们90%的场景，但实际上还有10%的场景，RN做的并不是很好。主要也是因为整个RN的机制，它虽然是最终渲染成原生的组件，但是UI的控制还是在JS中做的。受限于JS单线程一些限制，当有一些很复杂的交互、很复杂的手势或者快速的滑动，很有可能引起JS中的阻塞，造成动画的一些渲染的数据不能及时同步到原生当中，造成了整个页面的卡顿。
建议的方案有三种，第一个做RN的Base升级，把RN升级到最新的0.45，它会采用了一个新的叫Yoga的引擎。这种引擎是完全用native实现的，可以把大部分的动画渲染和交互放在原生的线程中做。经过测试，采用了Yoga引擎，整体的渲染性能可以提升30%以上。
第二种方式，有一些非常复杂的一些交互，比如左右滑动结合上下滑动一些手势，如果用单纯用RN做，很容易碰到一些手势冲突的问题。所以把这种组件原生化，完全用原生实现，所有的交互跟手势控制全在原生做。这样做就可以达到非常完美的性能，但同时也需要原生开发团队介入。
最后一个经验就是尽量使用Animated这种动画类，减少JS控制的UI数据同步，避免JS线程阻塞。
版本检测
另外在jsbundle文件当中增加了一个version文件，解决版本冲突检测。因为要支持线上更新，就意味着需要把每一个业务jsbundle文件做一套完善的版本控制。需要知道当前这个jsbundle文件的版本号是多少，可以跑在哪个客户端的版本当中，可以支持的这它的RN底层库是多少。这些信息都会记录下来，然后在每一次的升级之前做版本检测。这可以有效地避免线上不同客户端和不同RN版本之间的版本冲突问题，可以支持线上的灰度升级。
兼容检测
RN其实有最低版本支持，像它的早期版本在Android是支持API 16以上，iOS是iOS7以上。其实我们的主APP要支持的版本会比他更低一些，所以需要在主APP中做一些保护和判断，一旦检测到用户的版本不支持RN，就需要做一些降级处理，比如说把入口关闭或者跳转M页。这样最大的程度避免不支持RN版本的用户出现崩溃的情况。RN其实可以支持x86芯片，但是考虑到如果要支持x86的话，需要增加一套基于x86的so文件，会对包大小有影响，所以对所有的x86做了降级。
原生能力扩展
前面刚才也提到了我们的业务非常多样，很多的能力RN并不支持。所以基于RN框架我们扩展很多业务上用到的原生组件，比如做了整个多媒体的视频播放、视频录制、音频播放、音频录制等组件，还有一些文件上传、语音识别等。在RN提供了这套JS的接口，给垂直业务团队快速开发和使用。
3.通用组件库封装
我们也结合自己的业务做了一套通用组件库的封装，例如京东当中的用户登录、购物车、收银台等等业务，在RN中做了一套组件的封装。把所有的接口都提供了JS的API，样式和交互像常用的下拉刷新、对话框、按钮等等，也提供了一套通用的样式组件给开发者。在做业务开发的时候，完全不需要关心这些样式怎么画、颜色怎么搭配，只需要关注业务逻辑。剩下的事情由框架做，这可以提升整个业务开发的效率。
4.三端融合
刚才前面提到了很重要的一项工作就是克服了RN不支持Web端的问题。我们做了一套Web转换的工具，打通了三端。其实在业内三端融合也有广泛的研究，方案主要有三种。
第一种方式，就是在RN跟ReactJS之上再封装一套轻量的跨平台的抽象层，像微软发布的ReactXP就类似于这样的架构。使用这种架构，意味着所有API、类、组件都不能用RN API，必须要用新的定义的接口，而且目前API支持也不是太多，还在完善中，所以没有采用这种方式。
第二种就是ReactJS做开发，之后通过工具转换成RN，这种方案适合于比较偏重H5业务的一些团队，因为他优先需要上的是H5页面，用户体验比较偏重H5。通过工具向RN转换其实是个有损转换，因为RN支持的样式实际比CSS样式少。从ReactJS向RN转换的话，可能会丢掉一些属性和布局。
第三种方案就是先用RN做开发，开发完之后再通过WebPack工具向ReactJS进行转换。这种方式的好处是可以优先保证RN中的体验，而且RN的样式支持是CSS的一个子集，这意味着从RN向ReactJS转换不会丢失功能和属性，所以业内更多的方案也是采用这种方式。GitHub上有一些类似的开源框架。但它们支持的组件并不是太全，不能完全覆盖我们的业务，所以我们自己实现了一套。包括之前说的所有的原生组件，它只有原生部分，我们也增加了JS部分的实现，使我们的框架可以完整、功能完全没有丢失地转化为Web页面。
5.灰度更新
下面简单介绍我们后端的接入平台在服务端增加的灰度更新控制。发版之后，如果需要做一些RN组件更新，可以通过后台的更新服务器做一次支持这种灰度的更新。它大概的流程就是首先由APP端发起更新的请求，发送到路由控制，路由控制负责控制用户是不是在灰度比例范围之内。如果符合灰度策略，把这个请求转到服务端处理，服务端根据客户端上报的jsbundle文件的版本跟服务端部署的版本做一次比较，看有没有适合这个业务的新版本。如果有，把这个升级的版本号以及下发地址回传给客户端，客户端会直接根据下发的下载地址从云存储上下载升级包，完成整个升级过程。因为用户量比较大，所以每一次更新一定要有一个灰度策略，根据灰度比例逐渐放到全网，这是非常重要的。
6.降级容灾
我们把降级容灾定义为两种：一种叫被动降级，一种叫主动降级。所谓的被动降级是指客户端确实不支持RN框架，每次加载RN框架都会出现问题，那必须要进行被动的降级，跳转到对应的H5页面，使得对业务的影响降到最低。这种降级逻辑是在客户端当中做处理的，就是前面介绍的兼容性检测。第二种是主动降级，很可能在业务开发的时候会发现一些上游的接口出现了问题，导致客户端中的某项业务不能正确地运行，这个时候就需要由服务端控制对这项业务进行精准的降级。我们会支持多个维度灵活的配置，可以根据客户端的版本号、客户端的型号，配置灰度比例、白名单，精准地对某些用户的某些业务或者某些地区的某些用户进行降级，减少业务上的损失。在一些非常大的促销的时候，像双11、618这种峰值非常高的时候，可能会采用这种方式。
7.持续集成
这主要是我们内部的一个开发模型，把所有RN的基础库，包括自己提供的一些公共组件库、公共UI组件库都部署在内部的NPM Server上。每一个接入的业务开发者、每个业务都会有一个独立的GIT。因为在我们内部，其实业务开发团队可能会很多，我们的团队是负责维护框架，而业务开发团队各个部门各个地区都会有，他们会有申请自己独立的GIT，然后从NPM Server上下载最新的SDK包进行业务开发。业务开发完成调试之后，会通过CI打包平台发起打包命令，然后触发Jenkins当中的job，从对应的业务的规则拉取代码，进行编译打包。编译打包成功之后，把它部署到对应的Android或者iOS客户端版本当中进行整个发布。这种方式对业务开发者来说，最大的好处就是打包编译完全是脚本自动化，不需要获取客户端的源码就可以做到这个业务的开发和上线。
8.数据监控
JDReact三端融合平台我们也做了一套非常完善的数据监控中心。因为需要知道所有RN页面启动的时间、加载页面的时间、服务端返回的响应时间、界面渲染的时间。需要把这些APM数据上报，通过上报的数据分析，不断地优化性能。第二，也会把业务开发当中碰到的一些异常日志进行上报，可以帮助我们快速的定位问题，发现问题并部署相应的升级包。第三，因为灰度升级更新这个机制，需要有数据埋点来统计升级的成功率。有多少的用户真的是发布升级之后可以成功升级到这个版本。最后，也会针对DAU、UV、PV等基础数据做统计，这个主要也是帮业务方搜集一些运营数据，好做业务上的决策。
三、总结
这个框架推出有一年多的时间，到目前为止，京东APP当中已经有20多个业务正在使用这套框架，其中也有一些比较重要和常用的业务。我们整个平台也经历了去年的双11、618，今年即将到来的618，我们也会做更多的后台保障，在稳定性，包括降级上做一些处理，确保业务能够正常地推进。未来也希望能够不断的完善这个平台，不光是京东内部在用，一些很好的组件框架也可以开放出来，跟大家一起学习进步。
作者简介
沈晨，京东商城专家架构师、JDReact三端融合平台负责人。
感谢徐川，木环对本文的审校。
给InfoQ中文站投稿或者参与内容翻译工作，请邮件至[email protected]。也欢迎大家通过新浪微博（@InfoQ，@丁晓昀），微信（微信号：InfoQChina）关注我们。