【0154】【熱修復與插件化-2】 熱修復AndFix詳解

1.熱修復的基本認識

【內容提要】

1.1 熱修復的基本概念-動態更新

熱修復說白了就是」打補丁」，好比大家公司上線一個app，用戶反應有重大bug,須要緊急修復。若是按照通 
常作法,那就是程序猿加班搞定bug,而後測試,從新打包併發布。這樣帶來的問題就是成本高,效率低。因而,熱 
修復就應運而生.通常經過事先設定的接口從網上下載無Bug的代碼來替換有Bug的代碼。這樣就省事多了,用 
戶體驗也好。

 

1.2.熱修復的好處

【1】開發團隊能夠避免繁瑣的開發流程，使得bug的修改變得容易；

【2】避免用戶的流失；

【3】能夠輕易的實現小功能的更新；

1.3.熱修復的見解

 【說明】高質量的版本加上熱修復的技術，纔是最好的；

【1】亡羊補牢的手段，不要求輕易的使用；

【2】各家的熱修復框架都具備兼容性的問題；

【3】熱修復的流程與開發的流程是同樣的，也須要所有走一遍；

 1.4.常見的熱修復的對比

【技術選型的標準】

【本課程的選擇】AndFix使用最簡單，維護也來最簡單；Tinker開發是最複雜的，維護也是最複雜的；

2.AndFix的詳解

【內容提要】

2.1 AndFix的基本介紹

【說明】第一手資料要去gitHub官方去看；

 

【說明】使用的是註解；使用的是native方法打補丁；兼容性不是很好；每套虛擬機都須要去適配；

3.使用AndFix完成bug的修復

3.1 應用中集成AndFix

3.2【添加路徑的區別】

【classPath】若是是第三放的代碼中還使用到了自定義的gradle腳本文件，咱們須要以插件的方式進行使用；須要在project 下的gradle中添加依賴；而後在model中就可使用第三方的庫中的代碼了；

【dependingdencies】只是使用第三方的java代碼，只是添加此處的app下的gradle代碼便可；

3.3 AndFix的初始化

【說明】在使用AndFix第三方庫，須要咱們先封裝；

 【新建管理類】使用雙加鎖的單例模式；

【封裝PatchManager】

【增長load的調用】

【分裝以後的使用】

3.4  使用AndFix的準備

【模擬bug】log.e的第2個參數設置爲null，會報錯空指針異常；

【生成apk】

 

【說明】防止在第二次打包的時候將apk覆蓋掉，所以將打包好的apk臨時保存；

4. apatch文件的生成

 

【說明】能夠從官網下載；

【執行命令生成aptch文件】

【生成文件的輸出目錄】

【技巧】能夠將執行的命令保存成爲一個腳本文件，前面記得加sh；

5.補丁文件的安裝

 

6. AndFix組件化

6.1 待解決的問題

【說明】【模擬中存在的問題】

【1】實際的應用中須要經過網絡下載aptch文件，

【2】實際中不可能讓用戶點擊修復按鈕；

【3】能夠將此AndFix組件化；

6.2 實際開發中AndFix開發的步驟

 

6.3 組件化實現

【說明】修復的工做建立的是一個serverice服務；

 

【文件目錄的構造】

【檢查更新請求的發送】

 

【文件的下載】AndFix添加到文件路徑中就能夠直接修復了，不須要重啓設備等；

 

6.4 AndFix組件的調用

【說明】在實際的splash界面啓動的時候就開始啓動服務；

7.AndFix的源碼的講解

7.1 初始化

 

7.2 init方法

【功能】對patch文件的添加和刪除，若是應用的版本升級了，就刪除patch，若是沒有升級，就將全部的patch添加到mPatch列表中；

【說明】添加patch文件到list中，實際上全部的patch文件都存在到了mPatch中；

【Patch文件的轉換】將磁盤上的file轉換爲patch文件

 7.3 AddPatch方法

 

7.4 loadPatch方法

【說明】具備兩個重載的方法，區別是否指定了須要修復的patch文件；

7.5 fix方法

 【說明】AndFixManager其實只是對文件的管理，沒有真正的修復操做；

7.6 fixClass執行的方法

【功能】找到class字節碼中要替換的方法；

 

7.7 replaceMethod方法

7.8 【總結】

【說明】最終是調用c/c++中的代碼進行修復的；

首先將文件都轉換爲patch類；而後將patch經過名字轉換爲字節碼，而後經過反射找到要替換的方法；最終經過JNI完成方法的替換；

【優劣】

【1】只能修復方法級別的bug，使用的場景受到了限制；若是新增類或者是資源，AndFix是作不到的，須要使用Tinker；

【2】原理簡單、集成簡單、使用簡單、即便生效，不須要啓動app；

8.參考博客

【1】Android中熱修復框架AndFix原理解析及案例使用

【原文地址】https://blog.csdn.net/u011277123/article/details/53282381

1、前言

最近騰訊弄出一個Tinker熱修復框架，那麼本文先不介紹這個框架，先來介紹一下阿里的一個熱修復框架AndFix，這個框架出來已經很長時間了，可是看網上沒有太多很是詳細的講解，這裏就來作一次分析。正好項目中要使用到。首先這個框架是開源的：https://github.com/alibaba/AndFix 其實在最先的時候我已經分析了阿里的另一個熱修復框架：Dexposed框架，還不瞭解的同窗能夠點擊這裏查看：Dexposed框架原理解析以及使用 當時介紹這個框架的時候發現他的實現原理很簡單：

他的思想徹底來源於Xposed框架，完美詮釋了AOP編程，這裏用到最核心的知識點就是在native層獲取到指定方法的結構體，而後改變他的nativeFunc字段值，而這個值就是能夠指定這個方法對應的native函數指針，因此先從Java層跳到native層，改變指定方法的nativeFunc值，而後在改變以後的函數中調用Java層的回調便可。實現了方法的攔截功能。

2、源碼分析

那麼本文介紹的AndFix框架相對於Dexposed框架來講又有什麼區別呢？其實區別就在於AndFix框架更加輕便好用，在進行熱修復的過程當中更加方便了。固然這個優勢在後面的Tinker框架也是能提現出來的。這個框架的原理是：直接在native層進行方法的結構體信息對換，從而實現完美的方法新舊替換，從而實現熱修復功能。下面經過分析他的源碼來看他的具體實現，下載完源碼以後導入工程：

這裏能夠看到，由於在native層須要替換新舊方法結構體信息，因此這裏確定要作的工做就是虛擬機的兼容問題，這裏作了art和dalvik的分開處理邏輯，下面來看一下這個框架的基本使用規則：

用法仍是很簡單的，這裏的修復包是直接放在本地的，在實際操做中會從網上去下載。下面就開始分析源碼，這裏有一個主要的類就是PatchManager：

第1、PatchManager類初始化

在這個類的構造方法中作了兩件事，一件事是初始化AndFixManager類，一件事是建立修復包存放的沙盒目錄。這裏先來看第二件事建立沙盒目錄：

能夠看到這個目錄是：/data/data/xxx/files/apatch/xxx.apatch

當咱們從網上下載好修復包apatch文件以後，會調用addPatch方法，這時候會把修復包複製到這個地方，之後再次啓動時就會遍歷這個目錄加載apatch文件。

第2、AndFixManager的初始化

下面繼續來看AndFixManager初始化操做：

在這個初始化中也是幹了兩件事：一件事是判斷當前環境是否支持熱修復，一件事是初始化修復包安全校驗的工做，先來看一下判斷是否支持操做：

這裏支持的條件是：非YunOS系統，Android2.3-7.0系統版本，熱修復native層設置是否成功。這裏咱們看到應該值得關心的是setup操做，這個操做實際上是native層進行的，能夠直接看一下具體代碼：

這裏主要作了一些初始化操做，獲取一些函數指針，準備後續的replaceMethod函數中使用：

一、在libdvm.so動態獲取dvmDecodeIndirectRef函數指針和獲取dvmThreadSelf函數指針。

二、調用dest的 Method.getDeclaringClass方法獲取method的類對象clazz。

繼續回到AndFixManager的初始化中的第二件事：修復包安全校驗工做，其實這裏只是作了初始化操做，而真正校驗的工做在後面，主要是經過比對應用的簽名和修復包的簽名信息。後面再看吧！

第三：PatchManager的初始化操做

這裏的初始化作了一件事：是判斷當前PatchManager的版本號是否發生變化，若是發生變化就清空本地全部的修復包。若是沒有變化，直接調用初始化修復包方法

這個方法其實就是咱們上面提到的邏輯，會遍歷沙盒中修復包目錄中全部的修復包文件，而後把它添加到修復列表中。

第四：PatchManager的添加修復包操做

這裏提供了兩個添加修復包的方法，一個是接受文件樣式的參數：

這個方法就是上面的那個initPatchs方法中調用的地方，這裏會把目錄下全部的修復包文件加到列表中。這裏來看一下另一個主要類Patch的初始化操做：

這個初始化的主要工做就是經過JarFile類解析修復包文件，讀取他的META-INF\PATCH.MF文件內容，獲取須要修復類的名稱，多個修復類之間用逗號分隔，相似於這樣的樣式：

這裏的Utils類就是咱們須要修復的方法所屬的類名，可是這裏他又作了處理就是在每一個類的後面加了後綴：_CF。這裏分析完了全部須要修復的類名以後保存到一個列表中，後面會經過修復包名稱獲取到他的修復類名稱列表。

還有一個添加修復包文件的方法，接受的是文件路徑參數：

這個方法接受的是修復包文件路徑，首先會把這個文件拷貝到上面提到的沙盒目錄中以便下次進行遍歷操做，拷貝以後繼續調用上面的addPatch方法添加到列表中，最後就在調用加載修復包操做了。

注意：

第一個方法接受文件樣式的方法實際上是須要結合上面的initPatchs方法一塊兒使用，他調用的場景是：本地沙盒目錄中已經有了修復包文件，而且版本號沒有發生變化，這樣每次啓動程序的時候就會調用初始化操做，在這裏會遍歷沙盒目錄中全部的修復包文件，而後調用這個方法添加到全局文件列表中。

第二個方法接受的是文件路徑樣式，這個方法使用的場景是版本號發生變化，或者是本地沙盒中沒有修復包文件。好比第一次操做的時候，會從網絡上下載修復包文件，下載成功以後會把這個文件路徑經過這個方法調用便可，執行完以後也會主動調用加載修復包的操做了，好比這裏第一次在SD卡中放了一個修復包文件：

只要調用了這段代碼以後就能夠走完了全部的流程了：拷貝修復包到沙盒目錄中，加載修復包文件。

第五：PatchManager的加載修復包操做

這個方法有兩個地方會調用到：一個是上面提到的那個接受修復包路徑的addPatch方法，一個是調用完接受修復文件類型的addPatch方法以後手動調用一次，相似於這樣：

這個方法內部主要是經過Patch類獲取修復包全部的修復類名稱，以前已經介紹了Patch類的初始化操做，在哪裏會解析修復包的MF文件信息，獲取到修復包須要修復的類名而後保存到列表中，這裏就經過getClasses方法來獲取指定修復包名稱對應的修復類名稱列表，而後在調用AndFixManager的fix方法便可，下面再來看一下AndFixManager的fix方法的實現邏輯：

這個方法有點長，並且內容也比較多，這裏主要作了這麼幾件事：

第一件事：使用上面初始化完成的校驗類進行修復包的校驗工做，這裏的校驗就是比對修復包的簽名和應用的簽名是否一致：

這個具體實現邏輯不用介紹了，你們能夠下載源碼本身分析。

第二件事：使用DexFile和自定義類加載器來加載修復包文件

這個其實和使用DexClassLoader加載原理相似，並且DexClassLoader內部的加載邏輯也是使用了DexFile來進行操做的，而這裏爲何要進行加載操做呢？由於咱們須要獲取修復類中須要修復的方法名稱，而這個方法名稱是經過修復方法的註解來獲取到的，因此咋們得先進行類的加載而後獲取到他的方法信息，最後經過分析註解獲取方法名，這裏用的是反射機制來進行操做的。

這個加載完類以後就會繼續調用fixClass方法，再來看一下fixClass方法實現：

這裏主要是經過反射獲取指定類名須要修復類中的全部方法類型，而後在獲取到他的註解信息，上面已經分析了經過DexFile加載修復包文件，而後在加載上面Patch類中的getClasses方法獲取到的修復類名稱列表來進行類的加載，而後在用反射機制獲取類中全部的方法對應的註解信息，經過註解信息獲取指定修復的方法名稱，看一下這個註解的定義：

這裏提供了兩個方法，一個是獲取當前類名稱，一個是獲取當前方法名稱，能夠看一下具體事例：

上面解析完註解信息以後獲取到了方法名稱，緊接着就調用了replaceMethod方法開始了方法的替換操做

這裏還會作一件事就是經過上面獲得的修復新的方法信息以及須要修復的舊方法名稱來操做，不過這裏得先獲取到舊方法類型，能夠看到修復的新舊方法的簽名必須一致，所謂簽名就是方法的名稱，參數個數，參數類型都必須一致，否則這裏就報錯的。進而也修復不了了。最後在調用了AndFix的addReplaceMethod方法進行native層的修復工做：

這裏會作虛擬機的區分處理，可是他們大體的處理邏輯都是一致的，這裏來看一下dalvik的處理機制：

這裏的操做也是很是簡單的，主要是經過上層傳遞過來的新舊方法類型對象，經過JNIEnv的FromReflectedMethod方法獲取對應的方法結構體信息，而後將其信息進行替換便可，這裏能夠看到替換的信息也是很是多的，並且也看到了咱們以前介紹Dexposed框架用到的一個字段值nativeFunc，這個就是指定這個Java方法對應的native方法。可是在這以前也會看到有一段代碼是用來獲取修復方法的類信息的，這裏主要是用來作修復方法的類初始化操做，在以前咱們看setup方法的時候知道，那裏作了這麼兩件事：

一、在libdvm.so動態獲取dvmDecodeIndirectRef函數指針和獲取dvmThreadSelf函數指針。

二、調用dest的 Method.getDeclaringClass方法獲取method的類對象clazz。

而後在這裏就開始獲取修復方法對應的類信息，經過調用方法的getDeclaringClass獲取方法對應的類對象clazz，而後在調用dvm方法獲取到對應的類結構體信息ClassObject，最後在設置他的狀態信息標記這個類已經初始化完畢了。

注意：

這裏能夠看到經過一個類對象clazz類型能夠獲取到對應的結構體信息ClassObject，這個操做也是很是實用的，由於這個結構信息中有一個字段pDvmDex值，而這個值就是DvmDex結構體信息也就是底層對應的dex文件信息，因此說咱們能夠經過一個類信息獲得他對應的dex文件信息。

3、流程總結

到這裏就講解完了整個框架的全部技術點了，上面可能說的有點亂，下面在來大致總結一下，首先來看一張簡單的流程圖信息(圖片有點大，能夠下載看高清大圖)：

第1、Patch類負責解析每一個修復包apatch文件信息，獲取全部須要修復的類名

這個類的初始化操做中會經過傳遞進來的修復包文件，使用JarFile類進行文件解析，讀取他的META-INF\PATCH.MF文件信息，主要經過讀取Patch-Classes字段值來獲取須要修復的類名稱，多個類名稱之間用逗號分隔，並且每一個類名稱都有一個後綴：_CF。解析完成以後就會保存到一個用修復包名稱做爲key的HashMap中，後面會經過修復包名稱參數來調用getClasses方法獲取對應修復的類名稱列表。

第2、PatchManager負責管理多個Patch類也就是多個修復包信息

主要方法包括初始化，添加修復包，加載修復包，這個類是提供給外界調用的一個入口類，這裏有兩種方式調用：

一種方式是先調用init方法進行初始化，在這個初始化方法中會判斷當前的版本號，若是版本號發生變化就會清空本地全部的修復包文件，若是沒有變化就加在全部的本地修復包文件，而這個本地目錄就是沙盒中存放修復包文件的目錄：/data/data/xxx/apatch/xxx.apatch，而後在調用loadPatch方法進行修復包的加載工做。

一種方式是本地沒有修復包文件，也就是第一次操做的時候可能須要從服務器下載修復包文件，這時候會把下載下來的修復包文件路徑經過調用addPatch方法進行添加操做，而這裏的添加操做包括了：先把修復文件拷貝到上面的沙盒修復包目錄中，而後在調用loadPatch方法進行加載工做。

第3、AndFix類主要是和native層交互直接替換方法

這個類主要就是幾個native方法用來和底層進行交互的操做，而這些方法都是會被AndFixManager進行調用的。

第4、AndFixManager類主要是負責管理AndFix類

主要方法包括加載每一個修復包中須要修復的類，解析出每一個類的註解信息獲取該類須要修復的方法名稱，初始化的時候會進行修復包的校驗工做，主要經過對比修復包和應用的簽名信息。因此能夠知道每一個修復包是須要進行簽名操做的，而後他的fix方法會使用DexFile類進行加載修復包文件，調用Patch的getClasses方法獲取到全部須要修復的類名稱進行加載操做。而後在調用fixClass方法，在這個方法中主要經過遍歷修復類中全部指定MethodReplace註解信息的方法信息，而後在調用replaceMethod方法進行替換操做，而在這個方法中也會經過新方法的Method類型和註解信息中須要修復方法的名稱來獲得舊方法的Method類型，最終調用AndFix的native方法replaceMethod進行替換操做，因此這裏能夠看到替換的新舊方法的簽名信息必須一致，否則無效，也就是方法的名稱，參數個數，參數類型必須保持一致才能夠。

第5、Native層方法

在native層中會作art和dalvik虛擬機的區分處理工做，他們大體的邏輯都是一致的：

dalvik 模式下的Java hook

一、在libdvm.so動態獲取dvmDecodeIndirectRef函數指針和獲取dvmThreadSelf函數指針。

二、調用dest的 Method.getDeclaringClass方法獲取method的類對象clazz。

三、調用dvmDecodeIndirectRef方法，獲取clazz的ClassObject*

四、通關 env->FromReflectedMethod方法獲取dest的Method結構體函數的指針

五、替換method結構體的成員數據

art模式下的java hook

一、art模式中，咱們直接經過 env->FromReflectedMethod獲取到ArtMethod函數指針。

二、而後直接替換ArtMethod結構體的成員數據指針

4、框架使用案例

上面介紹完了原理，下面若是不用案例來作分析，那都是白扯淡，這裏咱們就用一個簡單的案例來進行實際操做一下，並且在這個過程當中會發現一個神奇的工具apatch，這裏的例子很簡單，本地定義一個獲取版本號的方法：

這時候咱們獲得這個值，而後顯示在界面上，而後開始出release包，這裏直接用eclipse構造簽名文件(這個簽名文件要記得保存好，後面會使用到)出包了。等包上線發佈以後，忽然發現這個版本號錯了，應該是1.0.2，那麼這時候就須要進行熱修復了，操做很簡單：

第一步：修改這個方法返回值爲1.0.2

第二步：繼續使用上面的簽名文件進行簽名獲得了一個修復以後的apk包

第三步：使用神器apatch進行線上發佈的release包和此次修復的fix包進行比對，獲取到修復文件apatch

java -jar apkpatch.jar -f app-release-fix.apk -t app-release-online.apk -o C:\Users\jiangwei1-g\Desktop\apkpatch-1.0.3 -k jiangwei.keystore -p 123456 -a jiangwei -e 123456

這裏在使用命令的時候須要用到簽名文件，由於在前面分析代碼的時候知道會作修復包的簽名驗證。這裏獲得了一個修復包文件以下：

並且會產生一個diff.dex文件和smali文件夾，這個就是修復類的文件對應的dex文件和smali代碼：

而咱們用壓縮軟件能夠打開apatch文件看看：

能夠看到這裏的classes.dex文件其實就是上面的diff.dex文件，只是這裏更像是Android中的apk文件目錄格式，一樣有一個META-INF目錄，這裏存放了簽名文件以及須要修復類信息的PATCH.MF文件：

簽名文件就很少說了，來看一下PATCH_MF文件信息：

Patch_Classes字段包含了須要修復的類的名稱信息了。

第四步：這裏爲了演示方便，直接把上面的修復文件拷貝到sd卡中，而後調用PatchManager的addPatch方法：

第五步：運行程序

這時候能夠發現版本號已經修復成了1.0.2了。

5、apatch工具原理解析

上面看到案例使用比較簡單，可是看到有一個比較牛逼的工具就是apatch，能夠生成有方法變更的類所在的dex文件，那下面就來一塊兒看看他的實現原理，沒找到源碼，直接使用jd-gui查看apatch.jar文件了：

這裏的核心代碼就是這部分，會把有方法變更的類信息列表對象DexBackedClassDef藉助baksmali類寫入到smali文件中，而後在藉助DexBuilder和SmaliMod類把smali類變成dex文件，也就是最終的diff.dex文件了。那麼下面在來看一下這個變更的DexBackedClassDef類列表信息如何獲得的：

在這裏使用DexBackedDexFile類進行加載新舊的dex文件，而後開始比對具體方法實現變更狀況，主要是方法：compareMethod的實現：

這裏會調用方法的getImplementation方法來判斷新舊方法的實現發生變更了，若是有就把當前的類對象加入變更列表中便可。

因此從這裏能夠看到這裏實際上是徹底藉助了第三方的功能：能夠把dex變成smali文件的baksmali工具包、能夠把smali變成dex文件的smali工具包。而這兩個工具包的源碼以前在介紹apktool反編譯工具的時候說到了，想查看源碼的同窗能夠查看這篇文章：反編譯利器apktool的源碼解析。從這裏能夠看到，咱們後續再處理dex，smali等文件格式的時候這兩個工具包用的很是多。

6、框架技術總結

到此這次修復操做就完成了。咱們的講解工做和案例演示工做也完成了，下面來總結一下這個框架的知識點，不過先來看一張大圖(能夠點擊下載查看高清大圖)：

第1、核心技術點

從上面能夠看到AndFix框架的技術點主要包括：

一、使用apatch工具生成修復包文件，主要藉助baksmali和smali工具包實現

二、Java層傳遞新舊方法類型對象，到native層獲取其對應的結構體信息實現完美替換新舊方法結構信息

第2、優勢和侷限性

優勢：從上面能夠看到這個框架的優勢在於輕巧便捷，集成成本低，維護性強。

侷限性：從上面的代碼分析能夠看到這個框架的侷限性仍是不少的，特別是他只能修復對應已經存在的方法，好比如今我想增長一個方法確定不行的，若是想給修復方法增長參數信息也是不能夠的，這個侷限性就很是大了。還有一個侷限性就是隻能進行代碼修復，資源是沒法作到的。因此從這裏能夠看到這個框架更偏重於方法的熱修復操做。

項目下載地址：http://download.csdn.net/detail/jiangwei0910410003/9678441

工具下載地址：http://download.csdn.net/detail/jiangwei0910410003/9678885

7、總結

在開發過程當中現階段熱修復技術仍是很火的，而一些大公司也相繼給出了一些熱修復的合理方案，每家都有各自的優勢和缺點，而我就要作到每家熱修復框架的詳細原理解析，從中可以學習到更多的技巧和知識，頂着頭疼的風險寫完了這篇文章，記得多點贊多分享！