Android APP終極瘦身指南

前言

以前寫了一篇《APK瘦身實踐》側重於實踐和效果對比，後來受徐川老師點撥，建議改寫成一篇更全面的瘦身終極殺招大全，深覺得然，思考良久，新開一篇。

指南條例

第1條：使用一套資源

這是最基本的一條規則，但很是重要。
對於絕大對數APP來講，只須要取一套設計圖就足夠了。鑑於如今分辨率的趨勢，建議取720p的資源，放到xhdpi目錄。
相對於多套資源，只使用720P的一套資源，在視覺上差異不大，不少大公司的產品也是如此，但卻能顯著的減小資源佔用大小，順便也能減輕設計師的出圖工做量了。
注意，這裏不是說把不是xhdpi的目錄都刪除，而是強調保留一套設計資源就夠了。

第2條：開啓minifyEnabled混淆代碼

在gradle使用minifyEnabled進行Proguard混淆的配置，可大大減少APP大小：

 

1 2 3 4 5 6 7

android { buildTypes { release { minifyEnabled true } } }

 

在proguard中，是否保留符號表對APP的大小是有顯著的影響的，可酌情不保留，可是建議儘可能保留用於調試。
詳細proguard的相關的配置和原理可自行查閱。

第3條：開啓shrinkResources去除無用資源

在gradle使用shrinkResources去除無用資源，效果很是好。

 

1 2 3 4 5 6 7

android { buildTypes { release { shrinkResources true } } }

 

第4條：刪除無用的語言資源

大部分應用其實並不須要支持幾十種語言的國際化支持。還好強大的gradle支持語言的配置，好比國內應用只支持中文：

 

1 2 3 4 5

android { defaultConfig { resConfigs "zh" } }

 

第5條：使用tinypng有損壓縮

android打包自己會對png進行無損壓縮，因此使用像tinypng這樣的有損壓縮是有必要的。
重點是Tinypng使用智能有損壓縮技術，以儘可能少的失真換來圖片大小的銳減，效果很是好，強烈推薦。
Tinypng的官方網站：《》

第6條：使用jpg格式

若是對於非透明的大圖，jpg將會比png的大小有顯著的優點，雖然不是絕對的，可是一般會減少到一半都不止。
在啓動頁，活動頁等之類的大圖展現區採用jpg將是很是明智的選擇。

第7條：使用webp格式

webp支持透明度，壓縮比比jpg更高但顯示效果卻不輸於jpg，官方評測quality參數等於75均衡最佳。
相對於jpg、png，webp做爲一種新的圖片格式，限於android的支持狀況暫時還沒用在手機端普遍應用起來。從Android 4.0+開始原生支持，可是不支持包含透明度，直到Android 4.2.1+才支持顯示含透明度的webp，使用的時候要特別注意。
官方介紹：https://developers.google.com/speed/webp/docs/precompiled

第8條：縮小大圖

若是通過上述步驟以後，你的工程裏面還有一些大圖，考慮是否有必要維持這樣的大尺寸，是否能適當的縮小。
事實上，因爲設計師出圖的緣由，咱們拿到的不少圖片徹底能夠適當的縮小而對視覺影響是極小的。

第9條：覆蓋第三庫裏的大圖

有些第三庫裏引用了一些大圖可是實際上並不會被咱們用到，就能夠考慮用1x1的透明圖片覆蓋。
你可能會有點不舒服，由於你的drawable下居然包含了一些莫名其妙的名稱的1x1圖片…

第10條：刪除armable-v7包下的so

基本上armable的so也是兼容armable-v7的，armable-v7a的庫會對圖形渲染方面有很大的改進，若是沒有這方面的要求，能夠精簡。
這裏不排除有極少數設備會Crash，可能和不一樣的so有必定的關係，請你們務必測試周全後再發布。

第11條：刪除x86包下的so

與第十條不一樣的是，x86包下的so在x86型號的手機是須要的，若是產品沒用這方面的要求也能夠精簡。
建議實際工做的配置是隻保留armable、armable-x86下的so文件，算是一個折中的方案。

第12條：使用微信資源壓縮打包工具

微信資源壓縮打包工具經過短資源名稱，採用７zip對APP進行極致壓縮實現減少APP的目標，效果很是的好，強烈推薦。
詳情參考：Android資源混淆工具使用說明
原理介紹：安裝包立減1M–微信Android資源混淆打包工具
建議開啓7zip，注意白名單的配置，不然會致使有些資源找不到，粗略配置以下，

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

<?xml version="1.0" encoding="UTF-8"?> <resproguard> <!--defaut property to set --> <issue id="property" > <seventzip value= "true" /> <!-- ... --> </issue> <issue id="whitelist" isactive="true"> <path value ="com.xxx.yyy.R.drawable.emoji_*" /> <path value ="com.xxx.yyy.... /> </issue> <issue id ="compress" isactive="true"> <!-- ... --> </issue> </resproguard>

 

第13條：使用provided編譯

對於一些庫是按照須要動態的加載，可能在某些版本並不須要，可是代碼又不方便去除不然會編譯不過。
使用provided能夠保證代碼編譯經過，可是實際打包中並不引用此第三方庫，實現了控制APP大小的目標。
可是也同時就須要開發者本身判斷不引用這個第三方庫時就不要執行到相關的代碼，避免APP崩潰。

第14條：使用shape背景

特別是在扁平化盛行的當下，不少純色的漸變的圓角的圖片均可以用shape實現，代碼靈活可控，省去了大量的背景圖片。

第15條：使用着色方案

相信你的工程裏也有不少selector文件，也有不少類似的圖片只是顏色不一樣，經過着色方案咱們能大大減輕這樣的工做量，減小這樣的文件。
藉助於android support庫可實現一個全版本兼容的着色方案，參考代碼：DrawableLess.java

第16條：在線化素材庫

若是你的APP支持素材庫(好比聊天表情庫)的話，考慮在線加載模式，由於每每素材庫都有不小的體積。
這一步須要開發者實如今線加載，一方面增長代碼的複雜度，一方面提升了APP的流量消耗，建議酌情選擇。

第17條：避免重複庫

避免重複庫看上去是理所固然的，可是祕密老是藏的很深，必定要小心你引用的第三方庫又引用了哪一個第三方庫，這就很容易出現功能重複的庫了，好比使用了兩個圖片加載庫：Glide和Picasso。
經過查看exploded-aar目錄和External Libraries或者反編譯生成的APK，儘可能避免重複庫的大小，減少APP大小。

第18條：使用更小的庫

一樣功能的庫在大小上是不一樣的，甚至會懸殊很大。
若是並沒有對某個庫特別需求而又對APP大小有嚴格要求的話，比較這些相同功能第三方庫的大小，選擇更小的庫會減少APP大小。

第19條：支持插件化

過去的一年，插件化技術雨後春筍同樣的都冒了出來，這些技術支持動態的加載代碼和動態的加載資源，把APP的一部分分離出來了，對於業務龐大的項目來講很是有用，極大的分解了APP大小。
由於插件化技術須要必定的技術保障和服務端系統支持，有必定的風險，如無必要（好比一些小型項目，也沒什麼擴展業務）就不須要了，建議酌情選擇。

第20條：精簡功能業務

這條徹底取決於業務需求。
從統計數據分析砍掉一些沒用的功能是徹底有可能的，甚至乾脆去掉一些花哨的功能出個輕聊版、極速版也不是不能夠的。

第21條：重複執行第1到20條

屢次執行上述步驟，你總能發現一些蛛絲馬跡，這是一個好消息，不是嗎？

在線評估

針對不少朋友的反饋，有必要對條例的適用範圍、易用性和風險指數作個粗略的評估，彙總以下，方便你們執行。

指南條例	適用範圍	易用性	風險指數	備註
使用一套資源	非極高UI要求的APP	易	無
開啓minifyEnabled	所有	易	無
開啓shrinkResources	所有	易	無
刪除無用的語言資源	非全球國際化應用	易	無
使用tinypng有損壓縮	非極高UI要求的APP	易	低
使用jpg格式	僅限非透明大圖	易	中
使用webp格式	僅限4.0+,4.2+設備	中	中
縮小大圖	限容許縮小的大圖	易	中
覆蓋第三庫裏的無用大圖	所有	中	高
刪除armable-v7包下的so	限容許對極少數設備不兼容	易	中
刪除x86包下的so	限容許對x86設備不兼容	易	高
使用微信資源壓縮打包工具	所有	中	中	切記要配置白名單
使使用provided編譯	所有	易	低	容錯處理
使用shape背景	所有	易	無
使用着色方案	所有	易	低
表情在線化	限含表情包的APP	中	高
避免重複庫	所有	中	中
使用更小的庫	所有	中	高
支持插件化	限擴展性要求高的APP	難	高
精簡功能業務	限容許精簡的APP	難	高

小結

相信通過上述步驟，必定能夠把你的Android APP極大的瘦身下去。
考慮到必定的風險性，建議挑選適合本身的方法就行；同時，我也會跟蹤最新的瘦身技巧，及時補充更新。