Facebook 通過線上及線下測試,啟動速度提升 20% 以上,Dex 大小減小 25%,對于內存較小的機型啟動速度的優化效果尤其明顯。

ReDex 是基于 Dex 文件的字節碼進行優化,從上圖 Android 編譯過程我們可以看出,Java 源文件經過 Java 編譯器轉換為 .class 文件,再轉換為虛擬機字節碼和三方庫一起轉換為 dex 文件。
Dex 優化相比基于源碼或者 Java 字節碼的好處是:
(1) 可以大限度的從全局以及類間進行優化;
(2) 可以類似于 C 在編譯后的 Linking 階段做優化一樣進行優化。
PS:Proguard 就是基于 Java 字節碼的優化。

ReDex 設計時將優化過程分為不同階段,類似污水處理分為機械處理-生物處理-深度處理等階段,每個階段可當做優化插件進行插拔(取舍),并可以跟在其他不相關的階段后面,這樣的好處有:
(1) 方便多個優化階段并行開發;
(2) 方便后續添加新的優化階段以及開源接受更多的優化;
(3) 用戶可以通過配置方便的決定用哪些優化。
ReDex 主要的優化在于減小 APK 大小以及提高啟動速度,分為 6 大點:
類字節碼在單個 Dex 中的布局是根據編譯順序而不是運行時行為決定,即便 Multidex 會將 App 定義的組件以及部分啟動需要的類放在 Main Dex 中,但依然不是根據運行時順序布局,這會導致程序啟動時需要查找隨機分布在 Dex 中的類。
ReDex 會將 APK 在 Lab 中試運行,并跟蹤啟動時哪些類需要加載,然后將這些類字節碼放到 Dex 前部,減少啟動時從閃存中尋找類的時間,從而提高 App 啟動速度。
跟 JS 的壓縮以及 Android 的 Proguard 類似。
將一些函數直接展開到調用它的函數中,減少函數調用切換的時間消耗。
刪除只有一個實現的接口,用實現直接代替。一定程度加快函數調用時間,并減少內存空間以及函數引用。
通過類似早期內存回收的標記-刪除策略,刪除無用代碼。
metadata 的一些數據在運行中并不需要,用 Dex 中已有的字符串代替源文件引用以及刪除無用的注解來減小 Dex 大小。
ReDex 自身的運行速度很快,雖然是針對 Dex 的優化,但接受 APK 參數,方便與已有編譯系統集成。
雖然 ReDex 會有類似 Proguard 的 mapping 文件提供,但目前應該沒有什么 Bug 收集平臺能對他進行支持,慎用。
redex -c oppass.config -o tmp/output.apk input.apk 其中 oppass.config 可類似于 ReDex 源碼下 config/default.config 文件,用于配置采用哪些優化階段。
比如上面說的需要反射的類不能刪除,文件路徑縮略配置表,啟動時先后加載的類列表。
通常情況下,ReDex 會和 Proguard 一起對 APK 進行優化,并且運行在 Proguard 后,通過 Proguard 文件列表的配置 ReDex 就可正確識別混淆后的類。
從 Android 編譯過程圖中我們也可以看出,APK 包除了 Dex 文件外,還包含 Resource 部分,這部分可優化的空間也很大。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點, 并不代表本站贊同其觀點和對其真實性負責,本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺,網站上部分文章為轉載,并不用于任何商業目的,我們已經盡可能的對作者和來源進行了通告,但是能力有限或疏忽,造成漏登,請及時聯系我們,我們將根據著作權人的要求,立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。