APK瘦身探索
最近幾周一直在研究如何為APK瘦身戏阅，折騰了很久婿奔，是時候?qū)懫┛涂偨Y(jié)一下了，雖然已經(jīng)準(zhǔn)備了下周一要在客戶端周會分享用的PPT：APK瘦身探索嚼松。
價值
雖然說APK瘦身對于Android對應(yīng)用可分配內(nèi)存的限制影響不大又憨，但是還是有一些影響的，就以圖片為例麻诀，將一些小圖標(biāo)替換為iconfont能有效減小內(nèi)存的分配痕寓，防止OOM的出現(xiàn)。
另外蝇闭，無論是iOS開發(fā)者還是Android開發(fā)者都應(yīng)該嘗試最好學(xué)會如何為IPA或APK瘦身呻率，不僅僅是為了幫助用戶省流量、減少下載時間呻引、減少占用的存儲空間等等礼仗，更重要的是為了<font color='#ee6252'>提高轉(zhuǎn)化率（注意：本文的轉(zhuǎn)化率均指下載轉(zhuǎn)化率）</font>。
那轉(zhuǎn)化率是什么呢逻悠？
舉個栗子：你的應(yīng)用大小是 18MB 元践，有100個潛在用戶想要去下載嘗試使用，結(jié)果有20個用戶嫌棄安裝包太大直接揚長而去蹂风，有20個用戶在等待下載的過程中取消下載卢厂，最終只有60個用戶真正下載安裝，那么應(yīng)用的轉(zhuǎn)化率就是 60/100 = 60% 惠啄。
那為什么要提高轉(zhuǎn)化率呢慎恒？
因為用戶在糾結(jié)下載你的產(chǎn)品還是你的競品的時候，往往會選擇那個體驗最好撵渡、功能最多融柬、性能最好、包最小的趋距。
工具
如何有條理的為APK瘦身粒氧，必須知道APK的目錄結(jié)構(gòu)，不過在講述這個之前节腐，我這里先介紹幾個工具外盯，在后文會用到。
AndroidStudio2.2.3
AndroidStudio升級到版本2.2.3之后提供了Analyze APK的功能（不過作為AS粉想必已經(jīng)升到AS2.3了吧翼雀，哈哈）饱苟，我們可以借助該工具清楚的了解APK的下載大小、解壓之后的大小狼渊、內(nèi)部各個文件夾或文件占用的大小等信息箱熬，進(jìn)而得知那些地方可以優(yōu)化。下圖為目前達(dá)人店APK的內(nèi)部信息：
另外使用該工具還可以反編譯資源文件、還原layout中的資源id城须，分析DEX蚤认、顯示每一個文件夾或文件的方法數(shù)，分析哪些第三方庫方法數(shù)很多但實際只用到了一部分等其他功能糕伐。
最后如何使用該工具砰琢？有以下兩種方式：
- 直接將APK拖拽進(jìn)入AndroidStudio即可
- 點擊菜單欄Build-Analyze APK...選項，再選擇需要分析的APK即可
NimbleDroid
NimbleDroid 是美國哥倫比亞大學(xué)的博士創(chuàng)業(yè)團(tuán)隊研發(fā)出來的自動化分析Android app性能指標(biāo)的系統(tǒng)赤炒，分析的方式有靜態(tài)和動態(tài)兩種方式：
其中靜態(tài)分析可以分析出APK安裝包中大文件排行榜氯析，各種知名SDK的大小以及占代碼整體的比例，各種類型文件的大小以及占排行莺褒，各種知名SDK的方法數(shù)以及占所有dex中方法數(shù)的比例,針對緩慢的方法，緩慢的第三方SDK和內(nèi)存泄漏雪情。
其中動態(tài)分析可以測量生成的速度遵岩、網(wǎng)絡(luò)、內(nèi)存和磁盤使用率巡通。
我用了一下上面這個工具尘执，感覺還是不錯的，下面我們來看幾張有逼格的圖（圖中數(shù)據(jù)來自于達(dá)人店APK）：
APK內(nèi)部各類型對應(yīng)文件占用的大小
APK內(nèi)部各個類庫的方法數(shù)
APK啟動過程中各個方法的執(zhí)行時間
ClassShark
ClassShark 是一款查看Android執(zhí)行文件（apk）的瀏覽工具宴凉，目前有兩個android App（Apk）和桌面（jar）的版本誊锭。
使用這款工具，可以很方便的打開APK弥锄、Class丧靡、Jar、res等文件和分析里面的內(nèi)容籽暇。
不過目前這個工具并不需要我們單獨使用温治，因為AS內(nèi)部的分析工具就是用的這個。
通過以上工具戒悠，我們可以方便快速的分析APK熬荆，找出那些可以優(yōu)化的部分，為了更加有條理的進(jìn)行講解绸狐，下面我會按照APK的目錄結(jié)構(gòu)來逐條闡述卤恳。
APK目錄結(jié)構(gòu)
上述表格左邊部分是APK內(nèi)部默認(rèn)存在的文件夾或文件，表格右邊對于各個文件夾或文件進(jìn)行了簡要的概述寒矿，詳細(xì)的說明會在之后根據(jù)左邊的順序一一講解突琳。
assets目錄
assets目錄用于存放需要打包到應(yīng)用程序的靜態(tài)文件，它包含以下幾個特性：
使用AssetManager類管理資源
assets目錄內(nèi)部文件不會被系統(tǒng)編譯
assets目錄支持任意深度的子目錄
-
獲取資源需要使用/assets開始（不包含它）的相對路徑名劫窒，具體代碼如下所示：
String fileNames[] = context.getAssets().list(path);
那么本今，assets目錄下都可以放什么文件呢？
說實在的，assets目錄可以存放各種文件冠息，不過正常情況下挪凑，一般只存放以下幾種文件：字體文件、WEB頁面逛艰、配置文件躏碳、某些圖片。
上述幾種文件除了配置文件之外散怖，我們都可以進(jìn)行適當(dāng)?shù)膲嚎s處理：
字體文件：可以使用字體資源文件編輯神器Glyphs進(jìn)行壓縮菇绵，其壓縮方式其實就是通過刪除不需要的字符從而減少APK的大小。
WEB頁面：可以考慮使用7zip壓縮工具對該文件進(jìn)行壓縮镇眷，在正式使用的時候解壓
某些圖片：可以使用tinypng進(jìn)行圖片壓縮咬最， 目前tinypng已經(jīng)支持png和jpg圖片、.9圖的壓縮
lib目錄
lib目錄用于存放通過C或C++編寫編譯生成的so文件（native庫/JNI開發(fā)）欠动，其基本目錄結(jié)構(gòu)如下圖所示：
因為目前市場上主流的架構(gòu)還只是arm架構(gòu)永乌，所以如果不是必要的話，可以考慮不支持x86和mips架構(gòu)具伍，但這并不意味著CPU是x86或mips架構(gòu)的手機(jī)就不能正常安裝使用APK了翅雏，因為放在arm目錄下的so庫是可以兼容到其他架構(gòu)的；
另外arm架構(gòu)中的eabi-v7a相比于eabi只是在圖形渲染方面有了很大的改進(jìn)人芽，所以如果so庫對圖形渲染沒有很高的要求的話望几，完全可以把so庫只存放在arm eabi目錄中，這樣可以大大減小APK的體積萤厅。
上面的說明可能比較籠統(tǒng)橄抹，下面就拿淘寶、微信的APK來說明一下：
可以看出淘寶和微信也是這樣處理祈坠，所以我們其實也可以這樣操作害碾。
res目錄
res目錄用于存放應(yīng)用程序的資源文件，主要包括布局文件赦拘、圖片慌随、XML配置文件等，它包含以下幾個特性：
- 使用Resources類管理資源
- res目錄內(nèi)部文件會被系統(tǒng)編譯
- res目錄不支持任意深度的子目錄
- 獲取資源不需要通過相對路徑找尋躺同，因為文件會被系統(tǒng)編譯阁猜，所以需要通過資源ID（注：資源ID被存放在resources.arsc文件中）查找
其基本目錄結(jié)構(gòu)如下圖所示：
上圖比較全面的列舉了res目錄下經(jīng)常包含的子目錄和文件，并解釋了各個子目錄或文件的含義蹋艺。
根據(jù)上圖我們顯然可以發(fā)現(xiàn)剃袍，res目錄就是我們APK瘦身里面的一大重要部分了，由于其包含的知識很大捎谨，下面我會分章節(jié)進(jìn)行闡述民效，盡量一一闡述清楚憔维。
只用一套圖
首先我給出這么一個結(jié)論：一個APK盡量只用一套圖片，從內(nèi)存占用和適配的角度考慮畏邢，建議放在xhdpi文件夾下业扒。
那么為什么要把圖片放在xhdpi文件夾下面呢？
由于此處知識涉及到Android屏幕適配方面的知識舒萎，比較復(fù)雜程储。本文是關(guān)于APK瘦身的，所以就不詳細(xì)講解了臂寝。下面進(jìn)行必要的闡述章鲤，首先讓我們來看兩張圖：
從上面兩張圖我們可以得到以下兩點信息：
- Android主要的設(shè)備分辨率為：1280*720、1920*1080
- iOS主要的設(shè)備分辨率為：1334*750咆贬、2208*1242败徊、1136*640
可能有人要問了，得到這兩點信息有什么用素征？
恩集嵌，單單這樣看并不能知道什么，為了幫助大家了解御毅，我繪制了下面這樣表格。不過在展示表格之前怜珍，我先為大家灌輸<font color='#ee6252'>兩個知識點</font>：
1端蛆、ppi計算公式
2、在Android設(shè)備中酥泛，dpi 等價于 ppi
恩今豆，此處請停留10秒......下面展示我繪制的表格：
有兩個注意點：
- 表格中上兩行代表的是Android的設(shè)備分辨率及相關(guān)數(shù)據(jù)，下三行代表的是iOS的設(shè)備分辨率及相關(guān)數(shù)據(jù)
- Android屏幕密度為320或480是由谷歌規(guī)定的柔袁，當(dāng)然這里排除各大廠商自行修改的情況
根據(jù)上述表格我們可以清楚的知道iOS流行的設(shè)備分辨率正好對應(yīng)Android流行的設(shè)備分辨率呆躲，那么知道這又有什么用？
除了一開始給出結(jié)論的內(nèi)存和適配因素外捶索，更重要的是可以節(jié)省設(shè)計資源和工作量插掂。在現(xiàn)在的App開發(fā)中（iOS和Android），有些設(shè)計師為了保持iOS和Android的體驗交互一致腥例，可能會以iPhone手機(jī)為基礎(chǔ)進(jìn)行設(shè)計辅甥，包括后期的切圖之類的。
不過根據(jù)上述表格燎竖，我們不是應(yīng)該使用兩套圖嗎璃弄？這里由于在Android設(shè)備中xhdpi和xxhdpi目錄下的圖片顯示效果差異不大，所以完全可以只使用一套圖构回。
現(xiàn)在我們的設(shè)備中只有一套圖了夏块，接下來該怎么為APK瘦身呢疏咐？
處理圖片
當(dāng)我們從設(shè)計師手中得到設(shè)計稿之后，之后的工作顯然就是切圖了脐供，如果設(shè)計師切好圖就更好了浑塞，得到圖片之后我們一定要記得壓縮。
如果圖片類型是.png或.jpg的話患民，我們可以使用tinypng進(jìn)行壓縮缩举；如果圖片類型是.gif的話，我建議使用PS進(jìn)行壓縮或裁剪匹颤，如果你不會PS的話仅孩，可以讓設(shè)計師幫忙。
如果你對圖片壓縮質(zhì)量不滿意的話印蓖，還可以考慮使用不帶alpha值的jpg圖片辽慕、9Patch圖片、同等質(zhì)量下文件更小的WebP圖片格式赦肃、或者使用SVG替換某些圖片資源等其他方式溅蛉。
下面對于最后兩種方式進(jìn)行簡要的闡述：
首先是WebP：AndroidStudio自2.3版本之后提供了Convert to WebP的功能，<font color='#ee6252'>選中res目錄后右擊滑到底部即可看到此功能</font>他宛，下面的引用講述了WebP的概念和支持度：
WebP是Google新推出的影像技術(shù)船侧，它可讓網(wǎng)頁圖檔有效進(jìn)行壓縮，同時在質(zhì)量相同的情況下厅各，WebP格式圖像的體積要比JPEG格式圖像小40%镜撩，進(jìn)而讓整體網(wǎng)頁下載速度加快。為了改善JPEG的圖片壓縮技術(shù)队塘，他們使用了一種基于VP8編碼的圖片壓縮器袁梗，利用預(yù)測編碼技術(shù)，同時還采用了一種基于RIFF的非常輕量級的容器憔古。這種容器只會給每張圖片增加20字節(jié)遮怜，但能讓圖片作者保存他們想要存儲的元數(shù)據(jù)。
android同樣作為google的產(chǎn)品鸿市，minsdk為4.0即api14以上就可以支持webp锯梁，但是對透明的圖片會存在一些問題，minsdk為4.2.1+即api17可以完美支持webp灸芳。
考慮目前市場4.2.1以下的手機(jī)占比已經(jīng)非常稀少涝桅，采用webp格式代替jpg、png的方案非忱友可行冯遂。
下面展示一下收益頁面背景圖片png形勢下和WebP形勢下各自的大小：
其次是SVG：SVG是可縮放矢量圖形（Scalable Vector Graphics）谒获，它使用XML格式定義圖像蛤肌，<font color='#ee6252'>可用于替換APK中的圖標(biāo)</font>壁却。
我們開發(fā)者不需要會如何制作，這是設(shè)計師的工作裸准，當(dāng)然設(shè)計師也不會傻乎乎通過寫代碼的方式繪制圖標(biāo)展东，顯然是使用軟件制作的。
目前達(dá)人店也使用了SVG炒俱，不過它的表現(xiàn)形式是阿里巴巴提供的iconfont盐肃，它不僅允許設(shè)計師自己制作SVG圖片上傳，也提供了百萬種圖標(biāo)供選擇权悟。
減少資源
經(jīng)過上述的方式處理圖片砸王，想必在圖片質(zhì)量方面已經(jīng)無計可施了，所以我們只能通過刪除無用圖片的方式來為APK瘦身了峦阁，當(dāng)然接下來要介紹的兩種方式可不僅僅是減少圖片谦铃，應(yīng)該稱之為減少資源。
這里有個問題：為什么會出現(xiàn)無用的資源呢榔昔？我認(rèn)為有以下幾種情況：
- 由于多人協(xié)作開發(fā)驹闰，沒有好的規(guī)范，導(dǎo)致個人思維嚴(yán)重撒会，隨便添加或刪除資源
- 目前公司有好的規(guī)范嘹朗，但之前沒有，歷史遺留問題诵肛，沒人愿意去管理
- 上一版需要該資源骡显，下一版不需要，然后沒有刪除
那么曾掂，既然知道了原因，就應(yīng)該想出辦法去解決壁顶，首先是最簡單的辦法珠洗，我們只需要在主模塊的gradle文件中配置shrinkResources即可，具體配置方法如下圖所示：
這就是為什么說它是最簡單的減少資源方法的原因若专。
當(dāng)然许蓖，因為簡單必然存在缺陷，因為它只能從打包的應(yīng)用程序和第三方代碼庫中刪除未被引用的資源调衰。如果在不同的資源文件夾下面有同名的資源文件膊爪，那么就沒有辦法刪除了，即使該資源真的沒有被使用嚎莉。
所以米酬，沒有好的辦法了，目前我能想到的只能是手動刪除了趋箩，我們可以通過AndroidStudio提供的Remove Unused Resources功能預(yù)覽刪除真正未使用的資源赃额，<font color='#ee6252'>選中res目錄右擊選擇Refactor-Remove Unused Resources...選項</font>之后會出現(xiàn)下面這樣的圖：
然后根據(jù)查找到結(jié)果加派，逐條雙擊打開文件，按快捷鍵fn+option+F7進(jìn)行查找跳芳，然后在分析是否應(yīng)該刪除芍锦，<font color='#ee6252'>注意：此處定要慎重，務(wù)必自測７膳琛Ｂα稹！</font>吓歇。
另外孽水，我們還可以通過將某些圖片轉(zhuǎn)換網(wǎng)絡(luò)圖片的方式解決，但是這個操作也是需要<font color='#ee6252'>慎重</font>的照瘾，最重要的一點是<font color='#ee6252'>不能影響用戶的體驗</font>匈棘。這邊路飛同學(xué)制作了一個Chrome插件來幫助我們快速上傳圖片到cdn中，可以通過此處下載：joyuploader析命。
最后主卫，還有一種辦法：使用AndroidStudio提供的Lint工具對工程做靜態(tài)代碼檢查，它不僅可以找出我們在代碼編寫上面的失誤鹃愤，還能夠列出那些未被使用的資源簇搅，甚至還可以指出哪些地方可能存在內(nèi)存泄漏等等，功能非常龐大软吐，所以如果工程較大的話瘩将，還是比較耗時的，當(dāng)然這并不是問題凹耙，因為我們可以針對某個模塊執(zhí)行靜態(tài)代碼檢查姿现。我們可以通過<font color='#ee6252'>選中菜單欄Analyze-Inspect Code...選項</font>執(zhí)行靜態(tài)代碼檢查，執(zhí)行完成的效果圖如下所示：
資源混淆
目前我們不僅在資源（特指圖片）質(zhì)量方面做到了極致肖抱，在資源數(shù)量方面也做到了極致备典，看起來真的到極致了。其實不然意述，我們還可以使用資源混淆的方式為APK瘦身提佣，通過壓縮文件內(nèi)容，減少文件名長度的方式實現(xiàn)荤崇。
目前比較出名的資源混淆方式是微信的AndResGuard和美團(tuán)的修改AAPT拌屏，不過由于美團(tuán)的資源混淆方法非常麻煩，還有如果需要通過getIdentifier的方式獲取資源時需要保證這些資源的名字不被混淆术荤，美團(tuán)很難實現(xiàn)倚喂，所以目前大家都在用微信的資源混淆方式，因為微信使用方便喜每，而且提供了白名單务唐。
下面是達(dá)人店APK未使用微信資源混淆和使用了微信資源混淆的差異：
可以清楚的看到雳攘，在使用了微信資源混淆之后，APK減少了0.7MB左右枫笛，效果還是十分明顯的吨灭。
那么為什么使用了微信資源混淆之后可以實現(xiàn)APK瘦身呢？下面這兩張圖清楚的展示了瘦身的原因（摘自微信資源混淆官方文檔）：
總結(jié)刑巧，安裝包大小減少的原因以下四個：
相對的喧兄，可得到影響效果的因素有以下幾個：
可以說，直到現(xiàn)在啊楚，我們對于資源的壓縮猜到了一個極致吠冤，下面是一些針對于某些資源的壓縮辦法。
其他資源
- 如果raw文件夾下有音頻文件恭理，盡量不要使用無損的音頻格式拯辙，比如wav⊙占郏可以考慮相比于mp3同等質(zhì)量但文件更小的opus音頻格式涯保。
- 能不用圖片的就不用圖片，除了通過前面提過的使用9Patch圖周伦、iconfont實現(xiàn)外夕春，還可以使用shape代碼實現(xiàn)，也可以考慮引進(jìn)VectorDrawable（矢量圖） 专挪，從5.0(API等級21)開始及志，android開始支持矢量圖。目前矢量圖兼容到API7寨腔，矢量圖動畫兼容到API11速侈。這里就不詳細(xì)講解了。
終于講完了res部分迫卢，碼字好累锌畸，接下來就相對輕松了，首先我們要講解的是classes.dex文件靖避。
classes.dex
首先，什么是classes.dex比默？classes.dex文件是Android系統(tǒng)的可執(zhí)行文件幻捏，包含應(yīng)用程序的全部操作指令以及運行時數(shù)據(jù)。
這里稍微介紹一下classes.dex文件的生成過程及對應(yīng)的命令：
java源代碼 -> class字節(jié)碼：[javac -source 1.6 -target 1.6 com/package1/*.java com/package2/*.java]
class字節(jié)碼 -> jar包：[jar cvf abc.jar com/package1/*.class com/package2/*.class]
jar包 -> dex文件：[dx --dex --output ***/abc.jar ***/abc_dex.jar]命咐，***是abc.jar的絕對路徑篡九。
從jar包到dex文件的過程是通過dx工具完成的，它的目的是使各個類能夠共享數(shù)據(jù)醋奠，在一定程度上降低了冗余榛臼，同時也使文件結(jié)構(gòu)更加緊湊伊佃，實驗表明，dex文件是傳統(tǒng)jar文件大小的50%左右沛善，具體表現(xiàn)形式可以看下圖：
既然dx工具已經(jīng)辦幫我們壓縮了那么多航揉，那我們還有什么好壓縮的呢？
當(dāng)然有金刁，因為dx工具并沒有壓縮class的內(nèi)容帅涂，所以我們的源代碼并沒有得到壓縮，下面我先介紹兩種常見的辦法來解決這個問題：
和之前最簡單的資源壓縮方式一樣尤蛮，我們也可以在主模塊的gradle文件中配置
minifyEnabled實現(xiàn)代碼混淆媳友，從而減小java文件的大小。因為混淆后的代碼將較長的文件名产捞、實例醇锚、變量、方法名等等做了簡化坯临，從而實現(xiàn)字節(jié)長度上的優(yōu)化焊唬。我們也可以使用之前所說的AndroidStudio提供的Lint工具執(zhí)行靜態(tài)代碼檢查，進(jìn)而刪除無用的類尿扯、方法求晶、變量等。
上面的兩種方式雖然能夠幫助我們減少APK的大小衷笋，但是實際上我們還可以做的更多芳杏。因為上面兩種方式是自動化的，所以必然不像人那么智能辟宗。
有時候我們可能遇到這樣的情況：我們引用了一個第三方類庫爵赵，但是只用到了其中的幾個功能，其他的大部分功能一直不用泊脐，這不是白白的浪費了用戶的流量空幻，降低了APK的下載轉(zhuǎn)化率么？為了解決這樣的問題容客，我們必須借助一些工具去找到這樣的類庫秕铛，比如在文章開頭介紹過的工具：NimbleDroid，下面是達(dá)人店APK目前存在的某個這樣的第三方類庫：
該類庫在達(dá)人店APK中只用到了掃一掃和生成二維碼這兩個功能缩挑，然而這個類庫定義的方法數(shù)竟然有1428但两，顯然不合理，完全可以抽離其內(nèi)部的掃一掃和生成二維碼代碼供置，單獨實現(xiàn)谨湘。
ReDex
最后介紹一下Facebook開源的一個減少APK大小以提高性能的工具 -- ReDex，它通過內(nèi)嵌以及清除僵尸代碼這樣的優(yōu)化方式來減少字節(jié)碼，其主要是對DEX做了優(yōu)化紧阔，能夠讓APK運行更快坊罢，不過需要多測試是否會崩潰。
下面分別是ReDex的教程地址和GitHub地址：
facebook/redex: A bytecode optimizer for Android apps
我個人由于時間問題擅耽，目前還未接入該工具活孩，下面就展示一下網(wǎng)友u012124438的測試數(shù)據(jù)好了：
后來我在使用 Redex 壓縮和優(yōu)化 Android APK一文的幫助下，成功的安裝并使用了ReDex秫筏，但是發(fā)現(xiàn)了以下兩個問題：
- 用ReDex處理過的APK诱鞠，其內(nèi)部的META-INF目錄會被刪除，雖然可以將ReDex處理過的APK用AndResGuard處理一下这敬，會重新出現(xiàn)該目錄航夺。
- 用ReDex處理過的APK，安裝好之后會出現(xiàn)Crash的問題崔涂，目前達(dá)人店APK要Crash三次之后才能正常使用阳掐，而且它對于達(dá)人店APK的貢獻(xiàn)只有20~25K，所以并未打算接入冷蚂。
resources.arsc
最后就是對于resources.arsc文件的壓縮處理了缭保，其實這里我們也不需要做什么，首先因為該文件記錄的是資源文件和資源ID的映射關(guān)系蝙茶，并沒有什么值得壓縮的地方艺骂；另外如果真的有值得壓縮的地方，也只有資源文件的名字了隆夯，不過這個早就在之前因為我們使用了微信資源混淆解決了钳恕，所以此處就不再多講了。
至此蹄衷，針對于APK目錄結(jié)構(gòu)忧额，逐條分析如何為APK瘦身已經(jīng)講完了，接下來介紹一下其他的壓縮方式愧口。
其他方式
使用APK Splits構(gòu)建APK
雖然我們上面很好的使用了resource shrinker可以回收一些未使用的資源(v7睦番、v4、google Service 等Libarry資源)耍属，但有些資源仍然未被清除托嚣。
例如：那些未使用的多套替代資源，或者是library內(nèi)部隱患著引用著的資源而我們卻沒有使用到厚骗∽⒁妫或者是我們要根據(jù)用戶的手機(jī)去提供不同版本的APK，如分辨率(xxhdpi,mhdpi等)溯捆，so庫等。那么我們可以使用APK Splits大大的減少一些無用的資源，這里我們主要參考了http://tools.android.com/tech-docs/new-build-system/user-guide/apk-splits文檔提揍。
使用多版本的APK
Multiple APK Support是一個在Google Play啤月，可以發(fā)布不同的應(yīng)用程序，分別針對不同的設(shè)備配置特征劳跃。每個APK是一個完整的谎仲、獨立的應(yīng)用程序版本，但他們分享在Google Play相同的應(yīng)用程序清單刨仑，必須共享相同的包名和與簽名郑诺。Google Play 會自動給你匹配相應(yīng)的APK，這樣我們的APK 就可以是分不同版本構(gòu)建需要資源文件杉武，從而減小APK的大小辙诞。
資源動態(tài)加載
我們可以在項目中使用資源動態(tài)加載形式，例如：表情轻抱，語言飞涂，離線庫等資源動態(tài)加載，減小APK的大小祈搜。
支持插件化
未來對于一些獨立業(yè)務(wù)模塊较店，可以做成插件化動態(tài)加載，用戶需要使用時容燕，只需下載少部分插件梁呈。
使用shape背景
特別是在扁平化盛行的當(dāng)下，很多純色的漸變的圓角的圖片都可以用shape實現(xiàn)蘸秘，代碼靈活可控官卡，省去了大量的背景圖片。
使用著色方案
相信你的工程里也有很多selector文件秘血，也有很多相似的圖片只是顏色不同味抖，通過著色方案我們能大大減輕這樣的工作量，減少這樣的文件灰粮。
借助于android support庫可實現(xiàn)一個全版本兼容的著色方案仔涩，參考代碼：DrawableLess.java
其他方式...
總結(jié)
如果你不是一個Android開發(fā)人員，對于之前的闡述可能非常模糊，并不能明顯的表現(xiàn)出APK瘦身這件事情的意義，下面我就來總結(jié)一下：
首先吵冒，針對于達(dá)人店APK做了哪些應(yīng)用吐葵？
字體文件使用Glyphs進(jìn)行壓縮，圖片使用tinypng進(jìn)行壓縮
只是用一套so文件
只使用一套圖
使用WebP圖片或SVG圖片替換某些PNG或JPG圖片
使用Google提供的Gradle插件實現(xiàn)代碼混淆和資源混淆
借助NimbleDroid雄家、AS Anylze/Lint工具分析查找刪除不需要的代碼或資源
使用微信提供的資源混淆工具（處于穩(wěn)定性測試階段）
使用Facebook提供的ReDex工具（處于調(diào)研階段）
其次，APK瘦身的效果如何？
這里我們就直接看圖好了：
可以明顯的發(fā)現(xiàn)适秩，達(dá)人店APK越來越小了，所以說，這個工作是很有意義的秽荞。
最后骤公，做一下競品分析？
根據(jù)上面圖表扬跋，可以發(fā)現(xiàn)我們的APK的大小是十分有優(yōu)勢的阶捆，能夠很好的提高下載轉(zhuǎn)化率。而iOS那邊顯然就比較大了钦听，雖然兩者之間不能比較洒试，但是還是可以進(jìn)行一系列優(yōu)化的。
忠告
最后的最后朴上，我想對大家說：在APK瘦身的道路上垒棋，一定要掌握好度，安排好事情的優(yōu)先級余指，如果目前要做的事情捕犬、要優(yōu)化的方面比較復(fù)雜，不僅需要花費很長的時間酵镜，而且最終效果也不明顯碉碉，可以考慮之后再做，甚至不做淮韭。
