微信热补丁Tinker -- 补丁流程

作为开发人员，会用别人的框架是远远不够的，我们可以学习别人的设计思想、实验原理，积累知识，才能不断提升自己。今天这一章主要给大家介绍Tinker补丁流程，深入到代码中去探索Tinker。

补丁流程

在文章[Android热补丁方案][7]中介绍了Tinker的原理框架，那里只是简单介绍一下Tinker框架的补丁流程，这里我重新整理了一份Tinker补丁流程：

上面的流程图中，已经把Tinker的补丁流程和集成Tinker需要注意的逻辑都已经表示的很清楚了。需要注意的地方就是需要开发者自己编写下载过程，然后调用Tinker的Api传入补丁，以及补丁成功后重启应用的逻辑，这个开发者需要结合自己项目的需求来制定，我自己项目里面是通过熄屏监听来杀掉应用进程，进行重启。

在合成补丁流程中，总结了以下几点最重要的部分：

• 安全校验: 无论在补丁合成还是加载，我们都需要有必要的安全校验。
• 版本管理: Tinker 支持补丁升级，甚至是多个补丁不停的切换。这里我们需要保证所有进程版本的一致性；
• 补丁加载: 如果通过反射系统加载我们合成好的 dex，so 与资源；
• 补丁合成: 这些都在单独的 patch 进程工作，这里包括 dex，so 还有资源，主要完成补丁包的合成以及升级；
• 监控回调: 在合成与加载过程中，出现问题及时回调；

经过源码分析，总结出了以下Tinker补丁流程图（上图虚线部分）：

以上图片中，标出了加载流程以及它实现的类和方法，本章也是主要着重这个流程分析。

源码跟踪

一、收到补丁

当补丁下载完成后，即调用下面的函数开始补丁：

/**
 * new patch file to install, try install them with :patch process
 *
 * @param context
 * @param patchLocation
 */
public static void onReceiveUpgradePatch(Context context, String patchLocation) {
    Tinker.with(context).getPatchListener().onPatchReceived(patchLocation, true);
}

此时的Tinker已经被初始化，在ApplicationLike中调用：

TinkerManager.installTinker(this);  

初始化的函数：

/**
 * install tinker with custom config, you must install tinker before you use their api
 * or you can just use {@link TinkerApplicationHelper}'s api
 *
 * @param applicationLike
 * @param loadReporter
 * @param patchReporter
 * @param listener
 * @param resultServiceClass
 * @param upgradePatchProcessor
 * @param repairPatchProcessor
 */
public static void install(ApplicationLike applicationLike, LoadReporter loadReporter, PatchReporter patchReporter,
                           PatchListener listener, Class<? extends AbstractResultService> resultServiceClass,
                           AbstractPatch upgradePatchProcessor, AbstractPatch repairPatchProcessor) {

    Tinker tinker = new Tinker.Builder(applicationLike.getApplication())
        .tinkerFlags(applicationLike.getTinkerFlags())
        .loadReport(loadReporter)
        .listener(listener)
        .patchReporter(patchReporter)
        .tinkerLoadVerifyFlag(applicationLike.getTinkerLoadVerifyFlag()).build();

    Tinker.create(tinker);
    tinker.install(applicationLike.getTinkerResultIntent(), resultServiceClass, upgradePatchProcessor, repairPatchProcessor);
}

传入的参数有：

• ApplicationLike：应用的代理application
• LoadReporter：加载合成的包的报告类
• PatchReporter：打修复包过程中的报告类
• PatchListener：对修复包最开始的检查
• ResultService：从合成进程取合成结果监听
• UpgradePatchProcessor：生成一个新的patch合成包
• ReparePatchProcessor：修复上一次合成失败的修复包

看一下Tinker中核心的install方法：

/**
 * you must install tinker first!!
 *
 * @param intentResult
 * @param serviceClass
 * @param upgradePatch
 * @param repairPatch
 */
public void install(Intent intentResult, Class<? extends AbstractResultService> serviceClass,
                    AbstractPatch upgradePatch, AbstractPatch repairPatch) {
    sInstalled = true;
    AbstractResultService.setResultServiceClass(serviceClass);
    TinkerPatchService.setPatchProcessor(upgradePatch, repairPatch);

    if (!isTinkerEnabled()) {
        TinkerLog.e(TAG, "tinker is disabled");
        return;
    }
    if (intentResult == null) {
        throw new TinkerRuntimeException("intentResult must not be null.");
    }
    tinkerLoadResult = new TinkerLoadResult();
    tinkerLoadResult.parseTinkerResult(getContext(), intentResult);
    //after load code set
    loadReporter.onLoadResult(patchDirectory, tinkerLoadResult.loadCode, tinkerLoadResult.costTime);

    if (!loaded) {
        TinkerLog.w(TAG, "tinker load fail!");
    }
}

主要做了以下的工作：

• 设置自定义的ResultService
• 设置自定义的UpgradePatch和ReparePatch
• 创建TinkerLoadResult调用parseTinkerResult(Context context, Intent intentResult)解析上次合成之后的信息：花费时间，返回值等。
• 调用LoaderReporter的onLoadResult方法，通知，加载结果。

二、补丁校验

准备工作都做完了，下面就是校验补丁包操作了。

调用第一步中的收到补丁函数，则PatchListener接收到补丁包：

/**
 * when we receive a patch, what would we do?
 * you can overwrite it
 *
 * @param path
 * @param isUpgrade
 * @return
 */
@Override
public int onPatchReceived(String path, boolean isUpgrade) {

    int returnCode = patchCheck(path, isUpgrade);

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

DefaultPatchListener的onPatchReceived方法：

• 对补丁包进行检查；
• 如果修复包校验通过，则开启一个单独的进程合成全量包；
• 如果修复包不完整或者有其它问题，则调用LoadReporter的onLoadPatchListenerReceiveFail(File patchFile, int errorCode, boolean isUpgrade)方法通知，并将原有赋予errorCode传达，这里跟我上面总结的流程分析图中一样。

下面我们来看下上述的对补丁的具体校验：

protected int patchCheck(String path, boolean isUpgrade) {
    Tinker manager = Tinker.with(context);
    //check SharePreferences also
    if (!manager.isTinkerEnabled() || 
        !ShareTinkerInternals.isTinkerEnableWithSharedPreferences(context)) {
        return ShareConstants.ERROR_PATCH_DISABLE;
    }
    File file = new File(path);

    if (!file.isFile() || !file.exists() || file.length() == 0) {
        return ShareConstants.ERROR_PATCH_NOTEXIST;
    }

    //patch service can not send request
    if (manager.isPatchProcess()) {
        return ShareConstants.ERROR_PATCH_INSERVICE;
    }

    //if the patch service is running, pending
    if (TinkerServiceInternals.isTinkerPatchServiceRunning(context)) {
        return ShareConstants.ERROR_PATCH_RUNNING;
    }
    return ShareConstants.ERROR_PATCH_OK;
}

这个是DefaultPatchListener的patchCheck方法，这里主要做了四件事：

• 检查Tinker开关是否开启，需要打开
• 检查Patch文件是否存在，需要存在
• 检查是否是合成进程的操作，需要否
• 检查合成进程是否正在执行，需要否

这里的合成进程指的是TinkerPatchService，这个需要检查校验完后才能去启动一个单独的进程去合成补丁。
除了DefaultPatchListener，我们还可以在SimplePatchListener中自定义一些补丁校验，官方Demo中还检查了以下方面：

• 检查Rom空间
• 检查Crash次数
• 检查新旧补丁PatchVersion
• 检查补丁Patch条件是否符合

经过所有的检查，当返回ERROR_PATCH_OK时才会去开启合成进程；若不是则通过LoadReporter的onLoadPatchListenerReceiveFail(File patchFile, int errorCode, boolean isUpgrade)方法通知，并将原有赋予errorCode传达。

三、补丁加载

当检查OK后，即开启

public static void runPatchService(Context context, String path, boolean isUpgradePatch) {
    Intent intent = new Intent(context, TinkerPatchService.class);
    intent.putExtra(PATCH_PATH_EXTRA, path);
    intent.putExtra(PATCH_NEW_EXTRA, isUpgradePatch);

    context.startService(intent);
}

在TinkerPatchService中开启合成进程的服务。它是一个IntentSerivce，是在单独的线程中进行的操作。下面来看一下onHandleIntent中的操作。

protected void onHandleIntent(Intent intent) {
    final Context context = getApplicationContext();
    Tinker tinker = Tinker.with(context);
    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);

    boolean isUpgradePatch = getPatchUpgradeExtra(intent);

    long begin = SystemClock.elapsedRealtime();
    boolean result;
    long cost;
    Throwable e = null;

    increasingPriority();
    PatchResult patchResult = new PatchResult();
    try {
        if (isUpgradePatch) {
            if (upgradePatchProcessor == null) {
                throw new TinkerRuntimeException("upgradePatchProcessor is null.");
            }
            result = upgradePatchProcessor.tryPatch(context, path, patchResult);

        } else {
            //just recover from exist patch
            if (repairPatchProcessor == null) {
                throw new TinkerRuntimeException("upgradePatchProcessor is null.");
            }
            result = repairPatchProcessor.tryPatch(context, path, patchResult);
        }
    } catch (Throwable throwable) {
        e = throwable;
        result = false;
        tinker.getPatchReporter().onPatchException(patchFile, e, isUpgradePatch);
    }

    cost = SystemClock.elapsedRealtime() - begin;
    tinker.getPatchReporter().
        onPatchResult(patchFile, result, cost, isUpgradePatch);

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

    AbstractResultService.runResultService(context, patchResult);
}  

这里主要有几个操作：

• 调用PatchRepoter的onPatchServiceStart(intent)，表示合成Patch的Service开启，用户可以自定义一些标记，用于跟踪合成进程；
• 调用increasingPriority()方法，让服务置于前台服务；
• 第一，startForeground(notificationId, notification); 这个方法，可以让后台服务置于前台，就像音乐播放器的，播放服务一样，不会被系统杀死。
• 第二，开启一个InnerService降低被杀死的概率。
• 调用tryPatch(context, path, patchResult)方法来执行合并操作，并将结果返回，具体的下面再分析这个合成方法，如果两个AbstractPatch为空，则会捕获异常。并且调用PatchReporter的onPatchException来通知。
• 修复成功后调用PatchReporter的onPatchResult()来通知，有花费时间等信息。
• 调用AbstactResultService的runResultService(Context context, PatchResult result)方法。也是在TinkerInstaller的Install的时候赋值。也是一个IntentService。这个Service会将补丁合成进程返回的结果返回给主进程，在单独的线程中执行。onHandleIntent中只是回调了runResultService(Context context, PatchResult result)方法。通过IntentService完成了进程间的通信。

最后我们先来预览一下合成方法：

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 (!patchFile.isFile() || !patchFile.exists()) {
        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, true, returnCode);
        return false;
    }

    patchResult.patchTinkerID = signatureCheck.getNewTinkerID();
    patchResult.baseTinkerID = signatureCheck.getTinkerID();

    //it is a new patch, so we should not find a exist
    SharePatchInfo oldInfo = manager.getTinkerLoadResultIfPresent().patchInfo;
    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;

    SharePatchInfo newInfo;

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

        if (oldInfo.oldVersion.equals(patchMd5) || oldInfo.newVersion.equals(patchMd5)) {
            TinkerLog.e(TAG, "UpgradePatch tryPatch:onPatchVersionCheckFail");
            manager.getPatchReporter().onPatchVersionCheckFail(patchFile, oldInfo, patchMd5, true);
            return false;
        }
        newInfo = new SharePatchInfo(oldInfo.oldVersion, patchMd5);
    } else {
        newInfo = new SharePatchInfo("", patchMd5);
    }

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

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

    final String patchName = SharePatchFileUtil.getPatchVersionDirectory(patchMd5);

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

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

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

    //copy file
    File destPatchFile = new File(patchVersionDirectory + "/" + SharePatchFileUtil.getPatchVersionFile(patchMd5));
    try {
        SharePatchFileUtil.copyFileUsingStream(patchFile, destPatchFile);
        TinkerLog.w(TAG, "UpgradePatch after %s size:%d, %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, true);
        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, true)) {
        TinkerLog.e(TAG, "UpgradePatch tryPatch:new patch recover, try patch dex failed");
        return false;
    }

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

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

    final File patchInfoFile = manager.getPatchInfoFile();

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


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

看到这么长的方法是不是很慌，不要慌，Tinker开发者写代码非常有条理性，从前面的代码分析中可以发现了，好了，下面来分析一下这段代码：

• 首先，还是常规的Tinker开关和Patch文件检查，随后ShareTinkerInternals的静态方法checkTinkerPackage(Context context, int tinkerFlag，File patchFile, ShareSecurityCheck securityCheck)传入了ShareSecurityCheck，主要做了一下检查操作，如果检查失败通过PatchReporter抛出onPatchPackageCheckFail：
• 签名检查，ShareSecurityCheck是检查签名的类，里面封装了签名检查的方法；
• TinkerId检查
• 检查Tinker开关类型，dex、resource、libriry 的支持性。
• SharePatchInfo，存储了修复包的版本信息，有oldVersion和newVersion，newVersion使用的是修复包的md5值。
• oldInfo何时会存在呢？加载成功过一次，也修复成功了，再次执行合成的时候，如果下载的包还是之前的包，则会报告onPatchVersionCheckFail。如果是新的修复包，则会把 oldVersion赋值给 SharePatchInfo(String oldVer, String newVew)中的ondVersion。到此为止，所有的检查已经完成。
• 拷贝修复包到data/data目录，从下载目录文件通过流读出写入data/data目录。
• DexDiff合成dex、BsDiff合成library、ResDiff合成res。
• 拷贝SharePatchInfo到PatchInfoFile中，PatchInfoFile在TinkerInstaller的install方法中初始化。

到这里，整个Tinker修复的流程已经走完，虽然感觉很复杂，但是条理很清晰，安全措施很齐全，也提现了Tinker的稳定性，最后合成补丁到下一篇研究。

---