【移動應用開發(fā)技術】2019 深入解析Android熱修復技術

【移動應用開發(fā)技術】2019深入解析Android熱修復技術

通過閱讀本文，你會對熱修復技術有更深的認知，本文會列出各類框架的優(yōu)缺點以及技術原理，文章末尾簡單描述一下Tinker的框架結構。什么是熱修復？熱修復框架分類技術原理及特點Tinker框架解析各框架對比圖總結正常開發(fā)流程https://upload-images.jianshu.io/upload_images/14847428-6fcac9b8292a263c?imageMogr2/auto-orient/striphttps://upload-images.jianshu.io/upload_images/14847428-800f660c9ac114e2?imageMogr2/auto-orient/strip熱修復優(yōu)勢https://upload-images.jianshu.io/upload_images/14847428-bebf2ab515584603?imageMogr2/auto-orient/strip修復什么？https://upload-images.jianshu.io/upload_images/14847428-165a5d7d51351616?imageMogr2/auto-orient/strip現(xiàn)狀：百花齊放百家爭鳴https://upload-images.jianshu.io/upload_images/14847428-4a7bcc2f46c27a12?imageMogr2/auto-orient/strip簡單分類；https://upload-images.jianshu.io/upload_images/14847428-7421c115c980ad94?imageMogr2/auto-orient/strip更合理的分類；https://upload-images.jianshu.io/upload_images/14847428-342465ddf97d4777?imageMogr2/auto-orient/strip3.1阿里Dexposed--native解決方案原理：直接在native層進行方法的結構體信息對換，從而實現(xiàn)完美的方法新舊替換，從而實現(xiàn)熱修復功能他的思想完全來源于Xposed框架，完美詮釋了AOP編程，這里用到最核心的知識點就是在native層獲取到指定方法的結構體，然后改變他的nativeFunc字段值，而這個值就是可以指定這個方法對應的native函數(shù)指針，所以先從Java層跳到native層，改變指定方法的nativeFunc值，然后在改變之后的函數(shù)中調(diào)用Java層的回調(diào)即可。實現(xiàn)了方法的攔截功能。基于開源框架Xposed實現(xiàn)，是一種AOP解決方案只HookApp本身的進程，不需要Root權限https://upload-images.jianshu.io/upload_images/14847428-57b80d75ff33ac3b?imageMogr2/auto-orient/striphttps://upload-images.jianshu.io/upload_images/14847428-7fae8bd84daf36a7?imageMogr2/auto-orient/striphttps://upload-images.jianshu.io/upload_images/14847428-6a14d74fe7ee5426?imageMogr2/auto-orient/strip優(yōu)點：即時生效不需要任何編譯器的插樁或者代碼改寫，對正常運行不引入任何性能開銷。這是AspectJ之類的框架沒法比擬的優(yōu)勢；對所改寫方法的性能開銷也極低（微秒級），基本可以忽略不計；從工程的角度來看，熱補丁僅僅是牛刀小試，它真正的威力在于『線上調(diào)試』；基于Xposed原理實現(xiàn)的AOP不僅可以hook自己的代碼，還可以hook同進程的AndroidSDK代碼，這也就可以讓我們有能力在App中填上Google自己挖的坑。缺點：Dalvik上近乎完美，不支持ART（需要另外的實現(xiàn)方式），所以5.0以上不能用了；最大挑戰(zhàn)在于穩(wěn)定性與兼容性，而且native異常排查難度更高；由于無法增加變量與類等限制，無法做到功能發(fā)布級別；3.2阿里AndFix--native解決方案原理：與Dexposed一樣都基于開源框架Xposed實現(xiàn)，是一種AOP解決方案優(yōu)點：即時生效支持dalvik和art（AndFixsupportsAndroidversionfrom2.3to7.0,bothARMandX86architecture,bothDalvikandARTruntime,both32bitand64bit.）與Dexposed框架相比AndFix框架更加輕便好用，在進行熱修復的過程中更加方便了缺點：面臨穩(wěn)定性與兼容性問題AndFix不支持新增方法，新增類，新增field等AndFix（Dexpsed）框架不穩(wěn)定的原因（痛點）https://upload-images.jianshu.io/upload_images/14847428-8559a691441eef82?imageMogr2/auto-orient/striphttps://upload-images.jianshu.io/upload_images/14847428-2d297bf2d2a00c21?imageMogr2/auto-orient/strip原理：原理是Hook了ClassLoader.pathList.dexElements[]。因為ClassLoader的findClass是通過遍歷dexElements[]中的dex來尋找類的。當然為了支持4.x的機型，需要打包的時候進行插樁。越靠前的Dex優(yōu)先被系統(tǒng)使用，基于類級別的修復https://upload-images.jianshu.io/upload_images/14847428-43de3722b03c8244?imageMogr2/auto-orient/strip優(yōu)點：不需要考慮對dalvik虛擬機和art虛擬機做適配代碼是非侵入式的，對apk體積影響不大缺點：需要下次啟動才會生效最大挑戰(zhàn)在于性能，即Dalvik平臺存在插樁導致的性能損耗，Art平臺由于地址偏移問題導致補丁包可能過大的問題虛擬機在安裝期間為類打上CLASS_ISPREVERIFIED標志是為了提高性能的，我們強制防止類被打上標志是否會影響性能？這里我們會做一下更加詳細的性能測試．但是在大項目中拆分dex的問題已經(jīng)比較嚴重，很多類都沒有被打上這個標志。插樁方案性能上的痛點：https://upload-images.jianshu.io/upload_images/14847428-6fb205e418da11df?imageMogr2/auto-orient/strip3.4美團Robust--InstantRun熱插拔原理原理：Robust插件對每個產(chǎn)品代碼的每個函數(shù)都在編譯打包階段自動的插入了一段代碼，插入過程對業(yè)務開發(fā)是完全透明編譯打包階段自動為每個class都增加了一個類型為ChangeQuickRedirect的靜態(tài)成員，而在每個方法前都插入了使用changeQuickRedirect相關的邏輯，當changeQuickRedirect不為null時，可能會執(zhí)行到accessDispatch從而替換掉之前老的邏輯，達到fix的目的。https://upload-images.jianshu.io/upload_images/14847428-c7b465ce03a6b039?imageMogr2/auto-orient/strip優(yōu)點：幾乎不會影響性能（方法調(diào)用，冷啟動）支持Android2.3-8.x版本高兼容性（Robust只是在正常的使用DexClassLoader）、高穩(wěn)定性，修復成功率高達99.9%補丁實時生效，不需要重新啟動支持方法級別的修復，包括靜態(tài)方法支持增加方法和類支持ProGuard的混淆、內(nèi)聯(lián)、優(yōu)化等操作缺點：代碼是侵入式的，會在原有的類中加入相關代碼so和資源的替換暫時不支持會增大apk的體積，平均一個函數(shù)會比原來增加17.47個字節(jié)，10萬個函數(shù)會增加1.67M。會增加少量方法數(shù)，使用了Robust插件后，原來能被ProGuard內(nèi)聯(lián)的函數(shù)不能被內(nèi)聯(lián)了3.5微信Tinker原理：服務端做dex差量，將差量包下發(fā)到客戶端，在ART模式的機型上本地跟原apk中的classes.dex做merge，merge成為一個新的merge.dex后將merge.dex插入pathClassLoader的dexElement，原理類同Q-Zone，為了實現(xiàn)差量包的最小化，Tinker自研了DexDiff/DexMerge算法。Tinker還支持資源和So包的更新，So補丁包使用BsDiff來生成，資源補丁包直接使用文件md5對比來生成，針對資源比較大的（默認大于100KB屬于大文件）會使用BsDiff來對文件生成差量補丁。https://upload-images.jianshu.io/upload_images/14847428-1db1e5d3cb5f8b22?imageMogr2/auto-orient/striphttps://upload-images.jianshu.io/upload_images/14847428-929f831ad790e2e0?imageMogr2/auto-orient/strip優(yōu)點：支持動態(tài)下發(fā)代碼支持替換So庫以及資源缺點：不能即時生效，需要下次啟動Tinker已知問題：Tinker不支持修改AndroidManifest.xml，Tinker不支持新增四大組件(1.9.0支持新增非export的Activity)；由于GooglePlay的開發(fā)者條款限制，不建議在GP渠道動態(tài)更新代碼；在AndroidN上，補丁對應用啟動時間有輕微的影響；不支持部分三星android-21機型，加載補丁時會主動拋出"TinkerRuntimeException:checkDexInstallfailed"；對于資源替換，不支持修改remoteView。例如transition動畫，notificationicon以及桌面圖標。Tinker性能痛點：Dex合并內(nèi)存消耗在vmhead上，容易OOM，最后導致合并失敗。如果本身app占用內(nèi)存已經(jīng)比較高，可能容易導致app本系統(tǒng)殺掉。3.6阿里Sophix原理(雙劍合璧)：https://upload-images.jianshu.io/upload_images/14847428-f48236448e191eca?imageMogr2/auto-orient/strip優(yōu)化Andfix（突破底層結構差異，解決穩(wěn)定性問題）：Andfix底層ArtMethod結構時采用內(nèi)部變量一一替換，倒是這個各個廠商是會修改的，所以兼容性不好。https://upload-images.jianshu.io/upload_images/14847428-e99cd0a6eb1dda46?imageMogr2/auto-orient/stripSophix改變了一下思路，采用整體替換方法結構，忽略底層實現(xiàn)，從而解決兼容穩(wěn)定性問題。https://upload-images.jianshu.io/upload_images/14847428-4395aacf401ae90d?imageMogr2/auto-orient/strip突破QQ和Tinker的缺陷QQ和Tinker的缺陷https://upload-images.jianshu.io/upload_images/14847428-d798bd64bb626ff4?imageMogr2/auto-orient/stripSophix對dex的解決方案Dalvik下采用阿里自研的全量dex方案：不是考慮把補丁包的dex插到所有dex前面（dex插樁），而是想辦法在原理的dex中刪除（只是刪除了類的定義）補丁dex中存在的類，這樣讓系統(tǒng)查找類的時候在原來的dex中找不到，那么只有補丁中的dex加載到系統(tǒng)中，系統(tǒng)自然就會從補丁包中找到對應的類。Art下本質(zhì)上虛擬機以及支持多dex的加載，Sophix的做法僅僅是把補丁dex作為主dex（classes.dex）而已，相當于重新組織了所有的dex文件：把補丁包的dex改名為classes.dex，以前apk的所有dex依次改為classes2.dex、classes3.dex...classesx.dex，如下圖所示。https://upload-images.jianshu.io/upload_images/14847428-fa398a0285fe8138?imageMogr2/auto-orient/strip資源修復另辟蹊徑常用方案（InstantRun技術）：這種方案的兼容問題在于替換AssetManager的地方https://upload-images.jianshu.io/upload_images/14847428-13eee5ca49b03820?imageMogr2/auto-orient/stripSophix資源修復方案https://upload-images.jianshu.io/upload_images/14847428-2e65475a9b453a74?imageMogr2/auto-orient/stripSO修復另辟蹊徑https://upload-images.jianshu.io/upload_images/14847428-0b77ea739de9d695?imageMogr2/auto-orient/strip之所以只貼了Tinker的代碼框架，是因為目前開源的方案中是最好的，當然除了Robust。代碼結構https://upload-images.j