Tinker Android热补丁框架

国际惯例先贴地址 Tinker开源地址：https://github.com/Tencent/tinker

玩过Dota的童鞋都知道地精修补匠的大招，我们希望发版本可以像它一样做到无限刷新。
Android热补丁技术应该分为以下两个流派：

Native，代表有阿里的Dexposed、AndFix与腾讯的内部方案KKFix；
Java，代表有Qzone的超级补丁、大众点评的nuwa、百度金融的rocooFix, 饿了么的amigo以及美团的robust。
Native流派与Java流派都有着自己的优缺点。事实上从来都没有最好的方案，只有最适合自己的。

Native的代表Dexposed/AndFix；最大挑战在于稳定性与兼容性，而且native异常排查难度更高。另一方面，由于无法增加变量与类等限制，无法做到功能发布级别；
java的代表Qzone；最大挑战在于性能，即Dalvik平台存在插桩导致的性能损耗，Art平台由于地址偏移问题导致补丁包可能过大的问题；

微信针对QQ空间超级补丁技术的不足提出了一个提供DEX差量包，整体替换DEX的方案。主要的原理是与QQ空间超级补丁技术基本相同，区别在于不再将patch.dex增加到elements数组中，而是差量的方式给出patch.dex，然后将patch.dex与应用的classes.dex合并，然后整体替换掉旧的DEX，达到修复的目的。

这里有个问题很关键,Tinker的亮点使用了QQ空间插桩的效果来规避Android的校验机制。 NUWA分析里面有具体介绍。 简单来说dvm有一条规则:一个类如果引用了另一个类,一般是要求他们由同一个dex加载.上面的流程显然犯规了,补丁肯定不和原来的类是同一个dex.但为什么MultiDex这类分包方案不犯规呢?是因为判断犯规有个条件,即如果类没有被打上IS_PREVERIFIED标记则不会触发判定.如果类在静态代码块或构造函数中引用到了不在同一个dex的文件则不会有IS_PREVERIFIED标记.因此最直接的办法就是手动在所有类的构造函数或static函数中加上一行引用其他dex的方法,这个dex出于性能考虑只有一个空的类比如class A {}.这个dex叫做hack dex, 给所有类加引用的步骤叫做"插桩".这也是目前nuwa目前所使用的手段，当然了,手动插桩是不现实的,一般会用JavaAssist做字节码层面的修改,但好像用AspectJ也可以~好处是源码级的改动,不需要做字节码的操作,但目前没人这么搞过
首先看下源码，最新源码是dev分支tags 1.6.2
https://github.com/Tencent/tinker/tree/dev/tinker-android/tinker-android-loader/src/main/java/com/tencent/tinker/loader

2016-10-08 09:51:30屏幕截图.png

从类名可以知道Tinker处理了类的加载,资源的加载以及so库的加载.我们的关注点在类加载上,根据经验判断,TinkerLoader类是类加载模块的入口,因此从该类开始:

@Override

public Intent tryLoad(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag) {

Intent resultIntent = new Intent();

long begin = SystemClock.elapsedRealtime();

tryLoadPatchFilesInternal(app, tinkerFlag, tinkerLoadVerifyFlag, resultIntent);

long cost = SystemClock.elapsedRealtime() - begin;

ShareIntentUtil.setIntentPatchCostTime(resultIntent, cost);

return resultIntent;

}```
TinkerLoader.tryLoad()很明显就是加载dex的入口函数,这里微信统计了加载时间,并进入tryLoadPatchFilesInternal()方法.这个方法较长,主要是对新旧两个dex做合并,这里截取其中关键的步骤:

if (isEnabledForDex) {

//tinker/patch.info/patch-641e634c/dex

boolean dexCheck = TinkerDexLoader.checkComplete(patchVersionDirectory, securityCheck, resultIntent);

if (!dexCheck) {

//file not found, do not load patch

Log.w(TAG, "tryLoadPatchFiles:dex check fail");

return;
}
}```
做了很多安全校验的机制以保证dex可用后,调用TinkerDexLoader.loadTinkerJars()方法.
loadTinkerJars()获取PathClassLoader并读取dex与dvm优化后的odex地址,

/**

 * Load tinker JARs and add them to

 * the Application ClassLoader.

 *

 * @param application The application.

 */

@TargetApi(Build.VERSION_CODES.ICE_CREAM_SANDWICH)

public static boolean loadTinkerJars(Application application, boolean tinkerLoadVerifyFlag, String directory, Intent intentResult) {

if (dexList.isEmpty()) {

Log.w(TAG, "there is no dex to load");

return true;

}

PathClassLoader classLoader = (PathClassLoader) TinkerDexLoader.class.getClassLoader();

if (classLoader != null) {

Log.i(TAG, "classloader: " + classLoader.toString());

} else {

Log.e(TAG, "classloader is null");

ShareIntentUtil.setIntentReturnCode(intentResult, ShareConstants.ERROR_LOAD_PATCH_VERSION_DEX_CLASSLOADER_NULL);

return false;

}

String dexPath = directory + "/" + DEX_PATH + "/";

File optimizeDir = new File(directory + "/" + DEX_OPTIMIZE_PATH);

// Log.i(TAG, "loadTinkerJars: dex path: " + dexPath);

// Log.i(TAG, "loadTinkerJars: opt path: " + optimizeDir.getAbsolutePath());

ArrayList 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);

if (tinkerLoadVerifyFlag) {

long start = System.currentTimeMillis();

String checkMd5 = isArtPlatForm ? info.destMd5InArt : info.destMd5InDvm;

if (!SharePatchFileUtil.verifyDexFileMd5(file, checkMd5)) {

//it is good to delete the mismatch file

ShareIntentUtil.setIntentReturnCode(intentResult, ShareConstants.ERROR_LOAD_PATCH_VERSION_DEX_MD5_MISMATCH);

intentResult.putExtra(ShareIntentUtil.INTENT_PATCH_MISMATCH_DEX_PATH,

file.getAbsolutePath());

return false;

}

Log.i(TAG, "verify dex file:" + file.getPath() + " md5, use time: " + (System.currentTimeMillis() - start));

}

legalFiles.add(file);

}

try {

SystemClassLoaderAdder.installDexes(application, classLoader, optimizeDir, legalFiles);

} catch (Throwable e) {

Log.e(TAG, "install dexes failed");

// e.printStackTrace();

intentResult.putExtra(ShareIntentUtil.INTENT_PATCH_EXCEPTION, e);

ShareIntentUtil.setIntentReturnCode(intentResult, ShareConstants.ERROR_LOAD_PATCH_VERSION_DEX_LOAD_EXCEPTION);

return false;

}

Log.i(TAG, "after loaded classloader: " + application.getClassLoader().toString());

return true;

}

接着遍历dexList,过滤md5不符校验不通过的,调用SystemClassLoaderAdder的 installDexs()方法.


public static void installDexes(Application application, PathClassLoader loader, File dexOptDir, List 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);

}

if (!checkDexInstall()) {

throw new TinkerRuntimeException(ShareConstants.CHECK_DEX_INSTALL_FAIL);

}
}
}```
可以看到Tinker对不同系统版本分开做了处理,这里我们就看使用最广泛的Android4.4到Android5.1.

/**

Installer for platform versions 19.

private static final class V19 {

private static void install(ClassLoader loader, List additionalClassPathEntries,

File optimizedDirectory)

throws IllegalArgumentException, IllegalAccessException,

NoSuchFieldException, InvocationTargetException, NoSuchMethodException, IOException {

/* The patched class loader is expected to be a descendant of

dalvik.system.BaseDexClassLoader. We modify its
dalvik.system.DexPathList pathList field to append additional DEX
file entries.

Field pathListField = ShareReflectUtil.findField(loader, "pathList");

Object dexPathList = pathListField.get(loader);

ArrayList suppressedExceptions = new ArrayList();

ShareReflectUtil.expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList,

new ArrayList(additionalClassPathEntries), optimizedDirectory,

suppressedExceptions));

if (suppressedExceptions.size() > 0) {

for (IOException e : suppressedExceptions) {

Log.w(TAG, "Exception in makeDexElement", e);

throw e;

}

}```
V19.install()中先通过反射获取BaseDexClassLoader中的dexPathList,然后调用了ShareReflectUtil.expandFieldArray().值得一提的是微信对异常的处理很细致,用List接收dexElements数组中每一个dex加载抛出的异常而不是笼统的抛出一个大异常.

接着跟到shareutil包下的ShareReflectUtil类,不要被它的注释误导了,这里不是替换普通的Field,调用这个方法的入参fieldName正是上一步中的”dexElements”,在这么不起眼的一个工具类中终于找到了Dex流派的核心方法。

/**
public static void expandFieldArray(Object instance, String fieldName, Object[] extraElements)

throws NoSuchFieldException, IllegalArgumentException, IllegalAccessException {

Field jlrField = findField(instance, fieldName);//这句是关键，这里的jlrField也就是所谓的dexElements

Object[] original = (Object[]) jlrField.get(instance);

Object[] combined = (Object[]) Array.newInstance(original.getClass().getComponentType(), original.length + extraElements.length);

// NOTE: changed to copy extraElements first, for patch load first

System.arraycopy(extraElements, 0, combined, 0, extraElements.length);

System.arraycopy(original, 0, combined, extraElements.length, original.length);

jlrField.set(instance, combined);

}

Tinker本质仍然是用dexElements中位置靠前的Dex优先加载类来实现热修复: )(ps：并没有传说那么先进)

Tinker虽然原理不变,但它也有拿得出手的重大优化:传统的插桩步骤会导致第一次加载类时耗时变长.应用启动时通常会加载大量类,所以对启动时间的影响很可观.Tinker的亮点是通过全量替换dex的方式避免unexpectedDEX,这样做所有的类自然都在同一个dex中.但这会带来补丁包dex过大的问题,由此微信自研了DexDiff算法来取代传统的BsDiff,极大降低了补丁包大小,又规避了运行性能问题又减小了补丁包大小,可以说是Dex流派的一大进步.

简单来说，在编译时通过新旧两个Dex生成差异path.dex。在运行时，将差异patch.dex重新跟原始安装包的旧Dex还原为新的Dex。这个过程可能比较耗费时间与内存，所以我们是单独放在一个后台进程:patch中。为了补丁包尽量的小，微信自研了DexDiff算法，它深度利用Dex的格式来减少差异的大小。它的粒度是Dex格式的每一项，可以充分利用原本Dex的信息，而BsDiff的粒度是文件，AndFix/QZone的粒度为class。

关于微信所使用的三种算法，如图所示

BsDiff；它格式无关，但对Dex效果不是特别好，而且非常不稳定。当前微信对于so与部分资源，依然使用bsdiff算法；

DexMerge；它主要问题在于合成时内存占用过大，一个12M的dex，峰值内存可能达到70多M；

DexDiff；通过深入Dex格式，实现一套diff差异小，内存占用少以及支持增删改的算法。

由于微信发布的Android_N混合编译与对热补丁影响解析,所以在tinker中完全使用了新的Dex，那样既不出现Art地址错乱的问题，在Dalvik也无须插桩。当然考虑到补丁包的体积，我们不能直接将新的Dex放在里面。但我们可以将新旧两个Dex的差异放到补丁包中

关于算法这块不再做过多介绍，根据腾讯bugly说后面会出文章详细说明。

整体的流程如下：

从流程图来看，同样可以很明显的找到这种方式的特点：

优势：
合成整包，不用在构造函数插入代码，防止verify，verify和opt在编译期间就已经完成，不会在运行期间进行
性能提高。兼容性和稳定性比较高。
开发者透明，不需要对包进行额外处理。
不足：
与超级补丁技术一样，不支持即时生效，必须通过重启应用的方式才能生效。
需要给应用开启新的进程才能进行合并，并且很容易因为内存消耗等原因合并失败。
合并时占用额外磁盘空间，对于多DEX的应用来说，如果修改了多个DEX文件，就需要下发多个patch.dex与对应的classes.dex进行合并操作时这种情况会更严重，因此合并过程的失败率也会更高。

目前热补丁各式各样，眼花缭乱啊。。。。思密达。。请勿转载使用，～～～～

Android历练记是一个关于Android最新技术探讨，包含安全，架构，Android技术开发，ui绘制，源码解析等领域，如果你有兴趣，我们可以一起讨论学习，
关注微信公众号 Android历练记 或扫一扫二维码：

Android历练记

Tinker Android热补丁框架

你可能感兴趣的:(Tinker Android热补丁框架)