宏观剖析Tinker整体玩法

最近根据基于Tinker1.9.14.7做了一套热修复框架，对tinker做了一些学习研究，结合自己之前framework经验，理解起来还比较快，产出8篇文章，内容牵扯到的android源码是基于Android Q的：
热修复框架 - 从Tinker 1.9.14.7开始
热修复框架 - TinkerApplication启动(一) - 初始化过程
热修复框架 - TinkerApplication启动(二) - 加载dex补丁过程
热修复框架 - TinkerApplication启动(三) - 加载资源补丁过程
热修复框架 - TinkerApplication启动(四) - 加载so补丁过程
热修复框架 - Tinker 安装流程分析
热修复框架 - Tinker patch合成流程
热修复框架 - Tinker disable逻辑梳理
从Tinker加载dex补丁看动态加载插件过程

本篇文章来做一个最后的总结，目的是梳理出整体脉络，对不管了是做过tinker热修复还是想了解的朋友，提供一点点小思路。

一、Tinker整体玩法

核心内容主要分4个部分：

新旧包根据差分算法做出diff patch
服务端管理不同基准包对应的diff patch，与客户端指定检验和下发规则。
客户端获取diff patch与当前apk合并，生成修复包。
加载修复包，替换基准包相关内容，到修复目的。

二、客户端通过Tinker处理patch包闭环

整体流程包括patch包校验、加载、合成环境准备、合成：

客户端通过Tinker处理patch包闭环

2.1 校验、合成：TinkerApplication初始化过程：
通过TinkerLoader.tryLoader对patch包进行校验，这里也包括tinker功能设置的校验等，如果patch包存在，且有效且tinker相关功能enable则尝试加载patch；
2.2 合成环境准备：Tinker.install
通过Tinker.install部署好Tinker合成patch包的整体环境：

    @Override
    public void onBaseContextAttached(Context base) {
        super.onBaseContextAttached(base);
        Log.d(TAG, "HotFixApplicationLike onBaseContextAttached");

        MultiDex.install(base);//使应用支持分包

        LoadReporter loadReporter = new DefaultLoadReporter(base);
        PatchReporter patchReporter = new DefaultPatchReporter(base);
        PatchListener patchListener = new DefaultPatchListener(base);
        AbstractPatch upgradePatchProcessor = new UpgradePatch();

        TinkerInstaller.install(this,
                loadReporter,//加载合成的包的报告类
                patchReporter,//打修复包过程中的报告类
                patchListener,//对修复包最开始的检查
                DefaultTinkerResultService.class, //patch包合成完成的后续操作服务
                upgradePatchProcessor);//生成一个新的patch合成包
    }

2.3 合成：TinkerInstaller.onReceiveUpgradePatch()
对服务端下发的patch包和当前基准包进行合成，生成合成包：tinker_classN.apk

对Tinker宏观玩法有个全局认识之后，再来看看tinker的局部玩法，总共3个点：

Dexdiff算法如何做patch dex；
如何加载修复补丁(包括dex、resource、so)；
如何设计与服务端交互。

下面一个个来看。

三、dexDiff算法

DexDiff是微信自研的差分包算法。

粗略理解差分思路：

dex文件结构

将dex包的关键section读取封装为对象，新旧包对比时，每个section对应一个算法比较器：

各section计算diff的算法

from dodola tinker

以stringDataSection为例：

先新旧数据排序，然后以compareTo比较字符串内容，以二路归并的方式，整理出带del、add、replace标签的diff内容。然后重新计算index和offset。

最终将修改的内容重新写入新文件，生成patch包。

整体dexdiff流程

读取old dex和new dex文件包装为Dex，经过DexPathGenerator处理，dex不同的section对应不同diff algorithm算法处理器处理，算法经过对新旧数据排序，然后通过二路归并的方式，由compareTo进行内容对比，打出del、add、replace标签（这个算法我玩了下，确实有意思），将一个个item封装为PatchOPeration，加入集合PatchOperationList，这部分属于内容分别。然后计算出对应section的size即为：patchedSectionSize。然后通过DexPathGenerator执行executeAndSaveTo 方法，分别计算各区域的offset、收集各区域的PatchOperationList, 最终创建一个新的patch dex按dex格式写入如上内容。然后将dex 、assets和META-INF/ 打成apk。这就是diff出来的差分包。其中，assets中package描述包信息，其他三个文件分别记录dex、res、so的相关信息，会在tinker加载补丁的时候做验证用。

我这姑且班门弄斧地尝试总结了下dexdiff的大概过程，其中的细节非常多，也非常难，坑也非常多，典型的包括Android N混合编译、厂商OTA后因为补丁包过大造成编译卡顿问题等等，dexDiff是Tinker最难的技术点，微信自己人也说这条路是跪着走完的。

四、加载修复补丁简介

dex:

hook classLoader对应的dexPathList中的makeDexElements，将修复dex插入dexElements最前面，保证相同类加载修复dex中的，而其后的失效。

so:
hook classLoader对应的dexPathList中的makePathElements方法，注入so到nativeLibraryPathElements数组中。这部分跟dexElements类似。

res:
替换LoadedApk对应的mResDir指向补丁包,ResourcesImpl mAssets替换为新的AssetManager，并用新AssetManager调用其addAssetPath加载补丁包。

其中：

LoadedApk是 APK文件信息封装对象。它在ActivityThread启动过程中被初始化，参与Apk加载过程。
Resource通过代理ResourceImpl来处理，ResourceImpl先尝试从缓存获取，没有缓存在通过AssetManager获取，AssetManager通过addAssetPath来加载apk资源，而具体实现是在native做的。

类关系如下图：

五、如何设计与服务端的交互

热修复patch在商业化项目中一般会通过服务端下发的方式给到app去合成，然后加载。这里就简单介绍下我做的一版：

上传：向服务端上传patch包策略文件，以及patch包。

下发：
1.check下当前基准包是否有patch包，通过版本号、渠道号、包名等几个维度来唯一定位。
2.获取策略文件域名，拉取策略文件。
3.根据策略文件来判断拉取哪个patch，是做新修复还是回滚，回滚是回滚到哪个版本。
4.拉取对应的patch包，并对包做校验。
5.如果是做小需求发版，还会拉取引导图，在开机时设置引导页面。
6.客户端合成patch包。
7.设计重启策略，最暴力的是直接kill。

patch下发流程

六、如何排查Tinker问题

最后，再来简单介绍下客户端相关Tinker问题如何排查
前面介绍了：TinkerApplication在初始化的时候，会执行TinkerLoader.tryLoad，它主要做两部分事情，校验与加载修复包。

这个校验过程，如果报错，会通过如下方法设置错误码：

ShareIntentUtil.setIntentReturnCode(resultIntent, ShareConstants.ERROR_LOAD_DISABLE);

然后到TinkerApplication初始化完成后后执行：Tinker.install，它通过如下方法解析TinkerApplication启动过程中反馈的加载补丁结果：

tinkerLoadResult.parseTinkerResult(getContext(), intentResult);

然后通过tinker.getLoadReporter()返回对应的回调，如果客户端注册了LoadReporter，会收到对应的回调，可以在这做打印。当然tryLoad 设置错误码时就会有相应的打印，直接通过错误码去反推出现的问题，能瞬间缩小排除范围。

举例：
我在写demo时遇到的问题：

I/Tinker.TinkerLoadResult: parseTinkerResult loadCode:-3, process name:com.stan.tinkersdkdemo, main process:true, systemOTA:false, fingerPrint:Xiaomi/dipper/dipper:9/PKQ1.180729.001/9.10.122:user/test-keys, oatDir:null, useInterpretMode:false

loadCode -3 :对应ERROR_LOAD_PATCH_INFO_NOT_EXIST
看看是什么原因设置的这种状态码：

if (!patchInfoFile.exists()) {
   Log.w(TAG, "tryLoadPatchFiles:patch info not exist:" + patchInfoFile.getAbsolutePath());
   ShareIntentUtil.setIntentReturnCode(resultIntent, ShareConstants.ERROR_LOAD_PATCH_INFO_NOT_EXIST);
   return;
}

patch.info不存在, adb查看下果然是，patch.info生成是在合成patch的地方，tinker通过如下方法合成patch，合成过程会生成tinker文件夹，以及内部的相关文件

TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), patch);

那就debug下这个流程就好了，最终问题是对应patch合成的service没有在manifest注册，因为patch合成任务是在service中做的，所以问题解决。

我这里只是提供一种简单的思路。

附：tinker文件夹：

cepheus:/data/data/com.stan.tinkersdkdemo/tinker # ls -al
total 36
drwx------ 3 u0_a350 u0_a350 4096 2020-08-12 10:14 .
drwx------ 8 u0_a350 u0_a350 4096 2020-08-12 10:14 ..
-rw------- 1 u0_a350 u0_a350    0 2020-08-12 10:15 info.lock
drwx------ 4 u0_a350 u0_a350 4096 2020-08-12 10:14 patch-8b79c8cc
-rw------- 1 u0_a350 u0_a350  367 2020-08-12 10:15 patch.info // patch信息描述文件

cepheus:/data/data/com.stan.tinkersdkdemo/tinker/patch-8b79c8cc # ls -al
total 40
drwx------ 4 u0_a350 u0_a350 4096 2020-08-12 10:14 .
drwx------ 3 u0_a350 u0_a350 4096 2020-08-12 10:14 ..
drwx------ 3 u0_a350 u0_a350 4096 2020-08-12 10:14 dex
drwx------ 2 u0_a350 u0_a350 4096 2020-08-12 10:14 odex
-rw------- 1 u0_a350 u0_a350 3443 2020-08-12 10:14 patch-8b79c8cc.apk //合成前的diff patch包

cepheus:/data/data/com.stan.tinkersdkdemo/tinker/patch-8b79c8cc/dex # ls -al
total 2328
drwx------ 3 u0_a350 u0_a350    4096 2020-08-12 10:14 .
drwx------ 4 u0_a350 u0_a350    4096 2020-08-12 10:14 ..
drwxrwx--x 3 u0_a350 u0_a350    4096 2020-08-12 10:14 oat
-rw------- 1 u0_a350 u0_a350 2351677 2020-08-12 10:14 tinker_classN.apk //合成后的patch包

当然tinker绝对不止这么点东西，能力有限，只简单窥探了冰山一角，文中错误之处欢迎批评指正！

参考：
Tinker
微信Tinker的一切都在这里，包括源码（一）
Android热修复Tinker源码分析之DexDiff / DexPatch
tinker github
全面解析Android热修复原理
Tinker源码分析(一):TinkerApplication