APK瘦身方案大全,盡情享用

看官須知

本文內容不會過於深刻，只是對一些經常使用方案的整理總結

瘦身緣由

Apk的大小對於用戶是否選擇下載應用起着相當重要的影響，也會是成爲用戶活躍度的緣由之一

APK組成

咱們都知道apk是由：

. asserts   
    . lib   
    . res 
    . dex 
    . META-INF    
    . androidManifest   
複製代碼

這幾個部分構成的。
一般來講咱們能夠AndroidStudio自帶的Analyze APK工具進行APK的資源分析進行咱們的瘦身工做,關於工具的使用請參考視頻
咱們的瘦身也是經過分析APK的組成部分後進行操做,注意，重點來了，下面說說我對瘦身方案的理解，拿出你的小本本記錄起來吧~

代碼瘦身

代碼混淆

道在開發過程當中每每爲了開發方面，咱們一般不會開啓混淆措施，一旦到了線上後，咱們無論爲了APK安全仍是瘦身，都建議開啓混淆措施

開啓混淆很簡單，在build.gradle文件中配置minifyEnable true便可。

buildTypes {
        release {
            minifyEnabled true//true開啓混淆配置，false關閉
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.duqian_android_keystore
        }
    }
複製代碼

混淆的具體措施，須要在proguard-rules.pro文件中進行操做。
常見的混淆配置以下：

-dontusemixedcaseclassnames  
        -dontskipnonpubliclibraryclasses  
        -verbose  
        -ignorewarnings 
        
        -dontshrink  
        -optimizationpasses 5    //指定代碼的壓縮級別 
        -dontusemixedcaseclassnames  //包明不混合大小寫 
        -dontusemixedcaseclassnames  //包明不混合大小寫  
        -dontskipnonpubliclibraryclasses   //不去忽略非公共的庫類  
        -dontoptimize   //優化  不優化輸入的類文件  

        -keepattributes *Annotation*  //保護註解  
        -keep public class * extends android.app.Fragment  // 保持哪些類不被混淆  
        -keep public class * extends android.support.v4.app.Fragment  //若是有引用v4包能夠添加下面這行  
複製代碼

三方庫處理

在開發過程當中，咱們由於業務需求，可能會引用不少第三方庫，而這些庫可能有着相同功能
好比Picasso和Glide，這兩個庫都是圖片加載的功能，若是沒有特殊要求的話，根據場景的選擇任選其一便可。

• 固然，本着瘦身的原則,咱們一般選擇一個 包體積更小 的較好。
• 對於第三方庫的管理，一般建議封裝一個 統一管理三方庫的基礎庫 ，這樣有利於後期庫的維護
• 若是咱們須要某個庫的某小部分功能，那麼建議就是 僅引入所需部分功能代碼 便可，加入咱們使用了Picasso，可是咱們只須要它支持webp功能，那麼這時候咱們就只引入webp功能就行了 原則就是 能小則小，不用最好

移除無用代碼

一般是伴隨着業務的不斷迭代，業務代碼只加不減，還有愈來愈多的代碼不敢刪除,這個時候咱們就須要都每一個頁面用戶的訪問狀況進行監測，一般咱們能夠經過使用埋點技術來對頁面的生命週期進行埋點，好比對Activity的onCreate進行埋點，Fragment的構造進行埋點，能夠經過相似的手段來分析用戶操做行爲，這樣能夠更好進行業務的優化。
隨便提一句，使用AOP埋點超好

資源瘦身

冗餘資源

1000行代碼可能佔用5KB的資源，可是100張圖片可能就是上百Kb的資源

可見對資源的一個優化是多麼的重要，那麼就須要刪除一些冗餘資源，操做以下:

資源文件右鍵-->Refactor-->Remove Unused Resource

圖片處理

關於圖片這一塊，咱們提到的次數是真的超超超多了，本文不對圖片處理進行解釋,具體對圖片的處理請參考Bitmap詳解。
關於圖片，咱們可能進行會說到如何進行選擇，還有對它進行的壓縮處理。
圖片有png、jpg和webp這三種格式，png無損，佔用的資源是最大的

png>jpg>webp //  資源從大到小
複製代碼

若是沒有特殊要求，只考慮佔用資源的大小，相信你們應該知道怎麼選了。

圖片壓縮就不過多的說了，推薦tinypng和TinyPngPlugin,

資源混淆

沒什麼好說的，你們看下AndResGuard,主要是將冗長的資源文件路徑縮短，從而達到一個節省資源的目的。

SO瘦身

SO,簡單的說就是Android上的一個動態連接庫，關於SO的操做，請進行JNI相關資料進行查閱

咱們都知道，在Android中有7類CPU架構,對應的ABI：

CPU架構	ABI
ARMv5	armeabi
ARMv7	armeabi-v7a
mips64	mips64
arm64-v8a	arm64-v8a
x86_64	x86_64
x86	x86
MIPS	mips

若是說將這些SO都加載進來，勢必會形成APK的體積膨脹,所以須要經過一些手段來解決

SO移除

在build.gradle的defaultConfig配置中添加下面的代碼

ndk {
                abiFilters "armeabi-v7a" //目前流行的armeabi和armeabi-v7a
            }
複製代碼

固然這樣作，也有缺陷,可能部分用戶由於沒法加載so庫，從而致使用戶體驗差

若是說咱們須要徹底的支持全部設備機型，那麼付出的代價真的太大了，此時咱們可能經過動態加載的方式來解決

動態加載SO

• 將全部的so文件都放到armeabi文件夾下，經過獲取用戶的CPU架構進行動態加載

• 能夠將須要的so文件上傳到服務器，而後先獲取用戶的CPU架構，再從服務器上下載對應的so文件進行加載

• 經過插件化插拔的方式就行下發

關於瘦身，零零灑灑的的總結這些了，但願對你有所幫助~~~