加载补丁dex
Tinker采用的是下发差分包，然后在手机端合成全量的dex文件进行加载。而在build.gradle配置中的tinkerPatch
dex.loader = ["com.tencent.tinker.loader.*",
"tinker.sample.android.app.SampleApplication",
"tinker.sample.android.app.BaseBuildInfo"
]
这个配置中的类不会出现在任何全量补丁dex里，也就是说在合成后，这些类还在老的dex文件中，比如在补丁前dex顺序是这样的：oldDex1 -> oldDex2 -> oldDex3…，那么假如修改了dex1中的文件，那么补丁顺序是这样的newDex1 -> oldDex1 -> oldDex2…其中合成后的newDex1中的类是oldDex1中除了dex.loader中标明的类之外的所有类，dex.loader中的类依然在oldDex1中。
由于Tinker的方案是基于Multidex实现的修改dexElements的顺序实现的，所以最终还是要修改classLoder中dexPathList中dexElements的顺序。Android中有两种ClassLoader用于加载dex文件，BootClassLoader、PathClassLoader和DexClassLoader都是继承自BaseDexClassLoader
public BaseDexClassLoader(String dexPath, File optimizedDirectory,
String libraryPath, ClassLoader parent) {
super(parent);
this.originalPath = dexPath;
this.pathList =
new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
}
@Override
protected Class<?> findClass(String name) throws ClassNotFoundException {
Class clazz = pathList.findClass(name);
if (clazz == null) {
throw new ClassNotFoundException(name);
}
return clazz;
}
//DexPathList
public Class findClass(String name) {
for (Element element : dexElements) {
DexFile dex = element.dexFile;
if (dex != null) {
Class clazz = dex.loadClassBinaryName(name, definingContext);
if (clazz != null) {
return clazz;
}
}
}
return null;
}
最终在DexPathList的findClass中遍历dexElements，谁在前面用谁。dexElements是在方法makeDexElements中生成的，我们的目的就是hook这个方法把dex插入到dexElements的前面。
Multidex.install()中是把dex插到dexElements的前面，Multidex是把其余的dex插到后面。相同的就是都是分版本加载
Tinker是将dex前置，Multidex是将dex后置
Android6.0以后把makeDexElements给改了，改成了makePathElements(List,File,List)，如果找不到的话再找一下makeDexElements(List,File,List)。其余没啥区别。
在Dalvik虚拟机中，总是在运行时通过JIT（Just-In—Time）把字节码文件编译成机器码文件再执行，这样跑起来程序就很慢，所在ART上，改为AOT（Ahead-Of—Time）提前编译，即在安装应用或OTA系统升级时提前把字节码编译成机器码，这样就可以直接执行了，提高了运行效率。但是AOT有个缺点就是每次执行的时间都太长了，并且占用的ROM空间又很大，所以在Android N上Google做了混合编译同时支持JIT和AOT。混合编译的作用简单来说，在应用运行时分析运行过的代码以及“热代码”，并将配置存储下来。在设备空闲与充电时，ART仅仅编译这份配置中的“热代码”。
就是在应用安装和首次运行不做AOT编译，先让用户愉快的玩耍起来，然后把在运行中JIT解释执行的那部分代码收集起来，在手机空闲的时候通过dex2aot编译生成一份名为app image的base.art文件，然后在下次启动的时候一次性把app image加载进来到缓存，预先加载代替用时查找以提升应用的性能。
app image中已经存在的类会被插入到ClassLoader的ClassTable，再次加载类时，直接从ClassTable中取而不会走DefineClass。假设base.art文件在补丁前已经存在，这里存在三种情况：
1.补丁修改的类都不appimage中；这种情况是最理想的，此时补丁机制依然有效；
2.补丁修改的类部分在appimage中；这种情况我们只能更新一部分的类，此时是最危险的。一部分类是新的，一部分类是旧的，app可能会出现地址错乱而出现crash。
3.补丁修改的类全部在appimage中；这种情况只是造成补丁不生效，app并不会因此造成crash。
Tinker的解决方案是，完全废弃掉PathClassloader，而采用一个新建Classloader来加载后续的所有类，即可达到将cache无用化的效果。
我们按步骤进行：
1.新建一个AndroidNClassLoader 它的parent是originPathClassLoader。注意，PathClassLoader的optimizedDirectory只能是null，这个后面还有用。
2.找到originPathClassLoader中的pathList 和 pathList中的类型为ClassLoader的definingContext。
3.替换definingContext为AndroidNClassLoader
4.将AndroidNClassLoader中的pathList替换为originPathClassLoader的pathList。
Android 的ClassLoader采用双亲委托模型，只有parent找不到的情况下才会去找AndroidNClassLoader，那我新建这个AndroidNClassLoader有什么用，最终还是会去originPathClassLoader中取找。其实不是这样的，我们已经将originPathClassLoader中pathList中的definingContext(是个ClassLoader)替换为了AndroidNClassLoader了。这个definingContext会在生成DexFile的时候传递进去，而ClassLoader的findClass()方法会调用pathList的findClass方法，如下：
//DexPathList.java
public Class findClass(String name) {
for (Element element : dexElements) {
DexFile dex = element.dexFile;
if (dex != null) {
Class clazz = dex.loadClassBinaryName(name, definingContext);
if (clazz != null) {
return clazz;
}
}
}
return null;
}
最终还是调用的dexFile.loadClassBinaryName()方法，其中的第二个参数其实就已经是AndroidNClassLoader了
加载补丁资源
Tinker的资源更新采用的InstantRun的资源补丁方式，全量替换资源。由于App加载资源是依赖Context.getResources()方法返回的Resources对象，Resources 内部包装了 AssetManager，最终由 AssetManager 从 apk 文件中加载资源。我们要做的就是新建一个AssetManager()，hook掉其中的addAssetPath()方法，将我们的资源补丁目录传递进去，然后循环替换Resources对象中的AssetManager对象，达到资源替换的目的。
public static void isResourceCanPatch(Context context) throws Throwable {
// Create a new AssetManager instance and point it to the resources installed under /sdcard
AssetManager assets = context.getAssets();
// Baidu os
if (assets.getClass().getName().equals("android.content.res.BaiduAssetManager")) {
Class baiduAssetManager = Class.forName("android.content.res.BaiduAssetManager");
newAssetManager = (AssetManager) baiduAssetManager.getConstructor().newInstance();
} else {
newAssetManager = AssetManager.class.getConstructor().newInstance();
}
addAssetPathMethod = AssetManager.class.getDeclaredMethod("addAssetPath", String.class);
addAssetPathMethod.setAccessible(true);
// Kitkat needs this method call, Lollipop doesn't. However, it doesn't seem to cause any harm
// in L, so we do it unconditionally.
ensureStringBlocksMethod = AssetManager.class.getDeclaredMethod("ensureStringBlocks");
ensureStringBlocksMethod.setAccessible(true);
// Iterate over all known Resources objects
if (SDK_INT >= KITKAT) {
//pre-N
// Find the singleton instance of ResourcesManager
Class<?> resourcesManagerClass = Class.forName("android.app.ResourcesManager");
Method mGetInstance = resourcesManagerClass.getDeclaredMethod("getInstance");
mGetInstance.setAccessible(true);
Object resourcesManager = mGetInstance.invoke(null);
try {
Field fMActiveResources = resourcesManagerClass.getDeclaredField("mActiveResources");
fMActiveResources.setAccessible(true);
ArrayMap<?, WeakReference<Resources>> arrayMap =
(ArrayMap<?, WeakReference<Resources>>) fMActiveResources.get(resourcesManager);
references = arrayMap.values();
} catch (NoSuchFieldException ignore) {
// N moved the resources to mResourceReferences
Field mResourceReferences = resourcesManagerClass.getDeclaredField("mResourceReferences");
mResourceReferences.setAccessible(true);
//noinspection unchecked
references = (Collection<WeakReference<Resources>>) mResourceReferences.get(resourcesManager);
}
} else {
Class<?> activityThread = Class.forName("android.app.ActivityThread");
Field fMActiveResources = activityThread.getDeclaredField("mActiveResources");
fMActiveResources.setAccessible(true);
Object thread = getActivityThread(context, activityThread);
@SuppressWarnings("unchecked")
HashMap<?, WeakReference<Resources>> map =
(HashMap<?, WeakReference<Resources>>) fMActiveResources.get(thread);
references = map.values();
}
// check resource
if (references == null || references.isEmpty()) {
throw new IllegalStateException("resource references is null or empty");
}
try {
assetsFiled = Resources.class.getDeclaredField("mAssets");
assetsFiled.setAccessible(true);
} catch (Throwable ignore) {
// N moved the mAssets inside an mResourcesImpl field
resourcesImplFiled = Resources.class.getDeclaredField("mResourcesImpl");
resourcesImplFiled.setAccessible(true);
}
}
按照步骤来吧，首先新建一个AssetManager对象，其中对BaiduROM做了兼容(BaiduAssetManager)，拿到其中的addAssetPath方法的反射addAssetPathMethod，然后拿到ensureStringBlocks的反射，然后区分版本拿到Resources的集合。
SDK >= 19，从ResourcesManager中拿到mActiveResources变量，是个持有Resources的ArrayMap，赋值给references，Android N中该变量叫做mResourceReferences
SDK < 19，从ActivityThread中获取mActiveResources，是个HashMap持有Resources，赋值给references
如果references为空，说明该系统不支持资源补丁，throw 一个IllegalStateException被上层调用catch。
然后调用monkeyPatchExistingResources方法(这个方法的名字跟InstantRun的资源补丁方法名是一样的)，将补丁资源路径(res/resources.apk)传递进去，代码就不贴了，简单描述为反射调用新建的AssetManager的addAssetPath将路径穿进去，然后主动调用ensureStringBlocks方法确保资源的字符串索引创建出来；然后循环遍历持有Resources对象的references集合，依次替换其中的AssetManager为新建的AssetManager，最后调用Resources.updateConfiguration将Resources对象的配置信息更新到最新状态，完成整个资源替换的过程。
**目前来看InstantRun的资源更新方式最简便而且兼容性也最好，市面上大多数的热补丁框架都采用这套方案。Tinker的这套方案虽然也采用全量的替换，但是在下发patch中依然采用差量资源的方式获取差分包，**下发到手机后再合成全量的资源文件，有效的控制了补丁文件的大小。
加载补丁so
so的更新方式跟dex和资源都不太一样，因为系统提供给了开发者自定义so目录的选项
public final class System {
...
public static void load(String pathName) {
Runtime.getRuntime().load(pathName, VMStack.getCallingClassLoader());
}
...
}
Tinker加载SO补丁提供了两个入口，分别是TinkerInstaller和TinkerApplicationHelper。他们两个的区别是TinkerInstaller只有在Tinker.install过之后才能使用,否则会抛出异常。
//TinkerInstaller
public static boolean loadLibraryFromTinker(Context context, String relativePath, String libname) throws UnsatisfiedLinkError {
final Tinker tinker = Tinker.with(context);
libname = libname.startsWith("lib") ? libname : "lib" + libname;
libname = libname.endsWith(".so") ? libname : libname + ".so";
String relativeLibPath = relativePath + "/" + libname;
//TODO we should add cpu abi, and the real path later
if (tinker.isEnabledForNativeLib() && tinker.isTinkerLoaded()) {
TinkerLoadResult loadResult = tinker.getTinkerLoadResultIfPresent();
if (loadResult.libs != null) {
for (String name : loadResult.libs.keySet()) {
if (name.equals(relativeLibPath)) {
String patchLibraryPath = loadResult.libraryDirectory + "/" + name;
File library = new File(patchLibraryPath);
if (library.exists()) {
//whether we check md5 when load
boolean verifyMd5 = tinker.isTinkerLoadVerify();
if (verifyMd5 && !SharePatchFileUtil.verifyFileMd5(library, loadResult.libs.get(name))) {
tinker.getLoadReporter().onLoadFileMd5Mismatch(library, ShareConstants.TYPE_LIBRARY);
} else {
System.load(patchLibraryPath);
TinkerLog.i(TAG, "loadLibraryFromTinker success:" + patchLibraryPath);
return true;
}
}
}
}
}
}
return false;
}
简单来说就是遍历检查的结果列表libs，找到要加载的类，调用System.load方法进行加载。
遇到的问题
在集成Tinker的过程中，遇到了一个问题(环境是Dalvik，ART没问题)，在前面我们提到了dex.loader的配置，我把项目中用于下载补丁文件的工具类A加到了其中，然后下发补丁报错，出现Class ref in pre-verified class resolved to unexpected implementation的crash。Qzone的那套热补丁为了消除这个错误采用插庄的方式来规避，Tinker采用全量dex的方式来规避该问题，那为什么还会出现呢。
根据log找到了报错点是在工具类A中的一个直接引用类B的方法中报错。错误原因在加载补丁dex一节其实已经提到一些，我们引用过来，这个配置(dex.loader)中的类不会出现在任何全量补丁dex里，也就是说在合成后，这些类还在老的dex文件中，比如在补丁前dex顺序是这样的：oldDex1 -> oldDex2 -> oldDex3…，那么假如修改了dex1中的文件，那么补丁顺序是这样的newDex1 -> oldDex1 -> oldDex2…其中合成后的newDex1中的类是oldDex1中除了dex.loader中标明的类之外的所有类，dex.loader中的类依然在oldDex1中。
也就是说A类是在dex.loader配置中的，补丁后，A依然在oldDex1中，而A的直接引用类B却出现在了newDex1中，并且在之前A类已经被打上了preverify标志，所在A再去newDex1中加载B的话就会报该错误。
那有的同学可能会问了，TinkerApplication也在oldDex1中的，而我们的ApplicationLike在补丁后也出现在了newDex1中，TinkerApplication反射调用ApplicationLike的生命周期方法为什么没有出现crash呢？还记得文章前面的有一个反射么，我们说了要注意后面会讲到，就是在这里用到的。
校验preverify的方法，正常的类加载会走到这里。
ClassObject* dvmResolveClass(const ClassObject* referrer, u4 classIdx,
bool fromUnverifiedConstant)
{
....
if (!fromUnverifiedConstant &&
IS_CLASS_FLAG_SET(referrer, CLASS_ISPREVERIFIED))
...
}
**而反射走了完全不同的路径，不会走到dvmResolveClass方法，也就不会报错了。**反射最直接的目的也是为了隔离开这两个类，也就是隔离开了Tinker组件和app。
为啥Dalvik有问题，ART没问题呢？那是因为在ART虚拟机原生支持从APK文件加载多个dex文件。在应用安装时执行dex2oat扫描 classes(…N).dex文件，并将它们编译成单个oat文件，供 Android设备执，也就不存在MultiDex的问题了。