背景

• app内已完成rn模块的集成

• jsbundle以静态文件的方式随app发版，缺少热更新能力

• 热更新能提高发版的效率

• 需要建设热更新包管理平台

热更新的概念

不用重新发布app版本，即不用更新app的安装包，在用户无感知的情况下，就可以对应用实现版本迭代、bug修复的技术解决方案称为热更新

对比常规开发流程而言，热更新的开发流程更加灵活方便，优势很多：

• 无需提交商店审核，实时发版

• 用户无感知，无需下载新应用，代价小

• 版本覆盖率高，新功能可快速触达用户，避免依赖app的版本升级

实现方式

react-native使用脚本语言js开发，具有“即读即运行”的特性，在“读”之前将之替换成新版本的脚本，运行时执行的便是新的逻辑了。js语言可以通过jsbundle的方式下载到app内，然后通过js引擎执行。继而可以实现最新的代码，不通过应用商店，直接下发到app内。

存在的问题

• 需要后台支持，不然无法实现包的分发

• 线上客户端会存在多个版本，根据不同版本的具体差异的不同，可能需要根据不同的客户端版本，下发不同的热更新内容

• 需要管理好app的版本和jsbundle包的版本，否则会出现线上问题

解决方案

• jsBundle包需要一个后台服务来上传、管理和分发，需要区分不同的环境：feature、uat、production等

• 需要封装客户端sdk，封装向平台请求jsbundle包、传输解密、版本管理等功能

系统架构

image.png

包管理平台

提供应用管理、应用版本管理、js包管理、js包上传和分发、异常时的回滚、传输过程中的加密、条件下发等功能

客户端SDK

提供了向后端请求js包，js版本管理、传输后的解密等功能

主要流程

image.png

热更新流程如下

前置工作：

• 在热更新平台创建App应用： 即需要接入热更新的app。

  • 设置应用名称、应用版本、管理员等信息

  • 后续需要获取到当前app应用的所有上线版本（或许需要打通app的Jenkins平台自动维护版本，或者手动维护）。

• 创建js包应用：

  • 选择需要投放的app，可以多选。

  • 设置git仓库

  • 设置打包脚本

• App内接入热更新SDK。

  • 配置好appKey

  • app启动会查询是否存在新版本，需要携带app标识、app版本号、本地已存在版本等参数

  • 客户端sdk根据服务端给的数据，进行下载、回滚或者不进行操作。

  • 如果需要下载，下载完毕后，本地签名校验文件完整性，然后存储到本地

  • 上报下载成功/下载失败的信息给管理后台

• 包管理服务

  • 服务收到客户端的请求后，根据参数返回当前app是否有新版本，以及新版本下载相关的信息。是否需要回滚等

• App打开RN页面

  • 查找本地Bundle信息，加载最新版本

  • 上报版本加载成功/失败的信息给管理后台

管理平台发版流程：

• js打包

  • 设置目标平台：iOS/Android的Bundle包，

  • 设置是否dev模式的包

• 发布

  • 选择发布的环境：feature/uat/beta（测试环境）

  • 选择投放的app版本：是一个区间，比如投放到1.0以上的版本， 1.0-2.0之间的版本

• 上线

  • 从已发布的版本中，选择要发布的jsbundle。

  • 必须是已发布过测试环境的包才可以操作上线，不允许直接上线

  • 设置是否灰度

  • 控制放量0%~100%

App应用管理

image.png

整体方案设计为多app的应用场景。接入sdk时，必须要使用appkey作为标识。应用管理中要管理appkey的生成，以及app版本信息的管理。

Bundle包管理

image.png

• 新建Bundle： 创建bundle的入口

• bundle名称： 工作中，交流沟通的名称

• 唯一标识： 唯一id，代码中使用的名称

• 入口组件名称：bundle内允许多入口

• 投放的app： 当前bundle会投放到哪些app上

• 操作

  • 查看详情： 更多细节信息，包大小，更新时间，版本号、打包、发布、上线、回滚等操作

  • 编辑： 编辑基础信息：git仓库地址等

新建bundle

image.png

打包

[图片上传失败...(image-92aa41-1712815885556)]

发布

[图片上传失败...(image-6ebf8d-1712815885556)]

上线

[图片上传失败...(image-4d65bb-1712815885556)]

存储

条件下发

在发布一个包之前，需要在小范围内进行测试或者线上回测，比如特定某个 iOS 版本或者特定某个用户；在验证通过后再进行全量用户的下发。这时可以用到条件下发。

分发平台在发布包时可以选择使用条件下发，除上传包外，还可以填写条件语句，只有满足条件的设备才会获取到最新版本的包。

• 特定版本

• 设备id

• 用户ID

当包的下发状态处于条件下发，且相关参数与 SDK 上报参数中的条件一致时，才会将包发送给该 SDK。

白名单

支持设置白名单，只有白名单里的用户id 或者设备id才可以获取最新版本的包

• 设备白名单

• 用户白名单

数据统计

提供分日、分 App、分版本的包分发数据统计功能。

SDK 设计

SDK只需实现版本的查询和 bundle包的下载即可。

以 iOS 为例：

客户端 SDK 启动时会发请求询问服务端，根据服务端返回数据进行相应处理。客户端 SDK 会保存下载到的jsbundle包，避免重复下载造成的流量损失。具体流程如下：

image.png

1. App 启动同时 SDK 也启动，并发送查询请求给服务端，请求携带 App 标识、App 版本号等参数；

2. 服务端根据收到的请求判断下发该app对应的配置信息，包括包版本信息、下载地址和其他一些信息。客户端 SDK 根据接口返回的数据判断进行下载、回滚或不进行任何操作；

3. 如果未返回任何信息，说明不存在新版本需要下发，此时客户端 SDK 不进行任何操作；

4. 如果返回的配置信息中，包的版本号等于本地生效脚本的版本，说明客户端保存的包已是最新的，SDK 直接执行本地保存的包；

5. 如果返回的包信息中，包的版本号不等于本地生效脚本的版本，说明服务端有新的修复包发布，或发生了回滚操作，客户端 SDK 判断本地是否存在该版本的包，存在时直接执行本地包；不存在时发起下载请求获取最新的包，并在本地缓存，然后执行。

成本

从三个方面了对比成本问题

• 使用第三方那个付费服务

• 私有化codepush

• 完全自研

应用数

共计118个独立的功能模块。我们按照60%的业务使用react-native开承载，我们简单把每个模块划分为一个应用（实际可能比模块数多），预计需要71个应用。

pushy最大支持20个应用。无法支持，pass

Codepush 根据应用数量收费：40/月

私有化部署和完全自研的工作量对比