1、携程大规模应用React Native的工程化实践Topic面临的挑战和方案的选择ReactNative在携程的使用现状CRN框架的优化我们的经验与实践总结与未来展望为什么会使用RN开发成本动态更新社区资源相对较低支持动态更新相对成熟，社区活跃包大小性能体验占用AppSize小用户体验佳现状 业务广泛接入 携程旅行App，线上70+RN业务模块 大量上海品茶入口使用RN开发 PV占比超过H5 Hybrid 集团内多App已接入使用?现状 业务深度使用 核心业务、全流程使用Native转RNHybrid转RN 复杂业务高(火车票)710个JavaScript模块100个Page代码7z压缩后600K

2、BCRN框架介绍运行页面性能监控稳定性优化Lazy RequireBundle拆分文档组件开发代码仓库动态打包配置发布系统及监控运维CLI工具线上错误监控框架预加载CRN是基于RN定制，以实现开发友好、运行稳定高效、运维可监控的大前端开发框架。开发 CLI和文档支持 CLI和文档开发 组件扩展支持 70+API和UI组件支持 重写fetch、listview等组件 扩展ScrollView组件 跨容器(Native、Hybrid、RN)通讯支持 组件开发原则，RN优先，Native兜底开发 Event机制 Event机制解决多端通讯问题Event.addEventListener(name,c

3、allback)Event.removeEventListener(name)Event.sendEvent(name,data)基于Notification实现开发 统一Storage 统一Storage提供Storage.load(params,callback)Storage.remove(params)Storage.save(params)设计说明存取支持domain区分不同业务存取expireDate支持存取内置加解密支持开发 CRN Page模型 CRN Page 模型CRN 容器:包含ReactRootView业务Page继承自CRN Page基类CRN容器：CRNViewCo

4、ntroller/CRNActivityCRNPageACRNPageBCRNPageCCRN App开发 Page生命周期扩展 CRN Page生命周期扩展所有CRN页面继承同一Page基类解决和Native/Hybrid/其它RN业务模块页面切换无回调问题解决App前后台切换无回调问题同一CRN容器内不同Page间切换pageWillAppearpageDidAppearpageWillDisappearpageDidDisappearCRN新增cmpDidMountcmpWillUpdatecmpDidUpdatecmpWillUnmount常规组件生命周期cmpWillMount运行

5、Bundle拆分和Require优化为什么要拆分简单HelloWorld项目release打包520KB，压缩后147KB大量业务模块上线，size占用是问题为何要改造Require后台预加载提升首屏渲染时间支持动态按需加载运行 Bundle打包文件结构1.Global Define/Require.2.Module define.3.Require()Bundle结构抽象 官方命令打包出的Bundle运行 Bundle代码执行顺序1.Global Define/Require.2.Module define.3.Require()1.Global Define/Require.3.Requi

6、re().2.Module define代码执行顺序 官方命令打包出的Bundle运行 Android Unbundle打包 RN Android Unbundle打包所有模块都打包成独立文件运行 CRN Bundle拆分 CRN打包方案，合并common官方命令打包出的bundle运行 Bundle拆分之后的加载CRN Bundle拆分之后执行过程框架JavaScriptA目录ReactInstanceManager/Bridge(JavaScript Core)RequireLoad业务代码资源B目录运行 Bundle拆分之后的加载CRN Native Require实现官方Android

7、在unbundle打包的js-modules目录中查找执行官方iOS在一个preparePack打包的二进制bundle中查找执行CRN改造iOS平台的nativeRequire，支持从磁盘目录查找和执行模块运行 JS模块加载Define 和 Require加载JS模块运行 预加载RN业务加载的耗时分布 预加载Require是代码真正执行的点Require耗时长后台Require框架代码，提速首屏渲染运行 预加载提速首屏加载 首屏加载提速后台创建instance（JavaScriptCore实例）加载框架代码Instance被使用之后，创建新的首屏加载性能相较官方提升约45%283358380

8、6668482020040060080010001200?A?)?(?(?(?(?数据基于RN0.30，iPhone6Sony Xperia多次测试后台创建JSC执行框架代码后台创建JSC执行框架代码后台创建JSC执行框架代码进入业务A仅执行业务代码进入业务B仅执行业务代码Instance(JSC)预创建流程运行 业务复杂度增加导致的问题简单页面，JS模块少全业务使用，JS模块多，首屏加载依旧缓慢运行 业务复杂度增加导致的问题 首屏加载慢问题重现业务复杂度增加，代码量剧增import代码在打包过程会变成require 解决方案进入业务时，尽可能少执行

9、requireimport*from引用模块Require(id)执行模块代码Define(path,id)定义模块import模块的内部处理流程运行 LazyRequire方案 CRN LazyRequire实现开发阶段，LazyRequire等价于require接入阶段，CRN Page 只需替换import打包阶段，Babel插件将lazyRequire参数从path替换成模块ID运行阶段，Page在切换时候，框架loadLazyRequire的内部实现运行 LazyRequire方案 线上数据复杂业务首屏加载提升明显(右图)彻底解决了复杂业务使用CRN的问题54834540518017

10、500400500600123?(?)?)?数据基于RN0.41，iPhone Simulator多次测试运行 其它Require优化方案 inlineRequire方案定义全局变量，使用时，require并赋值 ES5构造函数ReactNative内部组件以此方式导出推荐使用这种方式稳定性优化 iOS 框架层设置错误处理handler不设置在生产环境会crash记录错误来源 业务层出错显示出错浮层，支持重试稳定性优化 Android JavaScript层DevSupportManager Native层NativeModuleCallExceptionHandlerS

11、O加载优化页面长时间加载不成功的优化稳定性优化 降级处理 优雅降级自动降级参数传递的风险降级策略定制 具体方案CRN原始URL：/rn_abc/index?pa=1&pb=2&px=x降级H5站点URL：http:/ 错误日志收集 错误日志收集系统实时上报错误JS/Native异常日志完整callstack展示可按照模块名、版本过滤支持报警配置发布之后需关注数据走势运维 性能统计 CRN性能统计系统按业务模块，版本统计首屏时间加载耗时比例分布展示运维 发布增量包优化 Diff方案对zip包内部的每一项进行bsdiff，保留变化过的文件，然后7z压缩 优化点充分利用CRN包格式优势保留业务模块i

12、d的mapping，避免新增模块而导致模块id全乱的情况运维 发布增量包优化 线上数据线上22个CRN增量包，总计325KB，平均每个包15KB发布后一小时，新包使用率达97-98%实践经验 版本升级 组件依赖管理 CRN包的依赖管理 分平台打包 导航栏的选择CRN版本升级2016年6月2016年8月2017年2月2018年2月0.510.410.300.28CRN版本升级历程CRN版本升级 升级流程 升级成本框架团队成本2-3周业务升级一周完成 其它升级方案尽可能对业务简单避免业务包做跨RN版本的发布升级频率8-12个月/次框架框架团队验证团队验证业务配合升级业务配合升级发布系统确认发布系统

13、确认组件依赖管理 组件仓库CRN 仓库:常用组件，必需依赖CRN_Ext仓库:独立组件，按需依赖内网npm仓库：第三方模块，按需CRN相关仓库，使用git分支依赖 版本管理固定版本，避免使用、*构建过程检查依赖的版本CRN包的依赖管理 依赖规则业务包只依赖框架包业务包之间平行，不允许依赖 其它发布高到达率情况下，不提供强制更新功能不同业务包之间跳转，会触发最新增量包下载分平台打包 原方案CRN框架包分开打包业务包共用，以iOS平台打包正常运行一年多 问题暴露平台独立组件，打包产物不一致分2次打包，打包之后merge打包产物Android优先在js-diffs中查找模块导航栏的选择 官方Navi

14、gator0.44开始废弃复杂页面切换时，卡顿明显CRN使用该方案，优化了页面切换动化 第三方ReactNavigator（推荐）纯JavaScript实现，性能优秀，功能强大页面切换使用animated动画 第三方ReactNativeNavigatorNative实现，跨平台兼容性有些问题NavigatorCRN优化总结CRN框架对RN进行改造优化，解决了性能和稳定性两大核心问题，且在业务团队广泛深度使用CRNWEB基本成熟，已有10个左右业务模块接入，未来会大力推广，CRN(WEB)一体化的解决方案，进一步降低开发维护成本持续优化RN性能和稳定性，分享CRN的优化思路和方案，适时开源部分组件和方案QA