概述

為什么APK要瘦身。APK越大，在下載安裝過程中，他們耗費的流量會越多，安裝等待時間也會越長；對于產(chǎn)品本身，意味著下載轉(zhuǎn)化率會越低（因為競品中，用戶有更多機(jī)會選擇那個體驗最好，功能最多，性能最好，包最小的），所以apk的瘦身優(yōu)化也很重要，本篇博客將講述apk瘦身的相關(guān)內(nèi)容。

包體分析

在Android Studio工具欄里，打開build–>Analyze APK, 選擇要分析的APK包 。

可以看到占用空間的主要是代碼、圖片、資源和lib和assert文件，主要方向精簡代碼、壓縮圖片、去除無用的庫、減少asserts里面文件。

使用一套資源

對于絕大對數(shù)APP來說，只需要取一套設(shè)計圖就足夠了。鑒于現(xiàn)在分辨率的趨勢，建議取720p的資源，放到xhdpi目錄。
相對于多套資源，只使用720P的一套資源，在視覺上差別不大，很多大公司的產(chǎn)品也是如此，但卻能顯著的減少資源占用大小，順便也能減輕設(shè)計師的出圖工作量了。

開啟minifyEnabled混淆代碼

在gradle使用minifyEnabled進(jìn)行Proguard混淆的配置，可大大減小APP大小：

android {buildTypes {release {minifyEnabled true}} }

在proguard中，是否保留符號表對APP的大小是有顯著的影響的，可酌情不保留，但是建議盡量保留用于調(diào)試。
參數(shù)說明：

-include {filename} 從給定的文件中讀取配置參數(shù) -basedirectory {directoryname} 指定基礎(chǔ)目錄為以后相對的檔案名稱 -injars {class_path} 指定要處理的應(yīng)用程序jar,war,ear和目錄 -outjars {class_path} 指定處理完后要輸出的jar,war,ear和目錄的名稱 -libraryjars {classpath} 指定要處理的應(yīng)用程序jar,war,ear和目錄所需要的程序庫文件 -dontskipnonpubliclibraryclasses 指定不去忽略非公共的庫類。 -dontskipnonpubliclibraryclassmembers 指定不去忽略包可見的庫類的成員。

保留選項

-keep {Modifier} {class_specification} 保護(hù)指定的類文件和類的成員 -keepclassmembers {modifier} {class_specification} 保護(hù)指定類的成員，如果此類受到保護(hù)他們會保護(hù)的更好 -keepclasseswithmembers {class_specification} 保護(hù)指定的類和類的成員，但條件是所有指定的類和類成員是要存在。 -keepnames {class_specification} 保護(hù)指定的類和類的成員的名稱（如果他們不會壓縮步驟中刪除） -keepclassmembernames {class_specification} 保護(hù)指定的類的成員的名稱（如果他們不會壓縮步驟中刪除） -keepclasseswithmembernames {class_specification} 保護(hù)指定的類和類的成員的名稱，如果所有指定的類成員出席（在壓縮步驟之后） -printseeds {filename} 列出類和類的成員-keep選項的清單，標(biāo)準(zhǔn)輸出到給定的文件

壓縮

-dontshrink 不壓縮輸入的類文件 -printusage {filename} -whyareyoukeeping {class_specification}

優(yōu)化

-dontoptimize 不優(yōu)化輸入的類文件 -assumenosideeffects {class_specification} 優(yōu)化時假設(shè)指定的方法，沒有任何副作用 -allowaccessmodification 優(yōu)化時允許訪問并修改有修飾符的類和類的成員

混淆

-dontobfuscate 不混淆輸入的類文件 -printmapping {filename} -applymapping {filename} 重用映射增加混淆 -obfuscationdictionary {filename} 使用給定文件中的關(guān)鍵字作為要混淆方法的名稱 -overloadaggressively 混淆時應(yīng)用侵入式重載 -useuniqueclassmembernames 確定統(tǒng)一的混淆類的成員名稱來增加混淆 -flattenpackagehierarchy {package_name} 重新包裝所有重命名的包并放在給定的單一包中 -repackageclass {package_name} 重新包裝所有重命名的類文件中放在給定的單一包中 -dontusemixedcaseclassnames 混淆時不會產(chǎn)生形形色色的類名 -keepattributes {attribute_name,...} 保護(hù)給定的可選屬性，例如LineNumberTable, LocalVariableTable, SourceFile, Deprecated, Synthetic, Signature, and InnerClasses. -renamesourcefileattribute {string} 設(shè)置源文件中給定的字符串常量

開啟shrinkResources去除無用資源

在gradle使用shrinkResources去除無用資源，效果非常好。

android {buildTypes {release {shrinkResources true}} }

清理無用資源

版本迭代過程中，不但有廢棄代碼冗余，肯定會有無用的圖片存在。在build.gradle 里面配置shrinkResources true，在打包的時候會自動清除掉無用的資源，但經(jīng)過實驗發(fā)現(xiàn)打出的包并不會，而是會把部分無用資源用更小的東西代替掉。注意，這里的“無用”是指調(diào)用圖片的所有父級函數(shù)最終是廢棄代碼，而shrinkResources true 只能去除沒有任何父函數(shù)調(diào)用的情況，真正起效果只能通過Android Studio自帶的 “Remove Unused Resources”小插件來實現(xiàn)了，直接上圖。

更人性化是該查找結(jié)果可以“一鍵刪除”。當(dāng)然，可能圖片是經(jīng)過反射或字符拼接等方式獲取，所以這個檢測列表也不是全對，刪除后很大概率編譯失敗或部分頁面掛死、無圖等問題，這個無解，工具還沒智能到這個地步，你只能一遍又一遍“編譯—解決部分問題—再編譯再”，別問我為什么知道。

刪除無用的語言資源

大部分應(yīng)用其實并不需要支持幾十種語言的國際化支持。還好強(qiáng)大的gradle支持語言的配置，比如國內(nèi)應(yīng)用只支持中文：

android {defaultConfig {resConfigs "zh"} }

使用tinypng有損壓縮

TinyPNG工具只支持上傳PNG圖片到官網(wǎng)上壓縮，然后下載保存，在保持alpha通道的情況下對PNG的壓縮可以達(dá)到1/3之內(nèi)，而且用肉眼基本上分辨不出壓縮的損失.
Tinypng的官方網(wǎng)站：http://tinypng.com/

使用jpg格式

如果對于非透明的大圖，jpg將會比png的大小有顯著的優(yōu)勢，雖然不是絕對的，但是通常會減小到一半都不止。
在啟動頁，活動頁等之類的大圖展示區(qū)采用jpg將是非常明智的選擇。

使用webp格式

webp支持透明度，壓縮比比jpg更高但顯示效果卻不輸于jpg，官方評測quality參數(shù)等于75均衡最佳。
相對于jpg、png，webp作為一種新的圖片格式，限于android的支持情況暫時還沒用在手機(jī)端廣泛應(yīng)用起來。從Android 4.0+開始原生支持，但是不支持包含透明度，直到Android 4.2.1+才支持顯示含透明度的webp，使用的時候要特別注意。
官方介紹：https://developers.google.com/speed/webp/docs/precompiled

縮小大圖

如果經(jīng)過上述步驟之后，你的工程里面還有一些大圖，考慮是否有必要維持這樣的大尺寸，是否能適當(dāng)?shù)目s小。
事實上，由于設(shè)計師出圖的原因，我們拿到的很多圖片完全可以適當(dāng)?shù)目s小而對視覺影響是極小的。

刪除armable-v7包下的so

基本上armable的so也是兼容armable-v7的，armable-v7a的庫會對圖形渲染方面有很大的改進(jìn)，如果沒有這方面的要求，可以精簡。
這里不排除有極少數(shù)設(shè)備會Crash，可能和不同的so有一定的關(guān)系，請大家務(wù)必測試周全后再發(fā)布。

刪除x86包下的so

與第十條不同的是，x86包下的so在x86型號的手機(jī)是需要的，如果產(chǎn)品沒用這方面的要求也可以精簡。
建議實際工作的配置是只保留armable、armable-x86下的so文件，算是一個折中的方案。

使用微信資源壓縮打包工具

微信資源壓縮打包工具通過短資源名稱，采用７zip對APP進(jìn)行極致壓縮實現(xiàn)減小APP的目標(biāo)，效果非常的好，強(qiáng)烈推薦。

建議開啟7zip，注意白名單的配置，否則會導(dǎo)致有些資源找不到，官方已經(jīng)發(fā)布AndResGuard到gradle中了，非常方便：

apply plugin: 'AndResGuard' buildscript {dependencies {classpath 'com.tencent.mm:AndResGuard-gradle-plugin:1.1.7'} } andResGuard {mappingFile = nulluse7zip = trueuseSign = truekeepRoot = false// add <your_application_id>.R.drawable.icon into whitelist.// because the launcher will get thgge icon with his namedef packageName = <your_application_id>whiteList = [//for your iconpackageName + ".R.drawable.icon",//for fabricpackageName + ".R.string.com.crashlytics.*",//for umeng updatepackageName + ".R.string.umeng*",packageName + ".R.string.UM*",packageName + ".R.string.tb_*",packageName + ".R.layout.umeng*",packageName + ".R.layout.tb_*",packageName + ".R.drawable.umeng*",packageName + ".R.drawable.tb_*",packageName + ".R.anim.umeng*",packageName + ".R.color.umeng*",packageName + ".R.color.tb_*",packageName + ".R.style.*UM*",packageName + ".R.style.umeng*",packageName + ".R.id.umeng*"]compressFilePattern = ["*.png","*.jpg","*.jpeg","*.gif","resources.arsc"]sevenzip {artifact = 'com.tencent.mm:SevenZip:1.1.7'//path = "/usr/local/bin/7za"} }

會生成一個andresguard/resguard的Task，自動讀取release簽名進(jìn)行重新混淆打包。

使用provided編譯

對于一些庫是按照需要動態(tài)的加載，可能在某些版本并不需要，但是代碼又不方便去除否則會編譯不過。
使用provided可以保證代碼編譯通過，但是實際打包中并不引用此第三方庫，實現(xiàn)了控制APP大小的目標(biāo)。 但是也同時就需要開發(fā)者自己判斷不引用這個第三方庫時就不要執(zhí)行到相關(guān)的代碼，避免APP崩潰。

矢量圖

矢量圖是由點與線組成,和位圖不一樣,它再放大也能保持清晰度，而且使用矢量圖比位圖設(shè)計方案能節(jié)約30～40%的空間，現(xiàn)在谷歌一直在強(qiáng)調(diào)扁平化方式，矢量圖可很好的契合該設(shè)計理念。
—優(yōu)勢
(1)占用存儲空間小
(2) 無極拉伸不會出現(xiàn)鋸齒，可以照顧不同尺寸的機(jī)型
(3)Android Studio自帶很多資源，減小UI工作量
—劣勢
(1) 只支持5.0及以上系統(tǒng)
(2) 與位圖相比多了一層計算，需消耗更多性能
(3) 不支持.9圖
(4)不適合表現(xiàn)真實照片和復(fù)雜圖形，一般使用在簡單的icon和動畫上

使用著色方案

相信你的工程里也有很多selector文件，也有很多相似的圖片只是顏色不同，通過著色方案我們能大大減輕這樣的工作量，減少這樣的文件。
借助于android support庫可實現(xiàn)一個全版本兼容的著色方案，參考代碼：DrawableLess.java

在線化素材庫

如果你的APP支持素材庫(比如聊天表情庫)的話，考慮在線加載模式，因為往往素材庫都有不小的體積。這一步需要開發(fā)者實現(xiàn)在線加載，一方面增加代碼的復(fù)雜度，一方面提高了APP的流量消耗，建議酌情擇。

避免重復(fù)庫

避免重復(fù)庫看上去是理所當(dāng)然的，但是秘密總是藏的很深，一定要當(dāng)心你引用的第三方庫又引用了哪個第三方庫，這就很容易出現(xiàn)功能重復(fù)的庫了，比如使用了兩個圖片加載庫：Glide和Picasso。 通過查看exploded-aar目錄和External Libraries或者反編譯生成的APK，盡量避免重復(fù)庫的大小，減小APP大小。

清理第三方庫和冗余代碼

版本迭代過程中，因為刪減功能經(jīng)常有冗余代碼和第三方庫留下，這或多或少都會增加包體，這種情況沒有捷徑，只能每個文件查找，這是苦力活。還有要查看第三方庫有沒可能精簡，比如谷歌分基礎(chǔ)、廣告和分析包，網(wǎng)絡(luò)庫、supportv4等，這個就具體情況具體分析，不多闡述。

支持插件化

插件化技術(shù)支持動態(tài)的加載代碼和動態(tài)的加載資源，把APP的一部分分離出來了，對于業(yè)務(wù)龐大的項目來說非常有用，極大的分解了APP大小。
因為插件化技術(shù)需要一定的技術(shù)保障和服務(wù)端系統(tǒng)支持，有一定的風(fēng)險，如無必要（比如一些小型項目，也沒什么擴(kuò)展業(yè)務(wù)）就不需要了，建議酌情選擇。

Facebook的redex優(yōu)化字節(jié)碼

redex是facebook發(fā)布的一款android字節(jié)碼的優(yōu)化工具，需要按照說明文檔自行配置一下。

redex input.apk -o output.apk --sign -s <KEYSTORE> -a <KEYALIAS> -p <KEYPASS>

下面我們來看看它的效果，僅redex的話，減小了157k：

下面我們來看看它的效果，僅redex的話，減小了157k：

如果先進(jìn)行微信混淆，再redex，減小了565k，redex只貢獻(xiàn)了10k：

如果先進(jìn)行redex，在進(jìn)行微信混淆，減小了711k，redex貢獻(xiàn)了157k：

最后一種的效果是最好的，這是很容易解釋的，如果最后是redex的重新打包則浪費了前面的7zip壓縮，所以為了最優(yōu)效果要注意順序。
另外，據(jù)反應(yīng)redex后會有崩潰的現(xiàn)象，這個要留意一下，我這里壓縮之后都是可以正常運行的。
詳情參考：ReDex

總結(jié)

以上是生活随笔為你收集整理的Android优化系列之apk瘦身的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。