首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >干货 | 近万字长文详述携程大规模应用RN的工程化实践

干货 | 近万字长文详述携程大规模应用RN的工程化实践

作者头像
携程技术
发布2019-04-22 10:12:33
1.4K0
发布2019-04-22 10:12:33
举报
文章被收录于专栏:携程技术携程技术

作者简介

赵辛贵,携程无线平台研发部开发总监。2013年加入携程,主要负责App基础框架研发相关工作,目前重点关注React Native技术在公司的推广和研发支持、无线框架和工程架构升级。

本文来自赵辛贵在“2018携程技术峰会”上的分享。

一、RN在携程的使用情况

2015年3月React Native iOS开源,半年之后Android开源。携程于2016年6月份投入资源在React Native框架的预研,并于8月份正式上线,至今已有2年多。

随着业务使用的复杂度增加,各种问题随之而来,我们就这些问题一一提供解决方案,并建设相关配套系统来支撑业务开发团队使用。本文将从携程内部对RN(ReactNative简称,下同)的性能稳定性优化以及相关基础设施的建设来做分享。

截止2018年9月底,使用情况大致如下:

广泛使用: 生产环境总共有104个RN业务Bundle,其中携程旅行App中运行的有83个,其它21个运行在公司内其它独立App中,比如Trip.com、铁友智行等。从2016年8月份上线至今,PV以同比300%的增速增长,其日PV量已是传统H5 Hybrid技术的近2倍。

深度使用: 全流程使用,比如特价机票、特价酒店、国际机票、租车、旅拍等,已是全流程使用RN开发。复杂度高,火车票模块,5.8MB的js代码(uglify压缩后),超过100个页面,都打包在一个业务Bundle中。

总的来说,RN在携程已经广泛使用于生产环境,并得到业务和用户的认可。

二、CRN框架

我们基于React Native框架优化,定制成适合携程业务的跨平台开发框架 - CRN,提供从开发、发布、运维的全生命周期支持。

  • 开发框架,主要是提供在开发阶段的支持。包括工具&文档、组件和解决方案、跨平台打通和代码托管功能。 工具主要包括CLI和Packer,文档包括API文档和设计文档,跨平台主要是抹平平台差异组件间的API,代码托管是为了方便业务团队,特别是新加入CRN开发的团队,可以参考已有业务代码快速上手。
  • 性能优化,主要是为了解决首屏渲染的性能问题和RN框架的稳定性问题。为了解决首屏渲染性能问题,我们先后开发了框架拆分和预加载、业务按需加载、业务预加载和渐进式渲染方案,稍后会就这些方案做详细介绍。
  • 发布运维,主要是提供发布系统和性能、错误监控平台,让业务开发同事能够有完备的系统去发现和解决线上问题。

下面会从这几个方面详细介绍。

2.1 开发框架

以下是我们的crn-cli脚手架,对RN原始的CLI进行二次包装,提供从工程创建,服务启动,在已集成框架的App运行RN代码等常用功能,方便开发人员快速上手。

Commands:
  init                   建立并初始化CRN工程,可指定appId,默认为携程App
  start                  启动CRN服务,默认端口5389   
   run-ios                运行指定appId的IOS App
  run-android            运行指定appId的Android App
  run-patch              执行patch,替换CRN修改过的lib文件
  cli-update             更新cli版本
  example                创建CRN组件和API调用Demo工程
  aux                    增强型功能入口:log Server、本地打包、上传开发包等Options:
  -h, --help             显示命令帮助
  -v, --version          显示版本

文档方面,我们提供API文档和设计文档

API文档采用YUI doc根据代码注释自动生成,该文档中主要记录新增组件以及使用示例。

设计文档,主要包含一些组件/API的设计文档,常见问题解决方案,业务开发常见问题都可以再该文档站点找到对应的解决方案。

2.2 组件和解决方案

提供100多个业务和公共组件支持,并保证跨平台提供一致API。

三、CRN性能优化

在具体介绍性能优化方案之前,先看2段Demo视频,两段视频是同一份代码的运行效果,一份使用原始版本RN打包运行,另一份使用CRN打包运行。选择同一台测试机(2015年老款SumSung S6 Edge+,Android7.0系统),为确保环境尽可能一直,在每次运行Demo前,均清空所有后台程序。

原始版本RN运行Demo

CRN优化后运行Demo

分享具体性能优化措施前,先来解释几个基本概念。

  • React Native打包是符合commonjs规范的,参考下面的代码:
// moduleA.js
module.exports = function( value ){    
return value * 2;
}

// moduleB.js
var multiplyBy2 = require('./moduleA');
var result = multiplyBy2(4);

简单地说,模块必须通过module.exports导出对外的接口或者变量,通过require()导入其他模块,并同步加载该导入的模块。

  • define

简化版define实现如下

function define(moduleId, factory) {    if (moduleId in modules) {        return;
   }
   modules[moduleId] = {
       factory:factory,
       hasError:false,
       isInitialized:false,
       exports: undefined
   }
}

可以看到define仅仅是将模块代码嵌入到factory中,cache到modules对象内部,并未真正执行。

  • require

简化版require实现如下:

function require(moduleId) {    
var module = modules[moduleId];    
return (module && module.isInitialized)?module.exports:
   guardedLoadModule(moduleId, module);//代码执行,并赋值给module.exports
}

可以看到,require是真正模块代码执行的点,JS模块数越多,耗时越长。guardedLoadModule内部会使用try/catch包裹去执行模块代码,此处可以捕获所有模块的代码异常,RN内部的js错误,都是从此处抛出。

  • import

import在bundle编译前后的示例代码如下:

/*源码*/
import page1 from './src/Page1.js'
import page2 from './src/Page2.js'

/*编译后*/
var _Page = require(662); //662=./src/Page1.js
var _Page2 = _interopRequireDefault(_Page);
var _Page3 = require(663); //662=./src/Page2.js
var _Page4 = _interopRequireDefault(_Page3);

简单地说,编译后import等价于require。

  • 页面加载流程

以上是一个RN页面加载的全流程,首选是Native容器的创建,接着是下载安装最新包(如果有的话),之后开始CRN框架(包含Native和JS组件)加载,框架加载完成之后,加载业务代码,计算页面虚拟dom,通知Native进行页面首次渲染,如果有网络请求,请求完成之后,再次渲染。

灰色部分是可选的,真实RN页面的渲染性能包含4、5、6三部分,针对这三部分,我们提供了不同的性能优化方案。

  • CRN框架加载:框架和业务代码拆分、框架代码预加载、JSC执行引擎缓存
  • 业务代码加载:业务代码按需加载、业务代码预加载
  • 业务页面渲染:渐进式渲染、骨架图预渲染

接下来我们一一介绍。

3.1 CRN框架加载的优化

先看下react-native bundle命令打包之后的bundle文件结构

//头部 - 全局变量定义
(function(global) {    
global.require = _require;    
global.__d = define; /*...code... */
})(typeof global !== 'undefined' ? global : typeof self !== 'undefined' ? self:this);

//中间 -- 各模块定义部分
__d(/* demo/index.ios.js */function(global, require, module, exports) {    
    var _React Native = require(12); // 12 = react-native
   var theCompnent = require(524); // 524 = ./main
   _React Native.AppRegistry.registerComponent('Demo', function () {return theCompnent;});  
   module.exports = theCompnent;
   }, 0, null, "crn-demo/index.ios.js");__d(/* react-native-implementation */function(global, require, module, exports) {    
    var React Native = {/*...code... */}
   module.exports = React Native;
   }, 12, null, "react-native-implementation");  

// 尾部 -- 引擎初始化和入口模块执行
;require(50); //50为InitializeJavaScriptAppEngine模块
;require(0); //0为入口Component模块

结构可以简化为三部分:

  • 为头部全局变量定义;
  • 中间框架/业务模块定义;
  • 尾部引擎初始化/入口函数调用;
3.1.1 框架和业务代码拆分

先来看看我们打包之后的文件目录结构

//框架包rn_common目录结构
rn_common    
       ├── common_android.js  //Android CRN框架代码,包括RN+CRN扩展JS组件+常用第三方组件
   ├── common_ios.js      //iOS CRN框架代码,包括RN+CRN扩展JS组件+常用第三方组件
   └── pack.config        //打包日志文件,记录打包时间,RN版本,App版本等信息

//业务包rn_flight_booking目录结构
rn_flight_booking    
       ├── _crn_config_v2   //配置文件,记录业务代码所在文件夹,默认是js-modules,同时记录业务代码入口模块文件名
   ├── _crn_unbundle    //CRN打包格式标识文件,该文件存在时候,才当做CRN包格式加载
   ├── assets/          //图片资源目录,定制过资源打包/加载流程,iOS/Android目录一致
   ├── fonts/           //字体文件目录,每个js模块一个文件,文件名为模块ID.js
   ├── js-diffs/        //Android和iOS平台差异代码,Android优先加载该文件夹中的业务代码
   ├── js-modules/      //业务js代码目录
   └── pack.config      //打包日志文件,记录打包时间,RN版本,App版本等信息

rn_common为框架包,可以再后台线程加载,业务包在进入业务的时候才开始加载。

打包部分:

  • 生成框架jsbundle

业务代码拆分主要是把中间框架/业务模块定义给拆分开来,拆分的思路很简单,用一个空白页面作为入口点,AppRegistry.registerComponent加载这个入口点。进入业务时,通过这个入口点页面去加载真实的业务代码。把这个空白的入口点页面作为框架的一部分,通过react-native bundle命令打包成框架jsbundle。

  • 抽取业务js代码

对React Native unbundle的打包过程进行定制,首先让iOS支持unbundle打包(默认是不支持的), 将生成的业务js模块代码单独保存,每个js模块一个文件,文件名即为模块ID.js;

  • js模块加载优化

空白页面入口组件,要能加载(require)真实的业务代码,我们需要改造RN的require方法,简单修改Native SDK中的JSCExecutor(RCTJSCExecutor.mm/JSCExecutor.cpp)文件,调整nativeRequire实现即可。

3.1.2 框架代码预加载

RN框架instance

RCTBridge/ReactInstanceManager(后文统称为instance)是RN框架中核心的2个类,这个类分别控制不同平台的JavaScriptCore的执行,同时又都是各自平台ReactView的属性,View的显示于事件靠它来驱动。

所以为了能做到后台预加载js代码,首先要做的就是解开台ReactView和instance之间的耦合解开,能让instance在后台独立加载。处理起来不复杂,只需要对ReactRootView/RCTRootView接口做简单调整即可。

上图是我们定义的CRN框架instance的生命周期状态:

  • 框架加载过程,标记为Loading状态
  • 框架加载完成,标记为Ready状态
  • 框架引擎被业务使用,标记为Dirty状态
  • 框架在加载或者业务使用过程中出了异常,会被标记为Error状态

App启动,我们就会预创建一个框架引擎的instance,创建完成,状态标记为Ready并缓存起来,进入业务时候,会优先使用这个缓存的instance去加载业务代码,这个时候进入业务页面,只有业务代码的加载执行时间。当这个缓存的Ready状态的instance被使用之后,后台立即再创建一个,以备后续业务使用。

根据线上数据统计,我们发现95%的场景,都能直接使用到后台预创建好的框架instance,或者是已经加载过业务的instance。也就是说,进入业务页面,只有5%的用户,需要耗时间加载RN框架代码。

3.1.3 业务instance缓存

对于加载过业务代码的框架instance,在用户离开业务时候,会暂时缓存住,这样如果重复进入页面,少了业务代码的加载执行,打开速度提升明显。当暂存的加载过业务的instance数量超过2个时,会按照创建时间顺序,回收掉最早创建的instance。根据线上数据统计,有15%的场景,都会使用到的加载了业务代码的instance。

框架代码的加载优化已基本完成,来看我们当时测试的一组数据。

3.1.4 一组数据

上图是2016年10月,基于RN 0.30版本,在iPhone 6 和Sony Xperia Z5机型上,多次测试的平均数据。可以看到,优化后,首屏时间比原来都减少45%左右。后续我们升级0.41,0.51版本,该优化都一直在做,方案和思路都是一样的。

3.2 业务代码加载优化

业务代码加载优化我们主要从2个方面考虑,业务代码按需加载和预加载,先简单解释两者的差别

按需加载:是进入业务模块时候,只加载对应页面的代码

预加载: 是尚未进入业务模块前,即把需要进入业务页面的代码在后台加载执行掉

3.2.1 业务代码按需加载
LazyRequire按需加载方案

先来看一段我们初始化页面路由表的代码

import PageA from ("pages/PageA");
import PageB from ("pages/PageB");
import PageC from ("pages/PageC");
import PageD from ("pages/PageD");

//设置页面路由表
let pageList = [PageA, PageB, PageC, PageD];
App.startApp(pageList);

早期业务简单,页面数量少,上面的优化方案已经可以是RN基本达到native的体验,但是随着业务越来越复杂(当时有业务bundle,包含70多个Page js代码uglify之后达到3MB),首屏加载慢的问题又出来,为此我们实现一种懒加载的方案,进入业务时候,只加载当前需要显示的Page的代码, 对业务的使用非常简单,下面是我们懒加载的页面路由代码写法。

const PageA = lazyRequire("pages/PageA");
const PageB = lazyRequire("pages/PageB");
const PageC = lazyRequire("pages/PageC");
const PageD = lazyRequire("pages/PageD");
//设置页面路由表
let pageList = [PageA, PageB, PageC, PageD];
App.startApp(pageList);

对业务开发来说,切换成本非常低,只需要使用lazyRequire函数替代import指令。怎么做到的呢,其实也很简单。

//LazyRequire函数定义,返回lazyModule对象
LazyModule lazyRequire(path)

LazyModule = {
   load(); //代码真正执行的点,返回执行结果
}

细心的同学可能发现这里有个问题,lazyRequire函数传入的文件相对路径,打包之后,还是相对路径,而打包完成之后,每个业务js模块都被打成模块ID.js文件,这会导致运行时查找不到这些业务页面的模块。是的,在打包过程中,需要开发一个babel插件,将lazyRequire函数例的文件路径,转换成模块ID,实现方式和import 的babel插件基本一致。

随着业务代码增加,进入首屏需要加载(require)的代码会增加,前面分析过,require会导致JS代码的执行,是耗时的操作,最终导致首屏变慢。所以,我们就想,进入业务的时候,只加载第一个Page相关的代码,其他页面的,路由跳转过去的时候再加载。

Getter API导出模块

我们先来看看React Native模块内的组件导出方式:

//原始代码如下
//Module1.js
console.log("Start load module1");
module.exports = {    
doJob:()=> {        
console.log("doJob called in module1");
   }
}

//Module2.js
import Module1 from "./Module1";
//执行结果:Start load module1

这是最常见的模块导出和引用方式,和我们前面说的一样,import的时候,实际上会去执行对应的代码。接下来,我们创建一个common.js(文件名无限制),修改下模块的导出方式,参考下面的代码。

//common.js
module.exports = {    
get Module1() {        
return require('./Module1');
   }
}

//回到Module2.js的引用
import Module1 from "./common";
//执行结果:没打印任何日志

Module1.doJob();
//执行结果: 打印以下两条日志
//Start load module1
//doJob called in module1

可以看到,通过ES5的getter API来导出模块,在引用时,代码不会立即执行,直到导出对象真正使用时候,才开始执行。所以如果我们有自己的公共组件,多个业务都需要用到,那么使用getter API导出模块是一种不错的选择。其实RN里面的ReactNative模块导出方式也是这样,参考下面的代码。

const ReactNative = {    
get ActivityIndicator() { return require('ActivityIndicator'); },    
get ART() { return require('React NativeART'); },    
get DatePickerIOS() { return require('DatePickerIOS'); },    
get DrawerLayoutAndroid() { return require('DrawerLayoutAndroid'); },    
get Image() { return require('Image'); },    
get ListView() { return require('ListView'); },    
//...
}  
module.exports = React Native;

通过getter API导出模块实现按需加载是ES5默认支持的,对原始RN没有任何侵入性修改,是比较推荐的一种方案。

那我们为何需要LazyRequire呢?很明显,使用getter API导出替换LazyRequire是可行的,只是达到不了按需加载的功效了,因为在赋值页面路由表的时候,需要用到所有的Page对象,用到这些对象的时候,会直接触发所有Page的代码加载执行。

inlineRequire方案

方案很简单,预先定义模块对象,赋值为null,在使用时候判断对象是否为null,null时候则做真正的require,进行模块加载。看一段简单示例代码。

let VeryExpensiveModule = null;export default class Optimized extends Component {
   someEvent = ()=>{        
        if (VeryExpensiveModule == null) {            
            //require('path').default, 动态加载模块代码
           VeryExpensiveModule = require('./VeryExpensive').default;
       }
   }
}

3.2.2 工具和数据

为了能方便业务开发同事快速定位到具体是哪个js模块加载耗时长,以及具体的调用链是怎样的,我们开发了CRN Require Profile Tool

如上图所示,业务开发同学,很容易就发现是哪个模块加载耗时长,需要使用按需加载。

按需加载方案是2017年,基于RN 0.41版本开发的,当时上线前我们也做过首屏性能测试, 数据是iOS模拟器上跑出来的,由于首次进入业务加载的页面数量猛降,所以首屏时间减少了2/3。由于这个优化是在JS层做的优化,iOS、Android性能提示基本一致。

3.3 业务代码预加载

经常有这样的业务场景,A流程订单完成之后,有B产品推荐,A、B业务代码在不同的RN bundle里面,A业务开发完,希望能把B业务在后台加载掉,这样用户打开B业务首屏速度会更快。为此,我们提供了业务预加载方案。主要两个点,预加载和缓存。

预加载有前面框架代码拆分和预加载的基础,实现起来非常简单,基本没有改造成本。为了能让尽可能多的代码实现预加载,我们在LazyRequire里面添加逻辑,让在预加载状态模式下,LazyRequire等价于Require,强制加载。

缓存,先前业务代码的缓存是按照业务的URL作为key来存储的,预加载模式下为了尽可能提高缓存的命中率,我们将缓存的key统一成业务bundle名,同一业务,同一缓存,这么操作需要业务开发代码也要注意,避免全局变量的使用。

缓存的另外一个问题就是内存占用,我们在提供业务预加载的时候,用一个全局数组来缓存业务instance,超过限制,或者内存警告时候,会按照LRU策略清理没有使用的instance。实际测试下来,Android平台,预加载一个业务,会增加2MB左右内存(包括框架和业务代码都加载完),而渲染一个正常页面,占用约20MB内存,其中最主要的内存被图片占用。

先前同事在开发这个方案的时候我没在意性能数据,简单测试了下,发现效果非常不错,对于一般页面,业务代码提前预加载后,性能可以达到和native基本一致。我们使用了荣耀7X(千元机,性能偏中低端)进行测试,已经基本感知不到首屏加载和native有什么差别了。

3.4 业务页面渲染

我们发现,随着页面复杂度增加,渲染耗时逐渐增加,这也可以理解,要完成页面渲染,需要计算vitrual dom的diff,传输数据给native,如果数据传输有延迟,就会出现掉帧,为了让页面尽可能快的显示,我们需要简化首次渲染。

渐进式渲染

策略很简单,先渲染header部分,setTimeout去渲染其余部分,如果是listview/scrollview,先渲染屏幕可视区域,在滑动时候,再渲染其他区域。下面一个demo视频,我们看下。

骨架图

先渲染骨架图,由于骨架图相对简单,渲染很快,待请求数据返回后重新渲染界面。骨架图目前没有好的自动渲染框架,需要页面开发同学,根据页面样式,自行开发。

四、发布与运维

一个成熟完善的开发框架,是需要各种配套系统支撑的。我们也为CRN开发框架提供了多个内部系统,下面来介绍其中的主要几个。

4.1 发布系统

上图是我们的发布系统页面截图,除了常规的按照版本/平台/环境发布、灰度、回滚支持,我们还增加了发布结果和实时到达率的的报表,方便发布之后,对发布效果评估。

几点说明:

1、不同环境,按照顺便发布,首先发布FAT(开发环境)、测试通过再发UAT(跨业务测试环境)、测试通过再发PRD(生产)。真正的打包只在第一个环境打包,后续的环境都是直接发布前一环境的打包产物,避免重复打包导致的不一致问题,同时也提高发布效率;

2、跨RN版本,不支持同时发布,避免新版本RN代码发布到老的RN版本上,直接在发布系统选择版本的时候做了控制,不能选择2个不同RN版本的App;

3、控制发布版本数量,创建发布单时候,可以选择多个版本,经常有发布的同学为了简单,一键勾选所有版本,实际上老版本可能用户量非常小,而回归测试却覆盖不到所有版本,为了避免老版本因为测试不重复导致的问题,我们将版本选择功能做了优化,按照UV数量排序,并在版本后面显示UV比例,同时默认只能选择Top5版本,如果要发布更多版本,需要点击更多,展开其他版本。

监控指标:

1、发布结果:发布之后,分平台、App版本展示下载到这个包的成功、失败次数,以及失败的原因分布。

2、实时到达率:这个是业务最应该关注的数据,数据直观的展示,发布之后,实时的有多少比例的用户已经用到最新包。

为了提高实时到达率,我们在打包过程中记录业务模块ID和文件名之间的映射,这样可以避免新增文件出现的的大量JS文件的文件名(即为模块ID)变化,从而导致的差分包过大问题。做到只下发真实变更和新增的文件内容。通过线上数据分析,所有首页入口的RN模块,新版本发布之后,有85%的实时到达率,二级及以上入口,实时到达率可以达到97%。

4.2 性能报表

统计线上业务首屏加载的耗时趋势、分布和使用量,可以支持按照App/版本/系统过滤查看。

首屏首次渲染完成的时间点,可以在在下面2个点添加事件,抛给外层统计。

//基于RN 0.51版本
//Android ReactRootView.java 添加dispatchDraw方法
protected void dispatchDraw (Canvas canvas){    
//相对准确,可能会调用多次,内部要做好判断
}

//iOS RCTRootContentView.java
- (void)insertReactSubview:(UIView *)subview atIndex:(NSInteger)atIndex{    
//准确,RN自带的profile工具里面的TT时间,也是以此处为结束点
}

4.3 错误报表

用于收集客户端上报的RN错误,包括JS执行异常,或者是native runtime的一些异常,在业务模块发布之后,必须要到此平台确认自己的发布稳定性是否正常。

除了常规的版本、业务、平台功率,我们在错误堆栈详情页面,还将当前出错的业务包版本和打包记录关联起来,方便开发人员排查问题。

五、其他实践经验

5.1 版本升级

从2016年8月至今,总共更新0.28-0.30-0.41-0.51四个官方RN版本,除0.28是调研阶段仅使用两个月,其他都使用半年以上。整体升级相对可控,除0.41升级0.51,因为有PopertyType组件的移除,需要业务做些适配,其他版本升级对业务都是基本透明的,仅需常规回归测试。

升级流程上,首先是框架团队前期验证(包括打包,SDK定制,发布,监控全流程确认)、制定升级方案和时间点,接下来是业务团队配合升级和新版本发布,最后是框架团队确认所有业务都在新的RN版本重新打包发布过。

升级成本来说,框架团队大约需要3名工程师(iOS/Android/前端各1人),2-3周时间,业务升级和回归测试,一般可在一周内完成。

升级频率上,由于使用的业务团队太多,频繁的升级会对业务造成影响,为了尽可能对业务开发友好,大约8-12个月会升级一个RN重要版本。当然,如果是有重大的性能升级,比如RN frabic的重构版本,我们也会第一时间跟进升级。

5.2 第三方组件版本管理

先看看npm模块的版本规则:major.minor.patch, package.json支持模糊版本,比如>,>=,<,<=,~,^,.x,*, 其他都比较好理解,~,^简单解释下(完整本的版本说明参考semver )

//举例说明
~0.2.0 匹配 [0.2.0, 0.3.0), 有minor, 最大版本为minor+1, major不变,patch为0
~0     匹配 [0.0.0, 1.0.0), 无minor, 最大版本为major+1, minor,patch为0
^0.2.0 匹配 [0.2.0, 0.3.0), 最大版本为左侧第一个不为0的版本号+1
^1.2.0 匹配 [1.2.0, 2.0.0),

我们再看下react-native-recyclerview-list这个组件, 组件版本和依赖的RN版本关系如下。

如果我们使用的RN是0.47版本,对这个库的依赖方式写成^0.2.0, 当组件版本发布到0.2.2时候,都使用的很正常,一旦0.2.3版本发布,如果再打包发布,则会出现不兼容问题,线上会出大量JS报错。

我们就在生产环境出现过类似问题。为了避免类似问题,我们在打包之前做了preBuildCheck,检测第三方组件的依赖版本,凡是不使用固定版本的,直接报错。

5.3 分平台打包

目的是抹平组件的平台差异,解决资源加载路径不一致的问题。很长一段时间,我们iOS/Android的业务代码,只打一次包,以iOS平台打包。因为涉及到Native代码的新组建的引入,都是由框架团队控制,所以一直以来都没出什么问题。直到公司内部独立App,他们引入的第三方组件iOS/Android有差异,导致发布之后在Android上运行有问题。

分平台打包之后,先打包iOS,再打包Android,将差异代码存储在js-diff目录,加载时,Andorid先在js-diff中查找模块,查找得到直接使用,如果查找不到,再在默认的js-modules文件夹中查找。iOS则只在js-modules文件夹中进行模块查找。

5.4 稳定性优化

iOS平台相对简单,注意解决以下两个API相关问题后,绝大部分问题都好处理。

//自己注册错误handler,在此处去进行日志上报,并持续优化
void RCTSetFatalHandler(RCTFatalHandler fatalHandler);

//iOS所有错误都是通过此次抛出
void RCTFatal(NSError *error);

iOS所有错误都是通过此次抛出 void RCTFatal(NSError *error); ``` iOS RN注意事项:

  • 必须要自己注册错误处理handler,否则一旦有RCTFatal抛出错误,生产环境会有Crash
  • 所有的错误都是RCTFatal抛出,为了方便排查问题,需要记录error的来源

Android RN相对复杂,主要注意事项:

  • so加载失败。简单处理可以在原有的LoadLibrary加上try/catch,并在catch中再load一次,能大幅度降低该问题导致的Crash;
  • ReactInstanceManager创建过程中的Native异常,是通过DevSupportManager传递出去,需要处理DefaultNativeModuleCallExceptionHandler的handleException方法
  • JS执行出错,都是通过ExceptionsManagerModule模块抛出,所以需要将该错误和ReactInstanceManager相关联,并抛给上层;
  • libjsc.so Crash,如果有做Native Crash收集,会在后台系统看到不少libjsc相关报错,这是由于RN自带的JavaScriptCore版本为2014年的版本,兼容性和稳定性较差,建议参考开源的jsc-android-buildscrips项目,将JavaScriptCore升级到2017年11月的版本(WebkitGTK Revision 225067),我们升级到该版本后,发现该错误降低了90%;

六、总结

CRN框架对原生RN的大量底层改造优化,解决了性能和稳定性两大核心问题,从落地效果来看,其性能可以做到和Naitve基本一致水平,而开发成本却大幅降低。

CRN框架已在业务团队中广泛使用,为业务的快速迭代提供了强有力支持。对于规模化业务开发团队,使用RN作为跨平台开发的解决方案,是切实可行的选择。

2019年,我们计划根据开发资源情况,适时开源CRN框架的部分模块。

本文参与 腾讯云自媒体分享计划,分享自微信公众号。
原始发表:2019-01-07,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 携程技术中心 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体分享计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 一、RN在携程的使用情况
  • 二、CRN框架
    • 2.1 开发框架
      • 2.2 组件和解决方案
      • 三、CRN性能优化
        • 3.1 CRN框架加载的优化
          • 3.1.1 框架和业务代码拆分
          • 3.1.2 框架代码预加载
          • 3.1.3 业务instance缓存
          • 3.1.4 一组数据
        • 3.2 业务代码加载优化
          • 3.2.1 业务代码按需加载
        • 3.3 业务代码预加载
          • 3.4 业务页面渲染
          • 四、发布与运维
            • 4.1 发布系统
              • 4.2 性能报表
                • 五、其他实践经验
                  • 5.1 版本升级
                  • 5.2 第三方组件版本管理
                  • 5.3 分平台打包
                  • 5.4 稳定性优化
              • 六、总结
              相关产品与服务
              腾讯云 BI
              腾讯云 BI(Business Intelligence,BI)提供从数据源接入、数据建模到数据可视化分析全流程的BI能力,帮助经营者快速获取决策数据依据。系统采用敏捷自助式设计,使用者仅需通过简单拖拽即可完成原本复杂的报表开发过程,并支持报表的分享、推送等企业协作场景。
              领券
              问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档