芋头大搜车无线团队.pdf

大搜车 ReactNative 开发集成流程体系演变 芋头@大搜车无线团队 一、场景 场景 • 重业务逻辑，轻营销。更重要的是可控性而不是灵活。 • 核心解决客户端人力膨胀问题，主要由 Native 开发，需尽量尊从其习惯 。 • 公司内多个 app，以及合作方的 app，业务繁多。 • 完全耦合进 Native，模糊三端概念，互通互调。 战略级，没有退路 二、体系简介 三、开发与集成 最初版 当时核心需要解决的问题 • 实现热更新 • 版本锁定 • 三端互通 • 业务解耦，业务之间互相独立 • 发版时带上最新版的 bundle 版本锁定 • 大量的跨端依赖，端与RN的版本可能不兼容。 • RN 官方包 需要可以随时升级，因为不稳定因素很 多。 • SDK 可以不断迭代功能，而不影响线上业务。 SRN-HUB 版本管理服务 最初思路 • 在服务端判断请求来自哪个版本的app • 服务端维护一个关系：哪个app的哪个版本可以更新哪个版本的bundle • 根据这个关系，返回是否需要下载某个 bundle • 太复杂的架构不是好架构，要对使用者尽量透明 统一 Router • 没有复杂的存储规则，所有规则都在版本号里。 • ${major}.${feature}.${patch} • 版本号升级根据发布类型自动管理。 • 依赖声明在 app 工程内，由 app 自己决定依赖， 而不是三方管理依赖。 问题 • 发布前需要RN开发修改APP内的依赖文件，这个文件和 podfile ，以及 maven的依赖不在一起，客户端难以适应。 • bundle 包有环境的概念，在开发流程里不断切换环境的时候需要不断改依 赖文件，很麻烦。 • 测试环境一律走覆盖式热更新，但是上线前会忘记修改依赖。 • 热更新被滥用，规则成为摆设。 • 打包时需要拉取依赖的bundle集成到本地，拖慢打包过程。 2.0 版 核心解决 • 将 bundle 编译成Native 模块 • bundle 抽离公用模块 • 扫码调试等辅助开发工具 app 发布流程 npm run publish Build Bundle create Pod repo 各自仓库 create JAR Upload to SRNHub 然后在原生工程里声明依赖及版本 app 启动后流程 找到所有bundle 内 app 启动 扫描应用文件 解析并注册模块 的 info.json 返回需要更新的 SRN - HUB 检查热更新 bundle 列表和地址 下载并覆盖 测试环境 直接更新最 忽略规则，直接更新最新版 新版 bundle bundle 拆分