熱修復是很多開發者關心的技術，8月27日晚，阿里百川組織了“百川解碼”在線直播，以“熱修復的坑和阿里的解”爲主題，邀請了三位業界嘉賓對熱修復技術進行了探討，並介紹了阿里百川全面接受公測的熱修復解決方案：阿里百川HotFix，就網友提出的相關問題進行了解答。本文是此次直播的精彩回顧。
嘉賓簡介
歩川，阿里巴巴資深開發工程師，《讓App像Web一樣發佈新版本》一文作者，在OPPO從事Android Framework兩年，騰訊QQ空間工作一年半，熱衷研究安卓熱補丁方案。目前在手機淘寶終端架構，主要負責動態部署增強和優化、存儲相關工作。
劉昭，中華英才網Android技術負責人，具有豐富的移動開發經驗，崇尚開源社區文化，關注性能優化、研發效率、熱修復、插件化、數據驅動等，善於評估技術方案，解決疑難雜症。
澤胤，阿里巴巴無線技術專家，阿里百川HotFix項目負責人，無線事業部初創技術員工之一。經歷阿里巴巴無線技術從小到大的整個過程，參與過多個無線的重要項目，包括無線的H5建站，無線統一接入層，阿里的無線PUSH系統，以及第一版的Android客戶端等。主要技術方向是在線高併發和高可用性的維護與實現。
1. 熱修復是什麼
劉昭認爲，熱修復是在應用的App包發佈到市場之後，出現了Bug，無需替換包來進行在線更新的一種技術，對用戶是無感知的。
澤胤認爲，談到熱修復，就應該和動態部署的概念進行區分。熱修復是特指對微小改動進行修復的一個技術，它強調快速和無感的修復。而動態部署會複雜更多，它涵蓋的東西也更多，但核心的技術還是熱修復技術。
步川認爲，熱修復可以從技術上來理解並和動態部署進行區分。他提到，目前廣義上有兩種方案可以實現代碼的替換，一種是類的替換，基於Classloader，另一種是方法的替換，而這兩種方式各有優缺點。
方法的替換：只能替換方法的內容，所以不能夠對要patch的類進行方法的新增和刪除；但同時，方法的替換可以在應用不重啓的情況下實現。它包小、快速、功能單一、比較輕量，這種方案是熱修復。
類的替換：可以修改類結構，功能更加的強大；但是必須要重啓一次纔會有效，因爲已經加載過的類是不能夠被替換的。這種方案叫做“動態部署”。它幾乎能夠適應任何代碼的變更，所以很適合進行業務功能的迭代。
2. 熱修復技術對比
目前，業內有很多的熱修復方案，步川就熱修復技術向觀衆進行了對比講解。他提到，從廣義上來講，熱修復的實現方式可以被分爲類的替換和方法的替換。
類的替換
如圖1所示，APK包中包含了代碼和資源，代碼存放在classes.dex中，資源存放在APK的res目錄下，系統會通過ClassLoader裝載classes.dex來進行類加載。如果有多個classes.dex，那麼這多個classes.dex會在ClassLoader中會用數組的形式來進行組織，然後從前往後進行遍歷查找。
圖1
一種具體的方案如圖2所示，是利用多dex從前往後遍歷的有序特性，把patch.dex插入到數組的最前面，對patch進行有限查找，達到替換的目的，這時候就會出現preverify問題，爲了繞過這個問題，就必須往每個類的構造函數裏面進行插樁防止安裝期間的校驗，把校驗從編譯期間移動到了運行期間，導致運行期間每加載一個類，都要進行校驗和優化，降低了運行性能。
圖2
劉昭認爲，這種方案利用了ClassLoader，思想是比較好的，但是如果工程中的類比較多，就會在性能上造成比較大的影響。同時，有可能會導致patch包比較大。
步川提到，爲了解決上述性能問題，出現了另一種方案，如圖3所示：就是全量替換dex，下發一個patch.dex，然後把原來的dex和下發的patch.dex，合成一個新的全量dex，這個dex會全量替換原來的dex，最終本質上也只會在這個全量的dex中查找，從而不會出現preverify問題，所以這種方案不用插入構造函數，不會影響性能。但是，這種方案的包也可能會比較大，只改動了一行代碼，也必須合成一個全量的dex，如圖4所示，然後再dexopt出一個全量的odex。
圖3
圖4
方法的替換
如圖5所示，方法的替換的原理如下：在Android底層，有個數據結構記錄着類的信息，比如成員變量的個數，方法的個數，每個方法的code執行地址，程序運行的時候會根據這個地址跳轉到具體的code區域執行代碼。方法的替換就是替換這些地址，把地址指向另一個類的方法，從而達到了替換的目的。這種方式的包比較小，而且也不需要插樁來影響性能，但是它無法修改類的結構（比如方法數的增刪），而且有可能會有兼容性問題，例如廠商修改了類和方法的底層結構。
圖5
所以基於他們的優點和限制，區分熱修復和動態部署這兩種場景，可以在這兩種不同的情況下，選擇最優的方案，達到修復的目的。
3. 如何選擇熱修復技術方案
劉昭認爲，熱修復技術方案的選擇應該對應具體的使用場景。在patch包的數量、大小方面，HotFix是佔優勢的；但是HotFix不能新增類、新增字段（下文澤胤有迴應），從這個角度考慮，ClassLoader更好，但是會有一定的性能損耗；合成dex的方式，則需要知道用戶手機的ROM有多大，能不能提供20多M的空間來。
4. 基於AndFix的阿里百川HotFix做了哪些優化工作
阿里百川HotFix是基於AndFix的，澤胤提到，手機淘寶（下文簡稱“手淘”）對於Andfix實踐了大約一年左右，在工程和技術上做了一些改善，提高了其在穩定性、周邊工具鏈的性能和穩定性等方面的表現，使得這項技術更加成熟，同時也解決了不能新增類等問題，併成功落地手淘App。
具體的優化工作包括：在產品化方面，接入簡單，2行代碼即可接入，一般開發者1個小時即可完全跑通流程，大大降低工程成本；提供了相對完善的周邊工具鏈，通過後臺操作自由控制patch發佈，最大化保證用戶體驗。針對patch打包慢的問題進行優化，持續在工具鏈方面進行優化；在“打包工具交互”方面，開發了一個獨立的可執行文件，可以在工程裏面，用GRADLE、ANT中集成，甚至在JENKINS裏面去執行，提高了靈活性。
在產品化方面，接入簡單，2行代碼即可接入，一般開發者1個小時即可完全跑通流程，大大降低工程成本；提供了相對完善的周邊工具鏈，通過後臺操作自由控制patch發佈，最大化保證用戶體驗。
在安全方面，澤胤也做了說明：第一，阿里會提供一個私有RSA加密的功能，開發者在本地打出包以後用自己的RSA密鑰對中的私鑰加密，然後上傳百川平臺，再在SDK中放置自己的公鑰作爲解碼用，這樣上傳的內容完全加密確保絕對的信息安全，且不會被阿里看到；第二，傳輸層面，在設計上採用兩級的加密，動態密鑰和靜態密鑰相結合，因此網絡攔截無法竊取到包內容。
5. 熱修復的未來
從商業價值上來講，開發者目前非常需要熱修復技術，所以有一定的價值，但是未來，如果官方提供相應的功能，或者說React Native 等技術減弱了開發者對熱修復技術的依賴，則會對熱修復的技術產品造成衝擊。對於這樣的情況，澤胤認爲，作爲技術人員，要不斷學習進步。一項技術如果沒有了被使用的價值，那麼它是應該被淘汰掉的，例如歷史上很多編程語言或者技術的消亡。澤胤表示，產品的迭代和消亡也是很正常的。很樂意看到有新的，滿足開發者需求的技術可以代替老的技術。
步川認爲，從方案講，熱修復和動態部署不是互相排斥的，在特定的場景下兩者都可以做到最優，配合使用更佳。手淘同時使用這兩項技術，用熱修復解決Bug，用動態部署來迭代業務，相互配合好則會達到很完美的狀態。
劉昭提出，Android Studio 2.0之後，提供了Instant Run這樣的功能，從思想上來講是非常好地解決了熱修復patch的問題，之後的熱修復有沒有可能借鑑其思想？對於這個問題，步川認爲，Instant Run的更新力度比較大，同時又在代碼中增加了預埋邏輯，侵入性比較大。若基於Class Loader來開發一個工具，或許會更簡單。
6. 阿里百川HotFix開始公測
澤胤提到，市場上缺少阿里百川HotFix這樣的產品，雖然熱修復原理解析很多，但是真正難的是把這項技術做成熟、做穩定。基於手淘App這個大平臺，由工程實踐出來的阿里百川HotFix產品，可以推出獨立的服務來滿足市場上的需求。澤胤提到，阿里百川會有專門的團隊持續跟進該產品，解決問題，吸納用戶意見。
阿里百川HotFix從直播當晚開始正式進行公測，你還沒申請公測？
來吧點我！阿里百川HotFix公測申請