技術|Android安裝包優化

版權聲明

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優化

1. 經過工具移除行號信息，帶來的問題是沒法回溯Crash位置，但能夠解決
2. 多Dex時，經過重排Dex避免交叉索引，實現起來比較複雜
3. 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 | 包體積優化（下）：資源優化的進階實踐

以上

---

歡迎掃碼關注做者公衆號，及時獲取最新信息。