Android 應用瘦身實踐，從 18MB 到 12.5MB

開篇語

前陣子老大交給了我一個任務，主要是幫我們開發的直播應用做 Android 端的安裝包瘦身，花了大概一周的時間把安裝包從 18MB 減小到了 12.5MB。原本完全可以優化到 10MB 之下，但由於其他原因的限制，所以目前階段只到 12.5MB 為止。在此記錄一下優化的思路和用到的工具，方便自己以後 Review ，有需要的童鞋也可供參考。

瘦身的目的

從目的導向來看，我們是不會無緣無故去做一件事情的，那我們對應用瘦身的目的是為了什麼？答案是：提高下載轉化率。什麼是下載轉化率？舉個栗子：你的應用大小是 18MB ，有100個潛在用戶想要去下載嘗試使用，結果有20個用戶嫌棄安裝包太大直接揚長而去，有20個用戶在等待下載的過程中取消下載，最終只有60個用戶真正下載安裝，那麼應用的下載轉化率就是 60/100 = 60% 。

簡單的小結便是：安裝包越小，用戶下載等待的時間越短，對手機存儲配置小的設備體驗愈佳，應用的下載轉化率也就越高。記得以前在騰訊大講堂聽微信大牛說過，微信第一個版本只有差不多 400KB ，瞬間膜拜。

安裝包的組成

要對安裝包做瘦身，首先需要了解安裝包的組成結構，這裡簡單的梳理了一下組成各個部分及其作用：

其中，在安裝包中占比較大的包括：dex文件、res文件夾、assets文件夾、lib文件夾以及resource.arsc文件。所以，接下來的瘦身優化就是讓這些文件變小，以此達到瘦身的目的。

在 Android Studio 2.2.3 開始，就加入了浏覽 APK 結構的功能，我們直接把安裝包拖入 IDE ，就可以直接浏覽其組成和對應大小，這樣能夠很方便的對比分析出每一步優化後的結果。

資源瘦身

了解完 APK 的組成，我們可以開始著手優化的工作了，因為資源文件在 APK 中的占比最高，所以優先從資源瘦身開始著手。

盡量只保存一份圖片資源

開發目錄下會有個 drawable 或者 mipmap 目錄用於適配不同 dpi 的屏幕，下面是不同命名目錄所適配的 dpi 范圍

目前市面上絕大部分機型都處於 xxhdpi 的適配范圍，所以可以考慮只保留 xxhdpi 目錄下一份圖片資源，具體保留哪個目錄下的資源和保留幾份資源還得依照應用自身的實際機型分布決定。

使用 Drawable XML、Color、.9 PNG 代替 PNG

• 一些情況下，我們可以考慮使用 Drawable XML 來代替 PNG，如：漸變的背景圖，用幾行 XML 就可以描繪出來，何必使用幾十到上百K的 PNG 文件；
• 用 Color 代替 PNG，如：純色的背景；
• 從性能上看，比起使用圖片資源需要先將其生成 Bitmap 再傳到底層交由 GPU 渲染，用 Drawable XML 和 Color 則更加高效，它是直接將 Shape 信息傳到底層由 GPU 進行渲染，CPU 和 內存的占用會更少；
• 用 .9 PNG 代替 PNG，場景很多，不舉例了；

使用 JPG 代替 PNG

用 JPG 代替 PNG，由於 JPG 沒有 Alpha 通道，所以文件更小，適用於不需要透明度的圖片可以考慮。

謹慎使用 WebP 代替 PNG

由於 WebP 效果好，且相同效果下， WebP 文件比 PNG 文件要小得多 ，所以，網上很多人說使用 WebP 代替 PNG，對此，我保持異議。理由如下：

1. WebP 在 Android 端，最低只支持 4.0 ，要兼容 4.0 以下的環境需要額外引入兼容庫，反而增大安裝包體積；
2. Android Studio 不支持預覽 WebP 圖片，引用 WebP 的布局文件也無法預覽顯示；
3. 解壓了 BAT 們的應用，以及同類競品，基本沒有發現在資源文件中用 WebP 的；

有損編碼格式的音頻文件代替無損格式的音頻文件

從下面這篇官方文檔

https://developer.android.com/guide/topics/media/media-formats.html

可以看到 Android 平台支持的音視頻格式，下面列出有損和無損常用的格式（不要認為有損編碼就是音質很差）：

• 無損格式：WAV，PCM，ALS，ALAC，TAK，FLAC，APE，WavPack(WV)
• 有損格式：MP3，AAC，WMA，Ogg Vorbis

實際開發中需要使用音頻文件盡量采用 MP3、Ogg 這種有損格式，盡量不要用 WAV、PCM 這種無損音頻。

移除無用的資源

這裡的移除無用資源文件主要分為兩個部分：不打包沒有使用的資源和刪除沒有使用的資源。

不打包沒有使用的資源，在項目的 build.gradle 中配置 shrinkResources true 即可。

刪除沒有使用的資源，通過 Android Studio 選中項目右鍵 => Analyze => Run Inspection by Name => 輸入 Unused Resuroces

即可看到所有未使用的資源文件，建議定期清理掉這些沒用的文件，一方面可以減小工程的大小，另一方面太多的資源文件會導致打包後 resources.arsc 文件變得越來越大，公司有一項目 resources.arsc 文件已經達到 2-3 MB 的程度，有點驚人。

綜合以上幾點，就可以有效的精簡我們安裝包中的res文件夾、assets文件夾、resource.arsc文件大小，從而達到瘦身目的。

工具

上一章節提到的是優化的思路，本章節整理在優化過程中使用到的工具。

• TinyPNG：https://tinypng.com/ ，支持對 PNG/JPEG 文件做壓縮處理，效果不錯。
• pngquant：https://pngquant.org/ ， 支持 PNG 壓縮，有時候 TinyPNG 處理過的圖片噪點會稍多，可以考慮用 pngquant 來處理。
• ImageOptim：https://imageoptim.com/mac ，支持壓縮 PNG/JPEG/GIF ，而且效果顯著，可以看看這裡 https://www.diycode.cc/topics/496 ，遺憾的是它只支持 Mac ，Windows 黨很難過。
• mozjpeg：https://imageoptim.com/mozjpeg ， 用於 PNG 轉 JPEG、JPEG 壓縮，效果很好。
• Adobe Audition CC：http://www.adobe.com/cn/products/audition.html ，Adobe 出品，支持對音頻的采樣率，分辨率和聲道數目做更改，以此達到裁剪音頻的目的（采樣率，分辨率和聲道數目是音頻文件格式的關鍵參數，決定著音頻文件的大小）。

以上是我優化過程中用到的覺得不錯的工具，有更好的推薦，歡迎補充。

另外，在對圖片做壓縮的時候，不要貪圖方便直接將整個資源目錄下的圖片一次性壓縮一趟。很多時候，前面做這個項目的人可能已經對一些資源文件做過壓縮處理，很容易導致二次壓縮而引起一些圖片失真。這裡我建議是，去到應用的資源目錄下將資源文件從大到小排序，定一個標准，如超過 20KB 的圖片要做壓縮處理，則將這些符合條件的圖片 Copy 一份出來做壓縮處理，處理後確保沒出現失真的情況下再替換對應優化前的圖片資源。 音頻文件的處理，同理。

Native庫瘦身

Native 庫瘦身主要是減小對 CPU 架構的支持，配置起來很簡單，在 build.gradle 使用 abiFilters 配置需要用到的 CPU 架構，並將不需要兼容的 so 文件從項目中移除即可。

根據我們用戶的機型分布，最終只保留了對 armeabi-v7a 支持。注意，這裡需要根據自家產品的實際情況來決定。由於之前對 CPU 的架構分布不是很熟悉，感謝微信的張紹文、滬江的徐宜生以及虎牙的鄭曉濱幾位老司機給我科普了一發。

綜上所述，就可以有效的精簡我們安裝包中的 lib 文件夾大小，從而達到瘦身目的。也有一種做法是通過在 build.gradle 配置 include 來針對每個 CPU 架構生成單獨的安裝包，雖然看起來很不錯，但是很多國內應用市場上架的時候並不支持這種每個 CPU 配置一個包的做法，所以此做法較為雞肋，不太建議去做，如果應用只上 Google Play ，那確實要比配置 abiFilters 好得多。

代碼瘦身

這裡可以做的事情也是很多，主要如下：

• 移除廢棄功能的代碼，反正有 VCS ，刪了代碼隨時可以找回；
• 移除重復的代碼，如：已經有了的功能代碼，團隊成員不知道自己又寫了一套，只能靠代碼 Review 解決了；
• 移除功能重疊的框架，如：項目中有幾套網絡訪問框架 Volley、AsyncHttpClient、Retrofit 等，同樣只能靠代碼 Review 解決；
• 移除無用的 dependencies 或者 jar 包；
• 減小對 Support 兼容包的依賴，Support-V4 包非常大，項目引入無疑會增大 dex 文件的大小，Google 已經意識到這個問題，所以 Support-V7 一開始就做了拆分，並且開始對 Support-V4 做拆分，雖然目前成果還不明顯，不過還是蠻值得期待的，特別是發現你少了 Support-V4 包後，可能就從2個 dex 變成1個 dex 了呢；
• 插件化，一種懶加載思想的體現，先讓用戶能夠安裝宿主包，對於一些功能模塊做插件化，在特定的時機再下載安裝；

綜上所述，就可以有效的精簡我們安裝包中的 dex 文件大小，從而達到瘦身目的。

結束語

整個優化過程我把項目從 18 MB 優化到了 12.5 MB，以上有些優化點受其他一些原因的影響，只能暫時作罷，可以考慮納入下一次的優化排期。套路大概就是這麼些，實踐的時候請根據自身項目定奪，並優先優化性價比較高的部分（性價比=可優大小/所需時間）。