調研背景：

     App釋出出去後，如果發現有緊急或重要bug如何進行修復呢？

     重新發布一版APK？但這樣代價太大....

      那麼有沒有一種方案能夠不用更新整個APK，而只把伺服器上的很小的補丁檔案下載下來進行修復bug呢？

      本文的調研也正是為了解決該問題。

幾種解決方案對比：

      下面是找到的3款比較火的開源解決方案，分別都是利用不同原理實現的:

 結合我的目標，目標鎖定在第2個與第3個。

【AndFix的操作使用】

選擇第二個AndFix來進行研究：

第一步：模擬釋出APK：

使用自帶的sample中的列子，修了下onCreate()中的程式碼，如下：

安裝執行bug.apk，如預期輸出如下Log:

第二步：現在App釋出出去後有Bug啦，我們要改變onCreate()的輸出，趕緊開始製作patch.....

修改輸出程式碼為如下:

編譯出fix後的APK，這時需要使用AndFix/tools/下面的apkpatch這個工具來製作patch(補丁)檔案。

工具所在目錄：

工具使用說明:

ApkPatch v1.0.3 - a tool for build/merge Android Patch file (.apatch).
Copyright 2015 supern lee <
 
[email protected]>

usage: apkpatch -f <new> -t <old> -o <output> -k <keystore> -p <***> -a <alias> -e <***>
 -a,--alias <alias>     alias.
 -e,--epassword <***>   entry password.
 -f,--from <loc>        new Apk file path.
 -k,--keystore <loc>    keystore path.
 -n,--name <name>       patch name.
 -o,--out <dir>         output dir.
 -p,--kpassword <***>   keystore password.
 -t,--to <loc>          old Apk file path.

usage: apkpatch -m <apatch_path...> -k <keystore> -p <***> -a <alias> -e <***>
 -a,--alias <alias>     alias.
 -e,--epassword <***>   entry password.
 -k,--keystore <loc>    keystore path.
 -m,--merge <loc...>    path of .apatch files.
 -n,--name <name>       patch name.
 -o,--out <dir>         output dir.
 -p,--kpassword <***>   keystore password.

執行如下命令：
apkpatch.sh -f fixed.apk -t bug.apk -o out -k sig -p 123123 -a test_sig -e 123123

命令的輸出：
add modified Method:V  onCreate(Landroid/os/Bundle;)  in Class:Lcom/euler/andfix/MainActivity;

第三步：到此補丁檔案製作好了，就可以通過網路等渠道推送到手機上。

檢視out目錄，一共有3個，會在後面進行解釋：

這裡的.patch檔案就是我們需要的，把它push到手機：

重起剛才的APP，觀看Log輸出時否改變了：

^_^，補丁成功了，而且這個檔案也才3KB多點哦,非常適合線上修復bug～～～～

-rw-rw-r-- 1 yanchen yanchen 3468 12月 15 18:32 out/fixed-07d99a18833f092518fbb041c793e53b.apatch

【AndFix的原始碼分析】

============================================================================================================================

Patch的製作流程現在知道了，下一步就準備進入Code層面的分析，探究它的內部實現原理。

============================================================================================================================

首先來看Patch製作原理：

製作patch會用到apkpatch這個工具，而它會呼叫apkpatch-1.0.3.jar這個檔案。反編譯這個jar包,發現在製作patch時，它會進入ApkPatch的doPatch()這個函式完成的。

進入doPatch函式看看：

這個函式邏輯挺清晰的，一共就這4個步驟。

第一步是diff，它會比對兩個APK的差別，來看看它的程式碼是如何實現的：

這個函式會提取fixed.apk與bug.apk中的classes.dex檔案，然後通過2個for迴圈，來對比每個class檔案中的欄位與函式是否完全一致。

那麼欄位和函式又是如何對比的呢？

我們來看看compareMethod()函式內部實現：

原來對比函式時會看兩個是否有函式實現，有的話就會看兩個函式的函式體是否一致，程式碼如下：

如果不一致就會新增到一個叫info的HashSet變數中。

而比對欄位主要看欄位的初始值是否一樣，程式碼如下：

總結：

通過上面的步驟就比對出了兩個APK中的classes.dex中差別，並且將有差別的檔案儲存在了info變數中。

接下來進入第二步，開始進行buildCode(),這步的目的是將info中儲存的檔案寫到.smali檔案中,然後再打包成一個dex檔案。

比如下面的是我的demo產生的smali檔案：

在生成的smali函式中，它會新增一個自定義的Anotation，叫MethodReplace：

到此，第二個步驟也就完成了,它一共產生2個檔案：

接下來進入第三個步驟，呼叫build()函式,這步會將上一步產生的dex檔案寫入到一個jar檔案，並進行簽名，程式碼如下：

PatchBuilder的程式碼如下：

所以第三步完成後，會產生一個叫作diff.apatch的jar檔案。

接下來進入最後一步，呼叫release()函式，也就是通過它產生最終的patch檔案。

看看release()中都做了些什麼事情：

主要是將第三步生成的diff.apatch檔案重新命名為name-md5-.patch格式的檔案。

到此，patch的製作原理也就告一段落了，主要就是提取兩個APK中的classes.dex，對比他們中的class檔案是否有區別，將有區別的提取出來打包到.apatch檔案中。

最終的產物如下：

============================================================================================================================

以上是Patch的製作流程分析，下一下我們再來看看客戶端是如何將這個patch檔案打入自己的APK中的。

============================================================================================================================

那我們就來看看這幾行程式碼到底會做什麼事情。

init()函式主要工作時載入files/apatch/目錄下的.apatch檔案，程式碼如下：

initPatchs()程式碼如下：

它讀取mPathDir目錄下的所有.patch檔案，並將起新增到一個叫mPatchs的HashSet變數中。

這是mPatchDir的初始值：

看來這個函式的目的就是在啟動的時候，讀取所有本地的patch檔案。

讀取完畢後呼叫loadPatch()來進行執行時的APK修復，程式碼如下：

fix()函式的程式碼如下：

它會載入.apatch檔案中class，然後再呼叫fixClass()，繼續往下看：

會讀取自定義的Anotation MethodReplace,通過它獲取到class名字與method名字，進行替換。

在前面的分析中也介紹過MethodReplace的內容格式，可參考如下：

而在進行Replace Method是，是在Native層做：

在JNI的程式碼中，支援Dalvik與ART，這時它的程式碼結構：

其修復原理就是從記憶體中找出原來函式指令指標，讓它指向新的函式地址：

上面的meth變數便是我們bug.apk中的函式的控制代碼，target便是.aptach檔案中函式的控制代碼。

而insns是函式指令地址的指標，解釋如下：

到此函式替換的原理就水落石出了,就是函式Hook。

很犀利的做法。

【總結】

所以總結一下補丁執行的原理就是：

在執行時，讀取patch檔案中的函式，將它的函式指令地址賦給APK中的函式。

這樣不就等於替換了原來的函式麼？那麼bug也就可以被消除了。。。

當然這一切都是在記憶體中進行的，不會對本地的APK有任何影響。