包體積優化小意外

前言

承接上篇 Android App 包體積變化史 ，繼續對 Apk 文件的大小進行壓縮。

意外收穫

在以前 Android App 包體積變化史 的最後，咱們經過一些很是很是基礎的配置，把一個 Hello World 版本的 Demo 工程打包出的 release Apk 文件由 2MB 壓縮到了 865kb。

因爲工做時間的關係就沒有繼續跟進。在這期間，Android Studio 4.0 正式版發佈了，隨之最重要的兩個改變就是

• Gradle Android 插件的版本升級到了 4.0.0。
• Gradle 本地包裝器的版本升級到了 6.1.1。

固然，Android Studio 4.0 更新的一些特性已有相關介紹，詳細你們都看過這篇 Android Studio 4.0 穩定版發佈了。

這兩天把以前用來測試的項目從新在 Android 4.0 打開後，按照提示自動升級了上面提到的兩個版本號，想着繼續優化包體積，結果當打出 release apk 文件的時候，突然有了意外收穫。

竟然只有 701kb 了。

這是發生了什麼，難道哪天晚上在夢中作了優化本身忘了嗎？趕忙回滾到升級 gradle 插件以前的版本打個包試試看。

仍是 865 kb 啊。發生了什麼，兩個文件對比一下。

Android 自帶的 apk 比較工具備 bug 啊，😭😭。

不過沒關係，咱們直接肉眼對比兩張圖，大概能夠看出來，是編譯後的 kotlin 文件夾變小了，從 103kb 直接減小到了 9.7kb,事實的確如此嗎？是否是其餘配置暗度陳倉產生的效果？

爲了保險，反手就用 Android Studio 新建了一個如出一轍的 Hello World，用同一個 key 打包。

kotlin 文件夾只有 9.7KB 了。整個 apk 文件也只有 1.9MB 而已，再順手跑個 debug 的包看看。

能夠翻回去看看在 Android App 包體積變化史 的時候，kotlin 文件夾的大小怎麼着也有 103kb 啊。這不是意外收穫還能是啥？

至此，能夠得出結論，在 Android Studio 4.0 版本中。

• Gradle Android 插件的版本升級到 4.0.0。
• Gradle 本地包裝器的版本升級到 6.1.1。

會對包體積有明顯的增益。

Google Android 團隊牛逼 😏😏，Kotlin 牛逼。

一些說明：

• 期間 kotlin 插件版本版本沒有變化，一直都是 1.3.72
• 從圖中能夠看到 classes.dex 文件由稍微的增加，是由於 core-ktx 的版本由 1.2.0 升級到了 1.3.0

資源壓縮

回到正題，嘗完了意外收穫，是否是得一氣呵成想一想還能幹點啥，把包體積再壓一壓？看看現狀

Github MinApp-V2.0.0

因爲是 Hello World 版本，沒有什麼具體業務，classes.dex 已經作了混淆，暫時也想不出還有什麼可作的了。

代碼能夠混淆，那麼資源能夠混淆嗎？固然是能夠的，已經有大佬在領先咱們好久以前就想到了這個問題，甚至已經把這個問題解決了,這就是很是有名的 AndResGuard。

按照他的說明文件，簡單進行一下配置（因爲是 Demo 工程，沒有地方庫相關配置，按照配置模板直接進行便可），執行 resguardRelease 命令打出 final.apk 文件。

能夠看到已經減少到了 610 kb，出很少又壓縮了 90 kb。這樣的壓縮比純粹經過其餘方式仍是比較費勁和耗費人力的。所以，不管是對代碼，仍是資源，經過混淆的策略進行壓縮是一件性價比很是高的事情。

總結

610 kb 是極限嗎？顯然不是。 這裏仍然有壓縮的空間，只是壓縮到這種程度咱們就須要考慮投入產出比這件事情了。

一個 Apk 文件從真實的場景出發，是包含着全部業務邏輯和 UI 展示效果的集合包。Apk 文件越小，新用戶越容易獲取到。其實，除了一味地使用技術手段壓縮，咱們還能夠從業務角度出發，針對不一樣的區域及受衆作不到的定製，而不是一股腦的把全部要作的東西塞在一塊兒，而後想着怎麼作減法，這樣勢必會變成一個零和遊戲，由於需求不止，需求的變化不止。

但同時從意外收穫也能夠看到，不少時候官方發力作某些事情的時候，會比咱們開發者本身作更有效率，以前使用 kotlin 致使包體積變大的時候，甚至討論過要不要回到 java。可是，一旦 Android 官方聽到廣大開發者對於 kotlin 編譯產物增大包體積的抱怨，而且開始親自動手的話，效率是但是很是喜人的。

最後，包體積優化任重道遠，路漫漫其悠遠兮。