章鱼抓娃娃添加Bugly-Tinker热更新支持

Bugly热更新采用Tinker开源方案，官方文档如下： Bugly Android热更新使用指南 Bugly Android热更新详解

接入热更新

我们的章鱼App之前就已经接入了Bugly，所以添加热更新支持，只需在gradle文件中进行如下更改即可。

/// 注释掉之前的bugly
//"bugly": 'com.tencent.bugly:crashreport:latest.release', //日志统计
// 添加支持热更新的 bugly
"bugly": 'com.tencent.bugly:crashreport_upgrade:latest.release', //日志统计（1.3.4之前含Tinker热更新，现已剥离）
"tinker": 'com.tencent.tinker:tinker-android-lib:1.9.8', //Tinker热修复      

此外，我们还需要在project层级的build.gradle中添加classpath； 接下来添加tinker-support.gradle文件并在app.gradle里添加配置； ...... 不一一描述，这些Bugly官方文档里都有。下面主要讲接入热更新后，章鱼App项目引起的改动。

改造Application

在 tinker-support.gradle 文件中配置

enableProxyApplication = true

可以避免Application的改动，但为了更好的兼容性，Tinker官方推荐改造Application。

我们的Application改造前如下图左半，改造后如下图右半。

Application改造

配置tinker-support

一般来说，在改造好Application后，tinker-support.gradle 无需更改即可使用。但为了在章鱼项目下使用起来便捷，进行了如下修改。

修改文件路径

tinker-support默认指定的文件路径均位于build目录下，而build目录下的文件既不稳定也不会同步到git服务器。这很容易让我们发布线上包后丢失关键文件(用于生成对应补丁包的文件)，即打包后在 app/build/bakApk/日期 目录下生成的如下文件：

app-release.apk （必有，预发布为app-prerelease.apk ） app-release-mapping.txt （开启混淆后会有） app-release-R.txt （必有，预发布为app-prerelease-R.apk ）

这些文件大多数时候是无用的，每次运行项目或打包都会生成。我们真正需要的是线上包对应的这些文件。 所以，让tinker-support生成文件的路径不变，将待修复apk的目录修改为 app/bakApk/app-last-release 。 这样，每次我们发布线上包后，将上述生成文件复制一份并替换到 app/bakApk/app-last-release 目录下即可。

自动修改tinkerId

每次打补丁或发布线上包，都需要修改tinkerId，并保证其唯一性。 我们采用如下格式：

"r" + generateDate()

例如 r-05301455 。

提供便利的测试（配置 tinker-support-prerelease.gradle 文件）

以上两项配置保证了线上补丁发布的便利性，但在发布线上补丁前，我们希望对事情有所掌控。这时，我们可以先测试预发布环境补丁效果。

为了方便，将 tinker-support.gradle 复制一份命名为 tinker-support-prerelease.gradle ，将其基准包目录修改为 app/bakApk/app-last-release ，并修改相应文件名。

为了使tinkerId唯一且与线上补丁保持差异，采用如下格式：

"pr" + generateDate()

例如 pr-05301455 。

最后，在 app/build.gradle 文件中做如下修改（定义isReleaseTask()方法用于判断是否为正式环境），根据任务类型自动引入相对应的tinker-support配置。

if (isReleaseTask(gradle.startParameter.taskNames)) apply from: 'tinker-support.gradle'//tinker线上配置 else apply from: 'tinker-support-prerelease.gradle' //tinker测试预发布包补丁配置。

发包清单

1. 修改gradle配置，如versionName, versionCode等(tinker-support文件切换及tinkerId修改已自动化)；
2. walle打包（Tinker支持walle多渠道包热修复）；
3. 将刚才 app/build/bakApk/日期 目录下生成的文件备份到 app/bakApk/app-last-release 目录（切记，只有确认发布的线上包才这么做）；
4. 打tag，并将代码提交至服务器。

发补丁清单

Tinker wiki

Tinker补丁不具有即时性，需要app收到补丁后下次启动才会生效。 Tinker补丁支持修改gradle文件与资源文件。建议补丁与基准包(待修复包)保持一致的versionName, versionCode。 此外，Tinker对Manifest的修改支持性不好，建议补丁包别动Manifest，若需要改动，请先在预发布环境下测试补丁的效果。

补丁发布步骤：

1. 待发布代码测试通过；
2. 生成预发布环境补丁包；
3. 发布预发布环境补丁包并观察效果； ——若3顺利通过，则继续向下执行，否则break。
4. 生成线上补丁包；
5. 灰度发布线上补丁包并观察效果； ——若5顺利通过，则继续向下执行，否则break。
6. 全量发布线上补丁包。

第2、3步是对补丁是否能生效的测试，约耗时15～30分钟。理论上这两步是可以省去的，在你确保改动代码被Tinker支持的情况下。不过，不建议如此，热修复依然存在许多问题，在预发布环境先行测试补丁效果具有必要性。

如何生成补丁

线上补丁与测试补丁生成的差异主要体现在配置上。

生成测试补丁

1. 将代码切回至有问题的线上节点。
2. 在此配置下使用walle打 prerelease 包，并备份刚刚在 app/build/bakApk/日期 目录下生成的基准文件。
3. 安装刚刚生成的基准apk（即代码等同于线上包的debug包）；
4. 代码切回到待发布节点（前面几步造成的代码改动不需要保存），将第2步备份好的基准文件替换到 app/bakApk/app-last-prerelease 目录。——如果早已备份好线上对应的测试包，且已安装，则之前步骤都可以省去。
5. 如下图，执行 buildTinkerPatchPreRelease/buildTinkerPatchDebug 指令生成prerelease/debug补丁。

生成预发布补丁

生成线上补丁

因为在打包时已对线上补丁进行备份，所以生成线上补丁比测试补丁更为简单，步骤如下。

1. 将代码切换至待发布补丁的节点。
2. 保证versionName、versionCode与线上版本一致（以免后续升级有问题）。
3. 执行 buildTinkerPatchRelease 指令生成release补丁。

如何发布补丁

生成后的补丁位于项目 app/build/outputs/patch/环境 目录下，其中， patch_signed_7zip.apk 文件即为要发布的补丁。

将 patch_signed_7zip.apk 文件上传至Bugly指定项目即可。 图文请参照bugly官方文档：上传补丁包到平台。

观察补丁情况

每个补丁都对应着特定的一个apk，比如前面提到的线上apk或调试apk，在装有该apk的手机上观察补丁的下发与生效。补丁生效需app重启。

如何验证？

为了便于验证，在 build.gradle 里添加一个字段 APK_DATE

buildConfigField "String", "APK_DATE", ""${generateDate()}""

这样，APK_DATE 即为apk的构建时间（即我们用指令生成该apk或其最新补丁的时间）； 在设置页面连击版本号7次，即可观察到相关信息 "生成时：" + BuildConfig.APK_DATE。我们根据该时间信息可以很轻松地判定出当前包是否为补丁包。