Android熱修複方案盤點

享學課堂特邀作者：周周

轉載請聲明出處！

前言

上一個大的系列文章叫 “手把手講解”, 曆時10個月，出産博文二十餘篇，講解細緻，幾乎每一篇都提供了詳實的原理講解，提供了可運作

githubDemo

，并且針對Demo中的關鍵地方進行了重點拆解。相信每一位詳細閱讀文章的同行都會有所收獲。但是，講解雖詳細，但是缺乏對于技術的深度的挖掘。

從今天開始開辟新的專題:

移動架構師專業技能深入淺出

,以一步步成為架構師為目标，詳述一項架構師技能的最直接使用價值，橫向周邊知識以及縱深專業技術.

最直接使用價值： 網上最怕看到一種文章，全文開篇高大上，讓人覺得遙不可及，通篇看下來卻沒有展示技術如何落地，落地之後是何種效果。文章寫出來，就要以最容易讓人接受的方式帶讀者進入作者的世界，而不是裝作一副高高在上的樣子俯視衆生。是以，文章開篇，一定是最直接的展示技術的落地效果。提供可運作Demo可以讓讀者親自嘗試。

橫向周邊知識： 一項核心技術，必然不是獨立存在，技術是一個體系，但是一篇文章能夠詳述的技術有限，必然是以一項技術為中心，其他技術作為輔助。核心技術需要詳述，但是周邊技術，也需要交代，參天大樹拔地而起也少不得土壤作為依附。用簡明的語言交代周邊知識，并提供這些知識正确的研究方向。也是一個負責任的博文作者不可忽視的一步。

縱深專業技術: 做技術，最忌諱的就是淺嘗辄止。稍微深入一點就退出去，一來不利于了解底層實作,長此以往永遠隻是一個技術小白，成不了大師；二來不利于長久記憶, 記憶力再強的人時間長了，技術細節必然會記憶模糊。但是如果深入核心，了解了原理，在技術的大方向上絕對不會偏差。作為要成為架構師的男人，即使記不了那麼多細節，但是對于大方向的把握絕對不能錯。是以，技術縱深很有必要。

前情提要

上一篇 Android Muitldex熱更新修複方案原理提到了 熱修複的其中一種Muitidex方案，并且給出了示範Demo。但是真正完整去展現現實中的 熱修複開源架構，遠遠不夠。

正文大綱

• 阿裡AndFix 方案
• 美團 Robust方案
• 騰訊 Tinker dexdiff / DexMerge方案
• 騰訊 QZone Muitidex方案

正文

熱修複方案按照是否必須重新開機 分為兩類： 重新開機生效 / 即時生效。按照 實作方式可以分為3類： java層的實作 / native層的實作 / java native混合實作

阿裡AndFix 方案(已棄用)

AndFix 是 無需重新開機 的 native層 的實作. 但是，AndFix目前已經3年多沒維護更新。因為阿裡已經有了新的替代方案，不再需要維護。另外，這種純native的實作方式，相容性十分堪憂。既然已經被棄用，但是稍微了解一下 實作方案也是沒問題的。

上圖解讀：圖中有一段程式按照 

A=>B=>C

的順序去執行,然而發現執行到B的時候，存在一個bug，AndFix的修複方式為：在native層執行到B方法的時候，把方法的指針指向了 更新檔包裡的B方法，繞過了原來的B方法。進而達到了修複bug的目的。

使用方法:

在需要修複的方法上面，加上@MethodReplace注解，給定參數，class和method，表示 該方法替換為 哪個類的哪個方法。

缺陷：修複粒度為：method. AndFix隻能以方法為粒度去修複bug。作用有限，針對大範圍的類替換和資源替換，那就無能為力了。

美團 Robust方案

Robust 是 即時生效的Java層實作的熱修複實作方案.

美團的Robust方案，是參考了谷歌的InstantRun方案（之前在androidStudio裡面有這個選項，可以選擇打開instant run運作app)的思路而設計出來的。

其主要設計思想就是一句話：編譯打包時，在程式的某些方法裡面，都插入一段代碼（全自動操作）：

當 

changeQuickRedirect

不為空的時候，該方法就會命中 

if(changeQuickRedirect!=null)

，進而執行修複的實作代碼。當為空的時候，則正常執行原邏輯。

而平時我們自己編碼，隻需要加上一個 

@modify

注解,來标記這個方法需要打更新檔包，也就是需要插入上面這個 

if(changeQuickRedirect!=null)

代碼段。 

為什麼它可以即時生效？

上圖解析：利用ClassLoader，當用戶端手機收到更新檔包 patch.dex的時候，執行更新檔包，把指定方法的 

changeQuickRedirect

用反射的手段指派，讓它變成非空。進而讓下一次程式邏輯走到這裡的時候，走修複之後的邏輯。

Robust是如何将這麼多 ****

if(changeQuickRedirect!=null)

代碼段插入到代碼邏輯中的？:

上圖中的 

if(changeQuickRedirect!=null)

代碼段，并非我們手動編寫，而是由Robust架構自動插入的。這個技術叫做 位元組碼插樁，意為：對class進行操作，按照class檔案的格式，插入自己想要的邏輯。目前Robust支援兩種位元組碼插樁方案 

AspectJ

 和 

Javasist

.

騰訊 Tinker dexdiff / DexMerge方案

Tinker 是騰訊自研的 重新開機生效的 Java層的實作。

原理

Tinker基于一個基準dex，以及修複bug之後的dex，使用dexdiff算法，計算出差分包dex。然後把差分包推送給用戶端，用戶端收到之後，重新開機運作app，把差分包dex和原dex進行合并，形成新的dex。然後ClassLoader去建立類class對象的時候，就會建立修複bug之後的類class對象。進而達到 修複bug的目的。 

Dexdiff算法

了解增量更新的人應該知道 bsdiff。bsdiff是無視檔案格式，生成兩個二進制檔案的差異檔案。dexdiff是基于bsdiff，并且進行了針對dex檔案格式的優化。Tinker除了支援Dex修複之外，還支援so修複，隻不過so的差分包，是直接使用的bsdiff算法生成的。

騰訊 QZone Muitidex方案

Multidex方案是 基于ClassLoader的 純java實作 的 重新開機生效的熱修複方案.

原理

Apk打包的時候可能生成多個classes.dex檔案。JVM中 類加載器ClassLoader，在程式運作使用到某一個Class的時候，是按照順序查找的方式進行的。一旦找到，就會緩存起來，下一次loadClass就不會去查找，而是直接使用緩存中的（是以Muitldex方案必須重新開機app）. 而，當我們把更新檔dex檔案放到 順序查找的最前面，那麼類加載器 查找到它之後，就會直接使用。原來的同樣的類便處于後方，不會再生效。由此，使用更新檔Class完全替換了 原class.

至于更深入的原理，上一篇 Android Muitldex熱更新修複方案原理已經給出了詳細講解。在此就不贅述。

方案對比

結語

推薦一篇好文：https://www.cnblogs.com/popfisher/p/8543973.html 對于熱修複做了非常詳盡的講述。應該是行業大神所寫。本人拜讀之後略作了參考。本人能力有限，除 

Multidex

熱修複方案之外，其他三種隻是有所耳聞。接下來将會對 

Muitldex

方案的一些相容問題做出詳細解讀。盡情期待。

今日福利（點選下方文字超連結擷取）

如果你的技術提升遇到瓶頸了，或者缺進階Android進階視訊學習提升自己，這有大量大廠面試題為你面試做準備！

最後

分享一些系統的面試題，大家可以拿去刷一刷，準備面試漲薪。

請點贊後，戳這裡，免費擷取！

這些面試題相對應的技術點：

• JVM
• MySQL
• Mybatis
• MongoDB
• Redis
• Spring
• Spring boot
• Spring cloud
• Kafka
• RabbitMQ
• Nginx
• …

大類就是：

• Java基礎
• 資料結構與算法
• 并發程式設計
• 資料庫
• 設計模式
• 微服務
• 消息中間件

轉存中…(img-hykgN0mF-1623556466681)]

[外鍊圖檔轉存中…(img-UIgoV02f-1623556466681)]

[外鍊圖檔轉存中…(img-1zHB9NMm-1623556466682)]

[外鍊圖檔轉存中…(img-DCMIXmE5-1623556466682)]