Tinker API概览

    TinkerInstaller封装了一些比较重要的函数，现作简单的说明：

    Tinker类是整个框架的核心，我们需要构建它的单例。其中intentResult存放是我们加载补丁时的数据，它在install之后才将数据赋值给Tinker与TinkerLoadResult类。

    全部使用默认定义类的构造方法：

    若使用了自定义类，可选择多参数的install方法，具体用法可参考。

    你一定要先install Tinker之后，才能使用Tinker相关的API。不然你只能使用TinkerApplicationHelper.java中的API。

    发起补丁修复请求

    正如之前所说的，所有的补丁升级请求都将会分发到PatchListener去处理。

    发起升级补丁请求，即收到一个新的补丁包，多次补丁也是调用下面这个接口：

    1. public static void onReceiveUpgradePatch(Context context, String patchLocation) {
    2.     Tinker.with(context).getPatchListener().onPatchReceived(patchLocation);
    3. }

    不使用Hack的方式

    更新的Library库文件我们帮你保存在tinker下面的子目录下，但是我们并没有为你区分abi(部分手机判断不准确)。所以若想加载最新的库，你有两种方法，第一个是直接尝试去Tinker更新的库文件中加载，第二个参数是库文件相对安装包的路径。

    1. TinkerLoadLibrary.loadLibraryFromTinker(getApplicationContext(), "assets/x86", "libstlport_shared");

    但是我们更推荐的是，使用TinkerInstaller.loadLibrary接管你所有的库加载，它会自动先尝试去Tinker中的库文件中加载，但是需要注意的是！

    1. //load lib/armeabi library
    2. TinkerLoadLibrary.loadArmLibrary(getApplicationContext(), "libstlport_shared");
    3. //load lib/armeabi-v7a library
    4. TinkerLoadLibrary.loadArmV7Library(getApplicationContext(), "libstlport_shared");

    若想对第三方代码的库文件更新，可先使用TinkerLoadLibrary.load*Library对第三方库做提前的加载！更多使用方法可参考MainActivity.java。

    使用Hack的方式

    以上使用方式似乎并不能做到开发者透明，这是因为我们想尽量少的去hook系统框架减少兼容性的问题。Tinker也提供了一键反射Library Path的方式供大家选择：

    1. TinkerLoadLibrary.installNavitveLibraryABI(context, "armeabi");

    当然，当前手机系统的abi 需要大家自行判断传入即可，这样我们就无需再对library的加载做任何的介入。

    设置LogIml实现

    你可以设置自己的Log输出实现：

    1. public static void setLogIml(TinkerLog.LogImp imp) {
    2.     TinkerLog.setLogImp(imp);
    3. }

    Tinker类是整个库的核心，基本所有的补丁相关的信息我们都可以在这里获取到。TinkerApplication也有一些获取tinkerFlag的相关API，它们可以在Tinker未被初始化前使用。

    获取单例的方法非常简单：

    1. Tinker manager = Tinker.with(context);

    获取加载状态

    成员变量是标记是否有补丁加载成功的标记，只有它为true时，才能保证TinkerLoadResult的各个变量非空。

    获得加载的结果，也就是TinkerLoadResult的实例。它是有可能为空的，使用它请先确保为true：

    1. TinkerLoadResult loadResult = Tinker.with(context).getTinkerLoadResultIfPresent();

    当补丁出现异常或者某些情况，我们可能希望清空全部补丁，调用方法为：

    1. Tinker.with(context).cleanPatch();
    1. Tinker.with(context).cleanPatchByVersion();

    在升级版本时我们也无须手动去清除补丁，框架已经为我们做了这件事情。需要注意的是，在补丁已经加载的前提下清除补丁，可能会引起crash。这个时候更好重启一下所有的进程。

    其他API这里不再一一概述，请大家自行翻阅。

    因为加载补丁是在Tinker的Install之前的，我们将加载的结果保存在intent中，然后在Tinker的install方法中恢复这些结果。这里包括补丁的所有信息，例如加载的dex，library，我们定义的package config以及各个文件的目录等。但是需要注意的是，这里面的变量大多数是nullable。若Tinker的loaded为true，除了(要看补丁包里面是否真的有)，其他变量可以确保非空。

    获取packageConfig：

    这里需要注意的是，检查dex的Md5值需要使用SharePatchFileUtil.verifyDexFileMd5方法,这是由于dex有可能是被我们重新打包成jar模式。

    1. //获得基准包的tinkerId
    2. String oldTinkerId = Tinker.with(context).getTinkerLoadResultIfPresent().getTinkerID();
    3. String newTinkerId = Tinker.with(context).getTinkerLoadResultIfPresent().getNewTinkerID();

    更多接口请参考。

    在有些时候，你可能想在更后的时机才去，甚至在某些进程永远也不会去做这个动作。那样你可以通过TinkerApplicationHelper.java来获得一些当前加载的信息。

    基本所有的信息都可以在这里获得，但是由于这里是直接读取结果intent

    还有其他问题？请参考!