前語

跟著版別迭代，功用添加安裝包體積也會漸漸增大。本文主要是介紹APK減肥中用到的一些辦法。

APK剖析

既然是要優(yōu)化APK的巨細(xì)，那首先就得看下APK文件的構(gòu)成。

Android Studio在2.2版別添加 APK Analyzer功用，能夠直接翻開apk文件，如下圖所示


APK文件主要有如下幾部分組成：


從APK的構(gòu)成中能夠看出占比較大的幾個部分，能夠側(cè)重對其優(yōu)化



優(yōu)化

res文件夾

圖片資源緊縮

1、ImageOptim

供給了相應(yīng)客戶端，支撐經(jīng)過客戶端批量處理，mac上能夠運(yùn)用如下指令敞開：


2、TinyPng

沒有供給客戶端，支撐拖拽到網(wǎng)頁處理；供給了HTTP API來批量處理，可是有數(shù)量約束，每個key每個月能夠緊縮500張。 開發(fā)了一個gradle插件來批量操作，網(wǎng)上也有一些相似的插件：TinyPng Gradle插件

移除無用資源

1、經(jīng)過運(yùn)用Lint檢測刪去無用資源，某些事務(wù)代碼刪去的時分遺漏了相應(yīng)資源，能夠?qū)憘€腳本檢測移除不再運(yùn)用的資源

2、添加shrinkResources設(shè)置項(xiàng)(官方闡明)，有0.18M的優(yōu)化空間，可是該設(shè)置有危險如果要運(yùn)用需求做好測驗(yàn)


3、挑選支撐適宜的圖片，現(xiàn)在有l(wèi)dpi mdpi hdpi xhdpi xxhdpi xxxhdpi資源文件夾，可依據(jù)自己app的用戶設(shè)備挑選支撐2-3種即可（當(dāng)然一套也行） 高版別的gradle已不再支撐經(jīng)過resConfigs "nodpi", "hdpi", "xhdpi", "xxhdpi"裝備支撐的資源，只能人肉刪去。如果你只想打包某一種屏幕密度的資源，能夠運(yùn)用分包戰(zhàn)略，添加如下density裝備能夠只支撐打包xhdpi資源（如果呈現(xiàn)某些資源xhdpi沒有，而其他文件夾包含的狀況也不必憂慮，gradle會保存相應(yīng)資源），這種裝備終究會出多個apk包，詳細(xì)介紹可參看官方闡明。


4、如果想全體移除res下某個文件夾能夠添加如下aaptOptions裝備，而不必打包時手藝刪去，多個文件夾用:離隔



arsc文件

resource.arsc文件記錄了資源id和資源的對應(yīng)聯(lián)系（字符串的內(nèi)容，圖片的相對途徑等）

削減言語支撐

現(xiàn)在包含各種言語（v7包引進(jìn)），點(diǎn)擊resources.arsc能夠看到支撐80種


能夠經(jīng)過修正gradle裝備，去除不需求部分，這兒我們保存4種


只保存"zh-rCN", "zh-rHK", "zh-rTW", "en" 削減不必要的言語（80種減到5種，有一個default）apk可削減0.61M


資源混雜

開源解決方案AndResGuard能夠看下，經(jīng)過運(yùn)用段途徑和緊縮能夠減小apk，需求留意的是你的項(xiàng)目中某些資源需求keep，削減了1.5M。


架構(gòu)支撐


Android體系現(xiàn)在支撐以下七種不同的CPU架構(gòu)：ARMv5，ARMv7 (從2010年起)，x86 (從2011年起)，MIPS (從2012年起)，ARMv8，MIPS64和x86_64 (從2014年起)

每一個CPU架構(gòu)對應(yīng)一個ABI：armeabi，armeabi-v7a，x86，mips，arm64-v8a，mips64，x86_64

一切的x86/x86_64/armeabi-v7a/arm64-v8a設(shè)備都支撐armeabi架構(gòu)的.so文件，x86設(shè)備能夠很好的運(yùn)轉(zhuǎn)ARM類型函數(shù)庫，但并不確保100%不發(fā)生crash，特別是對舊設(shè)備。64位設(shè)備（arm64-v8a, x86_64, mips64）能夠運(yùn)轉(zhuǎn)32位的函數(shù)庫，可是以32位方法運(yùn)轉(zhuǎn)，在64位平臺上運(yùn)轉(zhuǎn)32位版別的ART和Android組件，將丟掉專為64位優(yōu)化過的功用（ART，webview，media等等）。所以一般的運(yùn)用完全能夠依據(jù)自己事務(wù)需求挑選運(yùn)用armeabi或許armeabi-v7a一種支撐就行。

能夠經(jīng)過gradle裝備


比方：微信、微博、QQ只保存了armeabi，F(xiàn)acebook、Twitter、Instagram只保存了armeabi-v7a

假定只支撐了armeabi，如果有特殊要求（比方視頻運(yùn)用）需求用到部分armeabi-v7a的so，能夠經(jīng)過改名放到armeabi文件夾中，依據(jù)手機(jī)實(shí)際狀況挑選加載。

動態(tài)下發(fā)

比較大的so能夠挑選動態(tài)下發(fā)的方法推遲加載，代碼上需求加一些判別邏輯。

dex文件

1、添加設(shè)置minifyEnabled true，混雜、緊縮代碼，這個設(shè)置現(xiàn)在app應(yīng)該都現(xiàn)已添加了。

2、刪去一些無用庫，前期為了兼容低版別手機(jī)，添加了一些兼容庫，跟著時間推移APP支撐的最低版別也在升高，之前的一些無用庫就能夠移除。

3、插件下發(fā)事務(wù)模塊 添加插架結(jié)構(gòu)，將部分代碼推遲下發(fā)加載，這部分作用顯著。

其他

極點(diǎn)狀況下能夠考慮以下兩種方法，能夠優(yōu)化約1M的空間

debug信息

一般我們會裝備Proguard保存行號等信息用于線上日志剖析，極點(diǎn)狀況下也可考慮移除這部分，會有5%-10%的作用，能夠削減了0.5M，可是出于方便性暫未移除。


supportv7包

如果對supportv7包依靠的不多，能夠直接把運(yùn)用到的內(nèi)容copy出來獨(dú)自處理，究竟該包會添加至少0.4M的體積，事務(wù)雜亂后這部分并不好操作和后續(xù)保護(hù)，頭條暫時并沒有運(yùn)用。



TODO

功用迭代不止，減肥工作不息。

要保持和持續(xù)減小apk包，有必要要不斷優(yōu)化，現(xiàn)在又如下思路還沒有施行，能夠看下

1、Google的support-v4包新版別現(xiàn)已做了拆分，24.2.0版別拆分成了5個module:support-compat、support-core-utils、support-core-ui、support-media-compat、support-fragment，能夠依據(jù)自己需求獨(dú)自引證相應(yīng)的module。 v7包也會依靠v4，maven依靠有個優(yōu)點(diǎn)，能夠經(jīng)過exclude獨(dú)自除掉相應(yīng)依靠，如下：


不過現(xiàn)在各家APP關(guān)于support包的運(yùn)用較深，support包各模塊也會有相關(guān)依靠聯(lián)系，詳細(xì)能不能運(yùn)用還需求看實(shí)際狀況了。

2、運(yùn)用ReDex優(yōu)化，這是Facebook開源的一個減小安卓app巨細(xì)以進(jìn)步功用的東西，集成的話有危險需求多測驗(yàn)，教程。

3、削減java躲藏開支，比方一些主動生成的函數(shù)等。