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

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

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