Tinker源码分析二

上次从加载流程介绍了修复包的加载过程，还剩下具体的dex、res、libriry的具体合成和应用。下面我将分别展开介绍：

一、dex的合成与加载

DexDiffPatchInternal的方法tryRecoverDexFiles(Tinker manager, ShareSecurityCheck checker, Context context, String patchVersionDirectory, File patchFile, boolean isUpgradePatch)

• 里面有从ShareSecurityCheck中得到"assets/dex_meta.txt"这个dex修复包配置文件。
• 然后调用了patchDexExtractViaDexDiff(Context context, String patchVersionDirectory, String meta, File patchFile, boolean isUpgradePatch)这个方法。

这个方法是具体的操作：

• 判断系统版本是art还是dalvik
• 调用extractDexDiffInternals(Context context, String dir, String meta, File patchFile, int type, boolean isUpgradePatch)执行diff操作。
• 生成优化dex的目录，调用loadDex(String sourcePathName, String outputPathName, int flags)加载生成的dex文件。
• 如果优化失败，则删除文件，并报告错误。

下面步步推进，再介绍上一个方法里面的核心方法：extractDexDiffInternals(Context context, String dir, String meta, File patchFile, int type, boolean isUpgradePatch)

• 从dex_meta.txt中得到各个dex的配置信息ArrayList patchList
• 得到两个ZipFile：应用本身的和修复包的。
• 在art系统中得到修复包中的小的dex文件SmallPatchedDexItemFile
• for循环patchList里面包含了md5值（dalvik和art不同），dex文件的路径等信息。若文件存在并且md5相同，则continue，不再处理。

这里面有几个文件需要区别一下，有点绕：

1.dir或者patchVersionDirectory是安全目录，而patchFile不是安全目录。
2.extractFile是安全目录下的真名字，比如class.dex。
3.patchRealPath是从dex_meta.txt文件中取到的真实class.dex路径。
4.分别得到apk和patch包中dex文件的ZipEntry

ZipEntry patchFileEntry = patch.getEntry(patchRealPath);
ZipEntry rawApkFileEntry = apk.getEntry(patchRealPath);

最终调用这个方法，完成合成的操作。

new DexPatchApplier(oldInputStream, oldDexSize, newInputStream, 
smallPatchInfoFile).executeAndSaveTo(zos);

里面对dex文件分数据类型进行对比，合成。（dexdiff）

二、TinkerInstall的调用时机
有两个作用：
1.回调LoaderReporter，返回加载结果。
2.初始化各个自定义类与Tinker实例，可以通过Tinker来调用相关api。发起升级补丁以及处理相关回调。

即使不调用也不影响Tinker对资源，dex，libriry的加载。