Tinker相关资料汇集

最新推荐文章于 2021-03-24 23:30:19 发布

twinslizzy维

最新推荐文章于 2021-03-24 23:30:19 发布

阅读量1.2k

点赞数

分类专栏：想法相关

想法相关专栏收录该内容

3 篇文章 0 订阅

订阅专栏

Tinker的一个例子

http://blog.csdn.net/y97524027/article/details/52678428

地址：https://github.com/Tencent/tinker

官方介绍：https://my.oschina.net/shwenzhang/blog/751618

接入指南：https://github.com/Tencent/tinker/wiki/Tinker-%E6%8E%A5%E5%85%A5%E6%8C%87%E5%8D%97

今天拿下来集成使用了一下，发现md上对集成使用的过程介绍的比较精简(后来发现wiki上面倒是很详细，需要的同学可以自己去看)，这里记录一下我集成使用的过程。

一、集成

我这里直接使用的是他1.6.2版本（1.6.0-1.6.3集成与使用的应该都类似，但是1.7.0以及以后，修改比较大，配置与使用略有不同）自带的sample，导入到studio中。

二、初始化配置

首先我们需要在app/bulid.gradle中，设置tinkerId的值，很多人开始编译就报错，提示“tinkerId is not set!!!”，就是因为这个值没有设置。获取tinkerId走的

 def gitSha() {  
return 'git rev-parse --short HEAD'.execute().text.trim()  
}

这个方法，也就是获取git的版本号，所以要是你没有安装配置git，或者git没有加入到环境变量中，会得不到git的版本号了。知道了原理，那解决方式就自己想了，我这里就直接写死，上面这个方法直接返回固定字符串。

---------------------------------------------------------------------------

补充：关于获取Git提交版本号

[java] view plain copy

1. git rev-parse --short HEAD

这段代码主要是用来显示最近一次提交到HEAD上的记录编号（类似于“b03b0c4”的字符串。个人对git命令行了解不多，如果有知道的大神麻烦指教一下）。

所以前面说的，除了环境变量配置好git（可以在命令行输入git --version，显示出了版本号，便是配置成功），再把你的项目与git关联起来，并且保证有一次提交记录，才能获取到该字符串。

具体使用可以看我的另一篇文章：关于git命令“git rev-parse --short HEAD”在android studio中使用与配置的个人探究

我在使用sample时先直接写死了。正式应用到项目上时，可以根据自己的实际情况来配置该参数。

---------------------------------------------------------------------------------------------------

之后，我们会看到Manifest.xml中，SampleApplication.Java这个类报红找不到。这个并不影响，因为到时候我们在编译的时候，tinker会为我们生成SampleApplication.java这个类，而起作用的代码就是SampleApplicationLike.java类声明上面的

[java] view plain copy
 @DefaultLifeCycle(application = "tinker.sample.android.app.SampleApplication",  
 flags = ShareConstants.TINKER_ENABLE_ALL,  
loadVerifyFlag = false)

这段注解，我们也可以把这段注解注释了，

自定定义一个SampleApplication类继承 TinkerApplication类，然后加入无参构造方法，得到的类为：

 /** 
 * Created by anzyhui on 2016/9/26. 
 */  
 public class SampleApplication extends TinkerApplication {  
 public SampleApplication(){  
         super(  
                //tinkerFlags, which types is supported  
                //dex only, library only, all support  
               ShareConstants.TINKER_ENABLE_ALL,  
               // This is passed as a string so the shell application does not  
               // have a binary dependency on your ApplicationLifeCycle class.  
               "tinker.sample.android.app.SampleApplicationLike");  
    }  
}

这些都是Tinker这边定好的规矩，咱们得照着来(第二个参数中的".app"不要忘了，也就是路径不要搞错了)，其中第一个参数表示支持修复的类型，有以下类型可以选：

public static final int TINKER_DISABLE             = 0x00;    
public static final int TINKER_DEX_MASK            = 0x01;    
public static final int TINKER_NATIVE_LIBRARY_MASK = 0x02;  
public static final int TINKER_RESOURCE_MASK       = 0x04;  
public static final int TINKER_DEX_AND_LIBRARY     = TINKER_DEX_MASK | TINKER_NATIVE_LIBRARY_MASK;  
public static final int TINKER_ENABLE_ALL          = TINKER_DEX_MASK | TINKER_NATIVE_LIBRARY_MASK | TINKER_RESOURCE_MASK;

从字面理解就知道什么意思了。

重新编译一下，一般也不会有问题，如果报类重复的异常的话，看看你是不是之前已经生成过了SampleApplication了，在\build\intermediates\classes\debug\tinker路径下对应的目录里，有的话，删掉再编译试下。

三、功能测试

（1）debug版本

先尝试debug版本

现在我们模拟打包一个出现bug的版本。

再activity_main.xml中加入俩控件：

<TextView  
    android:id="@+id/tvMessage"  
   android:layout_width="wrap_content"  
  android:layout_height="wrap_content"  
   android:layout_below="@+id/showInfo"  
    android:text="一切正常"    />  
<Button      
     android:id="@+id/btnBug"      
    android:layout_width="wrap_content"      
   android:layout_height="wrap_content"      
   android:layout_alignParentLeft="true"      
  android:layout_alignParentStart="true"      
    android:layout_below="@+id/tvMessage"      
  android:text="点击出现bug"/>

MainActivity中设置点击事件，点击btnBug时，tvMessage显示"出现bug了"文字。

打包生成apk

这时，在build/bakApk目录中，会生成一个apk和一个R.txt文件，R.txt的作用后面再讲。

apk运行至手机中，

点击点击btnBug按钮，显示：

好，现在来修复这个bug。

我们在activity_main.xml中删除该“点击出现bug”按钮，增加“点击修复bug”按钮：

（PS:也就是修改了res文件）

当然了MainActivity中的代码中，也修改了点击事件，删除了“点击出现bug”按钮的点击事件，增加了“点击修复bug”按钮的点击事件。

点击按钮后，上方文本要显示“bug已经修复了”。

代码改好后，我们需要配置一下前面提到了R.txt文件，这里面保存了每次编译得到的每个res文件的id值。

具体配置就是，在app/build.gradle的ext部分，添加oldApk（也就是出现bug的那个apk）的信息：

  ext {  
      //for some reason, you may want to ignore tinkerBuild, such as instant run debug build?  
      tinkerEnabled = true  
      //you should bak the following files  
      //old apk file to build patch apk  
      tinkerOldApkPath = "${bakPath}/app-debug-0927-11-47-21.apk"  //这个是你出现bug的apk完整名称，app/build/bakApk目录下  
      //proguard mapping file to build patch apk  
      tinkerApplyMappingPath = "${bakPath}/"  //暂未开启混淆，不用管  
      //resource R.txt to build patch apk, must input if there is resource changed  
     tinkerApplyResourcePath = "${bakPath}/app-debug-0927-11-47-21-R.txt"  //如果你修复了res文件，需要指定你bug版本的R.txt文件  
   
 }

然后，在studio的右上角，打开gradle，找到tinkerPatchDebug(我一直用的是debug签名，这个根据自己实际情况来)这个task，点击运行。就会在output目录下生成一个tinkerpatch目录，

在里面找到patch_signed_7zip.apk和patch_signed.apk，这就是我们的差分包。

因为代码中指定的差分包路径为：

  loadPatchButton.setOnClickListener(new View.OnClickListener() {  
              @Override  
              public void onClick(View v) {  
                  TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(), Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed_7zip.apk");  
              }  
          });

我们就直接使用patch_signed_7zip.apk，放到我们的手机根目录，再打开app，点击LOAD PATCH，

提示我们补丁加载成功，重启后生效。

这里，我们需要杀掉本进程，再进入app,才能应用补丁包修复成功。

有朋友评论说自己也加载成功但没法修复，是不是按得返回键退出（返回键退出时是activity销毁，进程还在）。

杀进程后再进入 ，应该就可以修复成功了，如果不成功，把补丁包逆向一下，看看自己修复的部分有没有在里面。

重启后，注意看界面上的按钮是不是已经被替换，

按钮已经替换了，这里我已经点击了按钮，所以上方文本内容也提示修复成功。

（2）release版本+混淆

release版本总体使用方式与的bug版本类似，

每次打出正式包时，我们应该备份好。

在打包前，修改app/build.gradle里的

/**  
* task type, you want to bak  
*/  
    //def taskName = "debug"  
    def taskName = "release"

tastName为release，minifyEnabled设置为true，

这样release打包时才会在bakApk下生成对应的apk，R.txt以及mapping文件。

之后的打包是一样的。

打差分包（补丁）的时候，我们要做的，同样是，替换里面的属性：

ext {  
     //for some reason, you may want to ignore tinkerBuild, such as instant run debug build?  
   tinkerEnabled = true  
   //you should bak the following files  
     //old apk file to build patch apk  
    tinkerOldApkPath = "${bakPath}/app-release-0929-11-28-36.apk"  
   //proguard mapping file to build patch apk  
    tinkerApplyMappingPath = "${bakPath}/app-release-0929-11-28-36-mapping.txt"  
  //resource R.txt to build patch apk, must input if there is resource changed  
    tinkerApplyResourcePath = "${bakPath}/app-release-0929-11-28-36-R.txt"        
}

开启了混淆的话，就要设置bug版本release包的mapping文件，以保证两次映射一致。

同样，右侧gradle，点击tinkerPatchRelease。

我这次Gradle任务进行了好几分钟，当时还以为是出错了，后来看了一下下图，

因为我是第一次打release包，所以在下载必要的jar包。

有运行慢的可以点进这里看看，是不是一样的情况。

差分包打包成功后，跟之前一样的操作，我这边测试成功没问题呢。

四、总结

之前研究过AndFix，主要是使用native方法，来修改出现bug的方法，虽然支持的系统版本也很广（2.3~7.0），但是具有一定的局限性，只能修改方法的内部实现，不支持新增方法，新增、修改成员变量等；而基于ClassLoader的各种实现，由于采用在字节码中在构造方法注入一段代码，防止被打上CLASS_ISPREVERIFIED标记，在dalvik中比较影响性能，而且支持系统也不全面，所以都不是特别的完美。而且他们都有一个缺点，不能修改资源文件。

这次Tinker的发布，打破了原有的性能问题，功能局限，实现了，支持对library、java类、res文件的修复，并且除了小部分版本的设备（wiki上说是部分三星api19版本），其他基本都可以覆盖到（yunOS另说）

dex文件是Android平台上可执行文件的类型。
　　对于Android DEX文件进行优化，需要注意的一点是DEX文件的结构是紧凑的，但是我们还是要想方设法的进行提高程序的运行速度，我们就仍然需要对DEX文件进行进一步优化。
　　调整所有字段的字节序（LITTLE_ENDIAN）和对齐结构中的每一个域 验证DEX文件中的所有类 对一些特定的类进行优化，对方法里的操作码进行优化 。优化后的文件大小会有所增加，应该是原Android DEX文件的1-4倍。 优化发生的时机有两个：对于预置应用，可以在系统编译后，生成优化文件，以ODEX结尾。
　　这样在发布时除APK文件（不包含DEX）以外，还有一个相应的Android DEX文件；对于非预置应用，包含在APK文件里的DEX文件会在运行时被优化，优化后的文件将被保存在缓存中。
　　每一个Android应用都运行在一个Dalvik虚拟机实例里，而每一个虚拟机实例都是一个独立的进程空间。虚拟机的线程机制，内存分配和管理，Mutex等等都是依赖底层操作系统而实现的。

Tinker原理分析

http://blog.csdn.net/lostinai/article/details/54694959

背景

在今年的MDCC大会上，微信开发团队宣布正式开源Tinker，在这之前微信团队已经发出过一些Tinker的相关文章，说实话在开源之前我们还是相当期待Tinker开源的，一方面是因为之前使用的热补丁一直存在一些兼容性问题，另一方面也好奇Tinker的实现方案。

在开源后我们团队第一时间着手研究Tinker，在详细阅读了源码之后，我们确定要在之后的一个版本集成Tinker上线，线上效果显示Tinker的修复效果果然牛逼，错误率明显下降的同时也没有报出兼容性的问题。附一张薄荷app使用Tinker修复前后的错误率对比。

从接入Tinker入手

想要深入某个框架，前提是要学会使用它。我们就从Tinker的接入入手一步一步解开它的实现原理。参照wiki我们做了如下操作。

实现一个Application

public class OneApplicationForTinker extends TinkerApplication {
    public OneApplicationForTinker() {
        super(
                //tinkerFlags, tinker支持的类型，dex,library，还是全部都支持！
                ShareConstants.TINKER_ENABLE_ALL,
                //ApplicationLike的实现类，只能传递字符串,不能使用class.getName()
                "com.boohee.one.MyApplication",
                //加载Tinker的主类名，对于特殊需求可能需要使用自己的加载类。需要注意的是：
                //这个类以及它使用的类都是不能被补丁修改的，并且我们需要将它们加到dex.loader[]中。
                //一般来说，我们使用默认即可。
                "com.tencent.tinker.loader.TinkerLoader",
                //由于合成过程中我们已经校验了各个文件的Md5，并将它们存放在/data/data/..目录中。
                // 默认每次加载时我们并不会去校验tinker文件的Md5,但是你也可通过开启loadVerifyFlag强制每次加载时校验，
                // 但是这会带来一定的时间损耗。
                false);
    }
}

其中的几个参数做了详细说明，Tinker其实提供了注解的方式生成该类，但是我们为了更清楚的了解Tinker的原理，所以并没有使用注解。

然后在AndroidManifest.xml中声明该类为application

...
<application
        android:name=".tinker.OneApplicationForTinker"
        ...
</application>

那我们就知道了，app的入口Application就是该类，该类继承自TinkerApplication。然后我们项目中的MyApplication继承自ApplicationLike，其实看到这里，就大概猜到了OneApplicationForTinker可能是一个代理，App中的Application的真正实现还是MyApplication。

Application的替换

为了做分析前的铺垫，我们从最开始的接入入手，实现了OneApplicationForTinker，继承自TinkerApplication。我们继续往下看。
看下TinkerApplication的实现

public abstract class TinkerApplication extends Application {
...

    protected TinkerApplication(int tinkerFlags, String delegateClassName,
                                String loaderClassName, boolean tinkerLoadVerifyFlag) {
        this.tinkerFlags = tinkerFlags;
        this.delegateClassName = delegateClassName;
        this.loaderClassName = loaderClassName;
        this.tinkerLoadVerifyFlag = tinkerLoadVerifyFlag;

    }

    private Object createDelegate() {
        try {
            // Use reflection to create the delegate so it doesn't need to go into the primary dex.
            // And we can also patch it
            Class<?> delegateClass = Class.forName(delegateClassName, false, getClassLoader());
            Constructor<?> constructor = delegateClass.getConstructor(Application.class, int.class, boolean.class, long.class, long.class,
                Intent.class, Resources[].class, ClassLoader[].class, AssetManager[].class);
            return constructor.newInstance(this, tinkerFlags, tinkerLoadVerifyFlag,
                applicationStartElapsedTime, applicationStartMillisTime,
                tinkerResultIntent, resources, classLoader, assetManager);
        } catch (Throwable e) {
            throw new TinkerRuntimeException("createDelegate failed", e);
        }
    }

    private synchronized void ensureDelegate() {
        if (delegate == null) {
            delegate = createDelegate();
        }
    }

    /**
     * Hook for sub-classes to run logic after the {@link Application#attachBaseContext} has been
     * called but before the delegate is created. Implementors should be very careful what they do
     * here since {@link android.app.Application#onCreate} will not have yet been called.
     */
    private void onBaseContextAttached(Context base) {
        applicationStartElapsedTime = SystemClock.elapsedRealtime();
        applicationStartMillisTime = System.currentTimeMillis();
        loadTinker();
        ensureDelegate();
        try {
            Method method = ShareReflectUtil.findMethod(delegate, "onBaseContextAttached", Context.class);
            method.invoke(delegate, base);
        } catch (Throwable t) {
            throw new TinkerRuntimeException("onBaseContextAttached method not found", t);
        }
        //重置安全模式次数，大于等于三次会进入安全模式不再加载
        if (useSafeMode) {
            String processName = ShareTinkerInternals.getProcessName(this);
            String preferName = ShareConstants.TINKER_OWN_PREFERENCE_CONFIG + processName;
            SharedPreferences sp = getSharedPreferences(preferName, Context.MODE_PRIVATE);
            sp.edit().putInt(ShareConstants.TINKER_SAFE_MODE_COUNT, 0).commit();
        }
    }

    @Override
    protected final void attachBaseContext(Context base) {
        super.attachBaseContext(base);
        onBaseContextAttached(base);
    }

    private void delegateMethod(String methodName) {
        if (delegate != null) {
            try {
                Method method = ShareReflectUtil.findMethod(delegate, methodName, new Class[0]);
                method.invoke(delegate, new Object[0]);
            } catch (Throwable t) {
                throw new TinkerRuntimeException(String.format("%s method not found", methodName), t);
            }
        }
    }

    @Override
    public final void onCreate() {
        super.onCreate();
        ensureDelegate();
        delegateMethod("onCreate");
    }
}

TinkerApplication继承自Application，说明它是正经的Application，而且在manifest文件中声明的也必须是它。然后在Application的各个声明周期方法中反射调用delegate同步Application的周期方法回调，其中的delegate是我们传过来的我们项目中的Application MyApplication。

其中的loaderTinker()方法是Tinker的加载流程，我们稍后会讲到，在反射调用MyApplication的attachBaseContext之前，loaderTinker()已经被调用完成，也就是说，Tinker是在加载完整个流程之后才去调用的app中的Application的attachBaseContext开始真正的整个App的生命周期。说白了就是采用了代理。

看到这里，如果你看过我之前写的从Instant run谈Android替换Application和动态加载机制，就会发现跟这个好像。区别在于，InstantRun是在编译器修改manifest插入IncrementalClassLoader，运行时动态替换成项目中实际使用的MyApplication，进而替换了ClassLoader和资源等，开发者在毫不知情的情况下就完成了替换。

其中大量使用了反射，hook系统api，替换运行时系统中保有的Application的引用，最终完成替换，Tinker团队之前做过测试，100w人会有几十个在替换的时候出现问题，而且如果反射替换Application的问题，那么这个过程是不可逆的。Tinker为了兼容性问题考虑，采用了工程代理的方式，避免进入兼容性的坑。虽然可以用注解的方式生成，但是这种方式相比InstantRun的那一套接入成本还是增大不少，不过为了线上的稳定，这一切都是值得的。

还有一点需要注意的是，TinkerApplication是采用反射调用的MyApplication，为什么一定是反射，我们直接传过去MyApplication的引用直接调用不就好了吗？关于这一点，我们后面会详细说明。

补丁加载

在补丁加载之前，我们需要知道补丁文件现在已经下发到app中，并且通过dexDiff合成并且校验然后push到/data/data/package_name/tinker/下。大概的文件目录：

root@android:/data/data/tinker.sample.android/tinker # ls
info.lock
patch-bc7c9396
patch.info

root@android:/data/data/tinker.sample.android/tinker/patch-bc7c9396 # ls
dex
odex
patch-bc7c9396.apk
res

刚才讲到loadTinker()方法是实现Tinker加载补丁的关键，我们继续看下实现

private void loadTinker() {
    //disable tinker, not need to install
    if (tinkerFlags == TINKER_DISABLE) {
        return;
    }
    tinkerResultIntent = new Intent();
    try {
        //reflect tinker loader, because loaderClass may be define by user!
        Class<?> tinkerLoadClass = Class.forName(loaderClassName, false, getClassLoader());

        Method loadMethod = tinkerLoadClass.getMethod(TINKER_LOADER_METHOD, TinkerApplication.class, int.class, boolean.class);
        Constructor<?> constructor = tinkerLoadClass.getConstructor();
        tinkerResultIntent = (Intent) loadMethod.invoke(constructor.newInstance(), this, tinkerFlags, tinkerLoadVerifyFlag);
    } catch (Throwable e) {
        //has exception, put exception error code
        ShareIntentUtil.setIntentReturnCode(tinkerResultIntent, ShareConstants.ERROR_LOAD_PATCH_UNKNOWN_EXCEPTION);
        tinkerResultIntent.putExtra(INTENT_PATCH_EXCEPTION, e);
    }
}

其中的loaderClassName是我们传过来的"com.tencent.tinker.loader.TinkerLoader"，反射调用TinkerLoader的tryLoad()方法拿到加载补丁结果，这里为什么也要用反射，是因为Tinker做了很多扩展性的工作，TinkerLoader只是默认实现，开发者完全可以自己定义加载器完成加载流程。

//TinkerLoader
    /**
     * only main process can handle patch version change or incomplete
     */
    @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;
    }

调用tryLoadPatchFilesInternal()方法，然后计算消耗时间。

    private void tryLoadPatchFilesInternal(TinkerApplication app, int tinkerFlag, boolean tinkerLoadVerifyFlag, Intent resultIntent) {
    ...
    ...
        //tinker/patch.info
        File patchInfoFile = SharePatchFileUtil.getPatchInfoFile(patchDirectoryPath);

        //old = 641e634c5b8f1649c75caf73794acbdf
        //new = 2c150d8560334966952678930ba67fa8
        File patchInfoLockFile = SharePatchFileUtil.getPatchInfoLockFile(patchDirectoryPath);

        patchInfo = SharePatchInfo.readAndCheckPropertyWithLock(patchInfoFile, patchInfoLockFile);

        String oldVersion = patchInfo.oldVersion;
        String newVersion = patchInfo.newVersion;

        resultIntent.putExtra(ShareIntentUtil.INTENT_PATCH_OLD_VERSION, oldVersion);
        resultIntent.putExtra(ShareIntentUtil.INTENT_PATCH_NEW_VERSION, newVersion);

        boolean mainProcess = ShareTinkerInternals.isInMainProcess(app);
        boolean versionChanged = !(oldVersion.equals(newVersion));

        String version = oldVersion;
        if (versionChanged && mainProcess) {
            version = newVersion;
        }

        //patch-641e634c
        String patchName = SharePatchFileUtil.getPatchVersionDirectory(version);

        //tinker/patch.info/patch-641e634c
        String patchVersionDirectory = patchDirectoryPath + "/" + patchName;
        File patchVersionDirectoryFile = new File(patchVersionDirectory);

        //tinker/patch.info/patch-641e634c/patch-641e634c.apk
        File patchVersionFile = new File(patchVersionDirectoryFile.getAbsolutePath(), SharePatchFileUtil.getPatchVersionFile(version));

        ShareSecurityCheck securityCheck = new ShareSecurityCheck(app);

//校验签名和tinkerId
        int returnCode = ShareTinkerInternals.checkSignatureAndTinkerID(app, patchVersionFile, securityCheck);

        resultIntent.putExtra(ShareIntentUtil.INTENT_PATCH_PACKAGE_CONFIG, securityCheck.getPackagePropertiesIfPresent());

        final boolean isEnabledForDex = ShareTinkerInternals.isTinkerEnabledForDex(tinkerFlag);

        if (isEnabledForDex) {
            //tinker/patch.info/patch-641e634c/dex
            boolean dexCheck = TinkerDexLoader.checkComplete(patchVersionDirectory, securityCheck, resultIntent);
            if (!dexCheck) {
                //file not found, do not load patch
                return;
            }
        }

        final boolean isEnabledForNativeLib = ShareTinkerInternals.isTinkerEnabledForNativeLib(tinkerFlag);

        if (isEnabledForNativeLib) {
            //tinker/patch.info/patch-641e634c/lib
            boolean libCheck = TinkerSoLoader.checkComplete(patchVersionDirectory, securityCheck, resultIntent);
            if (!libCheck) {
                //file not found, do not load patch
                return;
            }
        }

        //check resource
        final boolean isEnabledForResource = ShareTinkerInternals.isTinkerEnabledForResource(tinkerFlag);
        Log.w(TAG, "tryLoadPatchFiles:isEnabledForResource:" + isEnabledForResource);
        if (isEnabledForResource) {
            boolean resourceCheck = TinkerResourceLoader.checkComplete(app, patchVersionDirectory, securityCheck, resultIntent);
            if (!resourceCheck) {
                //file not found, do not load patch
                return;
            }
        }
        //we should first try rewrite patch info file, if there is a error, we can't load jar
        if (mainProcess && versionChanged) {
            patchInfo.oldVersion = version;
            //update old version to new
            ...
        }
        //是否已经进入安全模式
        if (!checkSafeModeCount(app)) {
            ...
            return;
        }
        //now we can load patch jar
        if (isEnabledForDex) {
            boolean loadTinkerJars = TinkerDexLoader.loadTinkerJars(app, tinkerLoadVerifyFlag, patchVersionDirectory, resultIntent);
        }

        //now we can load patch resource
        if (isEnabledForResource) {
            boolean loadTinkerResources = TinkerResourceLoader.loadTinkerResources(tinkerLoadVerifyFlag, patchVersionDirectory, resultIntent);
        }
        //all is ok!
        ShareIntentUtil.setIntentReturnCode(resultIntent, ShareConstants.ERROR_LOAD_OK);
        Log.i(TAG, "tryLoadPatchFiles: load end, ok!");
        return;
    }

贴的代码省略了好多判空操作，会判断补丁是否存在，检查补丁信息中的数据是否有效，校验补丁签名以及tinkerId与基准包是否一致。在校验签名时，为了加速校验速度，Tinker只校验 *_meta.txt文件，然后再根据meta文件中的md5校验其他文件。
其中，meta文件有以下几种：

package_meta.txt 补丁包的基本信息
dex_meta.txt 补丁包中dex文件的信息
so_meta.txt 补丁包中so文件的信息
res_meta.txt 补丁包中资源文件的信息

然后根据开发者配置的Tinker可补丁类型判断是否可以加载dex，res，so。然后分别分发给TinkerDexLoader、TinkerSoLoader、TinkerResourceLoader分别进行校验是否符合加载条件进而进行加载。

加载补丁dex

在开始讲load dex之前，先说下Tinker的补丁方案，Tinker采用的是下发差分包，然后在手机端合成全量的dex文件进行加载。而在build.gradle配置中的tinkerPatch

dex.loader = ["com.tencent.tinker.loader.*",
"tinker.sample.android.app.SampleApplication",
"tinker.sample.android.app.BaseBuildInfo"
]

这个配置中的类不会出现在任何全量补丁dex里，也就是说在合成后，这些类还在老的dex文件中，比如在补丁前dex顺序是这样的：oldDex1 -> oldDex2 -> oldDex3..，那么假如修改了dex1中的文件，那么补丁顺序是这样的newDex1 -> oldDex1 -> oldDex2...其中合成后的newDex1中的类是oldDex1中除了dex.loader中标明的类之外的所有类，dex.loader中的类依然在oldDex1中。

由于Tinker的方案是基于Multidex实现的修改dexElements的顺序实现的，所以最终还是要修改classLoder中dexPathList中dexElements的顺序。Android中有两种ClassLoader用于加载dex文件，BootClassLoader、PathClassLoader和DexClassLoader都是继承自BaseDexClassLoader

public BaseDexClassLoader(String dexPath, File optimizedDirectory,
            String libraryPath, ClassLoader parent) {
        super(parent);

        this.originalPath = dexPath;
        this.pathList =
            new DexPathList(this, dexPath, libraryPath, optimizedDirectory);
    }

    @Override
    protected Class<?> findClass(String name) throws ClassNotFoundException {
        Class clazz = pathList.findClass(name);

        if (clazz == null) {
            throw new ClassNotFoundException(name);
        }

        return clazz;
    }
    
//DexPathList
    public Class findClass(String name) {
        for (Element element : dexElements) {
            DexFile dex = element.dexFile;

            if (dex != null) {
                Class clazz = dex.loadClassBinaryName(name, definingContext);
                if (clazz != null) {
                    return clazz;
                }
            }
        }
        return null;
    }

最终在DexPathList的findClass中遍历dexElements，谁在前面用谁。而这个dexElements是在方法makeDexElements中生成的，我们的目的就是hook这个方法把dex插入到dexElements的前面。

继续加载流程，首先调用TinkerDexLoader的checkComplete校验dex_meta.xml文件中记载的dex补丁文件和经过opt优化过的文件是否存在，然后调用loadTinkerJars加载补丁dex。

    /**
     * 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) {

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

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

        ArrayList<File> 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
                    ...
                    return false;
                }
            }
            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;
    }

根据传过来的tinkerLoadVerifyFlag选项控制是否每次加载都要验证dex的md5值，一般来说不需要，默认也是false，会节省加载时间。然后调用SystemClassLoaderAdder去加载。

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

看到这里，如果你之前看过Multidex.install()方法的实现，就会感觉很相似。只不过热修复是把dex插到dexElements的前面，Multidex是把其余的dex插到后面。相同的就是都是分版本加载，我们分别来看，由于v14以下(Android4.0以前)太过古老，我们就不看了，从v14开始。

v14

14 <= SDK < 19
Android 4.0 <= Android系统 < Android 4.4

/**
 * Installer for platform versions 14, 15, 16, 17 and 18.
 */
private static final class V14 {

    private static void install(ClassLoader loader, List<File> additionalClassPathEntries,
                                File optimizedDirectory)
        throws IllegalArgumentException, IllegalAccessException,
        NoSuchFieldException, InvocationTargetException, NoSuchMethodException {
        Field pathListField = ShareReflectUtil.findField(loader, "pathList");
        Object dexPathList = pathListField.get(loader);
        ShareReflectUtil.expandFieldArray(dexPathList, "dexElements", makeDexElements(dexPathList,
            new ArrayList<File>(additionalClassPathEntries), optimizedDirectory));
    }

    private static Object[] makeDexElements(
        Object dexPathList, ArrayList<File> files, File optimizedDirectory)
        throws IllegalAccessException, InvocationTargetException,
        NoSuchMethodException {
        Method makeDexElements =
            ShareReflectUtil.findMethod(dexPathList, "makeDexElements", ArrayList.class, File.class);

        return (Object[]) makeDexElements.invoke(dexPathList, files, optimizedDirectory);
    }
}

反射找到classLoder中的pathList，然后反射调用pathList中的makeDexElements方法，穿进去的参数分别是补丁dexList和优化过的opt目录，在Tinker中是dex补丁目录的同级目录odex/。

其中有个ShareReflectUtil.expandFieldArray我们看下实现

public static void expandFieldArray(Object instance, String fieldName, Object[] extraElements)
    throws NoSuchFieldException, IllegalArgumentException, IllegalAccessException {
    Field jlrField = findField(instance, fieldName);

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

注意传进来的值分别是pathList,”dexElements”和新生成的dexElements数组，找到pathList的原始oldDexElements，然后生成一个新的数组combined，长度是oldDexElements.length + newDexElements.length。然后将newDexElements拷贝到combined的前面，将oldDexElements拷贝的combined的剩余位置，我们称之为dex前置。

刚才我们说Tinker是将dex前置，Multidex是将dex后置，我们顺便看下Multidex.install()中expandFieldArray的实现吧。

//Multidex.java
    private static void expandFieldArray(Object instance, String fieldName,
            Object[] extraElements) throws NoSuchFieldException, IllegalArgumentException,
            IllegalAccessException {
        Field jlrField = findField(instance, fieldName);
        Object[] original = (Object[]) jlrField.get(instance);
        Object[] combined = (Object[]) Array.newInstance(
                original.getClass().getComponentType(), original.length + extraElements.length);
        System.arraycopy(original, 0, combined, 0, original.length);
        System.arraycopy(extraElements, 0, combined, original.length, extraElements.length);
        jlrField.set(instance, combined);
    }

它是先把oldDexElements拷贝到了前面，在把newDexElements拷贝到了后面，我们称之为dex后置。

实际上，对于Multidex的项目，不论Tinker是否加载了补丁，都应该在ApplicationLike的onBaseContextAttached方法中执行MultiDex.install(base);。

v19

19 <= SDK < 23
Android 4.4 <= Android系统 < Android 6.0

跟v14的区别不大，只是在makeDexElements方法中多加了一个参数suppressedExceptions异常数组，另外在makeDexElements的catch异常中多加了一次重试

catch (NoSuchMethodException e) {
                Log.e(TAG, "NoSuchMethodException: makeDexElements(ArrayList,File,ArrayList) failure");
                try {
                    makeDexElements = ShareReflectUtil.findMethod(dexPathList, "makeDexElements", List.class, File.class, List.class);
                } catch (NoSuchMethodException e1) {
                    Log.e(TAG, "NoSuchMethodException: makeDexElements(List,File,List) failure");
                    throw e1;
                }
            }

是因为Tinker发现线上有的Rom将改方法参数类型给改了，本来是makeDexElements(ArrayList,File,ArrayList)，给改成了makeDexElements(List,File,List)，做了个兼容处理。

v23

23 <= SDK < 24
Android 6.0 <= Android系统 < Android 7.0

Android6.0以后把makeDexElements给改了，改成了makePathElements(List,File,List)，如果找不到的话再找一下makeDexElements(List,File,List)。其余没啥区别。

v24

SDK >=24
Android 系统 >= Android7.0

1
2
3

if (Build.VERSION.SDK_INT >= 24) {
    classLoader = AndroidNClassLoader.inject(loader, application);
}

哎，这个好像跟上面不太一样啊，这是为啥呢。
Android N混合编译与对热补丁影响解析中详细解释了混合编译对热不定的影响。我做下简单的总结。

我们知道，在Dalvik虚拟机中，总是在运行时通过JIT（Just-In—Time）把字节码文件编译成机器码文件再执行，这样跑起来程序就很慢，所在ART上，改为AOT（Ahead-Of—Time）提前编译，即在安装应用或OTA系统升级时提前把字节码编译成机器码，这样就可以直接执行了，提高了运行效率。但是AOT有个缺点就是每次执行的时间都太长了，并且占用的ROM空间又很大，所以在Android N上Google做了混合编译同时支持JIT和AOT。混合编译的作用简单来说，在应用运行时分析运行过的代码以及“热代码”，并将配置存储下来。在设备空闲与充电时，ART仅仅编译这份配置中的“热代码”。

简单来说，就是在应用安装和首次运行不做AOT编译，先让用户愉快的玩耍起来，然后把在运行中JIT解释执行的那部分代码收集起来，在手机空闲的时候通过dex2aot编译生成一份名为app image的base.art文件，然后在下次启动的时候一次性把app image加载进来到缓存，预先加载代替用时查找以提升应用的性能。

这种方式对热补丁的影响就是，app image中已经存在的类会被插入到ClassLoader的ClassTable，再次加载类时，直接从ClassTable中取而不会走DefineClass。假设base.art文件在补丁前已经存在，这里存在三种情况：

补丁修改的类都不appimage中；这种情况是最理想的，此时补丁机制依然有效；
补丁修改的类部分在appimage中；这种情况我们只能更新一部分的类，此时是最危险的。一部分类是新的，一部分类是旧的，app可能会出现地址错乱而出现crash。
补丁修改的类全部在appimage中；这种情况只是造成补丁不生效，app并不会因此造成crash。

Tinker的解决方案是，完全废弃掉PathClassloader，而采用一个新建Classloader来加载后续的所有类，即可达到将cache无用化的效果。基本原理我们清楚了，让我们来看下代码吧。

//AndroidNClassLoader.java
    public static AndroidNClassLoader inject(PathClassLoader originClassLoader, Application application) throws Exception {
        AndroidNClassLoader classLoader = createAndroidNClassLoader(originClassLoader);
        reflectPackageInfoClassloader(application, classLoader);
        return classLoader;
    }
    
        private static AndroidNClassLoader createAndroidNClassLoader(PathClassLoader original) throws Exception {
        //let all element ""
        AndroidNClassLoader androidNClassLoader = new AndroidNClassLoader("",  original);
        Field originPathList = findField(original, "pathList");
        Object originPathListObject = originPathList.get(original);
        //should reflect definingContext also
        Field originClassloader = findField(originPathListObject, "definingContext");
        originClassloader.set(originPathListObject, androidNClassLoader);
        //copy pathList
        Field pathListField = findField(androidNClassLoader, "pathList");
        //just use PathClassloader's pathList
        pathListField.set(androidNClassLoader, originPathListObject);
        return androidNClassLoader;
    }

我们按步骤进行：

新建一个AndroidNClassLoader 它的parent是originPathClassLoader。注意，PathClassLoader的optimizedDirectory只能是null，这个后面还有用。
找到originPathClassLoader中的pathList 和 pathList中的类型为ClassLoader的definingContext。
替换definingContext为AndroidNClassLoader
将AndroidNClassLoader中的pathList替换为originPathClassLoader的pathList。

有的同学可能会问，Android 的ClassLoader采用双亲委托模型，只有parent找不到的情况下才会去找AndroidNClassLoader，那我新建这个AndroidNClassLoader有什么用，最终还是会去originPathClassLoader中取找。其实不是这样的，我们已经将originPathClassLoader中pathList中的definingContext(是个ClassLoader)替换为了AndroidNClassLoader了。这个definingContext会在生成DexFile的时候传递进去，而ClassLoader的findClass()方法会调用pathList的findClass方法，如下：

//DexPathList.java
    public Class findClass(String name) {
        for (Element element : dexElements) {
            DexFile dex = element.dexFile;
            if (dex != null) {
                Class clazz = dex.loadClassBinaryName(name, definingContext);
                if (clazz != null) {
                    return clazz;
                }
            }
        }
        return null;
    }

最终还是调用的dexFile.loadClassBinaryName()方法，其中的第二个参数其实就已经是AndroidNClassLoader了。

还记得刚才说的AndroidNClassLder的optimizedDirectory是null吗

//DexPathList.java
    private static Element[] makeDexElements(ArrayList<File> files,
            File optimizedDirectory) {
            ...
            dex = loadDexFile(file, optimizedDirectory);
            ....
    }
    
        private static DexFile loadDexFile(File file, File optimizedDirectory)
            throws IOException {
        if (optimizedDirectory == null) {
            return new DexFile(file);
        } else {
            String optimizedPath = optimizedPathFor(file, optimizedDirectory);
            return DexFile.loadDex(file.getPath(), optimizedPath, 0);
        }
    }

看到这里我们明白了，optimizedDirectory是用来缓存我们需要加载的dex文件的，并创建一个DexFile对象，如果它为null，那么会直接使用dex文件原有的路径来创建DexFile对象。意思也就是说我不需要用缓存，不需要用app image加载。

接续往下走

    private static void reflectPackageInfoClassloader(Application application, ClassLoader reflectClassLoader) throws Exception {
    String defBase = "mBase";
    String defPackageInfo = "mPackageInfo";
    String defClassLoader = "mClassLoader";

    Context baseContext = (Context) findField(application, defBase).get(application);
    Object basePackageInfo = findField(baseContext, defPackageInfo).get(baseContext);
    Field classLoaderField = findField(basePackageInfo, defClassLoader);
    Thread.currentThread().setContextClassLoader(reflectClassLoader);
    classLoaderField.set(basePackageInfo, reflectClassLoader);
}

作用是替换掉了mPackageInfo中的ClassLoader，mPackageInfo是LoadedApk的对象，代表了APK文件在内存中的表示，诸如Apk文件的代码和资源，甚至代码里面的Activity，Service等组件的信息我们都可以通过此对象获取。

//ActivityThread.java
java.lang.ClassLoader cl = r.packageInfo.getClassLoader();
activity = mInstrumentation.newActivity(cl, component.getClassName(), r.intent);
StrictMode.incrementExpectedActivityCount(activity.getClass());
r.intent.setExtrasClassLoader(cl);

到这里就完成了AndroidNClassLoader的创建与替换，接下来的加载过程使用了v23的加载流程，就不细说了。

总结

至此，整个dex加载流程就分析完了。我们看到Tinker在兼容性上做了充足的工作，整个加载流程虽然跟其他基于Multidex的热补丁框架差不多，但是在兼容性上做了更完备的处理。

加载补丁资源

Tinker的资源更新采用的InstantRun的资源补丁方式，全量替换资源。由于App加载资源是依赖Context.getResources()方法返回的Resources对象，Resources 内部包装了 AssetManager，最终由 AssetManager 从 apk 文件中加载资源。我们要做的就是新建一个AssetManager()，hook掉其中的addAssetPath()方法，将我们的资源补丁目录传递进去，然后循环替换Resources对象中的AssetManager对象，达到资源替换的目的。看下代码实现。

首先依然先根据res_meta.xml文件中记载的信息检查文件(res/resources.apk)是否存在，实现在TinkerResourceLoader.checkComplete()方法，然后调用TinkerResourcePatcher.isResourceCanPatch(context);判断是否支持反射更新资源，看下具体的实现

public static void isResourceCanPatch(Context context) throws Throwable {
    // Create a new AssetManager instance and point it to the resources installed under /sdcard
    AssetManager assets = context.getAssets();
    // Baidu os
    if (assets.getClass().getName().equals("android.content.res.BaiduAssetManager")) {
        Class baiduAssetManager = Class.forName("android.content.res.BaiduAssetManager");
        newAssetManager = (AssetManager) baiduAssetManager.getConstructor().newInstance();
    } else {
        newAssetManager = AssetManager.class.getConstructor().newInstance();
    }
    addAssetPathMethod = AssetManager.class.getDeclaredMethod("addAssetPath", String.class);
    addAssetPathMethod.setAccessible(true);

    // Kitkat needs this method call, Lollipop doesn't. However, it doesn't seem to cause any harm
    // in L, so we do it unconditionally.
    ensureStringBlocksMethod = AssetManager.class.getDeclaredMethod("ensureStringBlocks");
    ensureStringBlocksMethod.setAccessible(true);

    // Iterate over all known Resources objects
    if (SDK_INT >= KITKAT) {
        //pre-N
        // Find the singleton instance of ResourcesManager
        Class<?> resourcesManagerClass = Class.forName("android.app.ResourcesManager");
        Method mGetInstance = resourcesManagerClass.getDeclaredMethod("getInstance");
        mGetInstance.setAccessible(true);
        Object resourcesManager = mGetInstance.invoke(null);
        try {
            Field fMActiveResources = resourcesManagerClass.getDeclaredField("mActiveResources");
            fMActiveResources.setAccessible(true);
            ArrayMap<?, WeakReference<Resources>> arrayMap =
                (ArrayMap<?, WeakReference<Resources>>) fMActiveResources.get(resourcesManager);
            references = arrayMap.values();
        } catch (NoSuchFieldException ignore) {
            // N moved the resources to mResourceReferences
            Field mResourceReferences = resourcesManagerClass.getDeclaredField("mResourceReferences");
            mResourceReferences.setAccessible(true);
            //noinspection unchecked
            references = (Collection<WeakReference<Resources>>) mResourceReferences.get(resourcesManager);
        }
    } else {
        Class<?> activityThread = Class.forName("android.app.ActivityThread");
        Field fMActiveResources = activityThread.getDeclaredField("mActiveResources");
        fMActiveResources.setAccessible(true);
        Object thread = getActivityThread(context, activityThread);
        @SuppressWarnings("unchecked")
        HashMap<?, WeakReference<Resources>> map =
            (HashMap<?, WeakReference<Resources>>) fMActiveResources.get(thread);
        references = map.values();
    }
    // check resource
    if (references == null || references.isEmpty()) {
        throw new IllegalStateException("resource references is null or empty");
    }
    try {
        assetsFiled = Resources.class.getDeclaredField("mAssets");
        assetsFiled.setAccessible(true);
    } catch (Throwable ignore) {
        // N moved the mAssets inside an mResourcesImpl field
        resourcesImplFiled = Resources.class.getDeclaredField("mResourcesImpl");
        resourcesImplFiled.setAccessible(true);
    }
}

按照步骤来吧，首先新建一个AssetManager对象，其中对BaiduROM做了兼容(BaiduAssetManager)，拿到其中的addAssetPath方法的反射addAssetPathMethod，然后拿到ensureStringBlocks的反射，然后区分版本拿到Resources的集合。

SDK >= 19，从ResourcesManager中拿到mActiveResources变量，是个持有Resources的ArrayMap，赋值给references，Android N中该变量叫做mResourceReferences
SDK < 19，从ActivityThread中获取mActiveResources，是个HashMap持有Resources，赋值给references

如果references为空，说明该系统不支持资源补丁，throw 一个IllegalStateException被上层调用catch。

然后调用monkeyPatchExistingResources方法(这个方法的名字跟InstantRun的资源补丁方法名是一样的)，将补丁资源路径(res/resources.apk)传递进去，代码就不贴了，简单描述为反射调用新建的AssetManager的addAssetPath将路径穿进去，然后主动调用ensureStringBlocks方法确保资源的字符串索引创建出来；然后循环遍历持有Resources对象的references集合，依次替换其中的AssetManager为新建的AssetManager，最后调用Resources.updateConfiguration将Resources对象的配置信息更新到最新状态，完成整个资源替换的过程。

目前来看InstantRun的资源更新方式最简便而且兼容性也最好，市面上大多数的热补丁框架都采用这套方案。Tinker的这套方案虽然也采用全量的替换，但是在下发patch中依然采用差量资源的方式获取差分包，下发到手机后再合成全量的资源文件，有效的控制了补丁文件的大小。

加载补丁so

依然根据so_meta.txt中的补丁信息校验so文件是否都存在。然后将so补丁列表存放在结果中libs的字段。

so的更新方式跟dex和资源都不太一样，因为系统提供给了开发者自定义so目录的选项

public final class System {
    ...
    public static void load(String pathName) {
        Runtime.getRuntime().load(pathName, VMStack.getCallingClassLoader());
    }
    ...
}

Tinker加载SO补丁提供了两个入口，分别是TinkerInstaller和TinkerApplicationHelper。他们两个的区别是TinkerInstaller只有在Tinker.install过之后才能使用,否则会抛出异常。

//TinkerInstaller
    public static boolean loadLibraryFromTinker(Context context, String relativePath, String libname) throws UnsatisfiedLinkError {
        final Tinker tinker = Tinker.with(context);

        libname = libname.startsWith("lib") ? libname : "lib" + libname;
        libname = libname.endsWith(".so") ? libname : libname + ".so";
        String relativeLibPath = relativePath + "/" + libname;

        //TODO we should add cpu abi, and the real path later
        if (tinker.isEnabledForNativeLib() && tinker.isTinkerLoaded()) {
            TinkerLoadResult loadResult = tinker.getTinkerLoadResultIfPresent();
            if (loadResult.libs != null) {
                for (String name : loadResult.libs.keySet()) {
                    if (name.equals(relativeLibPath)) {
                        String patchLibraryPath = loadResult.libraryDirectory + "/" + name;
                        File library = new File(patchLibraryPath);
                        if (library.exists()) {
                            //whether we check md5 when load
                            boolean verifyMd5 = tinker.isTinkerLoadVerify();
                            if (verifyMd5 && !SharePatchFileUtil.verifyFileMd5(library, loadResult.libs.get(name))) {
                                tinker.getLoadReporter().onLoadFileMd5Mismatch(library, ShareConstants.TYPE_LIBRARY);
                            } else {
                                System.load(patchLibraryPath);
                                TinkerLog.i(TAG, "loadLibraryFromTinker success:" + patchLibraryPath);
                                return true;
                            }
                        }
                    }
                }
            }
        }

        return false;
    }

简单来说就是遍历检查的结果列表libs，找到要加载的类，调用System.load方法进行加载。

遇到的问题

在集成Tinker的过程中，遇到了一个问题(环境是Dalvik，ART没问题)，在前面我们提到了dex.loader的配置，我把项目中用于下载补丁文件的工具类A加到了其中，然后下发补丁报错，出现Class ref in pre-verified class resolved to unexpected implementation的crash。Qzone的那套热补丁为了消除这个错误采用插庄的方式来规避，Tinker采用全量dex的方式来规避该问题，那为什么还会出现呢。

根据log找到了报错点是在工具类A中的一个直接引用类B的方法中报错。错误原因在加载补丁dex一节其实已经提到一些，我们引用过来，这个配置(dex.loader)中的类不会出现在任何全量补丁dex里，也就是说在合成后，这些类还在老的dex文件中，比如在补丁前dex顺序是这样的：oldDex1 -> oldDex2 -> oldDex3..，那么假如修改了dex1中的文件，那么补丁顺序是这样的newDex1 -> oldDex1 -> oldDex2...其中合成后的newDex1中的类是oldDex1中除了dex.loader中标明的类之外的所有类，dex.loader中的类依然在oldDex1中。
也就是说A类是在dex.loader配置中的，补丁后，A依然在oldDex1中，而A的直接引用类B却出现在了newDex1中，并且在之前A类已经被打上了preverify标志，所在A再去newDex1中加载B的话就会报该错误。

那有的同学可能会问了，TinkerApplication也在oldDex1中的，而我们的ApplicationLike在补丁后也出现在了newDex1中，TinkerApplication反射调用ApplicationLike的生命周期方法为什么没有出现crash呢？还记得文章前面的有一个反射么，我们说了要注意后面会讲到，就是在这里用到的。

校验preverify的方法，正常的类加载会走到这里。

ClassObject* dvmResolveClass(const ClassObject* referrer, u4 classIdx,
    bool fromUnverifiedConstant)
{
....
       if (!fromUnverifiedConstant &&
            IS_CLASS_FLAG_SET(referrer, CLASS_ISPREVERIFIED))
...
}

而反射走了完全不同的路径，不会走到dvmResolveClass方法，也就不会报错了。关于这个方法，我们下篇文章会详细讲解。反射最直接的目的也是为了隔离开这两个类，也就是隔离开了Tinker组件和app。如图

通过反射，将Tinker组建和App隔离开，并且先后顺序是先Tinker后App，这样可以防止App中的代码提前加载，确保App中所有的代码都可以具有被热修复的能力包括ApplicationLike。

然后又有同学问了，为啥Dalvik有问题，ART没问题呢？那是因为在ART虚拟机原生支持从APK文件加载多个dex文件。在应用安装时执行dex2oat扫描 classes(..N).dex文件，并将它们编译成单个oat文件，供 Android设备执，也就不存在MultiDex的问题了。

这个问题的issue

总结

到这里，Tinker的基本补丁加载流程就分析完了，本文只对补丁加载流程加以分析，对dexDiff差分以及补丁加载没有做说明，如果你对这部分感兴趣可以参考这篇文章Tinker Dexdiff算法解析。另外ART下的内联影响和OTA升级没有做过多说明，Tinker官方已经有相关文章。

我们简单对Tinker做下总结。
优点：

支持类、资源、so修复
兼容性处理的很好，全平台支持
由于不用插庄，所以性能损耗很小
完善的开发文档和官方技术支持
gradle支持，再自己定义下可以一键打补丁包
dexDiff算法使得补丁文件较小
扩展性良好，代码中处处为开发者留出开放接口，简直业界良心
支持多次补丁

缺点：

不支持及时生效，下发补丁需要重启生效，MultiDex方案决定的
占用ROM空间较大，这点空间在如今的手机大ROM下也不算个事
对加固支持不太好

总结下来Tinker是一种基于单ClassLoader加载多dex方案的热补丁框架，兼容性做的比较好，功能强大。如果你正在考虑接入热补丁，那么强烈推荐你使用Tinker，地精修补匠，带你无限刷新！

参考

微信Tinker的一切都在这里，包括源码(一)
Android N混合编译与对热补丁影响解析
 Tinker Dexdiff算法解析
 从Instant run谈Android替换Application和动态加载机制
 Android动态加载基础 ClassLoader工作机制
 Android应用程序资源管理器（Asset Manager）的创建过程分析

Tinker wiki

https://github.com/Tencent/tinker/wiki

Tinker -- 微信Android热补丁方案

Tinker是什么

Tinker是微信官方的Android热补丁解决方案，它支持动态下发代码、So库以及资源，让应用能够在不需要重新安装的情况下实现更新。当然，你也可以使用Tinker来更新你的插件。

它主要包括以下几个部分：

gradle编译插件: tinker-patch-gradle-plugin
核心sdk库: tinker-android-lib
非gradle编译用户的命令行版本: tinker-patch-cli.jar

为什么使用Tinker

当前市面的热补丁方案有很多，其中比较出名的有阿里的AndFix、美团的Robust以及QZone的超级补丁方案。但它们都存在无法解决的问题，这也是正是我们推出Tinker的原因。

	Tinker	QZone	AndFix	Robust
类替换	yes	yes	no	no
So替换	yes	no	no	no
资源替换	yes	yes	no	no
全平台支持	yes	yes	yes	yes
即时生效	no	no	yes	yes
性能损耗	较小	较大	较小	较小
补丁包大小	较小	较大	一般	一般
开发透明	yes	yes	no	no
复杂度	较低	较低	复杂	复杂
gradle支持	yes	no	no	no
Rom体积	较大	较小	较小	较小
成功率	较高	较高	一般	最高

总的来说:

AndFix作为native解决方案，首先面临的是稳定性与兼容性问题，更重要的是它无法实现类替换，它是需要大量额外的开发成本的；
Robust兼容性与成功率较高，但是它与AndFix一样，无法新增变量与类只能用做的bugFix方案；
Qzone方案可以做到发布产品功能，但是它主要问题是插桩带来Dalvik的性能问题，以及为了解决Art下内存地址问题而导致补丁包急速增大的。

特别是在Android N之后，由于混合编译的inline策略修改，对于市面上的各种方案都不太容易解决。而Tinker热补丁方案不仅支持类、So以及资源的替换，它还是2.X－7.X的全平台支持。利用Tinker我们不仅可以用做bugfix,甚至可以替代功能的发布。Tinker已运行在微信的数亿Android设备上，那么为什么你不使用Tinker呢？

Tinker的已知问题

由于原理与系统限制，Tinker有以下已知问题：

Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大组件；
由于Google Play的开发者条款限制，不建议在GP渠道动态更新代码；
在Android N上，补丁对应用启动时间有轻微的影响；
不支持部分三星android-21机型，加载补丁时会主动抛出"TinkerRuntimeException:checkDexInstall failed"；
由于各个厂商的加固实现并不一致，在1.7.6以及之后的版本，tinker不再支持加固的动态更新；
对于资源替换，不支持修改remoteView。例如transition动画，notification icon以及桌面图标。