Android 熱修復 Tinker接入及源碼淺析

lmaleon 7年前發布 | 13K 次閱讀安卓熱修復 Android開發移動開發

1 概述

熱修復這項技術，基本上已經成為項目比較重要的模塊了。主要因為項目在上線之后，都難免會有各種問題，而依靠發版去修復問題，成本太高了。

現在熱修復的技術基本上有阿里的AndFix、QZone的方案、美團提出的思想方案以及騰訊的Tinker等。

其中AndFix可能接入是最簡單的一個（和Tinker命令行接入方式差不多），不過兼容性還是是有一定的問題的；QZone方案對性能會有一定的影響，且在Art模式下出現內存錯亂的問題(其實這個問題我之前并不清楚，主要是tinker在MDCC上指出的);美團提出的思想方案主要是基于Instant Run的原理，目前尚未開源，不過這個方案我還是蠻喜歡的，主要是兼容性好。

這么看來，如果選擇開源方案，tinker目前是最佳的選擇，tinker的介紹有這么一句：

Tinker已運行在微信的數億Android設備上，那么為什么你不使用Tinker呢？

好了，說了這么多，下面來看看tinker如何接入，以及tinker的大致的原理分析。希望通過本文可以實現幫助大家更好的接入tinker，以及去了解tinker的一個大致的原理。

2 接入Tinker

接入tinker目前給了兩種方式，一種是基于命令行的方式，類似于AndFix的接入方式；一種就是gradle的方式。

考慮早期使用Andfix的app應該挺多的，以及很多人對gradle的相關配置還是覺得比較繁瑣的，下面對兩種方式都介紹下。

> > > >

（1）命令行接入

接入之前我們先考慮下，接入的話，正常需要的前提（開啟混淆的狀態）。

對于API一般來說，我們接入熱修庫，會在Application#onCreate中進行一下初始化操作。然后在某個地方去調用類似loadPatch這樣的API去加載patch文件。
對于patch的生成簡單的方式就是通過兩個apk做對比然后生成；需要注意的是：兩個apk做對比，需要的前提條件，第二次打包混淆所使用的mapping文件應該和線上apk是一致的。

最后就是看看這個項目有沒有需要配置混淆；

有了大致的概念，我們就基本了解命令行接入tinker，大致需要哪些步驟了。

依賴引入

dependencies {
    // ...
    //可選，用于生成application類
    provided('com.tencent.tinker:tinker-android-anno:1.7.7')
    //tinker的核心庫
    compile('com.tencent.tinker:tinker-android-lib:1.7.7')
}

順便加一下簽名的配置：

文末會有demo的下載地址，可以直接參考build.gradle文件，不用擔心這些簽名文件去哪找。

API引入

API主要就是初始化和loadPacth。

正常情況下，我們會考慮在Application的onCreate中去初始化，不過tinker推薦下面的寫法：

ApplicationLike通過名字你可能會猜，并非是Application的子類，而是一個類似Application的類。

tinker建議編寫一個ApplicationLike的子類，你可以當成Application去使用，注意頂部的注解：@DefaultLifeCycle，其application屬性，會在編譯期生成一個SimpleTinkerInApplication類。

所以，雖然我們這么寫了，但是實際上Application會在編譯期生成，所以AndroidManifest.xml中是這樣的：

<application
        android:name=".SimpleTinkerInApplication"
        .../>

編寫如果報紅，可以build下。

這樣其實也能猜出來，這個注解背后有個Annotation Processor在做處理，如果你沒了解過，可以看下：

Android 如何編寫基于編譯時注解的項目（ http://blog.csdn.net/lmj623565791/article/details/51931859 ）

通過該文會對一個編譯時注解的運行流程和基本API有一定的掌握，文中也會對tinker該部分的源碼做解析。

上述，就完成了tinker的初始化，那么調用loadPatch的時機，我們直接在Activity中添加一個Button設置：

我們會將patch文件直接push到sdcard根目錄；

所以一定要注意：添加SDCard權限，如果你是6.x以上的系統，自己添加上授權代碼，或者手動在設置頁面打開SDCard讀寫權限。

<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />

除以以外，有個特殊的地方就是tinker需要在AndroidManifest.xml中指定TINKER_ID。

<application>
  <meta-data
            android:name="TINKER_ID"
            android:value="tinker_id_6235657" />
    //...
</application>

到此API相關的就結束了，剩下的就是考慮patch如何生成。

patch生成

tinker提供了patch生成的工具，源碼見： tinker-patch-cli ，打成一個jar就可以使用，并且提供了命令行相關的參數以及文件。

命令行如下：

java -jar tinker-patch-cli-1.7.7.jar 
    -old old.apk 
    -new new.apk 
    -config tinker_config.xml 
    -out output

需要注意的就是tinker_config.xml，里面包含tinker的配置，例如簽名文件等。

這里我們直接使用tinker提供的簽名文件，所以不需要做修改，不過里面有個Application的item修改為與本例一致：

<loader value="com.zhy.tinkersimplein.SimpleTinkerInApplication"/>

大致的文件結構如下：

可以在tinker-patch-cli（ https://github.com/Tencent/tinker/tree/master/tinker-build/tinker-patch-cli ）中提取，或者直接下載文末的例子。

上述介紹了patch生成的命令，最后需要注意的就是，在第一次打出apk的時候，保留下生成的mapping文件，在/build/outputs/mapping/release/mapping.txt。

可以copy到與proguard-rules.pro同目錄，同時在第二次打修復包的時候，在proguard-rules.pro中添加上：

-applymapping mapping.txt

保證后續的打包與線上包使用的是同一個mapping文件。

tinker本身的混淆相關配置，可以參考：

tinker_proguard.pro（ https://github.com/Tencent/tinker/blob/master/tinker-build/tinker-patch-cli/tool_output/tinker_proguard.pro ）

如果，你對該部分描述不了解，可以直接查看源碼即可。

測試

首先隨便生成一個apk（API、混淆相關已經按照上述引入），安裝到手機或者模擬器上。

然后，copy出mapping.txt文件，設置applymapping，修改代碼，再次打包，生成new.apk。

兩次的apk，可以通過命令行指令去生成patch文件。

如果你下載本例，命令需要在[該目錄]下執行。

最終會在output文件夾中生成產物：

我們直接將patch_signed.apk push到sdcard，點擊loadpatch，一定要觀察命令行是否成功。

本例修改了title。

點擊loadPatch，觀察log，如果成功，應用默認為重啟，然后再次啟動即可達到修復效果。

到這里命令行的方式就介紹完了，和Andfix的接入的方式基本上是一樣的。

值得注意的是:該例僅展示了基本的接入，對于tinker的各種配置信息，還是需要去讀tinker的文檔（如果你確定要使用）tinker-wiki（ https://github.com/Tencent/tinker/wiki ）。

> > > >

（2）gradle接入

gradle接入的方式應該算是主流的方式，所以tinker也直接給出了例子，單獨將該tinker-sample-android（ https://github.com/Tencent/tinker/tree/master/tinker-sample-android ）以project方式引入即可。

引入之后，可以查看其接入API的方式，以及相關配置。

在你每次build時，會在build/bakApk下生成本地打包的apk，R文件，以及mapping文件。

如果你需要生成patch文件，可以通過：

./gradlew tinkerPatchRelease  // 或者 ./gradlew tinkerPatchDebug

生成。

生成目錄為:build/outputs/tinkerPatch

需要注意的是，需要在app/build.gradle中設置相比較的apk（即old.apk，本次為new.apk），

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"
}

提供的例子，基本上展示了tinker的自定義擴展的方式，具體還可以參考：

Tinker-自定義擴展（ https://github.com/Tencent/tinker/wiki/Tinker-%E8%87%AA%E5%AE%9A%E4%B9%89%E6%89%A9%E5%B1%95 ）

所以，如果你使用命令行方式接入，也不要忘了學習下其支持哪些擴展。

3 Application是如何編譯時生成的

從注釋和命名上看：

//可選，用于生成application類
provided('com.tencent.tinker:tinker-android-anno:1.7.7')

明顯是該庫，其結構如下：

典型的編譯時注解的項目，源碼見tinker-android-anno（ https://github.com/Tencent/tinker/tree/master/tinker-android/tinker-android-anno ）。

入口為 com.tencent.tinker.anno.AnnotationProcessor ，可以在該services/javax.annotation.processing.Processor文件中找到處理類全路徑。

再次建議，如果你不了解，簡單閱讀下Android 如何編寫基于編譯時注解的項目（ http://blog.csdn.net/lmj623565791/article/details/51931859 ）該文。

直接看AnnotationProcessor的process方法：

@Override
public boolean process(Set<? extends TypeElement> annotations, RoundEnvironment roundEnv) {
    processDefaultLifeCycle(roundEnv.getElementsAnnotatedWith(DefaultLifeCycle.class));
    return true;
}

直接調用了processDefaultLifeCycle：

代碼比較簡單，可以分三部分理解：

步驟1：首先找到被DefaultLifeCycle標識的Element(為類對象TypeElement)，得到該對象的包名，類名等信息，然后通過該對象，拿到@DefaultLifeCycle對象，獲取該注解中聲明屬性的值。
步驟2：讀取一個模板文件，讀取為字符串，將各個占位符通過步驟1中的值替代。
步驟3：通過JavaFileObject將替換完成的字符串寫文件，其實就是本例中的Application對象。

我們看一眼模板文件：

對應我們的SimpleTinkerInApplicationLike，

主要就幾個占位符：

包名，如果application屬性值以點開始，則同包；否則則截取
類名，application屬性值中的類名
%TINKER_FLAGS%對應flags
%APPLICATION_LIFE_CYCLE%，編寫的ApplicationLike的全路徑
“%TINKER_LOADER_CLASS%”，這個值我們沒有設置，實際上對應@DefaultLifeCycle的loaderClass屬性，默認值為com.tencent.tinker.loader.TinkerLoader
%TINKER_LOAD_VERIFY_FLAG%對應loadVerifyFlag

于是最終生成的代碼為：

tinker這么做的目的，文檔上是這么說的：

為了減少錯誤的出現，推薦使用Annotation生成Application類。

這樣大致了解了Application是如何生成的。

接下來我們大致看一下tinker的原理。

4 原理

來源于： https://github.com/Tencent/tinker

tinker貼了一張大致的原理圖。

tinker將old.apk和new.apk做了diff，拿到patch.dex，然后將patch.dex與本機中apk的classes.dex做了合并，生成新的classes.dex，運行時通過反射將合并后的dex文件放置在加載的dexElements數組的前面。

運行時替代的原理，其實和Qzone的方案差不多，都是去反射修改dexElements。

兩者的差異是：Qzone是直接將patch.dex插到數組的前面；而tinker是將patch.dex與app中的classes.dex合并后的全量dex插在數組的前面。

tinker這么做的目的還是因為Qzone方案中提到的CLASS_ISPREVERIFIED的解決方案存在問題；而tinker相當于換個思路解決了該問題。

接下來我們就從代碼中去驗證該原理。

本片文章源碼分析的兩條線：

應用啟動時，從默認目錄加載合并后的classes.dex
patch下發后，合成classes.dex至目標目錄

源碼分析

> > > >

（1）加載patch

加載的代碼實際上在生成的Application中調用的，其父類為TinkerApplication，在其attachBaseContext中輾轉會調用到loadTinker()方法，在該方法內部，反射調用了TinkerLoader的tryLoad方法。

tryLoadPatchFilesInternal中會調用到loadTinkerJars方法：

TinkerDexLoader.checkComplete主要是用于檢查下發的meta文件中記錄的dex信息（meta文件，可以查看生成patch的產物，在assets/dex-meta.txt），檢查meta文件中記錄的dex文件信息對應的dex文件是否存在，并把值存在TinkerDexLoader的靜態變量dexList中。

TinkerDexLoader.loadTinkerJars傳入四個參數，分別為application，tinkerLoadVerifyFlag（注解上聲明的值，傳入為false），patchVersionDirectory當前version的patch文件夾，intent，當前patch是否僅適用于art。

找出僅支持art的dex，且當前patch是否僅適用于art時，并行去loadDex。

關鍵是最后的installDexes：

這里實際上就是根據不同的系統版本，去反射處理dexElements。

我們看一下V19的實現（主要我看了下本機只有個22的源碼~）：

找到PathClassLoader（BaseDexClassLoader）對象中的pathList對象
根據pathList對象找到其中的makeDexElements方法，傳入patch相關的對應的實參，返回Element[]對象
拿到pathList對象中原本的dexElements方法
步驟2與步驟3中的Element[]數組進行合并，將patch相關的dex放在數組的前面
最后將合并后的數組，設置給pathList

這里其實和Qzone的提出的方案基本是一致的。如果你以前未了解過Qzone的方案，可以參考此文：

Android 熱補丁動態修復框架小結（ http://blog.csdn.net/lmj623565791/article/details/49883661 ）

> > > >

（2）合成patch

這里的入口為：

TinkerInstaller.onReceiveUpgradePatch(getApplicationContext(),
                Environment.getExternalStorageDirectory().getAbsolutePath() + "/patch_signed.apk");

上述代碼會調用DefaultPatchListener中的onPatchReceived方法:

首先對tinker的相關配置（isEnable）以及patch的合法性進行檢測，如果合法，則調用TinkerPatchService.runPatchService(context, path);

TinkerPatchService是IntentService的子類，這里通過intent設置了兩個參數，一個是patch的路徑，一個是resultServiceClass，該值是調用Tinker.install的時候設置的，默認為DefaultTinkerResultService.class。由于是IntentService，直接看onHandleIntent即可，如果你對IntentService陌生，可以查看此文：Android IntentService完全解析當Service遇到Handler （ http://blog.csdn.net/lmj623565791/article/details/47143563 ）。

比較清晰，主要關注upgradePatchProcessor.tryPatch方法，調用的是UpgradePatch.tryPatch。ps:這里有個有意思的地方increasingPriority()，其內部實現為：

如果你對“保活”這個話題比較關注，那么對這段代碼一定不陌生，主要是利用系統的一個漏洞來啟動一個前臺Service。如果有興趣，可以參考此文：關于 Android 進程保活，你所需要知道的一切（ http://www.jianshu.com/p/63aafe3c12af ）。

下面繼續回到tryPatch方法：

拷貝patch文件拷貝至私有目錄，然后調用DexDiffPatchInternal.tryRecoverDexFiles：

直接看patchDexExtractViaDexDiff

核心代碼主要在extractDexDiffInternals中：

這里的代碼比較關鍵了，可以看出首先解析了meta里面的信息，meta中包含了patch中每個dex的相關數據。然后通過Application拿到sourceDir，其實就是本機apk的路徑以及patch文件；根據mate中的信息開始遍歷，其實就是取出對應的dex文件，最后通過patchDexFile對兩個dex文件做合并。

通過ZipFile拿到其內部文件的InputStream，其實就是讀取本地apk對應的dex文件，以及patch中對應dex文件，對二者的通過executeAndSaveTo方法進行合并至patchedDexFile，即patch的目標私有目錄。

至于合并算法，這里其實才是tinker比較核心的地方，這個算法跟dex文件格式緊密關聯，如果有機會，然后我又能看懂的話，后面會單獨寫篇博客介紹。此外dodola已經有篇博客進行了介紹：

Tinker Dexdiff算法解析（ https://www.zybuluo.com/dodola/note/554061 ）

感興趣的可以閱讀下。

好了，到此我們就大致了解了tinker熱修復的原理~~

當然這里只分析了代碼了熱修復，后續考慮分析資源以及So的熱修、核心的diff算法、以及gradle插件等相關知識~

測試demo地址：

https://github.com/WanAndroid/tinkerTest

哇擦擦，好長的一篇，開工大吉，2017笑口常開~

來自：http://mp.weixin.qq.com/s/WHYA4aTWIHcd8CQ95StwDg

本文由用戶 lmaleon 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。

轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。

本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！

本文地址：http://www.baiduhome.net/lib/view/open1486353723259.html

安卓熱修復 Android開發移動開發

Android 熱修復 Tinker接入及源碼淺析

1 概述

2 接入Tinker

3 Application是如何編譯時生成的

4 原理

源碼分析

相關經驗

相關資訊

相關文檔

目錄