前言：最近接手一个新项目，用到了 tinker 热更新，记录一下使用心得。
00 Tinker 热更新过程
关于热更新原理，可以参考这篇文章：Android热更新技术的研究与实现。我简单说下 tinker 热更新的过程吧，首先当我们的应用集成了 tinker 后，每次应用冷启动都会请求补丁策略，tinker 首先会上报当前版本的 TINKER_ID：
1
2
| 07-04 09:56:13.393 2211-2211/com.huge.logistics I/CrashReport: TINKER_ID:base-2.20
NEW_TINKER_ID:
|
这样我们后台就能将这个唯一的 TINKER_ID 对应到一个版本，所以当我们上传了补丁包并选择下发后，如果匹配到目标版本，后台就会下发补丁策略，我们的 app 检测到有补丁就会去下载补丁并合成：
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
| 07-04 09:56:16.884 2211-2243/com.huge.logistics I/CrashReport: onUpgradeReceived: title:
newFeature: 测试热更新
publishTime: 0
publishType: 0
appBasicInfo: {
appId: 42477c8883
platformId: 1
versionCode: 0
versionName: null
buildNo: 0
iconUrl: null
apkId: 0
channelId: null
md5: c234ccd77afba4d76b7148c305d87d426158df98
sdkVer:
bundleId: null
}
apkBaseInfo: {
apkMd5: c234ccd77afba4d76b7148c305d87d426158df98
apkUrl: https://s.beta.gtimg.com/rdmimg/hot_patch/42477c8883/1d240f8e-2d20-4c58-a156-d3e919342498.zip
manifestMd5:
fileSize: 175772
signatureMd5:
}
updateStrategy: 0
popTimes: 0
popInterval: 0
diffApkInfo: {
null}
netType: null
reserved: 1, {
(
H2
3
)
}
strategyId: ceb6de11-d954-4470-a967-2c008f0a2f53
status: 1
updateTime: 1530668503000
updateType: 3
07-04 09:56:17.977 2211-2211/com.huge.logistics D/Tinker.TinkerManager: onDownloadSuccess.
07-04 09:56:17.978 2211-2211/com.huge.logistics D/Tinker.TinkerManager: check if has new patch.
07-04 09:56:18.127 2211-2211/com.huge.logistics D/Tinker.TinkerManager: has new patch.
07-04 09:56:18.133 2211-2211/com.huge.logistics D/Tinker.TinkerManager: starting patch.
|
合成成功后需要等用户重启应用后，更新才会生效：
1
2
3
4
5
6
7
8
9
| 07-04 09:56:24.662 2211-2414/com.huge.logistics W/Tinker.DefaultTinkerResultService: deleteRawPatchFile rawFile path: /data/user/0/com.huge.logistics/app_tmpPatch/tmpPatch.apk
07-04 09:56:24.662 2211-2414/com.huge.logistics I/Tinker.PatchFileUtil: safeDeleteFile, try to delete path: /data/user/0/com.huge.logistics/app_tmpPatch/tmpPatch.apk
07-04 09:56:24.662 2211-2414/com.huge.logistics I/Tinker.TinkerResultService: tinker wait screen to restart process
07-04 09:56:24.662 2211-2211/com.huge.logistics I/CrashReport: Tinker patch success, result:
PatchResult:
isSuccess:true
rawPatchFilePath:/data/user/0/com.huge.logistics/app_tmpPatch/tmpPatch.apk
costTime:6267
patchVersion:4a0c61fdc87d6a04b9fa74844819b4c0
|
可以看到合成成功后日志中有这么一行“tinker wait screen to restart process”，也就是需要重启应用所在的进程（重新加载dex）。当然如果你开启了更新弹窗，也可以让用户手动点击重启应用：
应用重启之后的日志：
1
2
3
4
5
| 07-04 10:10:42.859 8022-8022/com.huge.logistics I/Tinker.TinkerLoader: tryLoadPatchFiles: load end, ok!
07-04 10:10:42.867 8022-8022/com.huge.logistics I/Tinker.TinkerLoadResult: oh yeah, tinker load all success
07-04 10:10:42.867 8022-8022/com.huge.logistics I/Tinker.DefaultLoadReporter: patch loadReporter onLoadPatchVersionChanged: patch version change from to 4a0c61fdc87d6a04b9fa74844819b4c0
onLoadPatchVersionChanged, try kill all other process
07-04 10:10:42.871 8022-8022/com.huge.logistics I/Tinker.DefaultLoadReporter: patch loadReporter onLoadResult: patch load result, path:/data/user/0/com.huge.logistics/tinker, code: 0, cost: 176ms
|
可以看到更新后的 tinker-id：
1
2
3
4
| 07-04 10:10:43.106 8022-8022/com.huge.logistics I/CrashReport: [patch] inject success
07-04 10:10:43.124 8022-8022/com.huge.logistics I/CrashReport: save patch success event success!
07-04 10:10:43.128 8022-8022/com.huge.logistics I/CrashReport: TINKER_ID:base-2.20
NEW_TINKER_ID:base-2.20-hotfix-test
|
至此，一次热更新结束。
01 集成与初始化
官方文档写的很详细，直接按照文档写的步骤一步步执行就行了。tinker-support 插件各参数的详细配置介绍看这里，另外强烈推荐看一遍热更新API和热更新常见问题。
02 如何使用
同样官方文档上有很好的范例可供参考。
03 一些细节
之前想到一个问题，如果我们发布了一个基准版本 base-1.0 后，然后一部人安装了这个基准版本，然后我们又再次做了一些修改，发布了新的版本 base-1.1，这个时候另一部分人安装了这个新的版本，那么当我们发布热更新，这部分安装了 base-1.1 的人还能收到热更新吗？自己做了一个实验，结果证明是可以的，只要保证你发布的 base-1.1 的 tinkerId 和 base-1.0 是一样的（同时基准包目录也还是 base-1.0 的），这样就可以保证两个版本都可以收到热更新。