【騰訊Bugly乾貨分享】微信熱補丁 Tinker 的實踐演進之路

NO IMAGE

本文來自於騰訊bugly開發者社群,非經作者同意,請勿轉載,原文地址:http://dev.qq.com/topic/57ad7…

Dev Club 是一個交流移動開發技術,結交朋友,擴充套件人脈的社群,成員都是經過稽核的移動開發工程師。每週都會舉行嘉賓分享,話題討論等活動。

本期,我們邀請了騰訊WXG Android開發工程師——張紹文,為大家分享《微信熱補丁Tinker的實踐演進之路》

分享內容簡介

Tinker 是微信官方的 Android 熱補丁解決方案,它支援動態下發程式碼、So庫以及資源,讓應用能夠在不需要重新安裝的情況下實現更新。這裡大致介紹 Tinker 的實現原理,當時遇到的各種坑以及對它各個方面效能的優化工作。

內容大體框架:

  1. 當前各種熱補丁框架的比較以及 Tinker 的設計目標

  2. Tinker的實踐演進

  3. Tinker在實現中遇到的困難

下面是本期分享內容整理。


hello,大家好。我是張紹文,目前在微信主要負責 Android 的效能優化以及終端質量平臺相關工作。

下面開始我們今天的分享。

1. 當前各種熱補丁框架對比 & Tinker 的設計目標

熱補丁技術是當前非常熱門的 Android 開發技術,其中比較出名的方案有支付寶的 AndFix以及 QZone 的超級熱補丁方案。

微信大約在2015年6月開始嘗試應用,經過研究與嘗試現有的各個方案,我們發現它們都有著自身的一些侷限性。我們最終採用不同於它們的技術方案,自研微信熱補丁開源框架 Tinker。

下面我們先來講講先有框架的一些侷限性。

1.1 AndFix

Andfix 是阿里推出的開源框架,它在 github 的地址是:https://github.com/alibaba/An…

它的技術原理如下圖:它採用 native hook 的方式,這套方案直接使用 dalvik_replaceMethod 替換 class 中方法的實現。

它的缺點主要包括以下幾個:

  1. 相容性不佳;由於它採用 native 替換的方式,在 github Issue 中也有大量崩潰的反饋;

  2. 成功率不高;不支援修改 inline 方法,不支援修改方法引數超過8個或引數中帶有 long, double 或者 float。跟一些使用 Andfix 的產品討論過,它們的成功率不超過40%;
    原因:只替換了 DexCache 中的 ArtMethod 結構體,對於 Art 中一些 compiledCode 是直接通過 bx 過去

  3. 開發不透明;由於它還不支援增加 filed,我們需要為了補丁而補丁,無法採用這個技術釋出需求。

Andfix 的好處是可以立刻生效,但它可以支援的補丁場景非常有限,僅僅可以使用它來修復特定問題。

所以我們不考慮採用這個方案。

1.2 Qzone 超級補丁方案

現在我們講講 Qzone 超級補丁方案,在騰訊內部已開源。

這個方案使用 classloader 的方式,能實現更加友好的類替換。而且這與我們載入 Multidex 的做法相似,能基本保證穩定性與相容性。

它主要的面臨問題有兩個:

1.為了解決 unexpected DEX problem 異常,而採用插樁的方式給所有類插入不會真正執行的程式碼,防止類打上 preverify 標誌。

採用插樁導致所有類都非 preverify,導致上圖中的 verify 與 optimize 操作會在載入類時觸發。這會有一定的效能損耗,微信分別採用插樁與不插樁兩種方式做過兩種測試,一是連續載入700個50行左右的類,一是統計微信整個啟動完成的耗時。

2.在 art 平臺,若補丁中的類出現 Field、Method 或 Interface 變化,可能會導致出現記憶體地址錯亂的問題。為了解決這個問題,我們最後補丁中的類要有以下規則:

a. 修改跟新增的 class;
b. 若 class 有 field,method 或 interface 數量變化,它們所有的子類;
c. 若 class 有 field,method 或 interface 數量變化,它們以及它們所有子類的呼叫類。如果採用 ClassN 方式,即需要多個 dex 一起處理。

Qzone 的方案最為簡單,而且開發透明,補丁的成功率也是非常高的。

但由於微信對於執行效能以及補丁大小都比較敏感,我們最終也沒有采用這套方案。

1.3 Tinker 的設計目標

那麼微信希望的是一套怎麼樣的熱補丁框架呢,我們認為主要的目標有以下幾個:

  1. 開發透明;開發者無需關心是否在補丁版本,他可以隨意修改,不由框架限制;

  2. 效能無影響;補丁框架不能對應用帶來效能損耗;

  3. 完整支援;支援程式碼,So 庫以及資源的修復,可以釋出功能。

  4. 補丁大小較小;補丁大小應該儘量的小,提高升級率。

  5. 穩定,相容性好;保證微信的數億使用者的使用,儘量減少反射;

2. Tinker 的實踐演進

現在我們來講講微信熱補丁框架 Tinker 的實現,目前在騰訊內部已開源。

它的名字來至 Dota 中的地精修補匠,我們希望發版本可以像它一樣做到無限重新整理。

Tinker 的方案來源 gradle 編譯的 instant run 與 buck 編譯的 exopackage。它們的思想都是全量替換新的 Dex。即我們完全使用了新的 Dex,那樣既不出現 Art 地址錯亂的問題,在 Dalvik 也無須插樁。

但是 instant run 針對的是編譯期,它可以直接將最後生成的所有變化都直接拷到手機端。對於線上方案,這肯定是不可行的。所以當前核心問題是找到合適的,使補丁結果更小的差分演算法。

微信首先 demo 中採用的是 bsdiff,它無關檔案格式,但對於dex效果不是特別好,而且非常不穩定。當前微信對於 so,依然使用 bsdiff 演算法。

然後我們想到 dexmerge 演算法,把修改跟新增的類通過 dexmerge 方式與原來的 dex 合併,從而得到最終的完整 Dex。

經過實踐,dexmerge 的核心問題有兩個:

  1. 無法刪除 class;導致在 Dalvik 平臺會出現載入類重複的情況,這要求我們只能採用 miniloader 載入方案來避免;

  2. 合成時記憶體佔用過大;dexmerge 庫使用場景在 pc,它沒有太多的考慮記憶體問題。它的峰值記憶體可以達到輸入 dex 的大小的4倍-6倍。一個12M的 dex,峰值記憶體可能達到70多M。

最後我們決定基於 dex 的格式,自研出一種 Dexdiff 演算法,它需要達到以下目標;

  1. diff 結果小;

  2. 合成過程佔用記憶體小;

  3. 支援刪除、新增、修改 dex 中的 class。

這裡面主要的原理是深度利用原來 dex 中的資訊,對於 dex 的每一個 section 做處理。這塊在今天不再深入,感興趣的同學可以交流。

記憶體方面 dexdiff 峰值記憶體是 dex 的兩倍左右,達到預期的結果。

對於微信熱補丁的更多資訊,可以閱讀我之前發的一篇文章。

微信Android熱補丁實踐演進之路

然後我們來看看 Tinker 的框架設計,它主要包括以下幾部分:

  1. 補丁合成;這些都在單獨的 patch 程序工作,這裡包括 dex,so 還有資源,主要完成補丁包的合成以及升級;

  2. 補丁的載入;如果通過反射系統載入我們合成好的 dex,so 與資源;

  3. 監控回撥;在合成與載入過程中,出現問題及時回撥;

  4. 版本管理; Tinker 支援補丁升級,甚至是多個補丁不停的切換。這裡我們需要保證所有程序版本的一致性;

  5. 安全校驗;無論在補丁合成還是載入,我們都需要有必要的安全校驗。

在微信中,我們為 Tinker 框架加入了100多個實時上報,監控著在每個過程可能出現的問題:

3.Tinker 在實現中遇到的困難

接下來我們來看看在開發 Tinker 過程中,遇到的一些問題:

1. 廠商 OTA

對於 Art 平臺,dex2oat 時間較長。特別是廠商 OTA 之後,所有動態載入的程式碼都需要重新執行 dex2oat。這是因為 boot image 已經改變,但是系統在升級時只會給 ClassN.dex 重新 OTA。

對於補丁 dex 會出現主程序同步執行 dex2oat,這個時間非常久,很有可能會出現 ANR,對於小米等一些產品的開發板更是如此。這也是我們現在努力在實現分平臺合成的原因,即在 Art平臺,只合成規則下需要的 class。只要不是全量替換,重新 dex2oat 的時間是可以接受的。

2. Android N 混合編譯導致補丁機制失效

這塊花了一定的時間重新梳理了 Android N art 的程式碼,詳細的分析可以檢視之前我發的一篇文章。

Android N混合編譯與對熱補丁影響解析

3. Dex 反射成功但是不生效

開始的時候,我們載入補丁 dex 採用的是 makedexElement 的方式。但是發現大約有幾十萬臺機器,補丁載入成功了,但是使用的還是舊版本的程式碼。某些機器類似三星 s6 502系統,儘管反射 pathList 成功,查詢順序依然以 base.apk 優先。

這裡採取的解決方法是類似 instant run,採用反射 parent classloader 的方式。這裡不得不提,instant run 的 increaseClassLoader 實現非常精妙。

4. Xposed 等微信外掛

市面上有各種各樣的微信外掛,它們在微信啟動前會提前載入微信中的類,這會導致兩個問題:

a. 在 Dalvik 平臺,直接出現 Class ref in pre-verified class resolved to unexpected implementation 的 crash;

b. 在 Art 平臺,由於出現部分類使用了舊的程式碼,這可能導致補丁無效,或者地址錯亂的問題。

它們根本的原因都是Xposed反射呼叫,提前匯入了我們的某些類。

事實上,由於補丁使用不當或者其他問題,我們的確需要有一個安全模式。即在應用啟動不起來或多次 crash 時,進入補丁清理或者升級的流程。

結語

也許有人覺得 Tinker 過於臃腫,過於複雜。這是因為熱補丁並不是僅僅載入一個 dex 或 so 檔案,事實上它要關心的細節有很多。程序的一致性,控制可修改類的範圍,版本的管理,擴充套件性等等。

Tinker 的未來規劃是真正的開源出去,大約下週會提交分享平臺合成以及資源相關的所有程式碼。然後等公司的開源審計結束後將在 github 開源,歡迎大家接入 Tinker 內測,給我們更多的意見。

由於時間有限,今天的分享就到這裡。對於 So,資源的合成方式,dexdiff 的技術細節,若大家感興趣可以與我們交流。

互動問答環節

Q1:請教下 patch 程序和主程序是怎麼通訊的?

是通過 intent service 通訊的,主程序一個接受補丁結果的 intent service,patch 程序是一個接受補丁請求的 intent service

Q2:“分平臺合成”沒聽太明白,能再仔細說下麼?

分平臺合成就是在 Dalvik 平臺,我們合成全量的 dex,這可以避免我們插樁的要求。

在 Art 平臺,我們只合成上述三個條件下的類:

  1. 修改跟新增的 class;

  2. 若 class 有 field,method 或 interface 數量變化,它們所有的子類;

  3. 若 class 有 field,method 或 interface 數量變化,它們以及它們所有子類的呼叫類。如果採用 ClassN 方式,即需要多個 dex 一起處理。

這裡的難點是同一份 diff 程式碼,可以做到不同的合成方式。

Q3:對於內部空間不足引起的 patch 失敗現在有什麼好的解決辦法?

對於我們的方案,空間佔用有可能比較大,我們解決的方法有兩個:

  1. 在 patch 之前提前檢查使用者的剩餘空間,如果使用者剩餘空間過少,即不嘗試。

  2. 若本次失敗,我們會有回撥,然後我們會定期重試三次。

你也可以在這裡採用提示使用者清理空間。Tinker 框架是可以高度定製化的。

Q4:對於替換 classloader 失敗後再用 MultiDex install 這種方案有什麼考慮?

有的,對於替換失敗的話,的確會回退到類似 Multidex install 方式的

Q5:目前微信對熱補丁技術的應用場景一般集中在哪些方面呢?除了修復緊急的 BUG,還有哪些真實場景下用過這個技術嗎?微信是如何評估是否需要通過打熱補丁的方式來處理一些問題的呢?

正如我之前的一篇文章來說,在 Android 熱補丁技術的應用比 iOS 更加容易。我們可以完全做到無感知的開發,推給使用者等。這裡面的應用場景有很多,使用者除錯,版本升級,釋出需求,Abtest 等等。

Q6:想問下大神,對於替換 app 中使用的第三方 jar 包,有具體實踐嗎?

抱歉,這部分還沒有實踐。原理上是沒問題的,如果第三方的 jar 包是整合到原始碼,那麼編譯新包的時候已經可以帶上改變。如果第三方的 jar 包是動態載入的,也是沒有問題的。我們通過 parent classloader 的方式,查詢順序也會在你們之前。

Q7:patchCoreSDK 怎麼繞過 換 classloader 後跨 dex 載入類 accesserror 的問題?有對 patchcoreSDK 做強制訪問隔離嗎?

是的,Tinker 框架分為兩部分,核心載入程式碼,成為 loader 類,這裡大概有十幾個類,他們是不允許修改的。其他大部分 Tinker 的類也是可以通過補丁修改的,這裡 Tinker 框架已經做了處理,即在新合成的 Dex,我們已經刪除了 loader 相關的類,從而徹底避免了這個問題。

Q8:patch 成功後怎麼及時重啟其他程序?

為了保證各個程序的唯一性,我們有一個版本管理檔案用於記錄當前補丁的版本。它分為 old 與 new 兩個欄位。同時做了約定,只有 patch 程序可以修改 new 欄位,只有主程序可以修改 old 欄位,其他所有程序啟動時都只會載入 old 欄位的補丁版本。然後主要主程序可以發起版本升級,即把 new 欄位賦值給 old 欄位,這個時候主程序要殺掉其他所有的程序,以保證統一性。

而及時重啟其他程序的問題,主要是在我剛才講的 result service。在結果回撥中,我們如果發現補丁已經成功了,我們可以設定主程序在後臺或者鎖屏時自殺,以達到最快的應用。

Q9:完全使用新的資源包是怎麼理解?舊的資源包會被替換刪除嗎?

舊的資源包是安裝的 apk,我們是不會刪掉的。我們只是反射系統的一些介面,把它替換成新的資源包

Q10:超級補丁方案,有沒有想過不採用插樁的方式,而是去 hook 檢驗的方法,就能緩解效能的問題?

事實上,有些人實現 hook preverify 標誌來避免插樁。但是看過底層程式碼,就知道是不可行的。我們要知道系統檢查那個標誌位的真正原因,即使 hook 了 preverify 標誌,在真正執行過程中,由於 quck 指令以及 vtable 的優化,依然執行時會出問題。這個問題告訴我們,做事情需要知其然也要知其所以然。

Q11:合成新的資源和 so 是怎麼載入的?

so 可以通過反射 classloader 的 lib path,但是我們並不建議這麼多,一來是相容性問題,二來在某些機器上,多 abi 的判斷並不準確。我們更希望通過封裝程式碼來支援。對於資源,我們處理是跟 dex 差不多,啟動時即反射呼叫。

Q12:是否有動態下發第三方的 jar 包,如何呼叫第三方 jar 包的方法。反射?

Tinker 框架只會合成輸入 pattern 下的 dex,而且在啟動的時候把他們載入。如果呼叫的問題,使用者自己決定的。

Q13:差量下發更新,合成的時候是否會有效能問題?是否支援(圖片)資源的差量下發?

合成的話,我們對於記憶體、GC 以及耗時都有大量的優化。即使是微信這樣體量的 app,從外部監控來看,大部分使用者都能在60秒以內完成。

Q14:需要在補丁合成載入之後才進入程式(交由使用者操作)嗎?

合成與載入是分開兩個過程,我們的原則是除非合成已經徹底完成,不然其他程序是不會去載入的。即補丁不會去影相其他程序的載入效能

Q15:程式碼完全開源嗎?

對的,所有程式碼都會開源,從編譯到各個模組。

Q16:xposed 框架的那些外掛,是通過反射呼叫替換值?那一般有啥方式保證安全性?保證 app 資料的安全性?

它們只要是反射呼叫微信的某些類,達到某些功能的篡改。事實上,如果在 root 下,單純的保護是比較難的。

Q17:為什麼要在補丁成功的時候加結果回撥是為了啟動程式麼,但是和您剛才說的為了實時上報?

回撥結果是為了給使用者一個回撥,在這個回撥裡面它可以做各種各樣的工作。例如我彈出升級完成的 dialog。我設定鎖屏或者程式進入後臺後自殺,這可以加快補丁的應用

Q18:既然能載入 so 和資源,Tinker 能用於外掛化嗎?

Tinker 當前沒有做四大元件的代理,但是 Tinker 未來絕對是具備這個能力的

Q19:merge 失敗後的補救機制是怎樣的?可以回退麼?

merge 失敗,我們會收到回撥,這個時候我們不會載入的。在預設實現裡面,我們會刪除這些臨時檔案。

Q20:這套框架目前是多少個人在維護呢?

Tinker當前有3個人在開發維護

Q21:請問資源是編譯到 arsc 中還是反射載入二進位制流?

你的問題我不太明白,資源我們採用的是全量替換,即完全使用新的資源包

Q22:在加入 Tinker 之後,對各平臺的加固適配如何?微信是否有加固?

微信沒有使用加固,但是加固應該是不影響的,只需要把介面改一下就可以了。