android apk 瘦身

頭條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文件夾 圖片資源壓縮 一、ImageOptim

提供了相應客戶端，支持經過客戶端批量處理，mac上可使用以下命令開啓：

find . -name '*.png' | xargs open -a ImageOptim 二、TinyPng

沒有提供客戶端，支持拖拽到網頁處理；提供了HTTP API來批量處理，可是有數量限制，每一個key每月能夠壓縮500張。 開發了一個gradle插件來批量操做，網上也有一些相似的插件：TinyPng Gradle插件

移除無用資源 一、經過使用Lint檢測刪除無用資源，某些業務代碼刪除的時候遺漏了相應資源，能夠寫個腳本檢測移除再也不使用的資源

二、添加shrinkResources設置項(官方說明)，有0.18M的優化空間，可是該設置有風險若是要使用須要作好測試

三、選擇支持合適的圖片，目前有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'
}

} 四、若是想總體移除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

全部的x8六、x866四、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文件 一、添加設置minifyEnabled true，混淆、壓縮代碼，這個設置如今app應該都已經添加了。

二、刪除一些無用庫，早期爲了兼容低版本手機，添加了一些兼容庫，隨着時間推移APP支持的最低版本也在升高，以前的一些無用庫就能夠移除。

三、插件下發業務模塊 添加插架框架，將部分代碼延遲下發加載，這部分效果顯著。

其餘 極端狀況下能夠考慮如下兩種方式，能夠優化約1M的空間

debug信息 通常咱們會配置Proguard保留行號等信息用於線上日誌分析，極端狀況下也可考慮移除這部分，會有5%-10%的效果，能夠減小了0.5M，可是出於方便性暫未移除。

-keepattributes SourceFile,LineNumberTable supportv7包 若是對supportv7包依賴的很少，能夠直接把使用到的內容copy出來單獨處理，畢竟該包會增長至少0.4M的體積，業務複雜後這部分並很差操做和後續維護，頭條暫時並無使用。

TODO 功能迭代不止，瘦身事業不息。

要維持和繼續減少apk包，必需要不斷優化，如今又以下思路尚未實施，能夠看下

一、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包各模塊也會有相關依賴關係，具體能不能使用還須要看實際狀況了。

二、使用ReDex優化，這是Facebook開源的一個減少安卓app大小以提升性能的工具，集成的話有風險須要多測試，教程。

三、減小java隱藏開銷，好比一些自動生成的函數等。