開篇語

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

瘦身的目的

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

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

安裝包的組成

要對安裝包做瘦身，首先需要了解安裝包的組成結(jié)構(gòu)，這里簡單的梳理了一下組成各個部分及其作用： 

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

在 Android Studio 2.2.3 開始，就加入了瀏覽 APK 結(jié)構(gòu)的功能，我們直接把安裝包拖入 IDE ，就可以直接瀏覽其組成和對應(yīng)大小，這樣能夠很方便的對比分析出每一步優(yōu)化后的結(jié)果。 

資源瘦身

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

盡量只保存一份圖片資源

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

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

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

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

使用 JPG 代替 PNG

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

謹慎使用 WebP 代替 PNG

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

• WebP 在 Android 端，最低只支持 4.0 ，要兼容 4.0 以下的環(huán)境需要額外引入兼容庫，反而增大安裝包體積;
• Android Studio 不支持預(yù)覽 WebP 圖片，引用 WebP 的布局文件也無法預(yù)覽顯示;
• 解壓了 BAT 們的應(yīng)用，以及同類競品，基本沒有發(fā)現(xiàn)在資源文件中用 WebP 的;

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

從下面這篇官方文檔

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

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

• 無損格式：WAV，PCM，ALS，ALAC，TAK，F(xiàn)LAC，APE，WavPack(WV)
• 有損格式：MP3，AAC，WMA，Ogg Vorbis

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

移除無用的資源

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

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

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

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

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

工具

上一章節(jié)提到的是優(yōu)化的思路，本章節(jié)整理在優(yōu)化過程中使用到的工具。

• 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 轉(zhuǎn) JPEG、JPEG 壓縮，效果很好。
• Adobe Audition CC：http://www.adobe.com/cn/products/audition.html ，Adobe 出品，支持對音頻的采樣率，分辨率和聲道數(shù)目做更改，以此達到裁剪音頻的目的(采樣率，分辨率和聲道數(shù)目是音頻文件格式的關(guān)鍵參數(shù)，決定著音頻文件的大小)。

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

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

Native庫瘦身

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

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

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

代碼瘦身

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

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

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

結(jié)束語

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