android APK瘦身全面總結——如何從32.6M到13.6M

前言

以前我簡單介紹了關於svg圖片瘦身的問題，在公司，瘦身這個問題是我提出來的，因此這鍋我背了。公司項目是32.6M，我給本身的要求就是低於20M。上週花了一個星期瘦身，至於爲何花了一週，主要是svg適配問題我被搞矇蔽了。而後發現還要改大量代碼，想一想也就算了，又換了另外一種瘦身方法。 不少人是由於這標題而來的，怎麼可能，32.6M的竟然能夠變成13.6M。下面容我慢慢道來。

APK結構介紹

classes.dex

classes.dex是Java源碼編譯後生成的java字節碼文件。但因爲Android使用的dalvik虛擬機與標準的java虛擬機是不兼容的，dex文件與class文件相比，不管是文件結構仍是opcode都不同。目前常見的java反編譯工具都不能處理dex文件。Android模擬器中提供了一個dex文件的反編譯工具，dexdump。用法爲首先啓動Android模擬器，把要查看的dex文件用adb push上傳的模擬器中，而後經過adb shell登陸，找到要查看的dex文件，執行dexdump xxx.dex。另，有人介紹到Dedexer是目前在網上能找到的惟一一個反編譯dex文件的開源工具，須要本身編譯源代碼。

clases2.dex

同上，上面的是對你的java文件的編譯，這個是對你所導入的jar文件的編譯。 

resources.arsc

編譯後的二進制資源文件

AndroidMainfest.xml

該文件是每一個應用都必須定義和包含的，它描述了應用的名字、版本、權限、引用的庫文件等等信息，如要把apk上傳到Google Market上，也要對這個xml作一些配置。

assets

assets目錄能夠存放一些配置文件（好比webview本地資源、圖片資源等等），這些文件的內容在程序運行過程當中能夠經過相關的API得到。

lib

lib目錄下的子目錄armeabi存放的是一些so文件。

這個地方多講幾句，都是在開發過程當中摸索出來的。eclipse在打包的時候會根據文件名的命名規則（lib**.so）去打包so文件，開頭和結尾必須分別爲「lib」和「.so」，不然是不會打包到apk文件中的。其餘非eclipse開發環境沒有測試過。若是你是用SDK和NDK開發的話，這部分很重要，甚至能夠經過把一些不是so文件的文件經過更名打包到apk中，具體能幹些什麼那就看你想幹什麼了！

META-INF

META-INF目錄下存放的是簽名信息，用來保證apk包的完整性和系統的安全。

Res目錄

這是咱們存放xml drawable string color等等一些資源文件。

32.6M——13.6M

首先，我先聲明下，否則我怕會被打，目前13.6M的還在測試中，由於機型問題，目前無法測試。如今穩定包的大小是在19.8M——20.4M。

混淆和去除無用資源 在gradle使用minifyEnabled進行Proguard混淆的配置，可大大減少APP大小

刪除無用圖片資源

咱們公司項目到如今逸代了2年了。可想而知，代碼的冗餘太多了。版本更新會致使不少資源用不到，而後依舊存在包中。這事我是交給老大的作的，畢竟項目他最熟。因而乎刪了差很少100多張圖片。由於作了圖片適配。因此刪除的圖片資源差很少是在400張的樣子。這樣。咱們的app包從32.6M變成了26.8M。記得剛打包測試的時候，測試經理來個句。大家這包不對啊，怎麼少了六、7M。而後就回了是正常的，說我這邊搞完差很少會在20M左右。測試經理：什麼？在瘦個20M。這麼誇張。我：……..好了，不扯了，跑題了。

刪除無用resource資源 這個和上面的確定不同的。我這邊主要仍是指xml。首先，咱們須要點擊Analyze——>Run Inspection by Name…

繼續輸入：unused resource

直接點ok，而後等待：

看來公司項目還能少個300k~。大家對比着大家的項目一個個的刪就好了。

圖片瘦身之熊貓大法

前面我也說了。用svg適配改的代碼量太大了。因而乎我轉用了熊貓瘦身，也就是tinypng。官方網站：https://tinypng.com。下面我從官網給你們介紹下tinypng：

TinyPNG有什麼做用？

TinyPNG使用智能有損壓縮技術來減少 PNG文件的文件大小。經過選擇性地減小圖像中的顏色數量，須要較少的字節來存儲數據。效果幾乎不可見，但它使文件大小有很大的差異！

爲何要使用TinyPNG？

PNG是有用的，由於它是惟一普遍支持的格式，能夠存儲部分透明的圖像。格式使用壓縮，可是文件仍然可能很大。使用TinyPNG縮小您的應用程序和網站的圖像。它將使用更少的帶寬和更快的加載。

它是如何工做的？

當您上傳PNG（便攜式網絡圖形）文件時，圖像中的類似顏色會合並。這種技術被稱爲「量化」。經過減小顏色數量，24位PNG文件能夠轉換爲更小的8位索引彩色圖像。全部沒必要要的元數據也會被刪除。結果：更好的PNG文件100％支持透明度。有你的蛋糕，吃它了！

它支持處處嗎？

TinyPNG生成的文件在全部現代瀏覽器（包括移動設備）上完美顯示。仍然須要支持Internet Explorer 6？它一般忽略PNG透明度並顯示實心背景顏色。使用TinyPNG的背景變得透明瞭。二進制透明度沒有任何解決方法！

你爲何建立Tinypng？

咱們常用PNG圖像，但對加載時間感到失望。咱們建立TinyPNG在咱們的使命，使咱們本身的網站更快，更有趣的使用最好的壓縮。在2014年，咱們添加了JPEG圖像的智能壓縮，並在2016年，咱們添加了對動畫PNG的支持。

使用方法

咱們看到官網的介紹，在這邊上傳你的jpg或者png 一次最多20張，每張最大5MB。接下來咱們隨便來個測試：

從1.4M變成570k。縮了60%。可想而知，熊貓的強大。想要一次上傳所有，這tm就尷尬了。一年25美圓。大家可讓大家的UI給大家圖片的時候就用Tinypng壓縮在發過來。不過有的公司就給你個設計稿。那就得本身親自下手咯~

熊貓大法VS SVG大法

我對比了熊貓和svg的壓縮，前者app'大小是在20.4M，後者是在19.8M。下面上圖給大家對比下：

19.8M——13.6M

前面我也說了，這個目前還在測試機型。因此穩定性還沒保證。先說說是如何作的把。咱們公司項目用到了百度地圖SDK。全部用到了so庫。

固然我這邊只是部分。下面我是搜到了一些關於這些so庫的介紹：

mips、armeabi、armeabi-v7a和x86究竟是什麼

mips：MIPS是世界上很流行的一種RISC處理器。MIPS的意思是「無內部互鎖流水級的微處理器」(Microprocessor without interlocked piped stages)， 其機制是儘可能利用軟件辦法避免流水線中的數據相關問題。

armeabi：默認選項，將建立以基於 ARM* v5TE 的設備爲目標的庫。 具備這種目標的浮點運算使用軟件浮點運算。 使用此 ABI （二進制接口） 建立的二進制代碼將能夠在全部 ARM* 設備上運行。因此armeabi通用性很強。可是速度慢

armeabi-v7a：建立支持基於 ARM* v7 的設備的庫，並將使用硬件 FPU 指令。armeabi-v7a是針對有浮點運算或高級擴展功能的arm v7 cpu。 x

86:支持基於硬件的浮點運算的 IA-32 指令集。x86是能夠兼容armeabi平臺運行的，不管是armeabi-v7a仍是armeabi，同時帶來的也是性能上的損耗， 另外須要指出的是，打包出的x86的so，總會比armeabi平臺的體積更小。

小結

若是項目只包含了 armeabi，那麼在全部Android設備均可以運行； 若是項目只包含了 armeabi-v7a，除armeabi架構的設備外均可以運行； 若是項目只包含了 x86，那麼armeabi架構和armeabi-v7a的Android設備是沒法運行的； 若是同時包含了 armeabi， armeabi-v7a和x86， 全部設備均可以運行，程序在運行的時候去加載不一樣平臺對應的so，這是較爲完美的一種解決方案，同時也會致使包變大。 因此，這個仍是須要根據用戶的機型來判斷，目測我這邊還在測試中，若是沒問題。大小基本就在13.6M左右了。

總結

咱們須要對APP瘦身的時候須要瞭解他的結構，就像我第一次作瘦身的時候，雖然解決了，不過對各類問題都是屬於一臉矇蔽的狀況。因此，咱們須要要了解apk包下每一個文件都是幹嗎的，作了什麼，是否有用。只要你用心去作，就必定能夠解決。就像我當初給本身的目標是小於20M同樣。雖然如今和20M差很少。不過若是那邊測試能夠經過。那即是13.6M而不是20M。但願個人方法能幫助到大家。

本文寫於一年半前，做者：馬雲飛，原文連接：https://blog.csdn.net/sw950729/article/details/64919051

更多文章請關注個人公衆號：