Android應用瘦身

轉：https://zhuanlan.zhihu.com/p/25465537

瘦身的目的

從目的導向來看，咱們是不會平白無故去作一件事情的，那咱們對應用瘦身的目的是爲了什麼？答案是：提升下載轉化率。什麼是下載轉化率？舉個栗子：你的應用大小是 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，對此，我保持異議。理由以下：

• WebP 在 Android 端，最低只支持 4.0 ，要兼容 4.0 如下的環境須要額外引入兼容庫，反而增大安裝包體積；
• Android Studio 不支持預覽 WebP 圖片，引用 WebP 的佈局文件也沒法預覽顯示；
• 解壓了 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

實際開發中須要使用音頻文件儘可能採用 MP三、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：TinyPNG – Compress PNG images while preserving transparency ，支持對 PNG/JPEG 文件作壓縮處理，效果不錯。
• pngquant：pngquant - lossy PNG compressor ， 支持 PNG 壓縮，有時候 TinyPNG 處理過的圖片噪點會稍多，能夠考慮用 pngquant 來處理。
• ImageOptim：better Save for Web ，支持壓縮 PNG/JPEG/GIF ，並且效果顯著，能夠看看這裏 分享一個很是好用的免費 Mac 圖片無損壓縮工具 ImageOptim ，遺憾的是它只支持 Mac ，Windows 黨很難過。
• mozjpeg：ImageOptim online ， 用於 PNG 轉 JPEG、JPEG 壓縮，效果很好。
• Adobe Audition CC：Adobe Audition CC ，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 文件大小，從而達到瘦身目的。