58车商通RN落地与实践
导语
本文从RN的简介到在车商通落地，从宏观设计到深层次分析其通信原理，再到热更新的进阶设计三个方面，阐述了React Native在车商通中的设计以及流程。
背景
58车商通
58车商通是为车商打造发布及收车卖车、CRM管理、商机线索、库存管理、全网同步、营销推广功能等全方位SAAS服务的移动端APP。
主要功能包括：
1. 发布车源（核心功能）帮助车商快速发布车源，和主App 58同城起到相辅相成的作用。需求变化比较频繁，开始采用原生开发，但是无法满足需求的频繁变化，于是2017年改版为Hybrid。后续考虑改版为RN
2. 库存管理（核心功能）帮助车商高效的管理自己的车辆，包括已经发布的，已经售出的，已经下架的，等等，以及定价，预警等相关功能。需求变化相对稳定。
3. 客户管理（核心功能）帮助车商管理自己的客户，区分出客户的购买意向程度，以及后续沟通等等。变化频率相对稳定
4. 营销推广（核心功能）帮助车商推广车辆，包括置顶，刷新服务等，变化频率相对较高
总结：58车商通是58集团二手车部门的一个重要的App产物，帮助车商方便管理自己的车源，随时发布，同步其他市场。而 RN 模块第一次尝试放在了车商通的每日任务模块。
为什么会选中每日任务模块
每日任务模块：用户每日登陆之后可以通过每日的任务来赚取积分。用于推广等功能等。
那我们为什么要用每日任务模块来做呢。
首先， 每日任务模块体量较轻，入手起来相对比较简单
其次， 线上有成熟的h5，如果出现严重问题的话，我们可以及时切换到线上h5进行补救
然后， 每日任务模块虽然量轻，但是可以覆盖协议的大部分功能。
最后就是这个模块需求变化相对来说比较快，也可以检验热更新模块。
接下来我们来聊聊RN。
引言
开发已经经历了几个阶段，从Native App 到 WebApp大火，再到苹果公司禁Web，又发展到了Hybrid的Web与原生共生。再到React Native，这种利用Js 转成原生的取中方案，本文将就58车商通介绍下RN在其中的应用场景，以及发展阶段。
RN特点
Learn Once,Write AnyWhere.
如下图：我们可以清楚的看到RN是构建在React和JSX的基础上的。
使用RN的优点及不足
一个新的挑战：如何将开发成本和用户体检做好更好的平衡呢？
上面已经说了简单说了一些RN开发的背景，接下来简单介绍下RN的特性及优缺点
RN特性：
a) 提供了原生控件支持
使用RN可以使用底层原生控件，iOS可以使用UITabBar、
UINavigationController等标准的iOS平台组件；在Android平台我们可以使用
Drawer控件；这样，就让我们的App从使用上和视觉上拥有像原生App一样的验
b) 异步执行
所有的JavaScript逻辑与原生平台之间的所有操作都采用异步执行模式，原生模
块使用额外线程
c) 触屏处理
RN引入了一个类似于iOS上Responder Chain响应链事件处理机制的响应体系，
并基于此为开发者提供了诸如TouchableHighlight等更高级的组件，实现了高性
能的图层点击与接触处理
但是，说到底RN毕竟也是前端基于JSCore通过Runtime机制或者反射机制来和Native端进行交互，所以RN还是有缺点存在的
RN缺点以及不足：
1. 首先来说现在业内对于React Native的项目更新还是个很大的问题，58车商通现在使用的版本是0.53，如果我们想升级RN那必须发版，并且基础库以及各个业务模块可能都会受到影响。
2. React Native 的列表性能较差（不是滑动效果，是内存占用方面），如果cell 很多，那容易崩溃，原因是RN的list控件不像Native 端有重用机制，不过现在业内借鉴native的重用机制的思路也有解决方案，也是目前我们的一个优化方向
3. React Native 的调用基于JSCore 和 Runtime的消息转发机制，所以调起Native的组件，仍然是有一定的延迟，这个也是RN的一个瓶颈或者说上限，这也是为什么大家会说RN的效率是非常接近原生，但是远远高于WebApp的原因。
4. React Native 和Native 端是异步调用，所以有些操作必须要屏蔽用户操作行为，不过这个问题目前带来的问题影响很小
其实，综上来说，React Native 的开发总体上还是利远大于弊，而且，热更新对于App的Native开发，尤其是 iOS开发来说，价值很大，所以我们选择落地RN项目，并实际运用到车商通中来。
58车商通RN模块整体技术架构
车商通RN整体分为三个部分：
- 客户端：提供部分基础组件、提供交互协议、支持UI渲染展示页面
- 服务端：提供业务接口、提供项目bundle下载地址
- 热更新平台：提供项目bundle文件、支持更新、回滚
58车商通客户端设计和开发
客户端整体框架如下：
1. 入口组件
每个应用程序都有一个对应的入口文件，前端页面的开发项目目录如下：
index.js是Android和iOS渲染前端UI的统一入口
import { AppRegistry } from "react-native";import App from "./src/index"; //业务口AppRegistry.registerComponent("入口名字", () => App);把当前APP的前端UI对象注册到AppRegistry组件中；
- AppRegistry 是运行所有 React Native 应用程序的 JS 入口点
- 应用程序入口组件需要通过 AppRegistry.registerComponent 来注册它们自身
- 当注册完应用程序组件后，Native就会加载jsbundle文件并触发AppRegistry.runApplication运行应用
2. RN通信机制
这部分内容，其实网上的资料比较多，而我们结合源码，和已经一些已经公开的知识点，简单跟大家分享一下。后续如果大家感兴趣，可以在单拿出一篇文章来分析讨论。下面我们来简单看下RN从JS 端开始调起原生方法的原理（以OC为例）：
OC生成一张模块配置表，包含所有模块和模块里的方法，根据特定的标识宏（RCT_EXPORT_MODULE()），将可以暴露的方法暴露给JS。
OC-JS交互流程：（注：此图是网上的示意图，但是表达的意思很明确，所以借用一下）
1. js调用OC模块暴露出来的方法
2. 把调用方法分解为ModuleName、MethodName、arguments，再丢给MessageQueue处理
3. 把js的callback函数缓存在MessageQueue的一个成员变量里面，同时生成一个CallbackID来代表callback；在通过保存在MessageQueue的模块配置表把ModuleName、MethodName转成ModuleID、MethodID
4. 把ModuleID、MethodID、CallbackID和其他参数传给OC（JavaScriptCore）
5. OC接到消息，通过模块配置表拿到对于的模块和方法
6. RCTModuleMethod对js传过来的参数进行处理
7. OC模块方法执行完，执行block回调
8. 调用第6步中RCTModuleMethod生成的block
以上就是通信交互整个流程，但是在实际业务开发中我们发现，RN提供的基础组件已经不能满足我们的业务开发，部分需要依赖native原生功能来实现比如：模块间的跳转、分享等，这就需要我们与native底层约定一些交互方法来满足各种各样的业务场景，基于此前端封装了一个中间交互的协议层。
3. 58车商通RN交互协议设计
协议层是native和前端对NativeModules进行了一些约定的封装和处理，方便业务使用。
目前前端协议层通过一下几种类型类集中封装的：
RN跳转类：
协议约定：
param = { action, params }; 也是固定两个参数 action:唯一确定调起的native组件，都是以CST开头的 如：action = "CSTLoadPageRNWeb"表示RN跳转H5 params:协议交互参数，每个协议都有不同的参数，具体协议的参数和native约定 如： 跳转H5协议传参 let params = { url, //h5链接 jumpParameter, //参数 isDestoryBeforePage, //当前页面是否销毁关闭 title, //页面titl ...other }; CSTRNHandler的第二个参数就是协议的回调函数，传入function类型 固定接收两个参数 (error, event) => { 第一个参数error是一个错误对象（没有发生错误的时候为 null）第二个参数event是native返回给前端的具体回调数据 (jsonString类型) }根据以上约定规则，下面来看一下前端具体的协议封装，以跳转H5页面为例 const nativeBridge = NativeModules.CSTRNComponent.CSTRNHandler; function loadPage( { url, isDestoryBeforePage = 0, jumpParameter, title, ...other }, disappearCallBack = (error, nativeData) => {}, //回调函数 action = "CSTLoadPageRNWeb" ) { let params = { url, //h5链接 jumpParameter, //参数 isDestoryBeforePage, //当前页面是否销毁关闭 title, //页面title ...other }; const error = checker( arguments, [ { url: "s|r", jumpParameter: "o", isDestoryBeforePage: "n", title: "s" },"f","s" ],"loadPage" ); // 线上环境报错不调起 Native 的 API if (error === "error") { return error; } let paramToNative = { action, params };nativeBridge(JSON.stringify(paramToNative), disappearCallBack);4.58车商通-RN UI页面开发
在上面我们大概了解了RN APP中的启动流程和交互方式，那么如何应用要我们的日常开发中能，下面来介绍一下前端的UI的开发。
1、本地开发流程
为保证RN版本的匹配，和一些代码规范的统一，在开发自己项目时需要克隆RN种子工程。在开发过程中需要使用到本地调试，下面我们看看iOS端调试。
2、本地调试
a) iOS模拟器启动页面：
b) 启动Chrome浏览器调试：
command+D弹出模拟器工具类 选择选项Debug Js Remotely
c) 浏览器自动打开链接：http://localhost:8081/debugger-ui/
这时能在浏览器上查看所有前端js代码了
d) 断点调试
打开目的js文件，找到要调试的函数，直接打断点，当执行该函数时就直接断点拦截了。
58车商通-RN落地服务端开发设计
服务端在整个RNAPP中承担的角色，就是为APP提供基本的数据接口服务和提供RN项目资源信息和下载地址；
此处就讲一下RN项目下载更新流程。
服务端接口返回数据模型：
{ "respData": { "h5Url": "", "business": { "version": "90", "remoteUrl": "https://j1.58cdn.com.cn/escstatic/rn/apptest/10021/android/10021_90_android_business.tgz" }, "resource": { "version": "90", "remoteUrl": "https://j1.58cdn.com.cn/escstatic/rn/apptest/10021/android/10021_90_android_assets.tgz" }, "bundleId": "10021", "unpacking": true, "downNow": false }, "respCode": 0}服务端流程如下:
58车商通-热更新平台设计
1. 热更新流程
在传统的web开发中，我们修改完js之后在浏览器上就能直接看到效果，JavaScript本身就是一门动态语言，并不需要编译，浏览器每次刷新都拉取新的js文件；针对web应用最简单也最有效的优化就是缓存，当js没有更新，浏览器就不需要下载新的js文件；
在RN实现动态更新也是同样的思路，RN中前端JS代码最终都会打包成jsbundle文件，我们在需求更新时，在应用中从远程下载这个文件，并重新加载，就可以完成动态更新同时无需通过App Store重新发布；
APP RN资源更新流程：
1、 APP启动时：
2、 启动项目时：
所有前面的更新流程都会依赖于前端的RN资源，那么下面我们来看一下如何把一个项目在平台上录入、编译打包和上线的。
2. 平台资源录入
在项目开发完成，提交到公司Git代码仓库，就可以使用RN资源管理平台录入资源了；
平台功能如下：
项目录入：
在填写完信息后，平台会根据填写的git地址，把当前项目代码下载到服务器，并npm install安装当前项目需要的所有依赖；这个过程因为需要安装项目依赖，所以时间比较长，项目初始化完成就可以对项目编译打包了；
信息录入时，会为每个项目分配一个唯一的ID，也是客户端区分项目的唯一标识。
3. 58车商通-RN打包编译流程
RN项目编译打包流程：
打包产物jsbundle
打包之后JSBundle文件的结构，基本分为3部分：
在RN打包过程中，解析依赖关系，为每个模块添加一个id：
1、需求
在实际的RN业务开发中，我们会涉及到很多个业务，这些业务基本上也不会耦合，这时我们就需要创建多个RN项目，每个项目编译打包成独立的bundle；对于RN APP来说，即使只有一个helloworld页面，在使用官方命令react-native bundle打出来的jsbundle文件大约为530KB以上，RN依赖模块本身就占了99%以上；如果更新的话，需要从网络上拉取整个包下载时间长，还会海鸥飞用户流量，每次进入RN页面还都要执行RN基础模块的定义；在RN项目开发中基础库react和react-native是不变的，我们可以抽离这两个依赖打成common.bundle内置于APP中；
2、目标
- 抽离react和react-native打包成common.bundle
- 减小线上下发业务bundle体积，减少下载时间、节省用户流量
- 可预加载common.bundle，提升打开页面速度
3、分析
- 通过分析bundle结构和依赖查找，最终可以通过标记法进行分包
- 打包bundle时，根据entryFile进行深度遍历依赖分析，模块id不断递增，即越早引用的模块，id越小
- 在分析依赖时标记哪些模块属于common.bundle，哪些模块属于业务bundle
- 打包时先引入base.js保证common.bundle的模块id都在前面，先收集common.bundle的模块
- 在遍历进行依赖收集，输出业务bundle
//base.jsimport React, { Component } from "react";import {} from "react-native";4. 拆分打包流程
编译打包之后本地项目打包结果如下：
iOS端：
Android端:
5. 小结
优点：
- 一次性打包输出common.bundle和业务bundle，效率高
- 用户只需下载业务bundle，减少流量消耗和下载时间
缺点：
- 直接引用react-native作为基础，common中可能会引入一些用不到的模块
总体上利大于弊，开发中也不可预知需要用到react-native哪些模块，直接打包一个全集也未尝不可。
6. 项目提测、上线
项目提测流程：
项目上线流程：
7. 项目回滚
在日常开发中，纵然有多轮测试，也避免不了发布到线上不会存在问题，我们传统的解决方案就是定位问题，找出原因，解决完之后重新发布上线；如果是一个流量很大的需求，同时又出现了线上不容易解决的问题，此时线上就会出现长时间的功能无法使用的情况；这是我们就可以考虑到回滚，先把项目回滚到一个可用的版本，然后再来解决自己的问题。
RN项目回滚流程如下：
8. 展望
理论上我们还可以指定规则，解耦业务，根据不同的业务模块，划分出更多的bundle，每个bundle的模块id按照某个值开始，避免重复，类似android插件化处理资源id策略，按需加载业务bundle。
采坑
俗话说工欲善其事，必现踩其坑，下面我们分享一下我们在实践过程中遇到的坑：
1. 统一封装RN Fetch请求时android底层报错
作为前端开发人员，网络请求工具对大家来说肯定不陌生。iOS的AFNetworking，Android的okHttp等。但是对于RN来说，我们最常用到的就是js原生的Fetch请求了。
React Native提供了和web标准一致的Fetch API，用于满足开发者访问网络的需求。
错误原因：
在封装RN fetch请求时header进行了统一设置设置如下：
在实际请求时android底层抛异常 如下：
查看RN Android底层源码看到 RN的fetch请求在Android底层Content-Type只支持multipart/form-data类型。
但是iOS底层支持application/json、text/plain、application/x-www-form-urlencoded类型；不支持multipart/form-data。
解决方案：
在封装是需要分端去指定当前请求头，android端headers中Content-Type只能是multipart/form-data
2. Android端Fetch POST请求无参数时，报异常
错误原因：
前端统一封装POST请求如下：
如果POST请求无需传参 此时FormData如下：
FormData {_parts: Array(0)}
Android底层会报错，错误如下：
解决方案：
前端兼容POST参数，如果POST请求无需传参 也就是params为空时，前端拼接一个空的part，part的key、value值都置为空。
3. RN页面数据注入问题
3.1、页面props注入
iOS端：
通过RCTRootView的初始化函数你可以将任意属性传递给React Native应用。参数initialProperties必须是NSDictionary的一个实例。这一字典参数会在内部被转化为一个可供JS组件调用的JSON对象。
android端：
android底层目前无法实现参数注入的形式。
在实际业务开发中也无法使用此方面来实现RN页面的数据注入。
3.2、使用消息监听的方式
iOS端：
前端监听：
OC端需要自定义实现消息监听模块，在前端首次调用消息监听时OC端去注册监听事件，此时不会执行前端监听回调，需要前端再次调用监听事件。
android端：
前端监听：
android端消息监听使用的是RN封装的DeviceEventEmitter消息监听事件，可以在android端直接通过sendEvent方法发送广播消息，前端监听接收，实现消息的收发。
消息监听的方式整体的是可行的方案，但是android端和iOS端消息监听的实现差异太大，无法做到两端统一，此方案也不是可选的最优方案。
3.3、事件交互获取数据
最终我们的实现方案是前端和native端定义双方交互事件，通过native事件通信的方式去获取RN页面想要的数据。
4. iOS 端内存不释放
在测试过程中我们发现，iOS端在数次退出进入RN模块后会崩溃，纠其原因是
bridge没有释放，需要我们释放一下
总结
本文总结了RN在58车商通的应用场景以及整体设计流程，还包括热更新的几个阶段设计，从业务和技术两个方面进行了阐述。后续会持续的更新RN系列。如果后续同学们想研究下RN的底层实现，我们可以在发一篇文章共大家参考。
经过大家的共同努力，我们终于在车商通3.7.3期顺利上线了两个RN模块，但是我们也还有很多优化的空间。后续我们也会持续跟进。目前思路是从以下几个方面来继续优化
1. 前端工作，优化列表控件。目前的列表性能还不是特别好，还需要下一步继续优化
2. 热更新继续深入优化，最终做到增量更新（任重而道远）。
3. 优化首屏加载白屏的问题，需要native 端与前端一起来做。
4. native 内部代码结构还需要进一步调整，重构代码。
由于我们的RN 项目是先在公司的主站RN项目开源前落地并开发完成的，目前阶段，我们还没有做更深一步的差量化更新（以补丁包的形式下发更新），所以，深度上讲我们目前没有涉及更深层次。如今，公司主站App，更加成熟的RN体系已经开源，我们可以借鉴或者应用更加成熟的RN体系到应用的到项目中，以提高App的开发效率，缩短更新流程，降低更新风险
参考文章
1. ReactNative中文网
2. ReactNative GitHub源码
3. Fetch API
作者简介
桑锐/58同城/ iOS高级开发工程师
龚成辉 /58同城/ 前端高级开发工程师
END
阅读推荐
2.深度｜数据智能在二手车业务场景中的探索与沉淀——关于用户流量的预测与识别