Android 不僅系統版本眾多,機型眾多,而且各個市場都各有各的政策和審核速度,每次發佈一個版本對於開發同學來講都是一種漫長的煎熬。相比於 iOS 兩三天就能達到 80% 的覆蓋速度而言,Android 應用版本升級至少需要兩周才能達到 80% 的升級率,嚴重阻礙了版本迭代速度。也導致**市場上 ... ...
本文來自於騰訊bugly開發者社區,非經作者同意,請勿轉載,原文地址:http://dev.qq.com/topic/57a31921ac3a1fb613dd40f3
Android 不僅系統版本眾多,機型眾多,而且各個市場都各有各的政策和審核速度,每次發佈一個版本對於開發同學來講都是一種漫長的煎熬。相比於 iOS 兩三天就能達到 80% 的覆蓋速度而言,Android 應用版本升級至少需要兩周才能達到 80% 的升級率,嚴重阻礙了版本迭代速度。也導致市場上 App 版本分散,處理 bug 和投訴等也越來越麻煩。
- 修複的 bug 需要等待下個版本發佈視窗才能發佈?
- 已經 ready 的需求排隊上線,需要等待其他 Feature Team 合入代碼?
- 老版本升級速度慢?頻繁上線版本提醒用戶升級,影響用戶體驗?
這幾個問題是每個 App 開發同學都必然要面對的。那麼有沒有方法能在用戶無感知的情況下加速 bug 處理和版本迭代速度?
在這方面 PC 端 Chrome 瀏覽器的 patch 升級方案給我們了一個很好的借鑒:當 Chrome 有版本升級的時候會自動下載 patch 文件。下次啟動後,Chrome 就已經是新版本。
他山之石,可以攻玉
近一兩年 Android 熱補丁框架非常熱門。從最初 360 動態下發 lua 腳本,到後來出現的各種方案,如雨後春筍般出現。早期的補丁框架偏向於以代碼修複為主,主要分為兩大類:native hook 方案和 Multidex 方案。
native hook 方案如阿裡巴巴的 AndFix 和 Dexposed。Multidex 方案如 Qzone。切入點都是替換掉將要執行的代碼。基於 Qzone 方案的思路,出現了 nuwa 這個比較完善的庫,工具鏈比較完善。
類似 Chrome 的 patch 升級方案足以滿足加速 bug 處理和版本迭代速度的需求,給了我們很大的借鑒意義。在安卓系統上,可以通過 hotfix 的思路來達到這一目的:下發補丁文件,更新 App 版本。
站在巨人的肩膀上
在今年 3 月份開始做技術選型的時候把上面的幾種方案試了一輪。其中 AndFix 甚至跟上了現網的一個發佈版本,但是由於影響正向開發過程(只能修改方法、不能修改 field、不能新增類等問題)、庫本身難於維護(需要依賴外部開源力量進行維護)以及發現的莫名其妙的 bug(導致我們 App 下發 patch 後白屏),所以即使跟上了發佈版本也沒有使用。nuwa 僅支持更新 Java 代碼,不能更新資源和 so 文件,滿足不了我們的需求。
沒有好用的輪子,我們決定自己造一個,於是有了現在的 patch 方案。
App 只是一個載入器
既然做安卓 patch 方案,最好的結果就是能支持更新 App 所有的代碼和資源。但是
Application
類是 App 啟動之初就被安卓系統載入起來,所以至少Application
類和它啟動依賴的其他業務類是不能被更新的?- 修複 bug 或者版本迭代過程中難免會遇到需要修改資源文件的情況。資源文件能更新嗎?
- native 實現的 so 文件如何更新?
針對上面三個問題, 我們的設計是把 App 僅僅當做一個載入器。系統啟動 App 之後,載入器決定將要運行的代碼和資源的位置。當有新功能或者 bugfix 需要推送給用戶,替換載入器內容即可。
支持更新全部代碼
上面提到 Application
由於啟動就被載入而不能被更新的問題,我們代理了真實 Application
類的創建過程。通過代理 Application
,控制 Application
從新 dex 文件中載入。假設真實的 Application
類是 MyApplication
。我們在編譯期間自動修改 AndroidManifest.xml
文件,把 MyApplication
替換為 MoaiApplication
(是 App 的入口 Application)。App 啟動後由 MoaiApplication
載入完相應的文件(dex/資源文件/so 文件)後,再將控制權交回給 MyApplication
。
代理生命周期
將控制權交回給 MyApplication
,我們最初是代理 MyApplication
的生命周期。具體做法是,MoaiApplication
決定載入哪裡的業務代碼、資源文件以及 so 文件之後依然負責接收 App 的全部生命周期,然後把生命周期代理給 MyApplication
,簡單例子如下:
還有比較多生命周期函數上面代碼就沒一一列舉。
從上面代碼容易想到代理方案的缺點:必須要完整代理所有生命周期介面。否則 MyApplication
會由於生命周期不完整而出現奇怪的 bug。比如我們最初版本在測試過程中就出現了沒有代理 registerActivityLifecycleCallbacks
函數而導致拿不到 Activity
生命周期 onActivityCreated
/onActivityDestroyed
等回調。
反射 Application
踩到生命周期回調不完整的坑之後,我們開始考慮能不能把 App 運行期間 Application
的引用全部替換成 MyApplication
?這樣就無需 MoaiApplication
把生命周期代理給 MyApplication
,而是由 MyApplication
直接接收系統回調。安卓系統 ContextWrapper
的實現是包裝了一層真正的 mBase
上下文,App 真正使用到的就是這個 mBase
。通過反射 mBase
以及其中欄位對 Application
的引用,『徹底』解決了需要手寫代理 Application
全部生命周期的方法。
dex分包
Qzone 方案下發的 patch 文件是變更過的 Java 類組成的 patch.dex,在 dalvik 和 ART 虛擬機下分別需要解決 Class ref in pre-verified class resolved to unexpected implementation
和記憶體地址錯亂問題。這些問題根源在於改變了類原本所屬的 dex 文件。既然改變類所在的 dex 會導致各種各樣的問題,那直接替換掉整個 dex 不就好了?在調研 JRebal for Android 和 Instant Run 的時候也發現了他們有類似的做法。
我們把 App 的 dex 分成兩部分:
- patch 庫的 dex 文件 -> classes.dex
- 其他業務代碼的 dex 文件 -> classes[N].dex
其中 classes.dex 中僅包含了 patch 庫的全部代碼,並不包含任何其他業務代碼。
假設 apk 中包含三個文件:classes.dex、classes2.dex、classes3.dex。classes.dex 充當的角色就是載入器,負責啟動 App 並且載入後面的兩個 dex。這樣做的目的是,App 啟動需要用到的所有類都集中在 classes.dex 中,所有業務代碼的類都集中在 classes[N].dex 中。如果某次下發 patch 代碼把 classes2.dex 變更為 classes2-1.dex,那麼由載入器載入 classes2-1.dex 和 classes3.dex 即可實現更新包含 MyApplication
類在內的所有代碼。
怎麼載入更新後的代碼?
如果 dex 文件有更新,載入器會選擇載入更新後的文件。我們最初採用了 Google 官方的 Multidex 方案,擴展 DexPathList
的 dexElements
欄位。
Multidex 方案存在問題
Multidex 方案上線後發現某些機型(比如三星s6 5.0.2 ROM)並不能載入擴展進去的 dex 中的代碼。debug 階段卻能順利載入(debugger 拖慢代碼執行速度)。目前的猜測是某些廠商在 5.x 以上版本改動 ROM 導致 App 啟動邏輯有多線程併發執行。
最終我們棄用了 Multidex 方案,轉而 Hack 系統 ClassLoader。
ClassLoader Hack 方案
所有線程使用的是同一個 ClassLoader
對象。所以一旦 Hack 了這個對象,所有線程都開始使用 Hack 過的對象,從而能夠解決多線程導致載入不到擴展的 dex 文件中代碼的問題。
安卓系統載入代碼的 ClassLoader
是 PathClassLoader
和 BootClassLoader
。我們最初設計的方案是在 PathClassLoader
和 BootClassLoader
之間插入一個 BaseDexClassLoader
,讓所有業務代碼都在這個插入的 BaseDexClassLoader
中載入。但是這樣的設計存在缺陷:業務代碼的 ClassLoader
會變成 BaseDexClassLoader
,如果業務代碼依賴了 patch 庫的代碼(在 classes.dex 中),會出現 ClassNotFoundException
。
在這方面 Instant Run 的設計很精巧。它讓 PathClassLoader
插入的父 loader (IncrementalClassLoader
)包裝了 DelegateClassLoader
,並且把 DelegateClassLoader
的父 loader 設置為 PathClassLoader
,使得類載入的路徑變成:
在 DelegateClassLoader
載入業務代碼的時候(業務代碼在 classesN.dex 中),流程會沿著標記的順序最終第 5 步成功載入到業務代碼。業務代碼如果依賴 patch 庫的代碼,會在 PathClassLoader
載入。這樣所有代碼都可以被載入到。
怎麼更新資源?
單純更新 Java 代碼的 patch 框架,實用性會受到很大的局限。開發同學需要仔細驗證提交內容,確保提交中不包含資源文件的變更以及 native so 的改動,會導致本就複雜的開發流程變得更加繁瑣。所以我們在支持更新 Java 代碼的基礎之上,也支持更新資源和 native so 文件。
App 載入資源是依賴 Context#getResources
函數返回的 Resources
對象。Resources
內部包裝了 AssetManager
,最終由 AssetManager
從 apk 文件中載入資源。所以我們反射了替換系統預設的 Resources
,讓 AssetManager
從我們更新後的 apk 中載入資源。現階段的實現支持比如 string/anim/drawable/color/layout 等資源文件的變更。由於 Android 系統在安裝 apk 時候已經把 AndroidManifest.xml
文件解析並寫入到系統中,目前還不支持修改四大組件,比如增加 Activity
。後續會繼續研究如何做到無縫修改四大組件。
怎麼更新 so 文件?
在 Android 項目中使用 native 函數前需要先調用 System.loadLibrary(libName)
。
當 lib 文件需要更新或者有 bug 時候怎麼辦?首先想到的是在代碼中把載入 so 文件的代碼改成System.load(libFilePath)
,讓系統載入自己指定的 libFilePath
文件。然而這樣的改動需要
- 在源代碼中修改或者使用工具在編譯期把
loadLibrary
介面改為load
- patch 庫把 so 文件從 patch 文件中複製到特定目錄
這樣在運行期才有可能載入更新後的 so 文件。
通過分析系統載入 so 文件的方式後,我們使用了更簡單的處理方法。查找 lib 文件是通過調用 PathClassLoader
的 findLibrary
,最終調用到 DexPathList
的 findLibrary
。DexPathList
會在自己維護的列表目錄中查找對應的 lib 文件是否存在。所以我們在發現 patch 文件中有 so 文件變更的時候,會在 PathClassLoader
的 nativeLibraryDirectories
(Android6.0以下)或者nativeLibraryPathElements
(Android 6.0及以上)的最前面插入自定義的lib文件目錄。這樣 ClassLoader
在 findLibrary
的時候會先在自定義的 lib 目錄中查找,優先載入變更過的 so 文件。
patch 包的生成與應用
回到我們最初的目標:patch 不應該影響正向開發流程。我們生成 patch 文件是針對 apk 進行的,開發同學無需關心此次發佈是 patch 版本還是正常版本,只需要正常開發並且打包要發佈的 apk 即可,不會對正向開發流程產生任何影響。
我們提供 python 腳本生成兩個 apk 的:對比兩個 apk 中的所有文件,找出有變更的文件進行 diff,把 diff 結果寫入 patch 文件。線上用戶下載 patch 文件到本地之後,啟動一條新的進程使用 context.getApplicationInfo().sourceDir
路徑的 apk 與 patch 文件合併,得到新的 apk(包含資源文件,不包含 dex 文件)以及 dex 文件、native so 文件,併在這條進程中提前做 dex 優化(dex2oat/dexopt)。針對 dex 優化過程太慢的問題(優化過程慢會導致進程可能會系統kill,降低 patch 成功率)我們併發了 dex 優化過程,使 patch 過程耗時相對減小。新 apk、dex文件、so 文件就可以在下次啟動 App 的時候由載入器載入。
優勢和不足
正所謂沒有完美的架構,只有適合自己的架構。當前的開源方案並不能滿足我們加速 bug處理和版本迭代速度的需求,於是有了站在巨人肩膀上的思考和我們現在的 patch 方案。我們目前的優勢:
- 全面支持 patch Java 代碼、資源文件 和 native so 文件。版本只需要正常滾動,開發同學無需關心是發佈 patch 版本還是正常版本
- 使用相對簡單(減少接入成本也是我們的最初思考點之一),只需要在 build.gradle 中加入三行代碼即可,無需更多配置。
從我們團隊發佈的多個 patch 版本來看,下發的 diff 結果文件稍大。大文件下載過程可能出現的錯誤也會間接影響到 patch 鋪開的速度,所以我們也在嘗試更好的 diff 方案。Chrome 最初升級方案也是 bsdiff,而後慢慢演變出 Courgette 演算法。
演進與思考
我們對於補丁框架的定義不僅僅是『修複bug』就足夠,除此之外,如何快速接入,如何做到不影響現有流程,這對於很多應用來說至關重要。在此之上,搞清楚框架的定位,適當捨棄一些不重要方面的時候,快速迭代,在迭代中持續優化,事情往往比想象的更加簡單。
持續交付一直都是快速迭代思想的一種踐行方式,對於 App 開發而言,如果我們通過構造補丁框架這樣一個渠道,可以通過自動化系統把補丁快速地把新功能推送給用戶,那這個事情的意義就不僅僅是『修複 bug』這麼簡單。減少線上 crash 率和加速版本迭代、讓新功能儘早與用戶見面,從而可以在更短的時間內不斷收集用戶反饋信息對產品進行打磨。
目前我們已經在微信讀書線上三個版本開始試行了用補丁代替版本發佈或者加速老版本升級的做法,期待將來能通過這個渠道,為安卓開發同學們做到無感知的持續交付過程 。
更多精彩內容歡迎關註bugly的微信公眾賬號:
騰訊 Bugly是一款專為移動開發者打造的質量監控工具,幫助開發者快速,便捷的定位線上應用崩潰的情況以及解決方案。智能合併功能幫助開發同學把每天上報的數千條 Crash 根據根因合併分類,每日日報會列出影響用戶數最多的崩潰,精准定位功能幫助開發同學定位到出問題的代碼行,實時上報可以在發佈後快速的瞭解應用的質量情況,適配最新的 iOS, Android 官方操作系統,鵝廠的工程師都在使用,快來加入我們吧!
-
HTML基本元素(HTML框架、HTML表單、HTML5表單新屬性) ...
-
(1)瞭解背景:歷史、現狀、發展、應用領域、特點 ——要瞭解我要學的這門技術/語言的來龍去脈,尤其是現狀,這樣我們才知道學習它的價值等。 (2)搭建運行/測試環境 ——前端還好,要是後臺語言的話據說光搭建環境有的就需要半天,畢竟這些東西做好了,我們才能看到效果,事半功倍。 (3)編寫Hello Wo ...
-
本以為解決跨域上傳後沒有問題了,不成想被測試找出一個問題,那就是在手機上拍照上傳後圖片會旋轉。很頭痛,不過沒有辦法,問題還是需要解決的。在查閱了一系列資料後我找到了相應的解決方案,利用exif.js獲取圖片旋轉的方向,然後再轉過來圖片,之後再上傳。這個方案需要修改前面的腳本,同樣的,由於要傳base ...
-
先舉個簡單的例子, var myCanvas = document.getElementById("myCanvas"); var context= myCanvas.getContext("2d"); context.beginPath(); context.moveTo(150, 50); co ...
-
Android和iOS開發都支持C++開發,可以一套代碼多平臺使用。同時C++難以反編譯的特性也可以為Android開髮帶來代碼的保密,另一native特性也可以提高代碼的運行效率。 一、為什麼使用C/C++ 1. 便於移植,用C/C++寫得庫可以方便在其他的平臺上再次使用。 2. 代碼的保護,由於 ...
-
本文主要是基於極光推送的SDK封裝的一個快速集成極光推送的類的封裝(不喜勿噴) (1)首先說一下推送的一些原理: Push的原理: Push 的工作機制可以簡單的概括為下圖 圖中,Provider是指某個iPhone軟體的Push伺服器,這篇文章我將使用.net作為Provider。 APNS 是A ...
-
UICollectionViewCell的設置間距 #pragma mark - UICollectionView 大小(寬高,平均一行三個) - (CGSize)collectionView:(UICollectionView *)collectionView layout:(UICollecti ...
-
1、首先,先在朋友圈中查看小視頻,點擊發送朋友,通過文件傳輸助手發送到電腦上, 2、打開電腦上的WeChat Files\微信名\video文件夾,裡面保存了你傳到電腦上的視頻和視頻截圖,將這兩個文件通過文件傳輸助手發送到手機上, 3、打開Tencent\MicroMsg目錄,再打開不規則命名、名稱 ...