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文件进行加载

• 经过插件化插拔的方式就行下发

关于瘦身，零零洒洒的的总结这些了，但愿对你有所帮助~~~