Android插件化与热修复(六)-微信Tinker原理分析

 

Tinker热修复原理分析

热补丁技术是在用户不需要重新安装应用的情况下实现应用更新，可快速解决一些线上问题。热补丁省去了Android应用发布版本的成本，而且用户端的更新也是无感知的。

Tinker 是微信官方发布的 Android 热补丁解决方案，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新。本文中主要介绍一下Tinker的热补丁实现原理以及部分关键代码，本文中只涉及动态下发代码的方案，So库以及资源的更新在后续文章中再介绍。
在介绍Tinker热修复方案之前，我们先简单介绍一下QZONE 的热修复方案，因为两者的原理类似，Tinker 是一个更优化的方案。QZONE和Tinker都利用了Android 的类加载机制，Android中有两个主要的Classloader，PathClassLoader和DexClassLoader，它们都继承自BaseDexClassLoader，这两个类加载器的主要区别是：Android系统通过PathClassLoader来加载系统类和主dex中的类。而DexClassLoader则可用于加载指定路径的apk、jar或dex文件。上述两个类都是继承自BaseDexClassLoader

 

我们可以看一下关键源码：

//BaseDexClassLoader 

    public BaseDexClassLoader(String dexPath, File optimizedDirectory, String libraryPath, ClassLoader parent) { super(parent); this.pathList = new DexPathList(this, dexPath, libraryPath, optimizedDirectory);//创建一个DexPathList的实例 } protected Class<?> findClass(String name) throws ClassNotFoundException { List<Throwable> suppressedExceptions = new ArrayList<Throwable>(); Class c = pathList.findClass(name, suppressedExceptions); // 调用DexPathList中的findclass方法 return c; } // DexPathList public Class findClass(String name, List<Throwable> suppressed) { for (Element element : dexElements) { DexFile dex = element.dexFile; if (dex != null) { Class clazz = dex.loadClassBinaryName(name, definingContext, suppressed); if (clazz != null) { return clazz; } } } if (dexElementsSuppressedExceptions != null) { suppressed.addAll(Arrays.asList(dexElementsSuppressedExceptions)); } return null; } 

BaseDexClassLoader 的构造函数中创建一个DexPathList实例，DexPathList的构造函数会创建一个dexElements 数组,BaseDexClassLoader 在findclass方法中调用了pathList.findClass，这个方法中会遍历dexpathlist中的dexElements数组，然后初始化DexFile，如果DexFile不为空那么调用DexFile类的loadClassBinaryName方法返回Class实例。简言之，ClassLoader会遍历dexelements,然后加载这个数组中的dex文件. ClassLoader在加载到正确的类之后就会停止加载此类,因此我们将包含正确的类的Dex文件中插入在dexElements数组前面就可以完成对问题类的修复。这便是QQzone方案的主要机制，如下图所示：

 

但是QQ空间热修复技术存在一个问题：假设A类在static方法，private方法，构造函数，override方法中直接引用到B类。如果A类和B类在同一个dex中，那么A类就会被打上CLASS_ISPREVERIFIED标记，被打上这个标记的类不能引用其他dex中的类，否则就会报错，那使用上述的热修复方法就会出问题。为了防止热修复失败，需要防止类被打上CLASS_ISPREVERIFIED的标志（详细机制请参考QQ空间技术文章https://mp.weixin.qq.com/s?__biz=MzI1MTA1MzM2Nw==&mid=400118620&idx=1&sn=b4fdd5055731290eef12ad0d17f39d4a）
Qzone热修复方案会对所有类进行插桩操作，也就是在所有类的构造函数中引用另外一个单独的dex文件 heck.dex文件中的类，这种插桩操作导致所有类都无法打上CLASS_ISPREVERIFIED标识，也就解决了之前描述的问题。但这有一个副作用，会直接导致所有的verify与optimize操作在加载类时触发。这会产生一定的性能损耗。
为了优化性能需要避免进行插桩操作，微信Tinker针对这一问题采用了一种更优的方案。首先我们先通过下图来总体了解下Tinker热修复方案的流程

 

Tinker进行热修复的流程为：

1. 新dex与旧dex通过dex差分算法生成差异包 patch.dex
2. 将patch dex下发到客户端，客户端将patch dex与旧dex合成为新的全量dex
3. 将合成后的全量dex 插入到dex elements前面(此部分和QQ空间机制类似)，完成修复

可见，Tinker和QQ空间方案最大的不同是，Tinker 下发新旧DEX的差异包，然后将差异包和旧包合成新dex之后进行dex的全量替换，这样也就避免了QQ空间中的插桩操作。然后我们详细看下每一个流程的详细实现细节。
Tinker的差量包patch.dex是如何生成的，Tinker生成新旧dex的差异包使用了微信自研的dexdiff算法，dexdiff算法是基于dex文件的结构来设计的，首先我们详细看一下dex文件结构：

 

以下为dex文件中各个区域的内容含义：
header: dex文件头部，记录整个dex文件的相关属性
string_ids: 涉及了文件中所用到的所有字符串，包括内部名称（比如类型描述符）或者代码引用的常量对象。按照UTF-16来进行排序
type_ids: 涉及了文件中所有用到的类型（如类、数组或者原始类型），不论是否是在文件中定义。按照类型字符串在string_ids中的索引来排序
proto_ids: 文件中所有用到的方法原型。列表按返回值类型在type_ids中的索引进行排序，索引相同的话再按参数类型在type_ids中的索引排序。
field_ids: 文件中所有用到的类属性，不论其是否在文件中定义。列表依次按照所在类的类型（type_ids索引）、属性名（string_ids索引）、自身类型（type_ids）进行排序
method_ids: 涉及了文件中所有用到的方法，不论是否在文件中定义。列表依次按照方法所在类的类型（按type_ids索引）、方法名（按string_ids索引）、方法原型（按proto_ids索引），不得含有重复条目
class_defs: 类定义列表，列表的顺序必须符合一个类的基类以及其所实现的接口在这个类的前面这一规则。此外，列表中出现多个同名类的定义是无效的。
data: 数据区，包含上述各个结构所需的所有支持数据。不同的条目有不同的数据对齐要求，如果有需要，会在条目之前插入若干字节以满足合适的对齐
为了更直观的来理解，我们可以将如下代码编译生成dex文件，然后使用dex查看工具来看下Dex中的详细内容

public class Hello { public static void main(String[] argc) { System.out.println("Hello, Android!\n"); } } 

使用dex查看工具查看生成的dex文件，其中 string_ids区域的内容如下：

 

以string section为例，string section记录的是文件中所用到的所有字符串，包括内部名称（比如类型描述符）或者代码引用的常量对象，按照UTF-16来进行排序，如果修改代码后dex文件中这一区域数据发生了变化，我们如何记录数据的变更呢，我们通过一个简化的方案来描述diff算法，如下图示意图(图片引用自文章)，假设左边为原dex文件中的string section区域数据，右侧为修改代码后新dex中string section的数据，并且数据是顺序排列的。那么从old变为new，我们就需要知道哪些位置的数据要删除，哪些位置要添加数据，并把这些变化通过最少的数据量记录下来。

 

看着上面这个简化的示意图，我们描述一下diff算法的主要流程

1. 对于dex文件中的每项Section，遍历其每一项Item，进行新数据与旧数据的对比（新旧数据的对比方法是oldItem.compareTo(newItem)，结果小于0记为DEL，大于0记为ADD），记录在哪些位置需要ADD一个值，哪些位置需要DEL一个值，并把这些操作项存放于patchOperationList中。按照图中的例子，就是删除位置2的数据，在位置5添加f。为了减少存储的数据，
2. Tinker中会遍历patchOperationList，将同一个位置既有DEL标识又有ADD标识的情况，替换为REPLACE标识，最后将ADD，DEL，REPLACE标识数据分别记录到各自的List中
3. 最后将操作记录列表写入补丁patch.dex中
   生成patch.dex后，进行下一步是将patch下发到客户端后合成全量的dex，合成dex这部分内容此处不再展开说，是差量过程的反过程

 

下面通过关键代码来分析下合成dex结束后加载全量dex的流程：因为打完补丁的全量dex的加载是在Application 启动之后onBaseContextAttached完成的，这样无法对application类进行修复，为了解决这一问题Tinker中也是使用了一个application的代理类来完成application的实际逻辑处理。我们从代理application类的onBaseContextAttached方法开始看，设计到的几个关键类如下：

 

以下为源码部分

    @Override
    private void onBaseContextAttached(Context base) { loadTinker(); // 通过反射初始化我们之前传过来的com.tencent.tinker.loader.TinkerLoader，并且调用它的tryLoad方法，这个是加载补丁包的关键方法 ensureDelegate();// 生成application代理类，处理生命周期调用 applicationLike.onBaseContextAttached(base); ... } 

通过反射来调用TinkerLoader中的tryload方法，

    private void loadTinker() { tinkerResultIntent = new Intent(); try { //通过反射调用TinkerLoader中的tryload方法 Class<?> tinkerLoadClass = Class.forName(loaderClassName, false, getClassLoader()); Method loadMethod = tinkerLoadClass.getMethod(TINKER_LOADER_METHOD, TinkerApplication.class, int.class, boolean.class); Constructor<?> constructor = tinkerLoadClass.getConstructor(); tinkerResultIntent = (Intent) loadMethod.invoke(constructor.newInstance(), this, tinkerFlags, tinkerLoadVerifyFlag); } catch (Throwable e) { ShareIntentUtil.setIntentReturnCode(tinkerResultIntent, ShareConstants.ERROR_LOAD_PATCH_UNKNOWN_EXCEPTION); tinkerResultIntent.putExtra(INTENT_PATCH_EXCEPTION, e); } } 

TinkerLoader 类

    public Intent tryLoad(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag) { Intent resultIntent = new Intent(); long begin = SystemClock.elapsedRealtime(); tryLoadPatchFilesInternal(app, tinkerFlag, tinkerLoadVerifyFlag, resultIntent); //在tryLoadPatchFilesInternal中首先要进行环境校验,完成校验流程后再加载补丁，校验的详细内容不展开讨论 long cost = SystemClock.elapsedRealtime() - begin; ShareIntentUtil.setIntentPatchCostTime(resultIntent, cost); return resultIntent; } 

tryLoadPatchFilesInternal中首先进行校验工作，这部分校验工作的代码细节省略

    private void tryLoadPatchFilesInternal(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag, Intent resultIntent) { ....省略掉安全校验部分代码 final boolean isEnabledForDex = ShareTinkerInternals.isTinkerEnabledForDex(tinkerFlag); // 检查是否支持dex文件修复 if (isEnabledForDex) { //tinker/patch.info/patch-641e634c/dex boolean dexCheck = TinkerDexLoader.checkComplete(patchVersionDirectory, securityCheck, resultIntent); // 进一步检查dex文件是否存在 if (!dexCheck) { Log.w(TAG, "tryLoadPatchFiles:dex check fail"); return; } } boolean isSystemOTA = ShareTinkerInternals.isVmArt() && ShareTinkerInternals.isSystemOTA(patchInfo.fingerPrint); resultIntent.putExtra(ShareIntentUtil.INTENT_PATCH_SYSTEM_OTA, isSystemOTA); //如果用户是在ART环境并且做了OTA升级则在加载dex补丁的时候就会先把最近一次的补丁全部DexFile.loadDex一遍重新生成odex.再加载dex补丁 if (isEnabledForDex) { boolean loadTinkerJars = TinkerDexLoader.loadTinkerJars(app, tinkerLoadVerifyFlag, patchVersionDirectory, resultIntent, isSystemOTA); if (!loadTinkerJars) { Log.w(TAG, "tryLoadPatchFiles:onPatchLoadDexesFail"); return; } } ···· return; } 

//TinkerDexLoader
    @TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)
    public static boolean loadTinkerJars(Application application, boolean tinkerLoadVerifyFlag, String directory, Intent intentResult, boolean isSystemOTA) { PathClassLoader classLoader = (PathClassLoader) TinkerDexLoader.class.getClassLoader(); String dexPath = directory + "/" + DEX_PATH + "/"; File optimizeDir = new File(directory + "/" + DEX_OPTIMIZE_PATH); ArrayList<File> legalFiles = new ArrayList<>(); final boolean isArtPlatForm = ShareTinkerInternals.isVmArt(); // 获取合法的文件列表 for (ShareDexDiffPatchInfo info : dexList) { //for dalvik, ignore art support dex if (isJustArtSupportDex(info)) { continue; } String path = dexPath + info.realName; File file = new File(path); } legalFiles.add(file); } //isSystemOTA判断,如果用户是ART环境并且做了OTA升级，加载dex补丁的时候首先将最近一次的补丁全部DexFile.loadDex一遍.之所以这样做是因为有些场景做了OTA后,OTA的规则可能发生变化,在这种情况下去加载上个系统版本oat过的dex就会出现问题. if (isSystemOTA) { parallelOTAResult = true; parallelOTAThrowable = null; Log.w(TAG, "systemOTA, try parallel oat dexes!!!!!"); TinkerParallelDexOptimizer.optimizeAll( legalFiles, optimizeDir, new TinkerParallelDexOptimizer.ResultCallback() { long start; @Override public void onSuccess(File dexFile, File optimizedDir, File optimizedFile) { // Do nothing. Log.i(TAG, "success to optimize dex " + dexFile.getPath() + "use time " + (System.currentTimeMillis() - start)); } @Override public void onFailed(File dexFile, File optimizedDir, Throwable thr) { parallelOTAResult = false; parallelOTAThrowable = thr; Log.i(TAG, "fail to optimize dex " + dexFile.getPath() + "use time " + (System.currentTimeMillis() - start)); } } ); intentResult.putExtra(ShareIntentUtil.INTENT_PATCH_EXCEPTION, parallelOTAThrowable); ShareIntentUtil.setIntentReturnCode(intentResult, ShareConstants.ERROR_LOAD_PATCH_VERSION_PARALLEL_DEX_OPT_EXCEPTION); return false; } } try { //接下来就是调用SystemClassLoaderAdder的installDexes方法 SystemClassLoaderAdder.installDexes(application, classLoader, optimizeDir, legalFiles); } catch (Throwable e) { intentResult.putExtra(ShareIntentUtil.INTENT_PATCH_EXCEPTION, e); ShareIntentUtil.setIntentReturnCode(intentResult, ShareConstants.ERROR_LOAD_PATCH_VERSION_DEX_LOAD_EXCEPTION); return false; } return true; } 

经过前面的各种校验操作后，接下来到了真正加载dex补丁的流程。Tinker加载dex补丁按照系统版本不同会分别进行处理，如果加载失败将记录失败信息到intentResult中。

// SystemClassLoaderAdder
    public static void installDexes(Application application, PathClassLoader loader, File dexOptDir, List<File> files) throws Throwable { if (!files.isEmpty()) { ClassLoader classLoader = loader; if (Build.VERSION.SDK_INT >= 24) { classLoader = AndroidNClassLoader.inject(loader, application); } //because in dalvik, if inner class is not the same classloader with it wrapper class. //it won't fail at dex2opt if (Build.VERSION.SDK_INT >= 23) { V23.install(classLoader, files, dexOptDir); } else if (Build.VERSION.SDK_INT >= 19) { V19.install(classLoader, files, dexOptDir); } else if (Build.VERSION.SDK_INT >= 14) { V14.install(classLoader, files, dexOptDir); } else { V4.install(classLoader, files, dexOptDir); } //install done sPatchDexCount = files.size(); if (!checkDexInstall(classLoader)) { //reset patch dex SystemClassLoaderAdder.uninstallPatchDex(classLoader); throw new TinkerRuntimeException(ShareConstants.CHECK_DEX_INSTALL_FAIL); } } } 

对于每个系统版本的不同处理我们就不一一展开看，看下V23里面的处理流程

//V23
        private static void install(ClassLoader loader, List<File> additionalClassPathEntries,File optimizedDirectory) throws IllegalArgumentException, IllegalAccessException, NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException { Field pathListField = ShareReflectUtil.findField(loader, "pathList"); Object dexPathList = pathListField.get(loader); //通过反射拿到classloader的patchlist变量 ArrayList<IOException> suppressedExceptions = new ArrayList<IOException>(); // 通过反射获取pathList的dexElements参数，把经过合并后的DexElements设置为pathList的dexElements。 ShareReflectUtil.expandFieldArray(dexPathList, "dexElements", makePathElements(dexPathList,new ArrayList<File>(additionalClassPathEntries), optimizedDirectory,suppressedExceptions)); } private static Object[] makePathElements( Object dexPathList, ArrayList<File> files, File optimizedDirectory, ArrayList<IOException> suppressedExceptions) throws IllegalAccessException, InvocationTargetException, NoSuchMethodException { Method makePathElements; try { //反射pathList的makeDexElements方法，传入插件补丁dexList路径与优化过的opt目录，通过这个方法生成一个新的DexElements，这个DexElements为插件的DexElements。 makePathElements = ShareReflectUtil.findMethod(dexPathList, "makePathElements", List.class, File.class, List.class); } catch (NoSuchMethodException e) { Log.e(TAG, "NoSuchMethodException: makePathElements(List,File,List) failure"); try { makePathElements = ShareReflectUtil.findMethod(dexPathList, "makePathElements", ArrayList.class, File.class, ArrayList.class); } catch (NoSuchMethodException e1) { Log.e(TAG, "NoSuchMethodException: makeDexElements(ArrayList,File,ArrayList) failure"); try { Log.e(TAG, "NoSuchMethodException: try use v19 instead"); return V19.makeDexElements(dexPathList, files, optimizedDirectory, suppressedExceptions); } catch (NoSuchMethodException e2) { Log.e(TAG, "NoSuchMethodException: makeDexElements(List,File,List) failure"); throw e2; } } } return (Object[]) makePathElements.invoke(dexPathList, files, optimizedDirectory, suppressedExceptions); } } 

我们看到上面的流程，就是在文章开头的时候讲到的和QZONE一样的原理，通过反射获取到patchlist的dexElements字段，然后将合成补丁后的dex文件插入到dexelements数组的前面，这样打了补丁后的dex就可以先记载到从而完成修复工作。
微信tinker的资源与so的加载将在后续文章中继续介绍。

参考文章列表：
微信Tinker的一切都在这里，包括源码
微信热补丁Tinker – 补丁流程
[dex文件格式]
(http://www.cnblogs.com/dacainiao/p/6035274.html)