前段时间领导要求将android apk体积下降下来，所以个人就去了解了下这方面的知识。
当一个apk体积过大时，过大的体积导致编译的耗时过长跟用户不愿意去下载，并且版本的更新也会因为体积过大，必须在wifi环境才舍得更新，这样对于新版本的推广是得不偿失的。所以就有了缩减apk的需求。
apk缩减是一件很有意思的事情，相应的方法也有很多：

1.尽量少的依赖第三方sdk

可以通过抽取第三方关键代码达到快速开发的需求。因为你在引入一个第三方sdk的时候，往往会带入很多不必要的功能，并且第三方往往还有内部的依赖，需求功能之外的冗余代码还是蛮多的，所以手动的抽取出关键代码，往往会比较合适，当然，依赖可能造成的其他问题就不在这里一一说明了。
这里做一个小小的示范，如何抽取出关键代码：
抽取代码目标：PullZoomView ：是一种可伸缩的view
//直接依赖：

In your build.gradle:
 dependencies {
           compile 'com.github.frank-zhu:pullzoomview:1.0.0'
 }

我们选择另一种做法，直接抽取关键代码，现在我们下载代码， 看他的代码中都有什么

图片.png

//我们找到我们想要的控件了，那么现在就只需要抽取所需的代码就可以了

图片.png

直接抽取类还不够，我们会发现还有如下的styleable中的代码要抽取出来：

图片.png

我们找到res包中需要的代码拿出来就可以了，如果你没有attrs.xml文件，just to create：

图片.png

图片.png

2.删除不需要的代码跟没有被引用的图片

项目的长期迭代，往往会有一些图片被替代，不被使用，所以可以通过android studio自带的分析工具lint，进行分析，删除：
进入Android Studio的菜单中选择Analyze->Inspecting Code即可

分析完毕后在Inspection选项卡中会有一份详细的报告，找到Android Lint项目

拉到下面Unused resource这一栏打开，即是未被使用的资源列表，用户可以参照来手动删除资源

还有种方法，但是我并没有去关注这方面会不会带来潜在的风险，需要大家自己去尝试：

图片.png

3.压缩图片体积

即使向UI要求尽量减小图片的大小，但是UI也会因为自己的考量（图片质量）而不会真正的给出非常小的图片，那么这个时候需要我们手动的去压缩图片，对于这方面，可以通过专门的网站进行批量压缩，比如 TinyPng

图片.png

图片质量肉眼看不出变化，但是大小减小了72% ，就是这么的神奇

4.混淆apk

混淆也是压缩apk体积的一种，他会将代码进行替换，这种替换往往会减小代码占据的体积，一般可以因此降低两到三兆的体积。混淆需要配置好第三方的proguard-rules.pro 否则会出现功能错误

//在app的build.gradle文件下
 buildTypes {
        debug {
            minifyEnabled false
            zipAlignEnabled false
            shrinkResources false
            signingConfig signingConfigs.debug
        }
        release {
            //混淆
            minifyEnabled false 
    //所以尽可能的减少第三方的使用 也是可以降低混淆的难度
            //Zipalign优化
            zipAlignEnabled true
            // 移除无用的resource文件
            shrinkResources  false
            proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
            signingConfig signingConfigs.release
        }
    }

5.优化代码逻辑，减少Assets文件夹内容

这方面根据项目上面的业务来判断，比如公司项目由于用了weex，在assets文件夹里面放置了一些vue文件，某些界面直接用vue文件进行展示。由于想尽可能的压缩apk体积，所以将这一块的逻辑修改，不再直接加载assets文件夹里面的vue文件，而将所有的vue文件放置到服务器中，根据服务器判断是否需要下载这方面的文件到用户的sd卡中，再去加载这方面的文件。这样，再一次的减小了整个apk的体积。

6.丢弃 跟替换某些占据体积较大的依赖。

可以通过分析网站 ，分析整个apk中的大小分布

7.对于一些市场占有率不高的分辨率，请谨慎支持

即有选择性的提供xhdpi，xxhdpi的图片资源。建议优先提供xhdpi的图片，对于mdpi，ldpi与xxxhdpi根据需要提供有差异的部分即可

8.使用webp格式的图片资源

webp格式带来更低的体积，但是有点需要衡量的是，webp图片的解析需要jpg/png将近10倍的时间消耗，并且需要做好适配的问题。

9.用代码代替背景图片

对于一些背景图片，可以直接用selector.xml文件替代，既不会失真，体积又能进一步的减小。

10. .so包的优化

很多第三方会提供所有的.so包支持，但是我们其实并不需要那么多的架构支持，类似于x86和x86_64（都是模拟器）的so是不需要支持，在这方面也可以减少一部分体积开支：

defaultConfig {
        ndk {
            // 设置支持的SO库架构
            abiFilters 'armeabi-v7a'// , 'arm64-v8a', 'armeabi-v7a', 'x86_64', 'x86', 'arm64-v8a'
        }
    }

11.动态加载技术（插件化）

现在大型互联网移动App很多都采用了动态加载的技术，因为他们的业务需求太大，通过动态加载技术可以将一部分业务模块独立出来，以插件的方式分割出去，这样子主apk的体积就大大减小。当用户安装主apk后，静默的在后台下载插件apk，当用户点击使用到相关的子模块项目时候，动态的加载插件apk。 动态加载技术无疑从根本上减少了apk的体积，但是引入这个技术是有代价的，增加了项目的维护难度和开发难度。所以该技术适用于大型的移动应用，当你的业务大到不分开模块难以高效率开发维护的时候，再考虑动态加载技术吧，否则如果小规模应用，还是老老实实考虑传统的android官方推荐的开发方式。

12.用属性动画 代替帧动画

帧动画是由一系列的图片制作而成的，如果需要适配的话，消耗的资源还是很大的。

13.大神专用：使用较低版本的android api ，以便丢弃support.v4包

参考这篇文章

14.移除枚举

一个枚举能让classes.dex文件增加1–1.4K。枚举的加入会快速增加应用体积。我们可以使用@IntDef注解和Proguard代替枚举，它能提供和枚举一样的类型安全转换。

15.移除国际化

判断项目是否真的需要国际化，毕竟不是所有的app都需要去支持外文的。

android {
    defaultConfig {
        resConfigs "zh"
    }
}

16.利用微信资源压缩打包工具

微信同时利用7z深度压缩，大大减少了安装包体积，同时也增加了逼格，提升了反破解难度。
使用说明：微信资源压缩打包工具使用介绍 技术原理介绍：安装包立减1M–微信Android资源混淆打包工具

这里写图片描述

参考：
https://yq.aliyun.com/articles/57284?&utm_source=qq
http://blog.csdn.net/u011335851/article/details/52187739
http://www.jianshu.com/p/bd90dee57ad0
http://m.blog.csdn.net/article/details?id=50834617
http://blog.csdn.net/tim_yip/article/details/47022875