微信熱補丁Tinker的實踐演進之路

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

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

為了解決 unexpected DEX problem 異常，而采用插樁的方式給所有類插入不會真正運行的代碼，防止類打上 preverify 標志。

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


在 art 平台，若補丁中的類出現 Field、Method 或 Interface 變化，可能會導致出現內存地址錯亂的問題。為了解決這個問題，我們最後補丁中的類要有以下規則：
a. 修改跟新增的 class；
b. 若 class 有 field，method 或 interface 數量變化，它們所有的子類；
c. 若 class 有 field，method 或 interface 數量變化，它們以及它們所有子類的調用類。如果采用 ClassN 方式，即需要多個 dex 一起處理。

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

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

1.3 Tinker 的設計目標

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

2. 3. Tinker 的實踐演進

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

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

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

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

seo7PC9jb2RlPjwvY29kZT48L3A+DQo8Y29kZT48Y29kZT5kaWZmIL3hufvQoaO7ILrPs8m5/bPM1bzTw8TatObQoaO7INans9bJvrP9oaLQwtT2oaLQ3rjEIGRleCDW0LXEIGNsYXNzoaMgPC9jb2RlPjwvY29kZT4NCjxwPjxjb2RlPjxjb2RlPtXiwO/D5tb30qq1xNStwO3Kx8nutsjA+9PD1K3AtCBkZXgg1tC1xNDFz6KjrLbU09ogZGV4ILXEw7/Su7j2IHNlY3Rpb24g1/a0psDtoaPV4r/p1Nq98czssrvU2cnuyOujrLjQ0MvIpLXEzazRp7/J0tS9u8H3oaM8L2NvZGU+PC9jb2RlPjwvcD4NCjxwPjxjb2RlPjxjb2RlPjxpbWcgYWx0PQ=="" src="/uploadfile/Collfiles/20160820/20160820092319829.jpg" title="\" />

內存方面 dexdiff 峰值內存是 dex 的兩倍左右，達到預期的結果。

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

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

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

在微信中，我們為 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 平台，我們只合成上述三個條件下的類：

a. 修改跟新增的 class；
b. 若 class 有 field，method 或 interface 數量變化，它們所有的子類；
c. 若 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 之後，對各平台的加固適配如何？微信是否有加固？

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