WebP局限性
在我的上一篇文章提到，讓大家謹慎使用WebP格式的圖片，并且提及到Android
Studio不支持預覽WebP圖片的問題，而最新的2.3版本已經支持預覽WebP文件，同時還能夠幫我們將JPG和PNG轉換成為WebP圖片，雖然IDE的升級讓我們喜出望外，但你仍然要關心WebP的一下幾個問題：
WebP的編碼時間為PNG的5倍以上，解碼速度與PNG差不多，甚至更快；
WebP編碼時占用內存比PNG高25%，解碼時比PNG低30%；
Android 4.0+開始支持WebP圖片，但是帶透明度的WebP圖片是在4.2.1+之后才支持的，在4.2.1之前則無法顯示；
針對以上一二點，你可能需要考慮一下自家用戶實際機型分布情況，如果大部分都是中低端配置機型，使用了WebP后對體驗可能會有所下降，對于高配設備，完全可以忽略。而針對第三點，則需要考慮用戶的系統分布，相信絕大部分App的用戶已經滿足4.0+這個條件，但對于滿足4.2.1+條件就很難說了，至少我們這款有幾百萬用戶的產品仍有不少用戶不滿足此條件，因此也不敢隨便提升最低兼容版本，但是你仍然可以進行一些WebP的處理，主要如下：
對于不需要透明度的PNG圖片，先轉成JPG格式后，再使用IDE進行WebP轉換。不要直接用PNG轉換成WebP，否則轉換后的WebP仍然帶了透明度，在4.2.1之前的設備任然無法顯示，先轉換成JPG就是為了去除PNG的透明度；
將PNG轉換成JPG時，建議采用專業的圖片處理工具，因為我在使用一些在線轉換工具轉換成為JPG時，發現有少量的圖片轉換成JPG后再轉成WebP時在4.2.1之前依然無法正常顯示，但經過專業的處理的圖片處理工具轉換后的圖片則全部沒有問題；
在將JPG轉換成WebP圖片時，采用IDE默認75的有損壓縮質量，超過75之后，壓縮效果反而會變差；
雖然IDE給了我們WebP更方便的支持，但實際上受限于Android系統版本的問題，所以，我們只能對有限的圖片做處理，對于項目中有大量留白的透明像素的圖片，轉換成JPG效果會失真，所以，也只能暫時忽略掉。最后，推薦一個騰訊出品的WebP在線工具——智圖：https://zhitu.isux.us/。關于WebP的知識，我非常建議大家閱讀以下兩篇騰訊出品的文章，你會收獲很多
shrinkResources誤區
網上很多文章都說在build.gradle中開啟shrinkResources true的設置，這樣可以在打包過程中工具鏈會自動幫你移除相應一些無用的資源。
而實際上shrinkResource只能幫你壓縮合并資源，并不能幫你移除資源文件，讀者可以自行拷貝一些無用的資源文件放到工程中打包驗證，你會發這些文件將會原封不動的打進你的安裝包中。不過，從另一個角度去想，可能是因為我們拷貝資源到工程中時，IDE會幫我們在R.java文件中生成對應的資源ID信息，所以即使沒有顯式的在代碼中引用資源，但是自動生成信息的R類卻一直引用著。依靠配置shrinkResources true移除資源的目的無法達到，我們只能通過IDE的Remove Unused Resources功能篩選出工程中對應無用的資源
不過，建議大家使用它時選擇Preview模式，不要直接使用Refactor模式
因為代碼中引用方式不同，所以存在代碼中使用了某個資源，但是依然被當成沒有引用的情況，例如通過使用getIdentifier、Uri等方式。
resConfigs
Google在官方文檔提到，可以通過限制語言資源來壓縮包大小，但實際操作上，由于我們的應用原本就只支持中英文，所以實踐之后收效甚微，這里簡單提及一下。
SO壓縮
按照動態加載的思想，我們對項目中很多音視頻處理的SO文件進行了7zip極限壓縮，等到用戶升級安裝應用時，才動態解壓出SO文件進行加載調用（解壓耗時在我們最差的機型上只用了2.8s）。如果你的項目中有也存在大量自己開發的SO文件，可以考慮用這種方案進行優化，成效會很明顯。更有甚者，對于不常用的功能需要用到的SO文件，我們可以考慮從網絡中下載完成后再動態加載進來，這將更進一步的縮減了你安裝包的大小。
源碼梳理
我在上一篇文章中提到，對源代碼進行梳理建議，不少同學給我留言，基本都是認為源碼精簡對應用的瘦身作用非常有限。實際上，這并不能一概而論，得看具體的項目情況而言，這里就分享一下我在項目中實際操作好了。
合并網絡請求管理，移除原有的android-async-http、Volley，僅保留OkHttp；
合并圖片加載管理，移除原有的其他加載管理方案，僅保留Fresco；
合并整理功能重復的一些自定義控件；
移除歷史悠久已經廢棄的功能模塊代碼；
裁剪Fresco，例如不需要加載gif，WebP等可以把相應的功能模塊移除，不需要用OkHttp來管理Fresco的網絡加載可以移除（實際上移除后發現反倒少了一些Fresco加載圖片效果出問題的一些BUG，意料之外的收獲）；
移除一個開源的JSON解析庫com.fasterxml.jackson.core:jackson，這貨整整8000多個方法，移除后包直接小了200多K；
移除Google Zxing庫；
提取Android 4.2.2系統源碼中的一個漢字轉拼音的類，替換原有項目中的實現方案以及其帶進來的一個200多k的附屬文件；
當然有些功能比較復雜又加上年代久遠，所以梳理還是需要小心謹慎，最好能對一個功能模塊了解全面了再進行整理。在整理完源碼之后，再清理一波無用的資源，又可以節省不少空間。最后，推薦大家一個計算項目編譯后的方法數的Gradle插件
https://github.com/KeepSafe/dexcount-gradle-plugin/
使用它你可以看到每次改進后效果，也可以用它分析出包中含有較多方法的包是哪一個，是否有必要進行排查優化等等。在debug編譯的時候注意要開啟混淆，這樣可以看到實際混淆優化后的效果，因為混淆優化后，會有不少沒用的方法被優化移除，但對于引用的第三方類庫以及一些混淆規則中keep住的類則原封不動。
插件化
插件化同樣是一個不錯的優化方案，同樣利用動態加載的原理，不過這又屬于另一話題了，此處就不鋪開詳述了。
AndResGuard
https://github.com/shwenzhang/AndResGuard/
來自微信的資源混淆優化方案，同樣也是利用了7zip極限壓縮，具體原理可以詳細查看項目說明，一些需要注意問題均有詳細說明。比較值得注意的有以下幾點：
項目對于資源文件的名字做了混淆優化，所以一些第三方SDK以及項目中使用getIdentifier、Uri等方式加載資源，需要將對應的資源加入到白名單中，否則會出現閃退；
部分手機桌面快捷圖標的實現有問題，務必將程序桌面icon加入白名單；
通過修改zip摘要的方式生產渠道包，出渠道包時，解壓重壓縮會破壞7zip的效果，通過repackage命令可用7zip重壓縮；
實際操作中，我們使用此方案后包只少了大約200K，而且還伴隨著一些潛在風險，所以并沒有引入使用，其他同學可以實踐對比下，再評估是否要使用。
Redex
https://github.com/facebook/redex
Facebook出品的字節碼優化方案，其原理是優化打包過程中Java字節碼文件，和Proguard的原理一樣。針對此方案的優略之處，大家可以看看Trinea的文章：Facebook App優化工具ReDex優化的6點及未優化的一大方面。在實際操作中，使用此方案后包同樣也只少了大約200K，并且翻看了Github上的Issue還存在一些莫名其妙的閃退問題后，最終沒有考慮引入此方案。
總結
好了，本篇關于Android應用瘦身的文章到這里就結束了，整個實踐的過程有頗多的細節需要注意，避免瘦身后又給自己挖了一個大坑。盡量每做一個小模塊的改動，就生成一個commit，這樣發現問題后可以方便定位回滾。很多同學在我上篇文章中討論，關于這樣的瘦身是否有意義，對于我們的產品來說，經常有很多線下運營活動需要人們現場下載，這樣的瘦身對線下活動提高轉化率還是非常有用的。
