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 部分，這部分可優化的空間也很大。
本站文章版權歸原作者及原出處所有 。內容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網站上部分文章為轉載，并不用于任何商業目的，我們已經盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯系我們，我們將根據著作權人的要求，立即更正或者刪除有關內容。本站擁有對此聲明的最終解釋權。
