Android效能優化（十）之App瘦身攻略

1、 前言

如果你對App優化比較敏感，那麼Apk安裝包的大小就一定不會忽視。關於瘦身的原因，大概有以下幾個方面：

• 對於使用者來說，在功能差別不大的前提下，更小的Apk大小意味更少的流量消耗，也意味著更多的使用者下載；
• 對於產品來說，大於競品的Apk意味著較低的下載基數，不利於驗證產品策略；
• 對於開發人員來說，App瘦身則是一次技術優化、技術提升的機會；

2、 Apk的組成

2.1 Apk典型組成

下表為Apk目錄及檔案說明：

檔案/目錄	說明
assets/	存放一些靜態檔案，可以通過AssertManager訪問
lib/	如果該目錄存在，一般存放的是NDK編譯出來的so
META-INF/	儲存著APK的簽名資訊
res/	資原始檔所在目錄，包含drawable、layout等
AndroidManifest.xml	程式全域性配置檔案
classes.dex	Java Class，被DEX編譯後可供Dalvik/ART虛擬機器所理解的檔案格式
resources.arsc	編譯後生成的二進位制資原始檔

2.2 示例分析

做App瘦身之前需要對自己App現有組成有一個清晰的認識，上述解壓的方式只能粗略的看出具體目錄的大小，但是有用資訊仍然有限。

2.2.1 Android Studio Analyze APK

Android Studio 2.2之後有一個功能Analyze APK，方便簡單，功能還是Google自帶的靠譜；

• 檢視apk中任意檔案的大小，得到一個直觀的認識；
• 瞭解Dex檔案的組成，檢視使用那些開源庫等；
• 檢視二進位制檔案（如AndroidMainfest.xml等）；
• Apk的比較，便於發現兩個版本之間的區別。

2.2.2 反編譯工具ClassyShark

ClassShark 是一款檢視Android執行檔案（apk）的瀏覽工具，可以很方便的開啟APK/Class/Jar/res等檔案和分析裡面的內容。

2.2.3 Nimbledroid

NimbleDroid 是美國哥倫比亞大學的博士創業團隊研發出來的分析Android app效能指標的系統，分析的方式有靜態和動態兩種方式，其中靜態分析可以分析出APK安裝包中大檔案排行榜，各種知名SDK的大小以及佔程式碼整體的比例，各種型別檔案的大小以及佔排行，各種知名SDK的方法數以及佔所有dex中方法數的比例。

總結：這三種方式都可以對Apk的組成有一個更加清晰的認識，但更加推薦使用AndroidStudio自帶的Analyze APK，簡單、高效。

使用Analyze APK檢視到檔案大小之後發現，classes.dex、res、assets、lib等檔案較大，哪裡的脂肪多，我們就去抽哪裡。確定優化方向：

1. 程式碼部分：冗餘程式碼、無用功能、程式碼混淆、方法數縮減等；
2. 資源部分：冗餘資源、資源混淆、圖片處理等；
3. 對So檔案的處理等。

3、 Apk瘦身之程式碼瘦身

3.1 移除無用程式碼、功能

隨著版本的迭代，部分功能可能已被去掉，但是其程式碼還存在專案中。移除無用程式碼以及無用功能，有助於減少程式碼量，直接體現就是Dex的體積會變小。

備註：根據經驗，不用的程式碼在專案中存在屬於一個普遍現象，相當於殭屍程式碼，而且這類程式碼過多也會導致Dex檔案過大。

3.2 移除無用的庫、避免功能雷同的庫

3.2.1 專案中基礎功能的庫要統一實現，避免出現多套網路請求、圖片載入器等實現。

3.2.2 不用的庫要及時移除出專案，例如我們之前確定要由某推送切換到某推送的時候，此時就要把最初專案中的推送庫去掉，而不應該只是註釋掉其註冊程式碼。

3.2.3 一些功能可以曲線救國的話就不要引入SDK，例如定位功能，可以不引入定位SDK，而通過拿到經緯度然後呼叫相關介面來實現；同樣實現了功能而沒有引入SDK。

3.2.4 而引入SDK也需要考慮其方法數,可以使用ClassyShark、Nimbledroid或者APK method count等工具檢視。

備註：根據經驗，專案中存在之前使用之後不使用的庫的情況並不罕見。

3.3 啟用Proguard

程式碼混淆也稱為花指令，是將計算機程式的程式碼轉換為功能上等價但是難以閱讀、理解的行為。Proguard是一個免費的Java類檔案壓縮、優化、混淆、預先驗證的工具，可以檢測和移除未使用的類、欄位、方法、屬性，優化位元組碼並移除未使用的指令，並將程式碼中的類、欄位、方法的名字改為簡短、無意義的名字。

可以看出Proguard不僅能將diamante中的各種元素改的簡短，還可以移除冗餘程式碼，因此可以減少Dex檔案的大小。

android {
    buildTypes {
        release {
            minifyEnabled true
            proguardFiles getDefaultProguardFile(‘proguard-android.txt'),
                    'proguard-rules.pro'
        }
    }
    ...
}複製程式碼

其中，proguard-android.txt是獲取預設ProGuard設定，proguard-rules.pro檔案用於新增自定義ProGuard規則。

備註：對於Proguard，雖然效果很明顯，但仍然需要謹慎；

• 程式碼混淆會拖慢專案構建速度，因此debug模式下關掉Proguard不至於RD在執行程式碼的時候抓狂；
• 因為在debug模式下關掉了Proguard，如果混淆規則沒有配置好，在Release模式可能會出現debug模式下不出現的Bug；
• Proguard也不是你想搞就能搞，如果App做了一段時間之後再來做Proguard，專案包結構不規範的話，那Proguard的規則將會非常多。而短時間內調整包結構也是一件相當痛苦的事情。

3.4 縮減方法數

一般情況下縮減方法數，都是為了Android著名的64k方法數問題，此處不再回顧，參見之前《關於Multidex的系列文章》。而這裡說縮減方法數的目的，是為了App瘦身。

通過《Dalvik Executable format》，我們可以看到Dex檔案的組成。而從header-item表中的method-ids-size欄位可以看出，方法數縮減之後，可以減少方法列表的大小；同時，方法在Dex檔案中的佔用空間也減少了，App自然被瘦身。

而縮減方法數，除了上面寫到的普遍方法：移除無用方法、庫、使用較小的SDK之外還有：

1. 避免在內部類中訪問外部類的私有方法、變數。擋在Java內部類（包含匿名內部類）中訪問外部類的私有方法、變數的時候，編譯器會生成額外的方法，會增加方法數；
2. 避免呼叫派生類中的未被覆寫的方法，避免在派生類中呼叫未覆寫的基類的方法；避免用派生類的物件呼叫派生類中未覆蓋的基類的方法。呼叫派生類中的未被覆蓋的方法時，會多產生一個方法數；
3. 去掉部分類的get、set方法；當然這樣會犧牲一些物件導向的觀念。

4、 Apk瘦身之資源瘦身

對於重要性，程式碼和資源的瘦身同樣重要，但是從效果上來說，資原始檔的瘦身效果比程式碼的瘦身效果要好非常多。很有可能費力許久在程式碼上得到的瘦身效果，在資原始檔瘦身中輕鬆就得到了。

4.1 移除無用的資原始檔

移除無用資原始檔要比移除無用程式碼容易，在Android Studio的任何檔案中右擊，選擇清除無用資源即可刪除沒有用到的資原始檔。

備註：在build.gradle中設定shrinkResources為true後，每次打包的時候就會自動排除無用的資源。shrinkResources需要配合minifyEnabled一起使用。但是根據我的實驗：無用的資源還是會被打進Apk中，只是變成一張黑圖，體積也非常小，只有不到100b。有使用錯誤的地方歡迎指正！

4.2 Drawable目錄只保留一份資源

這條開發者中討論的比較多，確實Google強烈建議根據不同螢幕密度準備多套切圖資源來做適配的。但是鑑於Android上對UI要求不會是最頂級的那種高度，以及即便是放在合適（注意這兩個字）一個的目錄下，在不同的解析度下也會做自動的適配（等比例拉伸、縮放）；因此還是建議：對UI不是最頂級要求的話根據自己的使用者群體機型放在一個合適的目錄下。這樣毋庸置疑可以縮減Res的大小，進而減少Apk的體積。

備註：圖片放在不恰當的目錄有可能會對記憶體產生較大的影響，可以參考之前的文章《Android 效能優化（五）之細說 Bitmap》。

4.3 對圖片進行壓縮

之前我在專案裡發現過檔案大小過1M的圖片，可能是由於UI同學和RD同學的雙重疏忽，導致如此大的圖片到了專案中，對Apk體積的影響自然不言而喻。

可以考慮使用TinyPng、pngquant、ImageOptim等工具對圖片進行壓縮，這些工具可以減少PNG檔案大小，同時保持影像質量。

此處以TinyPng為例：TinyPng是一個相當不錯的圖片壓縮工具，在保持alpha通道的情況下對PNG的壓縮可以達到1/3之內，而且用肉眼基本上分辨不出壓縮的損失。這張3.4M的圖片被壓縮到了984.7k，壓縮率高達71%。

也有同學開發了一個AndroidStudio外掛：TinyPngPlugin，能夠批量地壓縮專案中的圖片，更加方便。

備註：需要注意的是在Android構建流程中AAPT會使用內建的壓縮演算法來優化res/drawable/目錄下的PNG圖片，但也可能會導致本來已經優化過的圖片體積變大，可以通過在build.gradle中設定cruncherEnabled來禁止AAPT採用預設方式優化我們已經優化過的圖片。

aaptOptions {
    cruncherEnabled = false
}複製程式碼

4.4 PNG轉換JPG

PNG是一種無損格式，JPG是有損格式。JPG在處理顏色很多的圖片時，根據壓縮率的不同，有時會去掉一些肉眼識別差距較小的中間顏色。但是PNG對於無損這個基本要求，會嚴格保留所有的色彩數。所以圖片尺寸大，或者色彩數量多特別是漸變色的多的時候，PNG的體積會明顯大於JPG。

在這種情況下，我們可以有所取捨。小尺寸、色彩較少或者有alpha通道透明度的時候，使用PNG；大尺寸、色彩漸變多的使用JPG。

備註：根據經驗，對於可以直接使用JPG格式的圖片，最好不要從PNG轉換為JPG，而是出圖的時候直接出JPG格式的圖片，相對而言，後者的效果更好。

4.5 使用向量圖

可縮放向量圖形（英語：Scalable Vector Graphics，SVG）是一種基於可擴充套件標記語言（XML），用於描述二維向量圖形的圖形格式。SVG由W3C制定，是一個開放標準。可以使用向量圖形來建立獨立於解析度的圖示和其他可伸縮圖片。使用向量圖片能夠有效的減少App中圖片所佔用的大小，向量圖形在Android中表示為VectorDrawable物件。

優點

• 圖片擴充套件性：不損傷圖片質量，一套圖適配所有；
• 圖片非常小：比使用點陣圖小十幾倍，有利於減小apk體積；

缺點

• 效能優損失，系統渲染VectorDrawable需要花費更多時間，因為向量圖的初始化載入會比相應的光柵圖片消耗更多的CPU週期，但是兩者之間的記憶體消耗和效能接近；
• 向量圖主要用在色調單一的icon。

4.6 使用WebP

Google於2010年提出了一種新的圖片壓縮格式 — WebP，為圖片提供了無損和有失真壓縮能力，同時在有損條件下支援透明通道。據官方實驗顯示：無損WebP相比PNG減少26%大小；有損WebP在相同的SSIM（Structural Similarity Index，結構相似性）下相比JPEG減少25%~34%的大小；有損WebP也支援透明通道，大小通常約為對應PNG的1/3。同時，谷歌於2014年提出了動態WebP，擴充WebP使其支援動圖能力。動態WebP相比GIF支援更豐富的色彩，並且也佔用更小空間，更適應行動網路的動圖播放。

優點：

• WebP在同畫質下體積更小，WebP支援透明度，壓縮比比JPEG更高但顯示效果卻不輸於JPEG；
• 可以通過工具、雲服務等進行PNG到WebP的轉換；

缺點：

• Android從4.0才開始WebP的原生支援，意味著要相容4.0以下機型需要新增適配庫；當然現在市面上適配4.0以下的應用已經很少了。
• Android 4.2.1+才支援顯示含透明度的WebP，因此最低版本小於4.2.1的App也不是想用就能用的。可以將不顯示透明度的圖片轉換為WebP。

4.7 資源混淆

在Apk打包過程中，aapt會將每一個資源生成一個對應的int數值，而我們通過這個int值來查詢使用資源。在Apk構成中，我們可以看到裡面有一個resources.arsc檔案，裡面儲存著資源id和資源key的對映關係。

當呼叫圖片時，先找到drawable分類，再根據當前的系統config找到匹配的config表，根據id找到對應的res資料。drawable在arsc中是當做string型別儲存的，res資料中有這個資源在res string pool池中的索引。根據這個索引可以在字串池中找到一個字串。這個字串其實就是一個路徑，比如：res/drawable-xhdpi/icon.png；混淆就是將這個路徑改為R/s/f.png；同時修改resources.arsc檔案的對映關係。這樣就能清楚的看出來資源混淆能減小Apk的原因：

• resources.arsc變小；
• 檔案資訊變小，採用了超短路徑，res/drawable-xhdpi/icon.png被修改為R/s/f.png。

這裡推薦微信的資源混淆方案：AndResGuard。

4.8 資源線上化

將部分使用頻率不高的資源例如圖片，放在網上，在恰當的時機提前下載，這樣也能節約部分空間。

5、 Apk瘦身之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指令去執行。

6、 Apk瘦身之7Zip壓縮

我們知道Apk檔案實際上就是一個Zip檔案。Android SDK的打包工具apkbuilder採用的是Deflate演算法將Android App的程式碼、資源等檔案進行壓縮，壓縮成Zip格式，然後簽名釋出。

既然是壓縮，那能不能改進其壓縮方式，獲取更小的Apk檔案？通過分析Apk打包的流程圖我們可以發現SignedJarBuilder類對整個工程包括程式碼Dex和一些課壓縮的資源、檔案進行壓縮，使用的是JDK中zip包下提供的演算法。

簡單的方式我們可以在不改變App編譯器工作的情況下，對生成的Apk檔案進行二次壓縮，同樣使用Deflate演算法，但是將壓縮等級從標準提升到極限壓縮。提高壓縮級別可在不對Apk包本身的內容做任何修改的情況下得到更小的Apk。

備註：

• 需要注意這樣極限壓縮之後的簽名被破壞，需要重新簽名。
• Android平臺對Apk安裝包的解壓演算法只支援Deflate演算法，其它演算法如LZMA，雖然壓縮率更好，但是由於Android平臺預設不支援，所以如果採用這種演算法壓縮Apk，會導致Apk無法安裝。
• 目前在Mac上沒發現好用的7Zip壓縮軟體，需要在Windows下使用。

7、 App瘦身總結：

7.1 程式碼瘦身

• 移除無用程式碼、功能；
• 移除無用的庫、避免功能雷同的庫；
• 啟用Proguard；
• 縮減方法數；

7.2 資源瘦身

• 移除無用的資原始檔；
• Drawable目錄只保留一份資源；
• 對圖片進行壓縮；
• PNG轉換JPG；
• 使用向量圖；
• 使用WebP；
• 資源混淆；
• 資源線上化；

7.3 So瘦身

• 在允許的情況下，針對使用者機型分佈保留特定架構的So；

7.4 7Zip壓縮

使用7Zip對Apk進行極限壓縮。

7.5 其它

• 類如外掛化，將Dex與資原始檔放在服務端，需要時下載；但是外掛化實施以及與現有專案結合難度不小，也超出本文主題，不細說；
• 通過在 build.gradle配置include來針對每個CPU架構生成單獨的安裝包，按照架構上傳Apk；但是這個方案在國內應用市場幾乎沒有採用的，只能在Google Play上使用。
• 一點經驗：對Apk進行瘦身，瘦身So以及資原始檔是見效最快的操作。瘦身So以及刪除不用的圖片、壓縮圖片之後，Apk會縮減很大的比例；而針對Dex的優化可能作用不會很明顯。

參考：

• Android效能優化典範《Smaller APKs : A checklist 》
• 《移動App效能評測與優化》
• 《Android使用向量圖（SVG, VectorDrawable）實踐篇》
• 《WebP原理和Android支援現狀介紹》
• 《談談Android的so》
• 《Android SO檔案的相容和適配》

歡迎關注微信公眾號：定期分享Java、Android乾貨！