上次从加载流程介绍了修复包的加载过程,还剩下具体的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<ShareDexDiffPatchInfo> 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
的加载。