android熱修復方案概覽

android熱修復相關(guān)的意義就不多說了,最近需求之余在看相關(guān)的內(nèi)容,接下來的文章會抽空分析一下熱修復相關(guān)的知識點,先來看一下目前比較知名的方案。

熱修復方案的類型

從原理上來分大致有以下三類:native方案classloader方案插入靜態(tài)變量埋點方案。

對于整個android系統(tǒng)來說,熱修復方案其實是一種逆向行為,無論是哪種方案,都可能存在兼容性問題的,而且每次android新版本發(fā)布,尤其對虛擬機等做優(yōu)化時,基本上都會成為熱修復的“坑”。不管別的,熱修復里面涉及到的知識點都是值得我們學習的,所以我決定較為系統(tǒng)的學習一下,提升自己的技能。

熱修復方案的特點

  • 最突出的優(yōu)點
    native方案:即時生效,無需重啟,這基本上是native方法的唯一優(yōu)點。
    classloader方案:修復范圍廣,包括代碼,資源,so等均可修復。
    埋點方案:兼容性好

  • 缺點
    native方案:兼容性較差,過于底層,bug不好定位,雖然阿里的sophix進行了修復,我個人認為還是存在兼容性問題的,據(jù)同事測試反映,基本上熱啟動的幾率很小,大部分都走的是冷啟動方案。
    classloader方案:之前不了解時覺得這個方案除了需要重啟生效外,沒有其他明顯的缺點,后來發(fā)現(xiàn)這個方案其實最大的問題在于Art虛擬機不斷優(yōu)化帶來的兼容性問題。
    埋點方案:修復范圍小,且打patch較復雜,雖然已經(jīng)實現(xiàn)了自動化patch,也有一些情況自動化patch無法完成或者有誤。

熱修復方案的選擇

大的選擇無非就是用別人的還是自己開發(fā)。除非公司支持,否則短時間開發(fā)出一個穩(wěn)定的熱修復方案是非常不容易的一件事,而且對基礎要求比較高,需要不斷的實踐,填坑。如果選擇開源方案,建議選擇靠譜的方案,比如Tinker或者Sophix,技術(shù)支持做的很好,但是方案確實非常重。至于美團的Robust,技術(shù)支持相對做的較差,或者人家就是給大家個思路,沒打算做技術(shù)支持,我們完全可以參照Robust自行實現(xiàn)一套,我司目前的熱修復方案就是參照Robust完成的。

個人建議:如果項目采用的是插件化架構(gòu),最好做的徹底點,盡量架空主項目,在主項目中使用類Robust方案,結(jié)合動態(tài)下發(fā)插件;如果是組件化方案,可以考慮接入Tinker或者Sophix,畢竟修復范圍要廣的多。

熱修復研究的意義

native方案:想要弄懂,需要去深入了解虛擬機相關(guān)知識,包括虛擬機底層執(zhí)行類和方法的流程,雖然native方案存在兼容性問題,但是完全可以應用于逆向分析領域,可以和如下的逆向分析開源庫歸為一類。

classloader方案:涉及到MultiDex,InstantRun,類加載器原理,dalvik的dexopt,art的dexoat等知識

埋點方案:涉及到InstantRun及字節(jié)碼相關(guān)技術(shù)。

這篇文章只是作為一個基本的介紹,不涉及任何原理。從下一篇文章開始具體介紹各個方案的技術(shù)點。

目前本人在公司負責熱修復相關(guān)的工作,主要是基于robust的熱修復相關(guān)工作。感興趣的同學歡迎進群交流。


image.png
最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成,瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明:文章內(nèi)容(如有圖片或視頻亦包括在內(nèi))由作者上傳并發(fā)布,文章內(nèi)容僅代表作者本人觀點,簡書系信息發(fā)布平臺,僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容