開(kāi)篇語(yǔ)

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

瘦身的目的

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

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

安裝包的組成

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

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

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

資源瘦身

了解完 APK 的組成，我們可以開(kāi)始著手優(yōu)化的工作了，因?yàn)橘Y源文件在 APK 中的占比最高，所以?xún)?yōu)先從資源瘦身開(kāi)始著手。

盡量只保存一份圖片資源

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

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

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

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

使用 JPG 代替 PNG

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

謹(jǐn)慎使用 WebP 代替 PNG

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

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

有損編碼格式的音頻文件代替無(wú)損格式的音頻文件

從下面這篇官方文檔

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

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

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

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

移除無(wú)用的資源

這里的移除無(wú)用資源文件主要分為兩個(gè)部分：不打包沒(méi)有使用的資源和刪除沒(méi)有使用的資源。

• 不打包沒(méi)有使用的資源，在項(xiàng)目的 build.gradle 中配置 shrinkResources true 即可。 

• 刪除沒(méi)有使用的資源，通過(guò) Android Studio 選中項(xiàng)目右鍵 => Analyze => Run Inspection by Name => 輸入 Unused Resuroces 

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

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

工具

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

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

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

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

Native庫(kù)瘦身

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

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

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

代碼瘦身

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

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

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

結(jié)束語(yǔ)

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