版權聲明
1.本文版權歸原作者所有，轉載需注明作者信息及原文出處。
2.本文作者：趙裕(vimerzhao),永久鏈接：https://github.com/vimerzhao/vimerzhao.github.io/blob/master/android/2020-02-11-apk-size-opt.md。
3.作者公眾號：V大師在一號線 。聯系郵箱：vimerzhao@foxmail.com。
背景
安裝包膨脹的原因
業務的增加、產品的演進是安裝包大小增加的本質原因。但是在演進之路上，由於一些所謂的技術債務，如：
- 使用的資源未經裁剪（如全量字體文件、分辨率過大的圖片）
- 不合理的大資源（如大的視頻、音頻可以在線拉取）
- 已下線業務沒有及時清理相關代碼、資源
- 等等
正是由於這些疏忽，安裝包有了不必要的增加，這也是我們需要優化的部分。
安裝包優化的價值
可能有的人覺得，現在基本是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 | 包體積優化（下）：資源優化的進階實踐
以上
歡迎掃碼關注作者公眾號，及時獲取最新信息。
