Facebook App 優化工具 ReDex 優化的 6 點及未優化的一大方面
ReDex 是 Facebook 開源的工具，通過對字節碼進行優化，以減小 Android Apk 大小，同時提高 App 啓動速度。
GitHub：ReDex，官網主頁：fbredex.com
去年十月 Facebook 就寫過一篇文章《Optimizing Android bytecode with ReDex》對其進行介紹，終於在上週 ReDex 開源了。
Facebook 通過線上及線下測試，啓動速度提升 20% 以上，Dex 大小減小 25%，對於內存較小的機型啓動速度的優化效果尤其明顯。
一. 設計介紹
1. 基於 Dex 的優化
ReDex 是基於 Dex 文件的字節碼進行優化，從上圖 Android 編譯過程我們可以看出，Java 源文件經過 Java 編譯器轉換爲 .class 文件，再轉換爲虛擬機字節碼和三方庫一起轉換爲 dex 文件。
Dex 優化相比基於源碼或者 Java 字節碼的好處是：
(1) 可以最大限度的從全局以及類間進行優化；
(2) 可以類似於 C 在編譯最後的 Linking 階段做優化一樣進行優化。
PS：Proguard 就是基於 Java 字節碼的優化。
2. 基於管道的優化過程設計
ReDex 設計時將優化過程分爲不同階段，類似污水處理分爲機械處理-生物處理-深度處理等階段，每個階段可當做優化插件進行插拔(取捨)，並可以跟在其他不相關的階段後面，這樣的好處有：
(1) 方便多個優化階段並行開發；
(2) 方便後續添加新的優化階段以及開源接受更多的優化；
(3) 用戶可以通過配置方便的決定用哪些優化。
二. 6 個優化點介紹
ReDex 主要的優化在於減小 APK 大小以及提高啓動速度，分爲 6 大點：
1. 基於反饋(啓動加載順序測試)的 Class 字節碼佈局
類字節碼在單個 Dex 中的佈局是根據編譯順序而不是運行時行爲決定，即便 Multidex 會將 App 定義的組件以及部分啓動需要的類放在 Main Dex 中，但依然不是根據運行時順序佈局，這會導致程序啓動時需要查找隨機分佈在 Dex 中的類。
ReDex 會將 APK 在 Lab 中試運行，並跟蹤啓動時哪些類需要加載，然後將這些類字節碼放到 Dex 前部，減少啓動時從閃存中尋找類的時間，從而提高 App 啓動速度。
2. 混淆和壓縮
跟 JS 的壓縮以及 Android 的 Proguard 類似。
3. 內聯函數
將一些函數直接展開到調用它的函數中，減少函數調用切換的時間消耗。
4. 刪除無用的 interfaces
刪除只有一個實現的接口，用實現直接代替。一定程度加快函數調用時間，並減少內存空間以及函數引用。
5. 刪除無用代碼
通過類似早期內存回收的標記-刪除策略，刪除無用代碼。
6. 刪除 metadata
metadata 的一些數據在運行中並不需要，用 Dex 中已有的字符串代替源文件引用以及刪除無用的註解來減小 Dex 大小。
ReDex 自身的運行速度很快，雖然是針對 Dex 的優化，但接受 APK 參數，方便與已有編譯系統集成。
三. 注意事項
1. 對於不能刪除的代碼需要額外配置，如 JNI 調用、反射、(佈局文件中調用？)等特殊情況。
2. 簽名後的 APK ReDex 處理後需要重新簽名，因爲 Dex 文件已經發生變化。
3. 某些優化階段如混淆會影響堆棧輸出
雖然 ReDex 會有類似 Proguard 的 mapping 文件提供，但目前應該沒有什麼 Bug 收集平臺能對他進行支持，慎用。
四. 配置
1. 可通過 -c 指定具體的優化階段配置文件
redex -c oppass.config -o tmp/output.apk input.apk 其中 oppass.config 可類似於 ReDex 源碼下 config/default.config 文件，用於配置採用哪些優化階段。
2. 每個優化階段可以單獨做額外的配置
比如上面說的需要反射的類不能刪除，文件路徑縮略配置表，啓動時先後加載的類列表。
3. Proguard 文件列表
通常情況下，ReDex 會和 Proguard 一起對 APK 進行優化，並且運行在 Proguard 後，通過 Proguard 文件列表的配置 ReDex 就可正確識別混淆後的類。
五. 其他優化
從 Android 編譯過程圖中我們也可以看出，APK 包除了 Dex 文件外，還包含 Resource 部分，這部分可優化的空間也很大，下次分享相關資料。