<h2>1 概述</h2>    <p>热修复这项技术，基本上已经成为项目比较重要的模块了。主要因为项目在上线之后，都难免会有各种问题，而依靠发版去修复问题，成本太高了。</p>    <p>现在热修复的技术基本上有阿里的AndFix、QZone的方案、美团提出的思想方案以及腾讯的Tinker等。</p>    <p>其中AndFix可能接入是最简单的一个（和Tinker命令行接入方式差不多），不过兼容性还是是有一定的问题的；QZone方案对性能会有一定的影响，且在Art模式下出现内存错乱的问题(其实这个问题我之前并不清楚，主要是tinker在MDCC上指出的);美团提出的思想方案主要是基于Instant Run的原理，目前尚未开源，不过这个方案我还是蛮喜欢的，主要是兼容性好。</p>    <p>这么看来，如果选择开源方案，tinker目前是最佳的选择，tinker的介绍有这么一句：</p>    <p>Tinker已运行在微信的数亿Android设备上，那么为什么你不使用Tinker呢？</p>    <p>好了，说了这么多，下面来看看tinker如何接入，以及tinker的大致的原理分析。希望通过本文可以实现帮助大家更好的接入tinker，以及去了解tinker的一个大致的原理。</p>    <h2>2 接入Tinker</h2>    <p>接入tinker目前给了两种方式，一种是基于命令行的方式，类似于AndFix的接入方式；一种就是gradle的方式。</p>    <p>考虑早期使用Andfix的app应该挺多的，以及很多人对gradle的相关配置还是觉得比较繁琐的，下面对两种方式都介绍下。</p>    <p>> > > ></p>    <p>（1）命令行接入</p>    <h3> </h3>    <p>接入之前我们先考虑下，接入的话，正常需要的前提（开启混淆的状态）。</p>    <ul>     <li> <p>对于API一般来说，我们接入热修库，会在Application#onCreate中进行一下初始化操作。然后在某个地方去调用类似loadPatch这样的API去加载patch文件。</p> </li>     <li> <p>对于patch的生成简单的方式就是通过两个apk做对比然后生成；需要注意的是：两个apk做对比，需要的前提条件，第二次打包混淆所使用的mapping文件应该和线上apk是一致的。</p> </li>    </ul>    <p>最后就是看看这个项目有没有需要配置混淆；</p>    <p>有了大致的概念，我们就基本了解命令行接入tinker，大致需要哪些步骤了。</p>    <p>依赖引入</p>    <pre>  dependencies {      // ...      //可选，用于生成application类      provided('com.tencent.tinker:tinker-android-anno:1.7.7')      //tinker的核心库      compile('com.tencent.tinker:tinker-android-lib:1.7.7')  }</pre>    <p>顺便加一下签名的配置：</p>    <p><img src="https://simg.open-open.com/show/b9354077496fdef80a08006051d10727.jpg"></p>    <p>文末会有demo的下载地址，可以直接参考build.gradle文件，不用担心这些签名文件去哪找。</p>    <p>API引入</p>    <p>API主要就是初始化和loadPacth。</p>    <p>正常情况下，我们会考虑在Application的onCreate中去初始化，不过tinker推荐下面的写法：</p>    <p><img src="https://simg.open-open.com/show/052ccb843f7f4aedc658ec66e93f3e46.jpg"></p>    <p>ApplicationLike通过名字你可能会猜，并非是Application的子类，而是一个类似Application的类。</p>    <p>tinker建议编写一个ApplicationLike的子类，你可以当成Application去使用，注意顶部的注解：@DefaultLifeCycle，其application属性，会在编译期生成一个SimpleTinkerInApplication类。</p>    <p>所以，虽然我们这么写了，但是实际上Application会在编译期生成，所以AndroidManifest.xml中是这样的：</p>    <pre>  <application          android:name=".SimpleTinkerInApplication"          .../></pre>    <p>编写如果报红，可以build下。</p>    <p>这样其实也能猜出来，这个注解背后有个Annotation Processor在做处理，如果你没了解过，可以看下：</p>    <ul>     <li> <p>Android 如何编写基于编译时注解的项目（ http://blog.csdn.net/lmj623565791/article/details/51931859 ）</p> </li>    </ul>    <p>通过该文会对一个编译时注解的运行流程和基本API有一定的掌握，文中也会对tinker该部分的源码做解析。</p>    <p>上述，就完成了tinker的初始化，那么调用loadPatch的时机，我们直接在Activity中添加一个Button设置：</p>    <p><img src="https://simg.open-open.com/show/e120901de488d5290f0d08ef79f388ad.jpg"></p>    <p>我们会将patch文件直接push到sdcard根目录；</p>    <p>所以一定要注意：添加SDCard权限，如果你是6.x以上的系统，自己添加上授权代码，或者手动在设置页面打开SDCard读写权限。</p>    <pre>  <uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" /></pre>    <p>除以以外，有个特殊的地方就是tinker需要在AndroidManifest.xml中指定TINKER_ID。</p>    <pre>  <application>    <meta-data              android:name="TINKER_ID"              android:value="tinker_id_6235657" />      //...  </application></pre>    <p>到此API相关的就结束了，剩下的就是考虑patch如何生成。</p>    <p>patch生成</p>    <p>tinker提供了patch生成的工具，源码见： tinker-patch-cli ，打成一个jar就可以使用，并且提供了命令行相关的参数以及文件。</p>    <p>命令行如下：</p>    <pre>  java -jar tinker-patch-cli-1.7.7.jar       -old old.apk       -new new.apk       -config tinker_config.xml       -out output</pre>    <p>需要注意的就是tinker_config.xml，里面包含tinker的配置，例如签名文件等。</p>    <p>这里我们直接使用tinker提供的签名文件，所以不需要做修改，不过里面有个Application的item修改为与本例一致：</p>    <pre>  <loader value="com.zhy.tinkersimplein.SimpleTinkerInApplication"/></pre>    <p>大致的文件结构如下：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/93a51bbe380f4ac1b59eb99778554719.jpg"></p>    <p>可以在tinker-patch-cli（ https://github.com/Tencent/tinker/tree/master/tinker-build/tinker-patch-cli ）中提取，或者直接下载文末的例子。</p>    <p>上述介绍了patch生成的命令，最后需要注意的就是，在第一次打出apk的时候，保留下生成的mapping文件，在/build/outputs/mapping/release/mapping.txt。</p>    <p>可以copy到与proguard-rules.pro同目录，同时在第二次打修复包的时候，在proguard-rules.pro中添加上：</p>    <pre>  -applymapping mapping.txt</pre>    <p>保证后续的打包与线上包使用的是同一个mapping文件。</p>    <p>tinker本身的混淆相关配置，可以参考：</p>    <ul>     <li> <p>tinker_proguard.pro（ https://github.com/Tencent/tinker/blob/master/tinker-build/tinker-patch-cli/tool_output/tinker_proguard.pro ）</p> </li>    </ul>    <p>如果，你对该部分描述不了解，可以直接查看源码即可。</p>    <p>测试</p>    <p>首先随便生成一个apk（API、混淆相关已经按照上述引入），安装到手机或者模拟器上。</p>    <p>然后，copy出mapping.txt文件，设置applymapping，修改代码，再次打包，生成new.apk。</p>    <p>两次的apk，可以通过命令行指令去生成patch文件。</p>    <p>如果你下载本例，命令需要在[该目录]下执行。</p>    <p>最终会在output文件夹中生成产物：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/48148dc5ca13e43aa9f0b436912d341c.jpg"></p>    <p>我们直接将patch_signed.apk push到sdcard，点击loadpatch，一定要观察命令行是否成功。</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/8934675cc96fc07b23dd64ba9d016f25.gif"></p>    <p>本例修改了title。</p>    <p>点击loadPatch，观察log，如果成功，应用默认为重启，然后再次启动即可达到修复效果。</p>    <p>到这里命令行的方式就介绍完了，和Andfix的接入的方式基本上是一样的。</p>    <p>值得注意的是:该例仅展示了基本的接入，对于tinker的各种配置信息，还是需要去读tinker的文档（如果你确定要使用）tinker-wiki（ https://github.com/Tencent/tinker/wiki ）。</p>    <p>> > > ></p>    <p>（2）gradle接入</p>    <p>gradle接入的方式应该算是主流的方式，所以tinker也直接给出了例子，单独将该tinker-sample-android（ https://github.com/Tencent/tinker/tree/master/tinker-sample-android ）以project方式引入即可。</p>    <p>引入之后，可以查看其接入API的方式，以及相关配置。</p>    <p>在你每次build时，会在build/bakApk下生成本地打包的apk，R文件，以及mapping文件。</p>    <p>如果你需要生成patch文件，可以通过：</p>    <pre>  ./gradlew tinkerPatchRelease  // 或者 ./gradlew tinkerPatchDebug</pre>    <p>生成。</p>    <p>生成目录为:build/outputs/tinkerPatch</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/903eee57fbae0d4889de12b95953a042.jpg"></p>    <p>需要注意的是，需要在app/build.gradle中设置相比较的apk（即old.apk，本次为new.apk），</p>    <pre>  ext {      tinkerEnabled = true      //old apk file to build patch apk      tinkerOldApkPath = "${bakPath}/old.apk"      //proguard mapping file to build patch apk      tinkerApplyMappingPath = "${bakPath}/old-mapping.txt"  }</pre>    <p>提供的例子，基本上展示了tinker的自定义扩展的方式，具体还可以参考：</p>    <ul>     <li> <p>Tinker-自定义扩展（ https://github.com/Tencent/tinker/wiki/Tinker-%E8%87%AA%E5%AE%9A%E4%B9%89%E6%89%A9%E5%B1%95 ）</p> </li>    </ul>    <p>所以，如果你使用命令行方式接入，也不要忘了学习下其支持哪些扩展。</p>    <h2>3 Application是如何编译时生成的</h2>    <p>从注释和命名上看：</p>    <pre>  //可选，用于生成application类  provided('com.tencent.tinker:tinker-android-anno:1.7.7')</pre>    <p>明显是该库，其结构如下：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/ea91c7f109101ba0c16dc14112ff863c.jpg"></p>    <p>典型的编译时注解的项目，源码见tinker-android-anno（ https://github.com/Tencent/tinker/tree/master/tinker-android/tinker-android-anno ）。</p>    <p>入口为 <strong>com.tencent.tinker.anno.AnnotationProcessor</strong> ，可以在该services/javax.annotation.processing.Processor文件中找到处理类全路径。</p>    <p>再次建议，如果你不了解，简单阅读下Android 如何编写基于编译时注解的项目（ http://blog.csdn.net/lmj623565791/article/details/51931859 ）该文。</p>    <p>直接看AnnotationProcessor的process方法：</p>    <pre>  @Override  public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {      processDefaultLifeCycle(roundEnv.getElementsAnnotatedWith(DefaultLifeCycle.class));      return true;  }</pre>    <p>直接调用了processDefaultLifeCycle：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/34f2a52043b5ed872593ed24560ed522.jpg"></p>    <p>代码比较简单，可以分三部分理解：</p>    <ul>     <li> <p>步骤1：首先找到被DefaultLifeCycle标识的Element(为类对象TypeElement)，得到该对象的包名，类名等信息，然后通过该对象，拿到@DefaultLifeCycle对象，获取该注解中声明属性的值。</p> </li>     <li> <p>步骤2：读取一个模板文件，读取为字符串，将各个占位符通过步骤1中的值替代。</p> </li>     <li> <p>步骤3：通过JavaFileObject将替换完成的字符串写文件，其实就是本例中的Application对象。</p> </li>    </ul>    <p>我们看一眼模板文件：</p>    <p><img src="https://simg.open-open.com/show/d39ae2b15378f6333a46e174402de78b.jpg"></p>    <p>对应我们的SimpleTinkerInApplicationLike，</p>    <p><img src="https://simg.open-open.com/show/40b3b1e77efda1b3d53059d394f0d8f7.jpg"></p>    <p>主要就几个占位符：</p>    <ul>     <li> <p>包名，如果application属性值以点开始，则同包；否则则截取</p> </li>     <li> <p>类名，application属性值中的类名</p> </li>     <li> <p>%TINKER_FLAGS%对应flags</p> </li>     <li> <p>%APPLICATION_LIFE_CYCLE%，编写的ApplicationLike的全路径</p> </li>     <li> <p>“%TINKER_LOADER_CLASS%”，这个值我们没有设置，实际上对应@DefaultLifeCycle的loaderClass属性，默认值为com.tencent.tinker.loader.TinkerLoader</p> </li>     <li> <p>%TINKER_LOAD_VERIFY_FLAG%对应loadVerifyFlag</p> </li>    </ul>    <p>于是最终生成的代码为：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/8165b60c0ceb4ed557ae523a2b45a7e6.jpg"></p>    <p>tinker这么做的目的，文档上是这么说的：</p>    <p>为了减少错误的出现，推荐使用Annotation生成Application类。</p>    <p>这样大致了解了Application是如何生成的。</p>    <p>接下来我们大致看一下tinker的原理。</p>    <h2>4 原理</h2>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/0361d4bb6edef46fa7c99ed5d814c096.jpg"></p>    <p>来源于： https://github.com/Tencent/tinker</p>    <p>tinker贴了一张大致的原理图。</p>    <p>tinker将old.apk和new.apk做了diff，拿到patch.dex，然后将patch.dex与本机中apk的classes.dex做了合并，生成新的classes.dex，运行时通过反射将合并后的dex文件放置在加载的dexElements数组的前面。</p>    <p>运行时替代的原理，其实和Qzone的方案差不多，都是去反射修改dexElements。</p>    <p>两者的差异是：Qzone是直接将patch.dex插到数组的前面；而tinker是将patch.dex与app中的classes.dex合并后的全量dex插在数组的前面。</p>    <p>tinker这么做的目的还是因为Qzone方案中提到的CLASS_ISPREVERIFIED的解决方案存在问题；而tinker相当于换个思路解决了该问题。</p>    <p>接下来我们就从代码中去验证该原理。</p>    <p>本片文章源码分析的两条线：</p>    <ul>     <li> <p>应用启动时，从默认目录加载合并后的classes.dex</p> </li>     <li> <p>patch下发后，合成classes.dex至目标目录</p> </li>    </ul>    <p>5</p>    <h2>源码分析</h2>    <p>> > > ></p>    <p>（1）加载patch</p>    <p>加载的代码实际上在生成的Application中调用的，其父类为TinkerApplication，在其attachBaseContext中辗转会调用到loadTinker()方法，在该方法内部，反射调用了TinkerLoader的tryLoad方法。</p>    <p><img src="https://simg.open-open.com/show/b019fe75c6064c995c62108c99ae8a6d.jpg"></p>    <p>tryLoadPatchFilesInternal中会调用到loadTinkerJars方法：</p>    <p><img src="https://simg.open-open.com/show/6d2c0aa2619ea4ab440e3cb2b381574e.jpg"></p>    <p>TinkerDexLoader.checkComplete主要是用于检查下发的meta文件中记录的dex信息（meta文件，可以查看生成patch的产物，在assets/dex-meta.txt），检查meta文件中记录的dex文件信息对应的dex文件是否存在，并把值存在TinkerDexLoader的静态变量dexList中。</p>    <p>TinkerDexLoader.loadTinkerJars传入四个参数，分别为application，tinkerLoadVerifyFlag（注解上声明的值，传入为false），patchVersionDirectory当前version的patch文件夹，intent，当前patch是否仅适用于art。</p>    <p><img src="https://simg.open-open.com/show/5e8396f0d385b239630b4a9c0ffe3a75.jpg"></p>    <p>找出仅支持art的dex，且当前patch是否仅适用于art时，并行去loadDex。</p>    <p>关键是最后的installDexes：</p>    <p><img src="https://simg.open-open.com/show/9b90fc829322c841c06e90ca9e81ed63.jpg"></p>    <p>这里实际上就是根据不同的系统版本，去反射处理dexElements。</p>    <p>我们看一下V19的实现（主要我看了下本机只有个22的源码~）：</p>    <p><img src="https://simg.open-open.com/show/38d80788863b4ea40f28efce9a631df3.jpg"></p>    <ol>     <li> <p>找到PathClassLoader（BaseDexClassLoader）对象中的pathList对象</p> </li>     <li> <p>根据pathList对象找到其中的makeDexElements方法，传入patch相关的对应的实参，返回Element[]对象</p> </li>     <li> <p>拿到pathList对象中原本的dexElements方法</p> </li>     <li> <p>步骤2与步骤3中的Element[]数组进行合并，将patch相关的dex放在数组的前面</p> </li>     <li> <p>最后将合并后的数组，设置给pathList</p> </li>    </ol>    <p>这里其实和Qzone的提出的方案基本是一致的。如果你以前未了解过Qzone的方案，可以参考此文：</p>    <ul>     <li> <p>Android 热补丁动态修复框架小结（ http://blog.csdn.net/lmj623565791/article/details/49883661 ）</p> </li>    </ul>    <p>> > > ></p>    <p>（2）合成patch</p>    <p>这里的入口为：</p>    <pre>  TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),                  Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk");</pre>    <p>上述代码会调用DefaultPatchListener中的onPatchReceived方法:</p>    <p><img src="https://simg.open-open.com/show/aec8f17e7054bd9fc32aa81543cc0937.jpg"></p>    <p>首先对tinker的相关配置（isEnable）以及patch的合法性进行检测，如果合法，则调用TinkerPatchService.runPatchService(context, path);</p>    <p><img src="https://simg.open-open.com/show/7fcad0c49af4089b4c0f183e842e7bd2.jpg"></p>    <p>TinkerPatchService是IntentService的子类，这里通过intent设置了两个参数，一个是patch的路径，一个是resultServiceClass，该值是调用Tinker.install的时候设置的，默认为DefaultTinkerResultService.class。由于是IntentService，直接看onHandleIntent即可，如果你对IntentService陌生，可以查看此文：Android IntentService完全解析 当Service遇到Handler （ http://blog.csdn.net/lmj623565791/article/details/47143563 ）。</p>    <p><img src="https://simg.open-open.com/show/2713e9a1aa3951a6c8ae6994e637d221.jpg"></p>    <p>比较清晰，主要关注upgradePatchProcessor.tryPatch方法，调用的是UpgradePatch.tryPatch。ps:这里有个有意思的地方increasingPriority()，其内部实现为：</p>    <p><img src="https://simg.open-open.com/show/abbea9f5a4f38fffde63e9f4eecd76af.jpg"></p>    <p>如果你对“保活”这个话题比较关注，那么对这段代码一定不陌生，主要是利用系统的一个漏洞来启动一个前台Service。如果有兴趣，可以参考此文：关于 Android 进程保活，你所需要知道的一切（ http://www.jianshu.com/p/63aafe3c12af ）。</p>    <p>下面继续回到tryPatch方法：</p>    <p><img src="https://simg.open-open.com/show/1c3f0d1a863aefb82aa813cdbd79e126.jpg"></p>    <p>拷贝patch文件拷贝至私有目录，然后调用DexDiffPatchInternal.tryRecoverDexFiles：</p>    <p><img src="https://simg.open-open.com/show/e2599db15dcdf620619816e9865a65b5.jpg"></p>    <p>直接看patchDexExtractViaDexDiff</p>    <p><img src="https://simg.open-open.com/show/2d1fd710b683a5994552d5c13c077955.jpg"></p>    <p>核心代码主要在extractDexDiffInternals中：</p>    <p><img src="https://simg.open-open.com/show/9abd9dd8bdd0fe80bc9d28fc4b1fc9f8.jpg"></p>    <p>这里的代码比较关键了，可以看出首先解析了meta里面的信息，meta中包含了patch中每个dex的相关数据。然后通过Application拿到sourceDir，其实就是本机apk的路径以及patch文件；根据mate中的信息开始遍历，其实就是取出对应的dex文件，最后通过patchDexFile对两个dex文件做合并。</p>    <p><img src="https://simg.open-open.com/show/abfd588babd868e629752786c671bc1f.jpg"></p>    <p>通过ZipFile拿到其内部文件的InputStream，其实就是读取本地apk对应的dex文件，以及patch中对应dex文件，对二者的通过executeAndSaveTo方法进行合并至patchedDexFile，即patch的目标私有目录。</p>    <p>至于合并算法，这里其实才是tinker比较核心的地方，这个算法跟dex文件格式紧密关联，如果有机会，然后我又能看懂的话，后面会单独写篇博客介绍。此外dodola已经有篇博客进行了介绍：</p>    <ul>     <li> <p>Tinker Dexdiff算法解析（ https://www.zybuluo.com/dodola/note/554061 ）</p> </li>    </ul>    <p>感兴趣的可以阅读下。</p>    <p>好了，到此我们就大致了解了tinker热修复的原理~~</p>    <p>当然这里只分析了代码了热修复，后续考虑分析资源以及So的热修、核心的diff算法、以及gradle插件等相关知识~</p>    <p>测试demo地址：</p>    <ul>     <li> <p>https://github.com/WanAndroid/tinkerTest</p> </li>    </ul>    <p>哇擦擦，好长的一篇，开工大吉，2017笑口常开~</p>    <p> </p>    <p> </p>    <p> </p>    <p>来自：http://mp.weixin.qq.com/s/WHYA4aTWIHcd8CQ95StwDg</p>    <p> </p>