tinker热修复——install过程

上一篇文章《tinker热修复——补丁加载合成》我们了解到了补丁加载合成的过程，但是在补丁加载合成过程中，有很多参数是在哪里传到加载合成过程的呢？比如loadReporter、patchReporter和 patchListener等参数，那么本文将为你一 一揭晓。

首先我们tinker的sample出发，看下tinker是如何一步步初始化，将参数传到加载合成过程的。

SampleApplicationLike的onBaseContextAttached方法

主要做的事情：

1、安装multiDex；

2、使用SampleApplicationContext缓存application和context；

3、利用TinkerManager做一些tinker的管理工作，设置好配置；

4、调用TinkerManager.installTinker方法。

我们主要到最重要的是调用TinkerManager.installTinker这个方法，那么方法很显然就是安装tineker，应该就是做一些tinker初始化的配置。

从方法的开头注释中我们知道，在这里我们可以指定自己的class，并且，有时，你只能安装tinker在你想要的进程中。

在该方法中，sample使用了自定义的报告类，如SampleLoadReporter等到，但是自定义的Reporter都要继承tinker默认的reporter，注入自定义的报告类，我们可以更加方便的获取得到tinker的安装合成的过程响应信息。

这里的UpgradePatch类就是上篇文章中，我们找到的tryPatch方法来合成补丁的实现类，而在安装tinker的时候已经将该类注入到Service中去了，在installTinker方法中最后调用了TinkerInstaller.install方法，而这个方法才是真正安装tinker，初始化tinekr，并将上面new出来的对象和需要的类，以参数的形式注入到Tinker中去了。

关于参数的说明，请看方法头的注释。 首先获取tinker对象并且将tinkerFlag、loadReporter、listener、patchReporter和tinkerLoadVerifyFlag设置到tinker，然后调用tinker的create，将刚刚通过Tinker.Builder创建的tinker赋值给Tinker的sInstance。最后调用tinker.install方法，接下来我们看看该方法的实现。

首先通过TinkerPatchService的setPatchProcessor方法将upgradePatch和resultService传到TinkerPatchService，而TinkerPatchService在《tinker热修复——补丁加载合成》我们已经看到其主要是为合成补丁包开启的一个新进程的服务，而补丁包的合成是在upgradePatch的tryPatch方法中实现的，resultService监听合成的结果。最后new一个TinkerLoadResult对象，然后调用其parseTinkerResult方法来解析加载合成补丁的结果，最后调用onLoadResult方法将结果通知。

其实Tinker的install过程就是初始化Tinker，并且自定义一些报告类和监听接口，以及Service等初始化，同时初始化Tinker的配置等。这些都是为了tinker合成补丁包做准备工作。