技術|Android安裝包優化
版權宣告
1.本文版權歸原作者所有，轉載需註明作者資訊及原文出處。
2.本文作者：趙裕(vimerzhao),永久連結：https://github.com/vimerzhao/vimerzhao.github.io/blob/master/android/2020-02-11-apk-size-opt.md。
3.作者公眾號：V大師在一號線 。聯絡郵箱：[email protected]。
背景
安裝包膨脹的原因
業務的增加、產品的演進是安裝包大小增加的本質原因。但是在演進之路上，由於一些所謂的技術債務，如：
- 使用的資源未經裁剪（如全量字型檔案、解析度過大的圖片）
- 不合理的大資源（如大的視訊、音訊可以線上拉取）
- 已下線業務沒有及時清理相關程式碼、資源
- 等等
正是由於這些疏忽，安裝包有了不必要的增加，這也是我們需要優化的部分。
安裝包優化的價值
可能有的人覺得，現在基本是4G、WiFi的網路環境，手機裝置的效能和儲存空間也非常充足，所以使用者對安裝包大小應該不是十分敏感。但是，這其實是一種錯覺，更多的時候應該看自己的目標市場，如果是一二線城市當然沒問題，但如果是三四線城市、農村等下沉市場或者印度、巴西等海外市場，上述假設顯然不成立了。
一般來說，安裝包大小會影響以下指標：
- 下載轉化率
- 安裝成功率
- 推廣成本
- 執行記憶體、空間佔用
綜上，對於一個“有餘力”的團隊，安裝包大小的優化還是很有必要的。
安裝包優化的套路
由前面的原因可知，從業務層面來看，安裝包大小的優化是“解鈴還須繫鈴人”，即：
- 壓縮資源
- 大資源轉成線上拉取
- 排查無用業務並下線
這些方法都比較常規，更像是對症下藥，下面梳理一些技術上普適的方法，獨立於業務，在上面那些方法都嘗試後，還可以使安裝包大小“更下一層樓”。
安裝包的主要構成就是程式碼和資源，所以優化也是從這兩個方面著手。
程式碼
混淆
一般是通過ProGuard，但很多用不好，且存在管理問題。最後一看專案，很多類被Keep住了，也不知道歷史背景是啥。
Dex優化
- 通過工具移除行號資訊，帶來的問題是無法回溯Crash位置，但可以解決
- 多Dex時，通過重排Dex避免交叉索引，實現起來比較複雜
- Dex壓縮，把實際的Dex壓縮，首次啟動通過一個殼去載入，會影響啟動速度，但是可以解決，也比較複雜
so優化
so的優化手段和Java程式碼其實比較類似，核心還是通過機制化的手段去裁剪、壓縮。
資源
資源本身
- 通過工具掃描無用資源，有些由於專案自身原因，可能沒有顯式引用，但外接的編譯指令碼會修改專案自身指令碼，這就很坑了
- 資源格式的優化，如PNG轉JPG（除去alpha通道），轉webp格式等
- 字型檔案只保留使用的，資源自身的二次優化
資源索引
通過AndResGuard工具壓縮資源名稱，進而降低索引檔案的大小。
感悟
核心思想
- 刪除不用的（顯而易見）
- 壓縮/轉移有用的（如圖片、字型檔案，如大資源的轉移，混淆資訊的map表也是一種轉移）
- 精簡系統產生的（dex重排）
常規的手段很容易到達瓶頸，高深的手段又有複雜、相容性等諸多問題，但綜合來看，還是兩點：
- 深刻理解底層：apk編譯流程、dex格式、資源引用、啟動流程、載入流程原理等
- 深刻理解工具：ProGuard（很多人的ProGuard配置都是Copy修改），ReDex，AndResGuard等
權衡之道
很多時候，優化就是權衡，重要的是取捨：
- 壓縮了Dex，就增加了啟動速度
- 拿掉了行號，就增加了恢復Crash堆疊的難度
- 混淆了程式碼，就增加了編譯指令碼的複雜度
- 等等
根本出路
- 建立監控：團隊每年都會優化一次安裝包大小，尤其是刪除、壓縮資源的時候，總是一頭霧水，不明白這個資源引入的目的，也不敢輕舉妄動。最後有一套系統，讓增量時有記錄，讓下線時有提醒，及時解決，而不是每到年底還一次技術債。
- 制定標準：某種意義上上，安裝包大小的優化不是某個人的事情，而是團隊的事情，最好有相關的實踐指南或CodeReview標準。當有人不合理地引入資源，又或者業務下線後對無效邏輯置之不顧時，能有規則來約束這種行為。
參考
- Android安裝包精簡系列之為什麼要優化精簡安裝包 | 子勰的部落格
- Android安裝包相關知識彙總
- 如何優雅地將你的APK安裝包減少20% - 簡書
- 22 | 包體積優化（上）：如何減少安裝包大小？
- 23 | 包體積優化（下）：資源優化的進階實踐
以上
歡迎掃碼關注作者公眾號，及時獲取最新資訊。
