專案背景：

更小的安裝包可以提升使用者轉化率，所以安裝包瘦身是很有必要的。

1：去除無用的語言資源

resConfigs “zh”

2：so庫相容

So（shared object，共享庫）是機器可以直接執行的二進位制程式碼，是Android上的動態連結庫，類似於Windows上的dll。每一個Android應用所支援的ABI是由其APK提供的.so檔案決定的，這些so檔案被打包在apk檔案的lib/目錄下。

So的常見的場景如：加解密演算法、音視訊編解碼、核心程式碼等。在生成SO檔案時，需要考慮適配市面上不同手機CPU架構，而生成支援不同平臺的SO檔案進行相容。目前Android共支援七種不同型別的CPU架構，分別是：ARMv5，ARMv7 (從2010年起)，x86 (從2011年起)，Mips (從2012年起)，ARMv8，Mips64和x86_64 (從2014年起)。

理論上對應CPU架構的So的執行效率是最高的，但是這樣會導致在libs目錄下放置各個架構平臺的So檔案，Apk檔案的大小自然也就更大了。那麼我們自然想到縮減Libs的目錄，一般情況（注意限定）下留下armeabi目錄即可，armeabi目錄下的So可以相容別的平臺的So，但是效能會有所損耗，失去對特定平臺的優化。

因此需要根據自己使用到的So功能來做具體的區分：對於效能敏感模組使用的So可以都放在armeabi目錄，然後通過程式碼判斷裝置的CPU型別，再載入其對應架構的SO檔案，例如微信就是這麼做的。既縮減了Apk的體積，也不影響效能敏感模組的執行。

移除特定平臺So的方式，這樣打包就只儲存armeabi裡的So。

ndk {
    //設定支援的SO庫架構
    abiFilters  'armeabi'
}

備註：
原本x86架構的CPU是不支援執行arm架構的So，但Intel和Google合作在x86機子的系統核心層之上加入了一個名為houdini的Binary Translator（二進位制轉換中間層），這個中間層會在執行期間動態的讀取arm指令並將之轉換為x86指令去執行。

3：png圖片轉webp

基本上，對於Android4.0的手機就有對WebP的 支援了，不過根據相關的資料顯示，對於Android 4.1才開始對WebP有了比較穩定的部分支援（即大多數只支援不含alpha通道的WebP圖片），Android 4.2才基本完全支援WebP。

Android4.2開始基本才完全支援WebP（4.0有些手機可能不支援，4.1可能不支援有alpha通道的WebP），而我們的應用本身最低支援的系統版本為4.1，怎麼辦？這裡採用了折中的方式，將可以去掉alpha通道的圖片進行WebP化，其他圖片儘量都進行一次壓縮。不過如果以後能將大部分甚至是全部圖片WebP化，估計應用大小會大大減小。

現在可以開始我們的裁包啦，由於專案中圖片資源過多，我們把目標鎖定在檔案大小大於30KB的圖片，對於小於30KB的則不管啦。

簡單的總結一下流程：
1. 通過APK Analyzer找出能WebP化的大圖

2. 將該圖片轉JPG，去掉alpha通道 //根據實際情況考慮哦

3. 將JPG轉WebP，並壓縮其餘PNG圖片

4. 最總要的一點，專案中沒用到的圖片趕緊刪掉啦啦啦


4：字型檔案剪裁

對ttf字型檔案壓縮，可以採用FontCreator工具只提取出你需要的文字。比如在做日期顯示時，其實只需要數字字型，但是使用原有的字型庫可能需要10MB大小，如果只是把你需要的字型提取出來生成的字型檔案只有10KB。

5：梳理依賴庫

去掉一些冗餘的依賴庫。或者去掉功能重複的依賴庫。

6：微信的資源混淆

7：facebook的redex方案

8：外掛化

資源離線+外掛化

9：蘑菇街的方案

參考資料：