Android APP终极瘦身指南

前言

以前写了一篇《APK瘦身实践》侧重于实践和效果对比，后来受徐川老师点拨，建议改写成一篇更全面的瘦身终极杀招大全，深觉得然，思考良久，新开一篇。

指南条例

第1条：使用一套资源

这是最基本的一条规则，但很是重要。
对于绝大对数APP来讲，只须要取一套设计图就足够了。鉴于如今分辨率的趋势，建议取720p的资源，放到xhdpi目录。
相对于多套资源，只使用720P的一套资源，在视觉上差异不大，不少大公司的产品也是如此，但却能显著的减小资源占用大小，顺便也能减轻设计师的出图工做量了。
注意，这里不是说把不是xhdpi的目录都删除，而是强调保留一套设计资源就够了。

第2条：开启minifyEnabled混淆代码

在gradle使用minifyEnabled进行Proguard混淆的配置，可大大减少APP大小：

 

1 2 3 4 5 6 7

android { buildTypes { release { minifyEnabled true } } }

 

在proguard中，是否保留符号表对APP的大小是有显著的影响的，可酌情不保留，可是建议尽可能保留用于调试。
详细proguard的相关的配置和原理可自行查阅。

第3条：开启shrinkResources去除无用资源

在gradle使用shrinkResources去除无用资源，效果很是好。

 

1 2 3 4 5 6 7

android { buildTypes { release { shrinkResources true } } }

 

第4条：删除无用的语言资源

大部分应用其实并不须要支持几十种语言的国际化支持。还好强大的gradle支持语言的配置，好比国内应用只支持中文：

 

1 2 3 4 5

android { defaultConfig { resConfigs "zh" } }

 

第5条：使用tinypng有损压缩

android打包自己会对png进行无损压缩，因此使用像tinypng这样的有损压缩是有必要的。
重点是Tinypng使用智能有损压缩技术，以尽可能少的失真换来图片大小的锐减，效果很是好，强烈推荐。
Tinypng的官方网站：《》

第6条：使用jpg格式

若是对于非透明的大图，jpg将会比png的大小有显著的优点，虽然不是绝对的，可是一般会减少到一半都不止。
在启动页，活动页等之类的大图展现区采用jpg将是很是明智的选择。

第7条：使用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

第8条：缩小大图

若是通过上述步骤以后，你的工程里面还有一些大图，考虑是否有必要维持这样的大尺寸，是否能适当的缩小。
事实上，因为设计师出图的缘由，咱们拿到的不少图片彻底能够适当的缩小而对视觉影响是极小的。

第9条：覆盖第三库里的大图

有些第三库里引用了一些大图可是实际上并不会被咱们用到，就能够考虑用1x1的透明图片覆盖。
你可能会有点不舒服，由于你的drawable下居然包含了一些莫名其妙的名称的1x1图片…

第10条：删除armable-v7包下的so

基本上armable的so也是兼容armable-v7的，armable-v7a的库会对图形渲染方面有很大的改进，若是没有这方面的要求，能够精简。
这里不排除有极少数设备会Crash，可能和不一样的so有必定的关系，请你们务必测试周全后再发布。

第11条：删除x86包下的so

与第十条不一样的是，x86包下的so在x86型号的手机是须要的，若是产品没用这方面的要求也能够精简。
建议实际工做的配置是只保留armable、armable-x86下的so文件，算是一个折中的方案。

第12条：使用微信资源压缩打包工具

微信资源压缩打包工具经过短资源名称，采用７zip对APP进行极致压缩实现减少APP的目标，效果很是的好，强烈推荐。
详情参考：Android资源混淆工具使用说明
原理介绍：安装包立减1M–微信Android资源混淆打包工具
建议开启7zip，注意白名单的配置，不然会致使有些资源找不到，粗略配置以下，

 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

<?xml version="1.0" encoding="UTF-8"?> <resproguard> <!--defaut property to set --> <issue id="property" > <seventzip value= "true" /> <!-- ... --> </issue> <issue id="whitelist" isactive="true"> <path value ="com.xxx.yyy.R.drawable.emoji_*" /> <path value ="com.xxx.yyy.... /> </issue> <issue id ="compress" isactive="true"> <!-- ... --> </issue> </resproguard>

 

第13条：使用provided编译

对于一些库是按照须要动态的加载，可能在某些版本并不须要，可是代码又不方便去除不然会编译不过。
使用provided能够保证代码编译经过，可是实际打包中并不引用此第三方库，实现了控制APP大小的目标。
可是也同时就须要开发者本身判断不引用这个第三方库时就不要执行到相关的代码，避免APP崩溃。

第14条：使用shape背景

特别是在扁平化盛行的当下，不少纯色的渐变的圆角的图片均可以用shape实现，代码灵活可控，省去了大量的背景图片。

第15条：使用着色方案

相信你的工程里也有不少selector文件，也有不少类似的图片只是颜色不一样，经过着色方案咱们能大大减轻这样的工做量，减小这样的文件。
借助于android support库可实现一个全版本兼容的着色方案，参考代码：DrawableLess.java

第16条：在线化素材库

若是你的APP支持素材库(好比聊天表情库)的话，考虑在线加载模式，由于每每素材库都有不小的体积。
这一步须要开发者实如今线加载，一方面增长代码的复杂度，一方面提升了APP的流量消耗，建议酌情选择。

第17条：避免重复库

避免重复库看上去是理所固然的，可是秘密老是藏的很深，必定要小心你引用的第三方库又引用了哪一个第三方库，这就很容易出现功能重复的库了，好比使用了两个图片加载库：Glide和Picasso。
经过查看exploded-aar目录和External Libraries或者反编译生成的APK，尽可能避免重复库的大小，减少APP大小。

第18条：使用更小的库

一样功能的库在大小上是不一样的，甚至会悬殊很大。
若是并没有对某个库特别需求而又对APP大小有严格要求的话，比较这些相同功能第三方库的大小，选择更小的库会减少APP大小。

第19条：支持插件化

过去的一年，插件化技术雨后春笋同样的都冒了出来，这些技术支持动态的加载代码和动态的加载资源，把APP的一部分分离出来了，对于业务庞大的项目来讲很是有用，极大的分解了APP大小。
由于插件化技术须要必定的技术保障和服务端系统支持，有必定的风险，如无必要（好比一些小型项目，也没什么扩展业务）就不须要了，建议酌情选择。

第20条：精简功能业务

这条彻底取决于业务需求。
从统计数据分析砍掉一些没用的功能是彻底有可能的，甚至干脆去掉一些花哨的功能出个轻聊版、极速版也不是不能够的。

第21条：重复执行第1到20条

屡次执行上述步骤，你总能发现一些蛛丝马迹，这是一个好消息，不是吗？

在线评估

针对不少朋友的反馈，有必要对条例的适用范围、易用性和风险指数作个粗略的评估，汇总以下，方便你们执行。

指南条例	适用范围	易用性	风险指数	备注
使用一套资源	非极高UI要求的APP	易	无
开启minifyEnabled	所有	易	无
开启shrinkResources	所有	易	无
删除无用的语言资源	非全球国际化应用	易	无
使用tinypng有损压缩	非极高UI要求的APP	易	低
使用jpg格式	仅限非透明大图	易	中
使用webp格式	仅限4.0+,4.2+设备	中	中
缩小大图	限容许缩小的大图	易	中
覆盖第三库里的无用大图	所有	中	高
删除armable-v7包下的so	限容许对极少数设备不兼容	易	中
删除x86包下的so	限容许对x86设备不兼容	易	高
使用微信资源压缩打包工具	所有	中	中	切记要配置白名单
使使用provided编译	所有	易	低	容错处理
使用shape背景	所有	易	无
使用着色方案	所有	易	低
表情在线化	限含表情包的APP	中	高
避免重复库	所有	中	中
使用更小的库	所有	中	高
支持插件化	限扩展性要求高的APP	难	高
精简功能业务	限容许精简的APP	难	高

小结

相信通过上述步骤，必定能够把你的Android APP极大的瘦身下去。
考虑到必定的风险性，建议挑选适合本身的方法就行；同时，我也会跟踪最新的瘦身技巧，及时补充更新。