頭條APK瘦身之路
隨着版本迭代,功能增加安裝包體積也會慢慢增大。
今日頭條576版本APK達到了25M,通過一系列的優化,到目前的607版本爲12M。本文主要是介紹頭條APK瘦身中用到的一些方法。
APK分析
既然是要優化APK的大小,那首先就得看下APK文件的構成。
Android Studio在2.2版本添加 APK Analyzer功能,可以直接打開apk文件,如下圖所示
APK文件主要有如下幾部分組成:
res主要是存放圖片資源
lib主要是存放so庫,各個cpu架構
classes.dex是java源碼編譯後生成的java字節碼文件,因方法數限制拆分了多個dex
assets主要存放不需要編譯處理的文件
resources.arsc是編譯後的二進制資源文件,包括圖片、文本索引等
META-INF 簽名信息
AndroidManifest.xml 描述配置文件
從APK的構成中可以看出佔比較大的幾個部分,可以着重對其優化
優化
res文件夾
圖片資源壓縮
提供了相應客戶端,支持通過客戶端批量處理,mac上可以使用如下命令開啓:
find . -name '*.png' | xargs open -a ImageOptim
2、TinyPng
沒有提供客戶端,支持拖拽到網頁處理;提供了HTTP API來批量處理,但是有數量限制,每個key每個月可以壓縮500張。 開發了一個gradle插件來批量操作,網上也有一些類似的插件:TinyPng Gradle插件
移除無用資源
1、通過使用Lint檢測刪除無用資源,某些業務代碼刪除的時候遺漏了相應資源,可以寫個腳本檢測移除不再使用的資源
2、添加shrinkResources設置項(官方說明),有0.18M的優化空間,但是該設置有風險如果要使用需要做好測試
3、選擇支持合適的圖片,目前有ldpi mdpi hdpi xhdpi xxhdpi xxxhdpi資源文件夾,可根據自己app的用戶設備選擇支持2-3種即可(當然一套也行)
高版本的gradle已不再支持通過resConfigs "nodpi", "hdpi", "xhdpi", "xxhdpi"配置支持的資源,只能人肉刪除。如果你只想打包某一種屏幕密度的資源,可以使用分包策略,添加如下density配置可以只支持打包xhdpi資源(如果出現某些資源xhdpi沒有,而其他文件夾包含的情況也不用擔心,gradle會保留相應資源),這種配置最終會出多個apk包,具體介紹可參看官方說明。
splits {
density {
enable true
reset()
include "xhdpi"
compatibleScreens 'small', 'normal', 'large', 'xlarge'
}
}
4、如果想整體移除res下某個文件夾可以添加如下aaptOptions配置,而不用打包時手工刪除,多個文件夾用:隔開
aaptOptions {
ignoreAssetsPattern 'color-night-v8:drawable-night-v8'
}
arsc文件
resource.arsc文件記錄了資源id和資源的對應關係(字符串的內容,圖片的相對路徑等)
減少語言支持
目前包括各種語言(v7包引入),點擊resources.arsc可以看到支持80種可以通過修改gradle配置,去除不需要部分,這裏我們保留4種
defaultConfig {
resConfigs "zh-rCN", "zh-rHK", "zh-rTW", "en"
}
只保留"zh-rCN", "zh-rHK", "zh-rTW", "en" 減少不必要的語言(80種減到5種,有一個default)apk可減少0.61M
資源混淆
開源解決方案AndResGuard可以看下,通過使用段路徑和壓縮可以減小apk,需要注意的是你的項目中某些資源需要keep,減少了1.5M。
lib文件夾
架構支持
Android系統目前支持以下七種不同的CPU架構:ARMv5,ARMv7 (從2010年起),x86 (從2011年起),MIPS (從2012年起),ARMv8,MIPS64和x86_64 (從2014年起)
每一個CPU架構對應一個ABI:armeabi,armeabi-v7a,x86,mips,arm64-v8a,mips64,x86_64
所有的x86、x8664、armeabi-v7a、arm64-v8a設備都支持armeabi架構的.so文件,x86設備能夠很好的運行ARM類型函數庫,但並不保證100%不發生crash,特別是對舊設備。64位設備(arm64-v8a, x8664, mips64)能夠運行32位的函數庫,但是以32位模式運行,在64位平臺上運行32位版本的ART和Android組件,將丟失專爲64位優化過的性能(ART,webview,media等等)。所以一般的應用完全可以根據自己業務需求選擇使用armeabi或者armeabi-v7a一種支持就行。
可以通過gradle配置
defaultConfig {
ndk {
abiFilter "armeabi"
}
}
比如:微信、微博、QQ只保留了armeabi,Facebook、Twitter、Instagram只保留了armeabi-v7a
假設只支持了armeabi,如果有特殊要求(比如視頻應用)需要用到部分armeabi-v7a的so,可以通過改名放到armeabi文件夾中,根據手機實際情況選擇加載。
動態下發
比較大的so可以選擇動態下發的形式延遲加載,代碼上需要加一些判斷邏輯。
dex文件
1、添加設置minifyEnabled true,混淆、壓縮代碼,這個設置現在app應該都已經添加了。
2、刪除一些無用庫,早期爲了兼容低版本手機,添加了一些兼容庫,隨着時間推移APP支持的最低版本也在升高,之前的一些無用庫就可以移除。
3、插件下發業務模塊 添加插架框架,將部分代碼延遲下發加載,這部分效果顯著。
其他
極端情況下可以考慮以下兩種方式,可以優化約1M的空間
debug信息
一般我們會配置Proguard保留行號等信息用於線上日誌分析,極端情況下也可考慮移除這部分,會有5%-10%的效果,可以減少了0.5M,但是出於方便性暫未移除。
-keepattributes SourceFile,LineNumberTable
supportv7包
如果對supportv7包依賴的不多,可以直接把使用到的內容copy出來單獨處理,畢竟該包會增加至少0.4M的體積,業務複雜後這部分並不好操作和後續維護,頭條暫時並沒有使用。
TODO
功能迭代不止,瘦身事業不息。
要維持和繼續減小apk包,必須要不斷優化,現在又如下思路還沒有實施,可以看下
1、Google的support-v4包新版本已經做了拆分,24.2.0版本拆分成了5個module:support-compat、support-core-utils、support-core-ui、support-media-compat、support-fragment,可以根據自己需要單獨引用相應的module。
v7包也會依賴v4,maven依賴有個好處,可以通過exclude單獨剔除相應依賴,如下:
compile ('com.android.support:appcompat-v7:24.2.0') {
exclude module: 'support-v4'
}
compile 'com.android.support:support-fragment:24.2.0'
不過目前各家APP對於support包的使用較深,support包各模塊也會有相關依賴關係,具體能不能使用還需要看實際情況了。
2、使用ReDex優化,這是Facebook開源的一個減小安卓app大小以提高性能的工具,集成的話有風險需要多測試,教程。
3、減少java隱藏開銷,比如一些自動生成的函數等。
轉自:https://techblog.toutiao.com/2017/05/16/apk/