每日推荐
Android 技能总结，各种基础和进阶内容的资料收集，包含自定义view知识、动画相关、常用控件、RecyclerView专题、热修复、Fragment专题等常用技术，以及技术网站推荐等。
https://github.com/389273716/android-skill-summary
新增了一个版块，主要用于推荐开源项目、优秀博文等。主要因为部分投稿项目很优秀，但是我又不希望整篇文章仅仅是开源项目的介绍，总希望订阅者读完可以直接获取一些知识，所以该类项目将在此版块推荐。还有些是一些非常好的文章，但是我拿不到授权，只能默默推荐下。
作者简介
本文由首席套路管授权发布。
首席套路管的博客地址：
http://blog.csdn.net/u012124438
概述
为什么APK要瘦身。APK越大，在下载安装过程中，他们耗费的流量会越多，安装等待时间也会越长；对于产品本身，意味着下载转化率会越低（因为竞品中，用户有更多机会选择那个体验最好，功能最多，性能最好，包最小的），所以apk的瘦身优化也很重要，本篇博客将讲述apk瘦身的相关内容。
2
包体分析
在Android Studio工具栏里，打开build–>Analyze APK, 选择要分析的APK包
可以看到占用空间的主要是代码、图片、资源和lib和assert文件，主要方向精简代码、压缩图片、去除无用的库、减少asserts里面文件。
3
使用一套资源
对于绝大对数APP来说，只需要取一套设计图就足够了。鉴于现在分辨率的趋势，建议取720p的资源，放到xhdpi目录。
相对于多套资源，只使用720P的一套资源，在视觉上差别不大，很多大公司的产品也是如此，但却能显著的减少资源占用大小，顺便也能减轻设计师的出图工作量了。
注意，这里不是说把不是xhdpi的目录都删除，而是强调保留一套设计资源就够了。
4
开启minifyEnabled混淆代码
在gradle使用minifyEnabled进行Proguard混淆的配置，可大大减小APP大小：
android {
buildTypes {
release {
minifyEnabled true
}
}
} 在proguard中，是否保留符号表对APP的大小是有显著的影响的，可酌情不保留，但是建议尽量保留用于调试。
参数：
保留选项
压缩
-dontshrink 不压缩输入的类文件
-printusage {filename}
-whyareyoukeeping {class_specification} 优化
混淆
5
开启shrinkResources去除无用资源
在gradle使用shrinkResources去除无用资源，效果非常好。
android {
buildTypes {
release {
shrinkResources true
}
}
}6
清理无用资源
版本迭代过程中，不但有废弃代码冗余，肯定会有无用的图片存在。
在build.gradle 里面配置shrinkResources true，在打包的时候会自动清除掉无用的资源，但经过实验发现打出的包并不会，而是会把部分无用资源用更小的东西代替掉。
注意，这里的“无用”是指调用图片的所有父级函数最终是废弃代码，而shrinkResources true 只能去除没有任何父函数调用的情况，真正起效果只能通过Android Studio自带的 “Remove Unused Resources”小插件来实现了，直接上图。
更人性化是该查找结果可以“一键删除”。
当然，可能图片是经过反射或字符拼接等方式获取，所以这个检测列表也不是全对，删除后很大概率编译失败或部分页面挂死、无图等问题，这个无解，工具还没智能到这个地步，你只能一遍又一遍“编译—解决部分问题—再编译再”，别问我为什么知道。
7删除无用的语言资源
大部分应用其实并不需要支持几十种语言的国际化支持。还好强大的gradle支持语言的配置，比如国内应用只支持中文：
android {
defaultConfig {
resConfigs "zh"
}
}使用tinypng有损压缩
TinyPNG工具只支持上传PNG图片到官网上压缩，然后下载保存，在保持alpha通道的情况下对PNG的压缩可以达到1/3之内，而且用肉眼基本上分辨不出压缩的损失.
Tinypng的官方网站：http://tinypng.com/
9
使用jpg格式
如果对于非透明的大图，jpg将会比png的大小有显著的优势，虽然不是绝对的，但是通常会减小到一半都不止。
在启动页，活动页等之类的大图展示区采用jpg将是非常明智的选择。
10
使用webp格式
webp支持透明度，压缩比比jpg更高但显示效果却不输于jpg，官方评测quality参数等于75均衡最佳。
相对于jpg、png，webp作为一种新的图片格式，限于android的支持情况暂时还没用在手机端广泛应用起来。从Android 4.0+开始原生支持，但是不支持包含透明度，直到Android 4.2.1+才支持显示含透明度的webp，使用的时候要特别注意。
官方介绍：
https://developers.google.com/speed/webp/docs/precompiled
11缩小大图
如果经过上述步骤之后，你的工程里面还有一些大图，考虑是否有必要维持这样的大尺寸，是否能适当的缩小。
事实上，由于设计师出图的原因，我们拿到的很多图片完全可以适当的缩小而对视觉影响是极小的。
12覆盖第三库里的大图
有些第三库里引用了一些大图但是实际上并不会被我们用到，就可以考虑用1x1的透明图片覆盖。
你可能会有点不舒服，因为你的drawable下竟然包含了一些莫名其妙的名称的1x1图片…
13精简so
删除armable-v7包下的so
基本上armable的so也是兼容armable-v7的，armable-v7a的库会对图形渲染方面有很大的改进，如果没有这方面的要求，可以精简。
这里不排除有极少数设备会Crash，可能和不同的so有一定的关系，请大家务必测试周全后再发布。
删除x86包下的so
与第十条不同的是，x86包下的so在x86型号的手机是需要的，如果产品没用这方面的要求也可以精简。
建议实际工作的配置是只保留armable、armable-x86下的so文件，算是一个折中的方案。
14
使用微信资源压缩打包工具
微信资源压缩打包工具通过短资源名称，采用７zip对APP进行极致压缩实现减小APP的目标，效果非常的好，强烈推荐。
建议开启7zip，注意白名单的配置，否则会导致有些资源找不到，官方已经发布AndResGuard到gradle中了，非常方便：
会生成一个andresguard/resguard的Task，自动读取release签名进行重新混淆打包。
15
使用provided编译
对于一些库是按照需要动态的加载，可能在某些版本并不需要，但是代码又不方便去除否则会编译不过。
使用provided可以保证代码编译通过，但是实际打包中并不引用此第三方库，实现了控制APP大小的目标。
但是也同时就需要开发者自己判断不引用这个第三方库时就不要执行到相关的代码，避免APP崩溃。
16
矢量图
矢量图是由点与线组成,和位图不一样,它再放大也能保持清晰度，而且使用矢量图比位图设计方案能节约30～40%的空间，现在谷歌一直在强调扁平化方式，矢量图可很好的契合该设计理念。
—优势
(1)占用存储空间小
(2) 无极拉伸不会出现锯齿，可以照顾不同尺寸的机型
(3)Android Studio自带很多资源，减小UI工作量
—劣势
(1) 只支持5.0及以上系统
(2) 与位图相比多了一层计算，需消耗更多性能
(3) 不支持.9图
(4)不适合表现真实照片和复杂图形，一般使用在简单的icon和动画上
17
使用shape背景
特别是在扁平化盛行的当下，很多纯色的渐变的圆角的图片都可以用shape实现，代码灵活可控，省去了大量的背景图片。
18使用着色方案
相信你的工程里也有很多selector文件，也有很多相似的图片只是颜色不同，通过着色方案我们能大大减轻这样的工作量，减少这样的文件。
借助于android support库可实现一个全版本兼容的着色方案，参考代码：DrawableLess.java(https://github.com/openproject/LessCode/blob/master/lesscode-core/src/main)
19在线化素材库
如果你的APP支持素材库(比如聊天表情库)的话，考虑在线加载模式，因为往往素材库都有不小的体积。
这一步需要开发者实现在线加载，一方面增加代码的复杂度，一方面提高了APP的流量消耗，建议酌情选择。
20避免重复库
避免重复库看上去是理所当然的，但是秘密总是藏的很深，一定要当心你引用的第三方库又引用了哪个第三方库，这就很容易出现功能重复的库了，比如使用了两个图片加载库：Glide和Picasso。
通过查看exploded-aar目录和External Libraries或者反编译生成的APK，尽量避免重复库的大小，减小APP大小。
21清理第三方库和冗余代码
版本迭代过程中，因为删减功能经常有冗余代码和第三方库留下，这或多或少都会增加包体，这种情况没有捷径，只能每个文件查找，这是苦力活。
还有要查看第三方库有没可能精简，比如谷歌分基础、广告和分析包，网络库、supportv4等，这个就具体情况具体分析，不多阐述。
22支持插件化
插件化技术支持动态的加载代码和动态的加载资源，把APP的一部分分离出来了，对于业务庞大的项目来说非常有用，极大的分解了APP大小。
因为插件化技术需要一定的技术保障和服务端系统支持，有一定的风险，如无必要（比如一些小型项目，也没什么扩展业务）就不需要了，建议酌情选择。
23Facebook的redex优化字节码
redex是facebook发布的一款android字节码的优化工具，需要按照说明文档自行配置一下。
redex input.apk
-o output.apk --sign
-s <KEYSTORE> -a <KEYALIAS> -p <KEYPASS>下面我们来看看它的效果，仅redex的话，减小了157k：
下面我们来看看它的效果，仅redex的话，减小了157k：
如果先进行微信混淆，再redex，减小了565k，redex只贡献了10k：
如果先进行redex，在进行微信混淆，减小了711k，redex贡献了157k：
最后一种的效果是最好的，这是很容易解释的，如果最后是redex的重新打包则浪费了前面的7zip压缩，所以为了最优效果要注意顺序。
另外，据反应redex后会有崩溃的现象，这个要留意一下，我这里压缩之后都是可以正常运行的。
详情参考：
https://github.com/facebook/redex