Android性能優(yōu)化（十）之App瘦身攻略

1、 前言

如果你對App優(yōu)化比較敏感，那么Apk安裝包的大小就一定不會忽視。關(guān)于瘦身的原因，大概有以下幾個方面：

  • 對于用戶來說，在功能差別不大的前提下，更小的Apk大小意味更少的流量消耗，也意味著更多的用戶下載；
  • 對于產(chǎn)品來說，大于競品的Apk意味著較低的下載基數(shù)，不利于驗證產(chǎn)品策略；
  • 對于開發(fā)人員來說，App瘦身則是一次技術(shù)優(yōu)化、技術(shù)提升的機(jī)會；

2、 Apk的組成

2.1 Apk典型組成

一個典型的Apk組成

下表為Apk目錄及文件說明：

文件/目錄 說明
assets/ 存放一些靜態(tài)文件，可以通過AssertManager訪問
lib/ 如果該目錄存在，一般存放的是NDK編譯出來的so
META-INF/ 保存著APK的簽名信息
res/ 資源文件所在目錄，包含drawable、layout等
AndroidManifest.xml 程序全局配置文件
classes.dex Java Class，被DEX編譯后可供Dalvik/ART虛擬機(jī)所理解的文件格式
resources.arsc 編譯后生成的二進(jìn)制資源文件

2.2 示例分析

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

2.2.1 Android Studio Analyze APK

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

  • 查看apk中任意文件的大小，得到一個直觀的認(rèn)識；
  • 了解Dex文件的組成，查看使用那些開源庫等；
  • 查看二進(jìn)制文件（如AndroidMainfest.xml等）；
  • Apk的比較，便于發(fā)現(xiàn)兩個版本之間的區(qū)別。
Analyze APK的使用
2.2.2 反編譯工具ClassyShark

ClassShark 是一款查看Android執(zhí)行文件（apk）的瀏覽工具，可以很方便的打開APK/Class/Jar/res等文件和分析里面的內(nèi)容。

ClassyShark的使用
2.2.3 Nimbledroid

NimbleDroid 是美國哥倫比亞大學(xué)的博士創(chuàng)業(yè)團(tuán)隊研發(fā)出來的分析Android app性能指標(biāo)的系統(tǒng)，分析的方式有靜態(tài)和動態(tài)兩種方式，其中靜態(tài)分析可以分析出APK安裝包中大文件排行榜，各種知名SDK的大小以及占代碼整體的比例，各種類型文件的大小以及占排行，各種知名SDK的方法數(shù)以及占所有dex中方法數(shù)的比例。

文件大小排行

方法數(shù)統(tǒng)計

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

使用Analyze APK查看到文件大小之后發(fā)現(xiàn)，classes.dex、res、assets、lib等文件較大，哪里的脂肪多，我們就去抽哪里。確定優(yōu)化方向：

  1. 代碼部分：冗余代碼、無用功能、代碼混淆、方法數(shù)縮減等；
  2. 資源部分：冗余資源、資源混淆、圖片處理等；
  3. 對So文件的處理等。

3、 Apk瘦身之代碼瘦身

3.1 移除無用代碼、功能

隨著版本的迭代，部分功能可能已被去掉，但是其代碼還存在項目中。移除無用代碼以及無用功能，有助于減少代碼量，直接體現(xiàn)就是Dex的體積會變小。

備注：根據(jù)經(jīng)驗，不用的代碼在項目中存在屬于一個普遍現(xiàn)象，相當(dāng)于僵尸代碼，而且這類代碼過多也會導(dǎo)致Dex文件過大。

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

3.2.1 項目中基礎(chǔ)功能的庫要統(tǒng)一實現(xiàn)，避免出現(xiàn)多套網(wǎng)絡(luò)請求、圖片加載器等實現(xiàn)。
3.2.2 不用的庫要及時移除出項目，例如我們之前確定要由某推送切換到某推送的時候，此時就要把最初項目中的推送庫去掉，而不應(yīng)該只是注釋掉其注冊代碼。
3.2.3 一些功能可以曲線救國的話就不要引入SDK，例如定位功能，可以不引入定位SDK，而通過拿到經(jīng)緯度然后調(diào)用相關(guān)接口來實現(xiàn)；同樣實現(xiàn)了功能而沒有引入SDK。
3.2.4 而引入SDK也需要考慮其方法數(shù),可以使用ClassyShark、Nimbledroid或者APK method count等工具查看。

備注：根據(jù)經(jīng)驗，項目中存在之前使用之后不使用的庫的情況并不罕見。

3.3 啟用Proguard

代碼混淆也稱為花指令，是將計算機(jī)程序的代碼轉(zhuǎn)換為功能上等價但是難以閱讀、理解的行為。Proguard是一個免費的Java類文件壓縮、優(yōu)化、混淆、預(yù)先驗證的工具，可以檢測和移除未使用的類、字段、方法、屬性，優(yōu)化字節(jié)碼并移除未使用的指令，并將代碼中的類、字段、方法的名字改為簡短、無意義的名字。

可以看出Proguard不僅能將diamante中的各種元素改的簡短，還可以移除冗余代碼，因此可以減少Dex文件的大小。

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

其中，proguard-android.txt是獲取默認(rèn)ProGuard設(shè)置，proguard-rules.pro文件用于添加自定義ProGuard規(guī)則。

備注：對于Proguard，雖然效果很明顯，但仍然需要謹(jǐn)慎；

  • 代碼混淆會拖慢項目構(gòu)建速度，因此debug模式下關(guān)掉Proguard不至于RD在運行代碼的時候抓狂；
  • 因為在debug模式下關(guān)掉了Proguard，如果混淆規(guī)則沒有配置好，在Release模式可能會出現(xiàn)debug模式下不出現(xiàn)的Bug；
  • Proguard也不是你想搞就能搞，如果App做了一段時間之后再來做Proguard，項目包結(jié)構(gòu)不規(guī)范的話，那Proguard的規(guī)則將會非常多。而短時間內(nèi)調(diào)整包結(jié)構(gòu)也是一件相當(dāng)痛苦的事情。

3.4 縮減方法數(shù)

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

通過《Dalvik Executable format》，我們可以看到Dex文件的組成。而從header-item表中的method-ids-size字段可以看出，方法數(shù)縮減之后，可以減少方法列表的大??；同時，方法在Dex文件中的占用空間也減少了，App自然被瘦身。

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

  1. 避免在內(nèi)部類中訪問外部類的私有方法、變量。當(dāng)在Java內(nèi)部類（包含匿名內(nèi)部類）中訪問外部類的私有方法、變量的時候，編譯器會生成額外的方法，會增加方法數(shù)；
  2. 避免調(diào)用派生類中的未被覆寫的方法，避免在派生類中調(diào)用未覆寫的基類的方法；避免用派生類的對象調(diào)用派生類中未覆蓋的基類的方法。調(diào)用派生類中的未被覆蓋的方法時，會多產(chǎn)生一個方法數(shù)；
  3. 去掉部分類的get、set方法；當(dāng)然這樣會犧牲一些面向?qū)ο蟮挠^念。

4、 Apk瘦身之資源瘦身

對于重要性，代碼和資源的瘦身同樣重要，但是從效果上來說，資源文件的瘦身效果比代碼的瘦身效果要好非常多。很有可能費力許久在代碼上得到的瘦身效果，在資源文件瘦身中輕松就得到了。

4.1 移除無用的資源文件

移除無用資源文件要比移除無用代碼容易，在Android Studio的任何文件中右擊，選擇清除無用資源即可刪除沒有用到的資源文件。

Remove Unused Resources

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

4.2 Drawable目錄只保留一份資源

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

備注：圖片放在不恰當(dāng)?shù)哪夸浻锌赡軙?nèi)存產(chǎn)生較大的影響，可以參考之前的文章《Android 性能優(yōu)化（五）之細(xì)說 Bitmap》。

4.3 對圖片進(jìn)行壓縮

之前我在項目里發(fā)現(xiàn)過文件大小過1M的圖片，可能是由于UI同學(xué)和RD同學(xué)的雙重疏忽，導(dǎo)致如此大的圖片到了項目中，對Apk體積的影響自然不言而喻。

可以考慮使用TinyPng、pngquant、ImageOptim等工具對圖片進(jìn)行壓縮，這些工具可以減少PNG文件大小，同時保持圖像質(zhì)量。

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

使用TinyPng壓縮圖片示例

也有同學(xué)開發(fā)了一個AndroidStudio插件：TinyPngPlugin，能夠批量地壓縮項目中的圖片，更加方便。

備注：需要注意的是在Android構(gòu)建流程中AAPT會使用內(nèi)置的壓縮算法來優(yōu)化res/drawable/目錄下的PNG圖片，但也可能會導(dǎo)致本來已經(jīng)優(yōu)化過的圖片體積變大，可以通過在build.gradle中設(shè)置cruncherEnabled來禁止AAPT采用默認(rèn)方式優(yōu)化我們已經(jīng)優(yōu)化過的圖片。

aaptOptions {
    cruncherEnabled = false
}

4.4 PNG轉(zhuǎn)換JPG

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

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

備注：根據(jù)經(jīng)驗，對于可以直接使用JPG格式的圖片，最好不要從PNG轉(zhuǎn)換為JPG，而是出圖的時候直接出JPG格式的圖片，相對而言，后者的效果更好。

4.5 使用矢量圖

可縮放矢量圖形（英語：Scalable Vector Graphics，SVG）是一種基于可擴(kuò)展標(biāo)記語言（XML），用于描述二維矢量圖形的圖形格式。SVG由W3C制定，是一個開放標(biāo)準(zhǔn)?？梢允褂檬噶繄D形來創(chuàng)建獨立于分辨率的圖標(biāo)和其他可伸縮圖片。使用矢量圖片能夠有效的減少App中圖片所占用的大小，矢量圖形在Android中表示為VectorDrawable對象。

優(yōu)點

  • 圖片擴(kuò)展性：不損傷圖片質(zhì)量，一套圖適配所有；
  • 圖片非常?。罕仁褂梦粓D小十幾倍，有利于減小apk體積；

缺點

  • 性能優(yōu)損失，系統(tǒng)渲染VectorDrawable需要花費更多時間，因為矢量圖的初始化加載會比相應(yīng)的光柵圖片消耗更多的CPU周期，但是兩者之間的內(nèi)存消耗和性能接近；
  • 矢量圖主要用在色調(diào)單一的icon。

4.6 使用WebP

Google于2010年提出了一種新的圖片壓縮格式 — WebP，為圖片提供了無損和有損壓縮能力，同時在有損條件下支持透明通道。據(jù)官方實驗顯示：無損WebP相比PNG減少26%大小；有損WebP在相同的SSIM（Structural Similarity Index，結(jié)構(gòu)相似性）下相比JPEG減少25%~34%的大小；有損WebP也支持透明通道，大小通常約為對應(yīng)PNG的1/3。同時，谷歌于2014年提出了動態(tài)WebP，拓展WebP使其支持動圖能力。動態(tài)WebP相比GIF支持更豐富的色彩，并且也占用更小空間，更適應(yīng)移動網(wǎng)絡(luò)的動圖播放。

優(yōu)點：

  • WebP在同畫質(zhì)下體積更小，WebP支持透明度，壓縮比比JPEG更高但顯示效果卻不輸于JPEG；
  • 可以通過工具、云服務(wù)等進(jìn)行PNG到WebP的轉(zhuǎn)換；

缺點：

  • Android從4.0才開始WebP的原生支持，意味著要兼容4.0以下機(jī)型需要添加適配庫；當(dāng)然現(xiàn)在市面上適配4.0以下的應(yīng)用已經(jīng)很少了。
  • Android 4.2.1+才支持顯示含透明度的WebP，因此最低版本小于4.2.1的App也不是想用就能用的。可以將不顯示透明度的圖片轉(zhuǎn)換為WebP。

4.7 資源混淆

在Apk打包過程中，aapt會將每一個資源生成一個對應(yīng)的int數(shù)值，而我們通過這個int值來查找使用資源。在Apk構(gòu)成中，我們可以看到里面有一個resources.arsc文件，里面保存著資源id和資源key的映射關(guān)系。

當(dāng)調(diào)用圖片時，先找到drawable分類，再根據(jù)當(dāng)前的系統(tǒng)config找到匹配的config表，根據(jù)id找到對應(yīng)的res數(shù)據(jù)。drawable在arsc中是當(dāng)做string類型保存的，res數(shù)據(jù)中有這個資源在res string pool池中的索引。根據(jù)這個索引可以在字符串池中找到一個字符串。這個字符串其實就是一個路徑，比如：res/drawable-xhdpi/icon.png；混淆就是將這個路徑改為R/s/f.png；同時修改resources.arsc文件的映射關(guān)系。這樣就能清楚的看出來資源混淆能減小Apk的原因：

  • resources.arsc變?。?/strong>
  • 文件信息變小，采用了超短路徑，res/drawable-xhdpi/icon.png被修改為R/s/f.png。

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

4.8 資源在線化

將部分使用頻率不高的資源例如圖片，放在網(wǎng)上，在恰當(dāng)?shù)臅r機(jī)提前下載，這樣也能節(jié)約部分空間。

5、 Apk瘦身之So瘦身

So（shared object，共享庫）是機(jī)器可以直接運行的二進(jìn)制代碼，是Android上的動態(tài)鏈接庫，類似于Windows上的dll。每一個Android應(yīng)用所支持的ABI是由其APK提供的.so文件決定的，這些so文件被打包在apk文件的lib/目錄下。

So的常見的場景如：加解密算法、音視頻編解碼、核心代碼等。在生成SO文件時，需要考慮適配市面上不同手機(jī)CPU架構(gòu)，而生成支持不同平臺的SO文件進(jìn)行兼容。目前Android共支持七種不同類型的CPU架構(gòu)，分別是：ARMv5，ARMv7 (從2010年起)，x86 (從2011年起)，Mips (從2012年起)，ARMv8，Mips64和x86_64 (從2014年起)。

理論上對應(yīng)CPU架構(gòu)的So的執(zhí)行效率是最高的，但是這樣會導(dǎo)致在libs目錄下放置各個架構(gòu)平臺的So文件，Apk文件的大小自然也就更大了。那么我們自然想到縮減Libs的目錄，一般情況（注意限定）下留下armeabi目錄即可，armeabi目錄下的So可以兼容別的平臺的So，但是性能會有所損耗，失去對特定平臺的優(yōu)化。

因此需要根據(jù)自己使用到的So功能來做具體的區(qū)分：對于性能敏感模塊使用的So可以都放在armeabi目錄，然后通過代碼判斷設(shè)備的CPU類型，再加載其對應(yīng)架構(gòu)的SO文件，例如微信就是這么做的。既縮減了Apk的體積，也不影響性能敏感模塊的執(zhí)行。

微信So的使用

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

ndk {
    //設(shè)置支持的SO庫架構(gòu)
    abiFilters  'armeabi'
}

備注：原本x86架構(gòu)的CPU是不支持運行arm架構(gòu)的So，但I(xiàn)ntel和Google合作在x86機(jī)子的系統(tǒng)內(nèi)核層之上加入了一個名為houdini的Binary Translator（二進(jìn)制轉(zhuǎn)換中間層），這個中間層會在運行期間動態(tài)的讀取arm指令并將之轉(zhuǎn)換為x86指令去執(zhí)行。

6、 Apk瘦身之7Zip壓縮

我們知道Apk文件實際上就是一個Zip文件。Android SDK的打包工具apkbuilder采用的是Deflate算法將Android App的代碼、資源等文件進(jìn)行壓縮，壓縮成Zip格式，然后簽名發(fā)布。

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

使用7Zip壓縮

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

備注：

  • 需要注意這樣極限壓縮之后的簽名被破壞，需要重新簽名。
  • Android平臺對Apk安裝包的解壓算法只支持Deflate算法，其它算法如LZMA，雖然壓縮率更好，但是由于Android平臺默認(rèn)不支持，所以如果采用這種算法壓縮Apk，會導(dǎo)致Apk無法安裝。
  • 目前在Mac上沒發(fā)現(xiàn)好用的7Zip壓縮軟件，需要在Windows下使用。

7、 App瘦身總結(jié)：

7.1 代碼瘦身

  • 移除無用代碼、功能；
  • 移除無用的庫、避免功能雷同的庫；
  • 啟用Proguard；
  • 縮減方法數(shù)；

7.2 資源瘦身

  • 移除無用的資源文件；
  • Drawable目錄只保留一份資源；
  • 對圖片進(jìn)行壓縮；
  • PNG轉(zhuǎn)換JPG；
  • 使用矢量圖；
  • 使用WebP；
  • 資源混淆；
  • 資源在線化；

7.3 So瘦身

  • 在允許的情況下，針對用戶機(jī)型分布保留特定架構(gòu)的So；

7.4 7Zip壓縮

使用7Zip對Apk進(jìn)行極限壓縮。

7.5 其它

  • 類如插件化，將Dex與資源文件放在服務(wù)端，需要時下載；但是插件化實施以及與現(xiàn)有項目結(jié)合難度不小，也超出本文主題，不細(xì)說；
  • 通過在 build.gradle配置include來針對每個CPU架構(gòu)生成單獨的安裝包，按照架構(gòu)上傳Apk；但是這個方案在國內(nèi)應(yīng)用市場幾乎沒有采用的，只能在Google Play上使用。
  • 一點經(jīng)驗：對Apk進(jìn)行瘦身，瘦身So以及資源文件是見效最快的操作。瘦身So以及刪除不用的圖片、壓縮圖片之后，Apk會縮減很大的比例；而針對Dex的優(yōu)化可能作用不會很明顯。

參考：

歡迎關(guān)注微信公眾號：定期分享Java、Android干貨！

歡迎關(guān)注
最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務(wù)。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容