頭條APK瘦身之路 隨著版本迭代，功能增加安裝包體積也會慢慢增大。

今日頭條576版本APK達到了25M，通過一系列的優化，到目前的607版本為12M。本文主要是介紹頭條APK瘦身中用到的一些方法。

APK分析 既然是要優化APK的大小，那首先就得看下APK檔案的構成。

Android Studio在2.2版本新增 APK Analyzer功能，可以直接開啟apk檔案，如下圖所示 image

APK檔案主要有如下幾部分組成：

   res主要是存放圖片資源

   lib主要是存放so庫，各個cpu架構

   classes.dex是java原始碼編譯後生成的java位元組碼檔案，因方法數限制拆分了多個dex

   assets主要存放不需要編譯處理的檔案

   resources.arsc是編譯後的二進位制資原始檔，包括圖片、文字索引等

   META-INF 簽名信息

   AndroidManifest.xml 描述配置檔案
 

從APK的構成中可以看出佔比較大的幾個部分，可以著重對其優化

優化 res資料夾 圖片資源壓縮 1、ImageOptim

提供了相應客戶端，支援通過客戶端批量處理，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種 image 可以通過修改gradle配置，去除不需要部分，這裡我們保留4種

defaultConfig { resConfigs "zh-rCN", "zh-rHK", "zh-rTW", "en" } 只保留"zh-rCN", "zh-rHK", "zh-rTW", "en" 減少不必要的語言（80種減到5種，有一個default）apk可減少0.61M image

資源混淆 開源解決方案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隱藏開銷，比如一些自動生成的函式等。