Hello，大家好链患，我是Clock巧鸭。這是我春節(jié)前的最后一篇技術(shù)分享文章了，在這里提前預(yù)祝大家雞年萬事如意麻捻，身體健康纲仍，新年升職加薪。
開篇語
前陣子老大交給了我一個任務(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)化就是讓這些文件變小仅财，以此達(dá)到瘦身的目的。
在 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 進(jìn)行渲染怨规，CPU 和 內(nèi)存的占用會更少；
- 用 .9 PNG 代替 PNG锡足，場景很多波丰，不舉例了；
使用 JPG 代替 PNG
用 JPG 代替 PNG舶得，由于 JPG 沒有 Alpha 通道掰烟，所以文件更小，適用于不需要透明度的圖片可以考慮。
謹(jǐn)慎使用 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 平臺支持的音視頻格式劣针，下面列出有損和無損常用的格式（不要認(rèn)為有損編碼就是音質(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)達(dá)到 2-3 MB 的程度，有點驚人售葡。
綜合以上幾點看杭，就可以有效的精簡我們安裝包中的res文件夾、assets文件夾挟伙、resource.arsc文件大小楼雹，從而達(dá)到瘦身目的。
工具
上一章節(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ù)目做更改，以此達(dá)到裁剪音頻的目的（采樣率籍凝，分辨率和聲道數(shù)目是音頻文件格式的關(guān)鍵參數(shù)周瞎，決定著音頻文件的大小）饵蒂。
以上是我優(yōu)化過程中用到的覺得不錯的工具声诸，有更好的推薦，歡迎補充苹享。
另外双絮，在對圖片做壓縮的時候浴麻，不要貪圖方便直接將整個資源目錄下的圖片一次性壓縮一趟。很多時候囤攀，前面做這個項目的人可能已經(jīng)對一些資源文件做過壓縮處理软免，很容易導(dǎo)致二次壓縮而引起一些圖片失真。這里我建議是焚挠，去到應(yīng)用的資源目錄下將資源文件從大到小排序膏萧，定一個標(biāo)準(zhǔn)，如超過 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 文件夾大小，從而達(dá)到瘦身目的跪另。也有一種做法是通過在 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 文件大小，從而達(dá)到瘦身目的击喂。
結(jié)束語
整個優(yōu)化過程我把項目從 18 MB 優(yōu)化到了 12.5 MB维苔，以上有些優(yōu)化點受其他一些原因的影響，只能暫時作罷懂昂，可以考慮納入下一次的優(yōu)化排期介时。套路大概就是這么些，實踐的時候請根據(jù)自身項目定奪凌彬，并優(yōu)先優(yōu)化性價比較高的部分（性價比=可優(yōu)大小/所需時間）沸柔。
- 我的個人博客：http://blog.coderclock.com/
- 我的知乎專欄：https://zhuanlan.zhihu.com/coderclock
- 我的Diycode：https://www.diycode.cc/d_clock
- 我的新浪微博：D_clock愛吃蔥花
- 我的微信公眾號：技術(shù)視界
