# Tinker学习计划(2)-Tinker的原理一

前言

在 Tinker学习计划(1)-Tinker的集成 这边文章中我们首先学习了如何去集成Tinker热更新框架，去实现我们自己App的热更新功能。这篇文章主要是从架构和源码的角度去理解Tinker。我计划是分成以下几步：

• Tinker的结构(主要是分析Tinker的架构，从宏观层面来了解Tinker)
• Tinker代码修复的原理(描述补丁包生效的过程，源码分析)
• Tinker资源修复的原理(Tinker资源构建的原理，及修复的原理，源码层面)
• Tinker对.SO是如何处理的(源码层面)
• tinker-patch-gradle-plugin源码解析
• DexDiff算法(源码层面)

Tinker的结构

包结构

在 Tinker的集成 这篇文章，我们的思路基本是按照Tinker Demo里提供的思路来集成，说白了就是通过在Gradle里Compile腾讯上传的代码，这的确能达成目的，但是对于学习却是不方便的，虽然能看到源码，但是.class文件在IDE里操作起来还是很麻烦的，所以在分析结构和学习源码之前，我们重新打个工程，这个工程里不会像下面这样来应用Lib了：

compile('com.tencent.tinker:tinker-android-lib:1.7.11')
provided("com.tencent.tinker:tinker-android-anno:1.7.11")

而是直接把Tinker开源的其他代码来搭建一个包含所有源码的工程，讲起来特别高大上实际实现起来很简单，这里就不细讲了。贴几张图查来大家就了解了。

首先你注释掉 app/build.gradle 中上面的两个依赖库。然后拷贝Github上Tinker的库过来。

下面是整个工程的结构：

settings.gradle，修改成如下即可：

同步时，可能会遇到如下问题：

Error:Unable to find method 'org.gradle.api.internal.artifacts.configurations.ConfigurationInternal.getModule()Lorg/gradle/api/internal/artifacts/ModuleInternal;'.
Possible causes for this unexpected error include:<ul><li>Gradle's dependency cache may be corrupt (this sometimes occurs after a network connection timeout.)
<a href="syncProject">Re-download dependencies and sync project (requires network)</a></li><li>The state of a Gradle build process (daemon) may be corrupt. Stopping all Gradle daemons may solve this problem.
<a href="stopGradleDaemons">Stop Gradle build processes (requires restart)</a></li><li>Your project may be using a third-party plugin which is not compatible with the other plugins in the project or the version of Gradle requested by the project.</li></ul>In the case of corrupt Gradle processes, you can also try closing the IDE and then killing all Java processes.

解决该问题：只需要修改以下两个地方：

• 修改 /gradle/gradle-wrapper.properties 文件:

  distributionUrl=https://services.gradle.org/distributions/gradle-3.3-all.zip

  修改为：

  distributionUrl=https://services.gradle.org/distributions/gradle-2.14.1-all.zip

• 工程根目录 build.gradle 的gradle插件依赖修改版本，如下：

  classpath 'com.android.tools.build:gradle:2.2.0'

• 其他的估计就是一些路径问题，出现的时候看着改下就可以了。

可能有的童鞋还是不太了解，索性简单花了一个图来表示各个库的依赖关系：

tinker_android_anno :

工程结构如下：

简单的看了下，实际上这是一个为了在编译期间生成Application的类，至于原理很简单，使用者通过DefaultLifeCycle这个注解来填充一些数据，AnnotationProcessor是集成AbstractProcessor这个类的，这个库的作用也就是说在编译完成以后，自动给工程填充了一个Application类，如下：

关于AbstractProcessor原理介绍，可参考文章：
AbstractProcessor参考

tinker-android-lib

跟Tinker框架相关的类及代码都是在Module中，我们业务开发包括集成也只需要关系这个Module即可。

tinker-commons

从名称就可以看出该Module是业务无关的，里面主要是DexPatch相关的代码，包括Tinker是DexDiff核心的部分，后期我们会详细分析。

third-party:aosp_dexutils

主要包含tinker是如何定义Dex的，这个也是业务无关的

third-party:bsdiff_util

bsdiff相关的代码，在某些情况下，微信的Dex合成实际上用的是Bsdiff算法，当然做了优化。

框架原理

这章我们主要对Tinker的框架进行分析，从宏观层面了解tinker的构造，我尽量讲的详细，这是站在我的角度来思考这个问题，有可能和原作者思想有出入的地方，大家理解。讲解之前先看一张图：

可以看出，集成了tinker的App框架分成了两类进程，一个是原来具体业务中的进程，一个是tinker需要的Patch进程。他们的分工也很明确，我们先说下patch进程，这个很好理解，类似于我们的Demo比较简单，一个按钮作为加载load补丁包的入口，或许线上的项目可能是由于服务端灰度来控制补丁包的下发，然后再去加载，事实上都是一个意思，而这个加载补丁包的过程就是在patch进程中进行的，为什么这么做应该也是因为为了减少业务进程的开销吧。从图中可以看出，patch进程的作用主要是在合并Dex，即通过DexDiff算法来合并原始Dex和补丁Dex，优化Dex及为了避免在进程重启时做这个事，在合并玩Dex后，即完成dexopt的过程。当然做这些事之前都有一些校验的工作。至于patch上报，说白了就是定义了一个生命周期，在做这些事情当中如果发生一些异常行为，可以上报给其他模块或者服务端，tinker这块是支持自定义的。按照规则实现它的接口即可。

具体业务进程的定位很简单，只要是做了tinker框架的初始化，检查是否存在补丁吧，如果有补丁包，通过hook的方式替换原始Dex的加载。校验模块也是必须的，load的上报和patch的上报类似。至于里面还有一些安全模式的校验，我们后面会在谈到。

那这两个进程是怎么进行协同的，实际上他们是通过文件来进行沟通和传递数据的，由于涉及到多进程来访问文件，所以里面也用到了文件锁来避免出现问题。

这个图只是一个抽象，让大家从上帝角度来了解tinker的工作原理，这个时候只需要知道tinker是这种原理工作的。

patch进程工作的流程图：

现在是不是有感觉了，大概知道patch进程的工作原理了。接下来，开始撸源码了。

TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), "/sdcard/patch.apk");

这个就是补丁包加载的入口，后面的路径就是放补丁包的路径，如果是云端下发的，就是下载的地址。

DefaultPatchListener.java

int returnCode = patchCheck(path);
if (returnCode == ShareConstants.ERROR_PATCH_OK) {
    TinkerPatchService.runPatchService(context, path);
} else {
    Tinker.with(context).getLoadReporter().onLoadPatchListenerReceiveFail(new File(path), returnCode);
}
return returnCode;

protected int patchCheck(String path) {
    Tinker manager = Tinker.with(context);
    //如果有设置项则判断是否启动tinker，包括在Application中传入的参数来决定
    if (!manager.isTinkerEnabled() || !ShareTinkerInternals.isTinkerEnableWithSharedPreferences(context)) {
        return ShareConstants.ERROR_PATCH_DISABLE;
    }
    File file = new File(path);
    //判断文件合理性
    if (!SharePatchFileUtil.isLegalFile(file)) {
        return ShareConstants.ERROR_PATCH_NOTEXIST;
    }
    //patch进程中不处理这个操作
    if (manager.isPatchProcess()) {
        return ShareConstants.ERROR_PATCH_INSERVICE;
    }
    //由于对与一个patch操作，做完了就会kill patch进程，如果当前patch进程正存在，则不处理
    if(TinkerServiceInternals.isTinkerPatchServiceRunning(context)) {
        return ShareConstants.ERROR_PATCH_RUNNING;
    }
    //不支持vm支持jit编译以及apilevel在24以下的机器
    if (ShareTinkerInternals.isVmJit()) {
        return ShareConstants.ERROR_PATCH_JIT;
    }
        return ShareConstants.ERROR_PATCH_OK;
    }
}

这个类很简单，就是做一些基本的验证，如果错了，会丢到LoadReporter这个接口的实现类，至于怎么处理，用户可以自定义。tinker的默认实现只是打印了错误日志而已。这里就不贴代码了。我们按照流程接着往下说，验证成功以后，tinker会启动一个IntentService。处于 com.XXX.XXX:patch 进程中。

public static void runPatchService(Context context, String path) {
try {
      Intent intent = new Intent(context, TinkerPatchService.class);
      intent.putExtra(PATCH_PATH_EXTRA, path);
      intent.putExtra(RESULT_CLASS_EXTRA, resultServiceClass.getName());
      context.startService(intent);
      } catch (Throwable throwable) {
          TinkerLog.e(TAG, "start patch service fail, exception:" + throwable);
      }
    }
}

我们在来看看TinkerPatchService中的OnHanderIntent这个方法。

protected void onHandleIntent(Intent intent) {
        final Context context = getApplicationContext();
        Tinker tinker = Tinker.with(context);
        //patch开始时，上报给patchReporter的实现类
        tinker.getPatchReporter().onPatchServiceStart(intent);

        if (intent == null) {
            TinkerLog.e(TAG, "TinkerPatchService received a null intent, ignoring.");
            return;
        }
        String path = getPatchPathExtra(intent);
        if (path == null) {
            TinkerLog.e(TAG, "TinkerPatchService can't get the path extra, ignoring.");
            return;
        }
        File patchFile = new File(path);

        long begin = SystemClock.elapsedRealtime();
        boolean result;
        long cost;
        Throwable e = null;
        //提升进程优先级，尽快让patch操作执行，tinker用了两种不同的方案，感
        //兴趣的童鞋可以看下
        increasingPriority();
        PatchResult patchResult = new PatchResult();
        try {
            if (upgradePatchProcessor == null) {
                throw new TinkerRuntimeException("upgradePatchProcessor is null.");
            }
            result = upgradePatchProcessor.tryPatch(context, path, patchResult);
        } catch (Throwable throwable) {
            e = throwable;
            result = false;
            tinker.getPatchReporter().onPatchException(patchFile, e);
        }

        cost = SystemClock.elapsedRealtime() - begin;
        //patch结果出来后，上报给patchReporter的实现类
        tinker.getPatchReporter().
            onPatchResult(patchFile, result, cost);

        patchResult.isSuccess = result;
        patchResult.rawPatchFilePath = path;
        patchResult.costTime = cost;
        patchResult.e = e;

        AbstractResultService.runResultService(context, patchResult, getPatchResultExtra(intent));

    }
}

可以看出来，这个主要是调用upgradePatchProcessor这个类的方法tryPatch。分析这个之前，我们先聊下PatchReporter这个接口。

public interface PatchReporter {
    void onPatchServiceStart(Intent intent);
    void onPatchPackageCheckFail(File patchFile, int errorCode);
    void onPatchVersionCheckFail(File patchFile, SharePatchInfo oldPatchInfo, String patchFileVersion);
    void onPatchTypeExtractFail(File patchFile, File extractTo, String filename, int fileType);
    void onPatchDexOptFail(File patchFile, List<File> dexFiles, Throwable t);
    void onPatchResult(File patchFile, boolean success, long cost);
    void onPatchException(File patchFile, Throwable e);
    void onPatchInfoCorrupted(File patchFile, String oldVersion, String newVersion);
}

实际上细心的同学就会发现，tinker里很多这种设计，主要也是为了方便开发者自定义一些行为，tinker封装了最核心的那部分代码。比方说patch操作，如果在patch操作中出现一些问题，开发者可以定义其行为。

好，我们接着看patch的流程：

public boolean tryPatch(Context context, String tempPatchPath, PatchResult patchResult) {
        Tinker manager = Tinker.with(context);
        final File patchFile = new File(tempPatchPath);
        if (!manager.isTinkerEnabled() || !ShareTinkerInternals.isTinkerEnableWithSharedPreferences(context)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:patch is disabled, just return");
            return false;
        }
        if (!SharePatchFileUtil.isLegalFile(patchFile)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:patch file is not found, just return");
            return false;
        }
        //check the signature, we should create a new checker
        ShareSecurityCheck signatureCheck = new ShareSecurityCheck(context);

        int returnCode = ShareTinkerInternals.checkTinkerPackage(context, manager.getTinkerFlags(), patchFile, signatureCheck);
        if (returnCode != ShareConstants.ERROR_PACKAGE_CHECK_OK) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:onPatchPackageCheckFail");
            manager.getPatchReporter().onPatchPackageCheckFail(patchFile, returnCode);
            return false;
        }

        String patchMd5 = SharePatchFileUtil.getMD5(patchFile);
        if (patchMd5 == null) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:patch md5 is null, just return");
            return false;
        }
        //use md5 as version
        patchResult.patchVersion = patchMd5;

        //check ok, we can real recover a new patch
        final String patchDirectory = manager.getPatchDirectory().getAbsolutePath();

        File patchInfoLockFile = SharePatchFileUtil.getPatchInfoLockFile(patchDirectory);
        File patchInfoFile = SharePatchFileUtil.getPatchInfoFile(patchDirectory);

        SharePatchInfo oldInfo = SharePatchInfo.readAndCheckPropertyWithLock(patchInfoFile, patchInfoLockFile);

        //it is a new patch, so we should not find a exist
        SharePatchInfo newInfo;

        //already have patch
        if (oldInfo != null) {
            if (oldInfo.oldVersion == null || oldInfo.newVersion == null || oldInfo.oatDir == null) {
                TinkerLog.e(TAG, "UpgradePatch tryPatch:onPatchInfoCorrupted");
                manager.getPatchReporter().onPatchInfoCorrupted(patchFile, oldInfo.oldVersion, oldInfo.newVersion);
                return false;
            }

            if (!SharePatchFileUtil.checkIfMd5Valid(patchMd5)) {
                TinkerLog.e(TAG, "UpgradePatch tryPatch:onPatchVersionCheckFail md5 %s is valid", patchMd5);
                manager.getPatchReporter().onPatchVersionCheckFail(patchFile, oldInfo, patchMd5);
                return false;
            }
            // if it is interpret now, use changing flag to wait main process
            final String finalOatDir = oldInfo.oatDir.equals(ShareConstants.INTERPRET_DEX_OPTIMIZE_PATH)
                ? ShareConstants.CHANING_DEX_OPTIMIZE_PATH : oldInfo.oatDir;
            newInfo = new SharePatchInfo(oldInfo.oldVersion, patchMd5, Build.FINGERPRINT, finalOatDir);
        } else {
            newInfo = new SharePatchInfo("", patchMd5, Build.FINGERPRINT, ShareConstants.DEFAULT_DEX_OPTIMIZE_PATH);
        }

        //it is a new patch, we first delete if there is any files
        //don't delete dir for faster retry
//        SharePatchFileUtil.deleteDir(patchVersionDirectory);
        final String patchName = SharePatchFileUtil.getPatchVersionDirectory(patchMd5);

        final String patchVersionDirectory = patchDirectory + "/" + patchName;

        TinkerLog.i(TAG, "UpgradePatch tryPatch:patchVersionDirectory:%s", patchVersionDirectory);

        //copy file
        File destPatchFile = new File(patchVersionDirectory + "/" + SharePatchFileUtil.getPatchVersionFile(patchMd5));

        try {
            // check md5 first
            if (!patchMd5.equals(SharePatchFileUtil.getMD5(destPatchFile))) {
                SharePatchFileUtil.copyFileUsingStream(patchFile, destPatchFile);
                TinkerLog.w(TAG, "UpgradePatch copy patch file, src file: %s size: %d, dest file: %s size:%d", patchFile.getAbsolutePath(), patchFile.length(),
                    destPatchFile.getAbsolutePath(), destPatchFile.length());
            }
        } catch (IOException e) {
//            e.printStackTrace();
            TinkerLog.e(TAG, "UpgradePatch tryPatch:copy patch file fail from %s to %s", patchFile.getPath(), destPatchFile.getPath());
            manager.getPatchReporter().onPatchTypeExtractFail(patchFile, destPatchFile, patchFile.getName(), ShareConstants.TYPE_PATCH_FILE);
            return false;
        }

        //we use destPatchFile instead of patchFile, because patchFile may be deleted during the patch process
        if (!DexDiffPatchInternal.tryRecoverDexFiles(manager, signatureCheck, context, patchVersionDirectory, destPatchFile)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch dex failed");
            return false;
        }

        if (!BsDiffPatchInternal.tryRecoverLibraryFiles(manager, signatureCheck, context, patchVersionDirectory, destPatchFile)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch library failed");
            return false;
        }

        if (!ResDiffPatchInternal.tryRecoverResourceFiles(manager, signatureCheck, context, patchVersionDirectory, destPatchFile)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch resource failed");
            return false;
        }

        // check dex opt file at last, some phone such as VIVO/OPPO like to change dex2oat to interpreted
        if (!DexDiffPatchInternal.waitAndCheckDexOptFile(patchFile, manager)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, check dex opt file failed");
            return false;
        }

        if (!SharePatchInfo.rewritePatchInfoFileWithLock(patchInfoFile, newInfo, patchInfoLockFile)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, rewrite patch info failed");
            manager.getPatchReporter().onPatchInfoCorrupted(patchFile, newInfo.oldVersion, newInfo.newVersion);
            return false;
        }

        TinkerLog.w(TAG, "UpgradePatch tryPatch: done, it is ok");
        return true;
}

这个函数体有几个重要的步骤，一个是签名检查：ShareSecurityCheck。然后是MD5检查，然后是Patch的核心部分，也就是DexDiffPatchInternal、BsDiffPatchInternal、ResDiffPatchInternal，他们都是集成BasePatchInternal。我们先看ShareSecurityCheck：

ShareSecurityCheck
他主要是做了这些工作，第一是判断patch包的签名和当前安装的apk的签名是否一致，详细代码在ShareSecurityCheck类的verifyPatchMetaSignature函数。第二就是判断patch包的tinker_id是否和基准包的tinker_id是否一致。这个很好理解，各自取出manefest中的tinker_id的值来坐下equals判断即可。昨晚这些以后，tinker还做了一个判断，如下：

public static int checkPackageAndTinkerFlag(ShareSecurityCheck securityCheck, int tinkerFlag) {
        if (isTinkerEnabledAll(tinkerFlag)) {
            return ShareConstants.ERROR_PACKAGE_CHECK_OK;
        }
        HashMap<String, String> metaContentMap = securityCheck.getMetaContentMap();
        //check dex
        boolean dexEnable = isTinkerEnabledForDex(tinkerFlag);
        if (!dexEnable && metaContentMap.containsKey(ShareConstants.DEX_META_FILE)) {
            return ShareConstants.ERROR_PACKAGE_CHECK_TINKERFLAG_NOT_SUPPORT;
        }
        //check native library
        boolean nativeEnable = isTinkerEnabledForNativeLib(tinkerFlag);
        if (!nativeEnable && metaContentMap.containsKey(ShareConstants.SO_META_FILE)) {
            return ShareConstants.ERROR_PACKAGE_CHECK_TINKERFLAG_NOT_SUPPORT;
        }
        //check resource
        boolean resEnable = isTinkerEnabledForResource(tinkerFlag);
        if (!resEnable && metaContentMap.containsKey(ShareConstants.RES_META_FILE)) {
            return ShareConstants.ERROR_PACKAGE_CHECK_TINKERFLAG_NOT_SUPPORT;
        }

        return ShareConstants.ERROR_PACKAGE_CHECK_OK;
    }

tinkerFlag是Application申明的时候我们初始化的，主要的含义就是当前tinker支持哪些热更新，dex，so，res，还是全部，或者一个都不。那这个函数主要的作用的是什么呢，实际上tinker在构建patch包时，如果资源有更新，会在asset下生成一个文件dex_meta.txt。

如果有资源或者so的更新也会对应生成，so_meta.txt和res_meta.txt。这样就很好理解了，比如说当前tinker我们设置成不支持代码更新，但是代码确在patch包修改了，那当前的patch包我们认为是一个无效的patch包，随之放弃更新。

我们接着说MD5的校验、说这个之前，我们先彻底的分析一下，tinker存储patch的文件结构，下面是一个做过一次热更新的时候的app files下文件结构图。

• info.lock这个文件是为了解决跨进程读写patch.info这个文件所建立的文件锁

• patch.info说白了是一个配置文件，里面是处理完补丁包以后的一些配置信息，当进程重启以后，patch以外的其他进程会去读这个文件数据来获取当前是否要加载patch的合成包，cat一下这个文件

  
  

  说白了就是一个�key-value形式的ini配置文件，上面#号开头的是注释，可以不用管，dir对应的是dex目录，print是当前rom信息，为了判断OTA升级用的，new和old是版本，tinker的版本是以MD5来做处理的。

• patch-xxxx 目录下面存储的是补丁包的具体数据，patch后面那串数字实际上是补丁包MD5的0到8位。至于为什么是0-8位，是协议层面的事情，暂不撰述。
• patch-xxxx.apk就是补丁包，从云端下载复制到改目录下的。
• dex目录，目录中是从patch.apk中抽取的dex文件，至于为什么以jar结尾(实际上也是dex_meta.txt这个文件中来控制的),原因暂且不明，而为什么在编译的的时候做这个事，猜测可能是由于兼容性(davalik和art).
• odex目录，是通过dex目录中dex文件经过优化Dex2oat而来。两种方式，一种是DexFile.loadDex(**),第二种是通过在代码中构建命令行来进行优化。

那如果是多个补丁包呢？

实际上就是在patch-xxxx目录并列的层次下面多一个patch-xxxx目录而已，后面的xxxx就是那个补丁包的md5取 0-8位。只不过patch.info里的old和new字段对应的是最新的那个补丁包的md5值。

说完了文件结构，我们接着上面的MD5校验继续撸。

MD5在Tinker里的作用主要以下几个方面

• 安全校验，这个很好理解
• 作为当前patch的版本号，以及文件夹以MD5作为标识，类似于Patch-xxxx
• 多个补丁包更新时，判断两个补丁包是否一致

获取MD5是通过下面这个方法来完成的：

public final static String getMD5(final InputStream is) {
        if (is == null) {
            return null;
        }
        try {
            BufferedInputStream bis = new BufferedInputStream(is);
            MessageDigest md = MessageDigest.getInstance("MD5");
            StringBuilder md5Str = new StringBuilder(32);

            byte[] buf = new byte[ShareConstants.MD5_FILE_BUF_LENGTH];
            int readCount;
            while ((readCount = bis.read(buf)) != -1) {
                md.update(buf, 0, readCount);
            }

            byte[] hashValue = md.digest();

            for (int i = 0; i < hashValue.length; i++) {
                md5Str.append(Integer.toString((hashValue[i] & 0xff) + 0x100, 16).substring(1));
            }
            return md5Str.toString();
        } catch (Exception e) {
            return null;
}

那现在配置文件，源文件都准备好了，就要做下面的dex合成，资源合成了。这块我们留到下篇文章接着细说。

总结

好的，今天的文章就到这里，主要分析了Tinker的结构，tinker的启动流程，以及在做dex合成之前，tinker做了哪些事情。下一节我们继续分析。