场景实践

最近修改时间2021-10-18 11:37:60

优化原生和热更包体积

iOS 原生包优化(ipa)

在导出 ipa 以便上传到 pushy 服务时,可以取消 bitcode 选项以大幅减小 ipa 大小。上架 app store 或者通过 testflight 分发测试包时仍然可以保留 bitcode 选项,不影响热更新。

bitcode

Android 原生包优化(apk)

apk 的优化主要考虑两个方向:

  • 启用 proguard 压缩混淆源码。但这一步可能导致一些使用反射的代码运行时报错,启用后需要充分测试每个页面和功能,以及需要阅读一些第三方关于 proguard 的特别设置说明。
  • 分开编译不同的 cpu 架构。找到android/app/build.gradle中的 cpu 架构部分,如下所示启用enable选项:
splits {
    abi {
        reset()
-       enable enableSeparateBuildPerCPUArchitecture
+       enable true        // 启用单独的 cpu 架构编译
        universalApk false  // If true, also generate a universal APK
    }
}

如此一来会在编译目录中输出多个 apk 文件,分发和上传到热更新服务时只需要使用app-arm64-v8a-release.apk文件,可以大幅减小 apk 的大小。

热更新包优化(ppk)

热更新包的主要内容是 js 包和其所引用的静态资源(主要是图片)。

  • js 包成分分析。可以借助一些第三方工具(如react-native-bundle-visualizer)来分析 js 文件中哪些占比较大,是否可以用其他库替换等(如 dayjs 替换 moment,lodash-es 替换 lodash)。
  • 图片优化。

有很多渠道包需要热更,如何操作比较方便?

  1. 如果渠道包的js代码和初始资源有差别(无论多么细微的差别),那么只能单独生成 apk,分别上传和绑定。可以考虑写一些脚本自动调用 cli 来执行批量操作。
  2. 如果渠道包的js代码和初始资源完全一致,可以考虑使用一些动态生成渠道包的方案(比如腾讯的 VasDolly美团的 walle等),所有的渠道包基于同一个基础 apk 生成。这样可以只用上传一个基础 apk,对此 apk 的热更操作可以对所有渠道包生效。

如何支持 aab 格式的原生包?

如果您需要使用 aab 格式的 android 原生包,那么可以在上传到 Google play 之后,在其控制台中下载转换后的 apk 格式(见下图),然后将这个 apk 包上传到热更新的后台,即可正常支持热更新。

aab

CI 的集成

在开发环境中,每次 bundle 都会生成一个不同名字的 ppk 文件,这不利于持续集成(CI)系统的引入。

要解决这个问题,你可以使用--output参数来指定输出 ppk 文件的名字和路径,便于进行自动发布。

版本测试与发布

我们强烈建议您先发布一个测试包,再发布一个除了版本号以外均完全相同的发布包。在每次往发布包发起热更新之前,先往对应的测试包进行更新操作,基本测试通过之后,可以将发布包更新到完全相同的热更新版本之上。如果在测试包中发现了重大问题,你就可以先进行修复,再次更新测试通过后,再将发布包更新至修复后的版本。这样,可以最大程度的避免用户通过热更新获得一个有问题的版本。

元信息(Meta Info)的使用

在发布热更新版本时,或者在网页端,你可以编辑版本的元信息。这是一段在检查更新时可以获得的字符串,你可以在其中按你所想的格式保存一些信息。

举例来说,可能某个版本包含一些重要的更新内容,所以用户会得到一个不同样式的通知。如何使用元信息,完全取决于您的想象力!

下面会列举一些实战中更有意义的元信息的使用。

Hot-fix

有时候我们不小心发布了一个有严重问题的版本,所以需要进行一个紧急的修复,此时我们可能希望之前已经更新到有问题版本的用户进行紧急甚至静默进行更新。

这时候,我们可以在元信息中包含有问题的版本的列表,而在客户端检查更新时,将从元信息里取到的列表与当前版本(currentVersion)比对,如果匹配成功,我们就进行静默更新,否则则按照一般的更新流程提示用户。