Android教程網
  1. 首頁
  2. Android 技術
  3. Android 手機
  4. Android 系統教程
  5. Android 游戲
 Android教程網 >> Android技術 >> 關於Android編程 >> 淺談主流熱修復技術

淺談主流熱修復技術

編輯:關於Android編程

熱修復

熱修復作為當下熱門的技術,在業界內比較著名的有阿裡巴巴的AndFix、Dexposed,騰訊QQ空間的超級補丁技術和微信的Tinker。最近阿裡百川推出的HotFix熱修復服務就基於AndFix技術,定位於線上緊急BUG的即時修復,所以AndFix技術這塊我們重點分析阿裡百川HotFix。下面,我們就分別介紹QQ空間超級熱補丁技術和微信的Tinker以及阿裡百川HotFix技術

qq空間超級補丁方案

超級補丁技術基於DEX分包方案,使用了多DEX加載的原理,大致的過程就是:把BUG方法修復以後,放到一個單獨的DEX裡,插入到dexElements數組的最前面,讓虛擬機去加載修復完後的方法。
這裡寫圖片描述

當patch.dex中包含Test.class時就會優先加載,在後續的DEX中遇到Test.class的話就會直接返回而不去加載,這樣就達到了修復的目的。

但是有一個問題是,當兩個調用關系的類不在同一個DEX時,就會產生異常報錯。我們知道,在APK安裝時,虛擬機需要將classes.dex優化成odex文件,然後才會執行。在這個過程中,會進行類的verify操作,如果調用關系的類都在同一個DEX中的話就會被打上CLASS_ISPREVERIFIED的標志,然後才會寫入odex文件。

所以,為了可以正常的進行打補丁修復,必須避免類被打上CLASS_ISPREVERIFIED標志,具體的做法就是單獨放一個類在另外DEX中,讓其他類調用。

我們來逆向手機QQ空間APK看一下具體的實現:

先進入程序入口QZoneRealApplication,在attachBaseContext中進行了兩步操作:修復CLASS_ISPREVERIFIED標志導致的unexpected DEX problem異常、加載修復的DEX。
這裡寫圖片描述

修復unexpectedDEX problem異常
\
可以看到,這裡是要加載一個libs目錄下的dalvikhack.jar。在項目的assets/libs找到該文件,解壓得到classes.dex文件,逆向打開該DEX文件
這裡寫圖片描述
通過不同的DEX加載進來,然後在每一個類的構造方法中引用其他dex中的唯一類AnitLazyLoad,避免類被打上CLASS_ISPREVERIFIED標志
這裡寫圖片描述
在無修復的情況下,將DO_VERIFY_CLASSES設置為false,提高性能。只有在需要修復的時候,才設置為true
這裡寫圖片描述
至於如何加載進來,與接下來第二個步驟基本相同 加載修復的DEX
從loadPatchDex()方法進入,經過幾次跳轉,到達核心的代碼段,SystemClassLoaderInjector.c()。由於進行了混淆和多次方法的跳轉,於是將核心代碼段做了如下整理
這裡寫圖片描述
修復的步驟為:
可以看出是通過獲取到當前應用的Classloader,即為BaseDexClassloader 通過反射獲取到他的DexPathList屬性對象pathList 通過反射調用pathList的dexElements方法把patch.dex轉化為Element[] 兩個Element[]進行合並,把patch.dex放到最前面去 加載Element[],達到修復目的
這裡寫圖片描述

優勢
1. 沒有合成整包(和微信Tinker比起來),產物比較小,比較靈活
2. 可以實現類替換,兼容性高。(某些三星手機不起作用)

不足
1. 不支持即時生效,必須通過重啟才能生效
2. 實現修復這個過程,必須在應用中加入兩個dex!dalvikhack.dex中只有一個類,對性能影響不大,但是對於patch.dex來說,修復的類到了一定數量,就需要花不少的時間加載。對手淘這種航母級應用來說,啟動耗時增加2s以上是不能夠接受的事
3. 在ART模式下,如果類修改了結構,就會出現內存錯亂的問題。為了解決這個問題,就必須把所有相關的調用類、父類子類等等全部加載到patch.dex中,導致補丁包異常的大,進一步增加應用啟動加載的時候,耗時更加嚴重

微信Tinker

微信針對QQ空間超級補丁技術的不足提出了一個提供DEX差量包,整體替換DEX的方案。主要的原理是與QQ空間超級補丁技術基本相同,區別在於不再將patch.dex增加到elements數組中,而是差量的方式給出patch.dex,然後將patch.dex與應用的classes.dex合並,然後整體替換掉舊的DEX,達到修復的目的

這裡寫圖片描述

我們來逆向微信APK看一下具體的實現:
先找到應用入口TinkerApplication,在onBaseContextAttached()調用了loadTinker()

這裡寫圖片描述
* 進入TinkerLoader的tryLoad()方法中

這裡寫圖片描述
* 從方法名可以預見,在tryLoadPatchFilesInternal()中嘗試加載本地的補丁,再經過跳轉進入核心修復功能類SystemClassLoaderAdder.class中

這裡寫圖片描述
* 代碼中可以看出,根據Android版本的不同,分別采取具體的修復操作,不過原理都是一樣的。我們以V19為例

這裡寫圖片描述
* 從代碼中可以看到,通過反射操作得到PathClassLoader的DexPatchList,反射調用patchlist的makeDexElements()方法吧本地的dex文件直接替換到Element[]數組中去,達到修復的目的。
對於如何進行patch.dex與classes.dex的合並操作,這裡微信開啟了一個新的進程,開啟新進程的服務TinkerPatchService進行合並

這裡寫圖片描述

這裡寫圖片描述

優勢
1. 合成整包,不用在構造函數插入代碼,防止verify,verify和opt在編譯期間就已經完成,不會在運行期間進行
2. 性能提高。兼容性和穩定性比較高。
3. 開發者透明,不需要對包進行額外處理

不足
1. 與超級補丁技術一樣,不支持即時生效,必須通過重啟應用的方式才能生效。
2. 需要給應用開啟新的進程才能進行合並,並且很容易因為內存消耗等原因合並失敗。
3. 占用額外磁盤空間,對於多DEX的應用來說,如果修改了多個DEX文件,就需要下發多個patch.dex與對應的classes.dex進行合並操作時這種情況會更嚴重,因此合並過程的失敗率也會更高。

阿裡百川HotFix

阿裡百川推出的熱修復HotFix服務,相對於QQ空間超級補丁技術和微信Tinker來說,定位於緊急bug修復的場景下,能夠最及時的修復bug,下拉補丁立即生效無需等待

AndFix實現原理
AndFix不同於QQ空間超級補丁技術和微信Tinker通過增加或替換整個DEX的方案,提供了一種運行時在Native修改Filed指針的方式,實現方法的替換,達到即時生效無需重啟,對應用無性能消耗的目的
這裡寫圖片描述 AndFix實現過程
這裡寫圖片描述
以Dalvik設備為例,來分析具體的實現過程 setup()
這裡寫圖片描述
對於Dalvik來說,遵循JIT即時編譯機制,需要在運行時裝載libdvm.so動態庫,獲取以下內部函數:
1) dvmThreadSelf( ):查詢當前的線程;
2)dvmDecodeIndirectRef():根據當前線程獲得ClassObject對象。 setFieldFlag
這裡寫圖片描述
該操作的目的:讓private、protected的方法和字段可被動態庫看見並識別。原因在於動態庫會忽略非public屬性的字段和方法 replaceMethod
這裡寫圖片描述

該步驟是方法替換的核心,替換的流程如下
這裡寫圖片描述

優勢
1. BUG修復的即時性
2. 補丁包同樣采用差量技術,生成的PATCH體積小
3. 對應用無侵入,幾乎無性能損耗

不足
1. 不支持新增字段,以及修改方法,也不支持對資源的替換。
2. 由於廠商的自定義ROM,對少數機型暫不支持

綜合分析各個方案

這裡寫圖片描述

熱修復的坑和解

我們可以看到,QQ空間超級補丁技術和微信Tinker的修復原理都基於類加載,在功能上已經支持類、資源的替換和新增,功能非常強大。既然已經有了這麼強大的熱修復技術,為什麼阿裡百川還要推出自己的熱修復方案HotFix呢?

一、多DEX帶來的性能問題和影響

我們知道,多DEX方案用來解決應用方法數65k的問題,現在Google也官方支持了MultiDex的實現方案。但是,這實在是應用因方法數超出而作出的不得已的下策,但是超級補丁技術和Tinker作為一種熱修復的方案,平生給應用增加了多個DEX,而多DEX技術最大的問題在於性能上的坑,因此基於這種方案的補丁技術影響應用的性能是無疑的

1. 啟動加載時間過長

我們可以看到,超級補丁技術和Tinker都選擇在Application的attachBaseContext()進行補丁dex的加載,即使這是加載dex的最佳時機,但是依然會帶來很大的性能問題,首當其沖的就是啟動時間太長。
對於補丁DEX來說,應用啟動時虛擬機會進行dexopt操作,將patch.dex文件轉換成odex文件,這個過程非常耗時。而這個過程,又要求需要在主線程中,以同步的方式執行,否則無法成功進行修復。就DEX的加載時間,大概做了以下的時間測試
這裡寫圖片描述
隨著patch.dex的增加,在不做任何優化的情況下,啟動時間也直線增長。對於一個應用來說,這簡直是災難性的

2. 易造成應用的ANR和Crash

正是尤其多DEX加載導致了啟動時間過長,很容易就會引發應用的ANR。我們知道當應用在主線程等待超過5s以後,就會直接導致長時間無響應而退出。超級補丁技術為保證ART不出現地址錯亂問題,需要將所有關聯的類全部加入到補丁中,而微信Tinker采取一種差量包合並加載的方式,都會使要加載的dex體積變得很大。這也很大程度上容易導致ANR情況的出現。
除了應用ANR以外,多DEX模式也同樣很容易導致Crash情況的出現。我們知道,超級補丁技術為了保證ART設備下不出現地址錯亂問題,需要把修改類的所有相關類全部加入到補丁中,這裡會出現一個問題,為了保證補丁包的體積最小,能否保證引入全部的關聯類而不引入無關的類呢?一旦沒有引入關聯的類,就會出現以下的異常:
1. NoClassDefFoundError
2. Could not find class
3. Could not find method
出現這些異常,就會直接導致應用的Crash退出。
所以,不難看出如果我們需要修復一個不是Crash的BUG,但是因為未加入相關類而導致了更嚴重的Crash,就更加的得不償失。
總的來說,熱修復本質的目的是為了保證應用更加穩定,而不是為了更強大的功能引入更大的風險和不穩定性。

二、熱修復 or 插件化?

插件化:一個程序劃分為不同的部分,以插件的形式加載到應用中去,本質上它使用的技術還是熱修復技術,只是加入了更多工程實踐,讓它支持大規模的代碼更新以及資源和SO包的更新。

熱修復:當線上應用出現緊急BUG,為了避免重新發版,並且保證修復的及時性而進行的一項在線推送補丁的修復方案。

從概念上我們可以看到,插件化使用場景更多是功能,熱修復使用常見在於修復。從這個層面來說,插件化必然功能更加強大,能做的事情也更多。QQ空間超級補丁技術和微信Tinker從類、資源的替換和更新上來看,與其說是熱修復,不如說是插件化。
當然,強大的功能也就增加了不穩定的因素。比如上文提到的增加啟動時間,導致ANR、Crash的問題。
QQ空間超級補丁技術和微信Tinker提供了更加強大的功能,但是對應用的性能和穩定有較大的影響,就BUG修復的這個使用場景上還不夠明確,並且顯得過重

針對應用的性能損耗,我們可以舉例做一個對比

某APP的啟動載入時間為3s左右,本身就是基於多DEX模式的實現。 分別接入三種熱修復服務,根據騰訊提供超級補丁技術和Tinker的數據,那麼會變成以下的場景: 阿裡百川HotFix:啟動時間幾乎無增加,不增加運行期額外的磁盤消耗。 QQ空間超級補丁技術:如果應用有700個類,啟動耗時增加超過2.5s,達到5.5s以上。 微信Tinker:假設應用有5個DEX文件,分別修改了這5個DEX,產生5個patch.dex文件,就要進行5次的patch合並動作,假設每個補丁1M,那麼就要多占用7.5M的磁盤空間。

顯然對於修復緊急BUG這個場景,阿裡百川HotFix的更為合適,它更加輕量,可以在不重啟的情況下生效,且對性能幾乎沒有影響。微信Tinker、QQ空間超級補丁技術更多地把場景定位在發布小的新功能上,采用ClassLoader的模式,犧牲較高的性能代價去實現類、資源新增或替換的功能。阿裡百川HotFix對應用本身做到無侵入,無性能損耗

總結

QQ空間超級補丁技術和微信Tinker 支持新增類和資源的替換,在一些功能化的更新上更為強大,但對應用的性能和穩定會有的一定的影響;阿裡百川HotFix雖然暫時不支持新增類和資源的替換,對新功能的發布也有所限制,但是作為一項定位為線上緊急BUG的熱修復的服務來說,能夠真正做到BUG即時修復用戶無感知,同時保證對應用性能不產生不必要的損耗,在熱修復方面不失為一個好的選擇!

  1. 上一頁:
  2. 下一頁:
熱門文章
閱讀排行版
Copyright © Android教程網 All Rights Reserved