我的Android进阶之旅------>Android APP终极瘦身指南

首先声明，下面文字转载于：

APK瘦身实践

http://www.jayfeng.com/2015/12/29/APK%E7%98%A6%E8%BA%AB%E5%AE%9E%E8%B7%B5/

APP终极瘦身指南

http://www.jayfeng.com/2016/03/01/Android-APP%E7%BB%88%E6%9E%81%E7%98%A6%E8%BA%AB%E6%8C%87%E5%8D%97/

Android APK瘦身实践

因为推广的需要，公司需要把APK的大小再“减小”一下，4M以内！
当达到4M以内之后，公司建议说，能否再压压？2M如何？

瘦身前

因为平时就考虑到大小的限制，所以很多工作已经做过了，如下列举现在的状态：

1. 7.3M（Debug版本）和6.5M（Release版本）
2. 开启minifyEnabled
3. 开启shrinkResources
4. 已经去除不相关的大型库
5. 图片和代码已经经历过粗略的一轮清理

开始魔鬼瘦身

1. tinypng有损压缩

android打包本身会对png进行无损压缩，不信大家可以看看apk中的图片的大小实际上比你代码工程里的图片要小（针对没进行过无损压缩的那些png图）。
所以，纯粹的进行无损压缩并不会对apk的减小有任何效果，这是我特别想在这里强调的一个经验。
现在大家主流的比较喜欢用的tinypng其实是有损压缩：

https://tinypng.com/
[原文] TinyPNG uses smart lossy compression techniques to reduce the file size of your PNG files…
[翻译] TinyPNG使用智能有损压缩技术，来减少PNG文件的大小…

通过tinypng确实能在尽量少的损失下再减小apk，如果图片资源多或者大的话，效果还是很明显的。
具体减少多少，因为这个处理过程我们是间隔做的，无法准确给出结果，就按200k～500k算吧。

2. png换成jpg

经验发现，一些背景，启动页，宣传页的PNG图片比较大，这些图片图形比较复杂，如果转用有损JPG可能只有不到一半（当然是有损，不过通过设置压缩参数可以这种损失比较小到忽略）。
因为都是大图，所以这种方式能有效减小apk的大小。
这种情况下的apk的减小是不可估量的。

3. jpg换成webp

如果png大图转成jpg还是很大，或者想压的更小，而尽量不降低画质，那么可以考虑一下webp。

android 4.0+才原生支持webp, 但是我们的app是兼容2.3+，所以4.0以下的设备将无法看到图片。

1. 考虑到我们4.0以下的所有设备比例之和大约在0.44%，非常少
2. 4.0以下的设备不会崩溃

我们选择不对4.0以下做webp兼容处理，不显示就不显示。否则，要引入webp相关so文件增大apk大小。

通过把下面四张大图换成webp，webp的quality参数按50配置(据说官方评测75是最佳值)，清晰度勉强可以接受，这个值大家具体按产品要求来定。

其中安装jpg转webp工具:

1	brew install webp

转换命令如下

1 2 3

cwebp -q <quality> input.jpg -o output.webp // Example: cwebp -q 50 a.jpg -o a.webp

更多下载：https://developers.google.com/speed/webp/docs/precompiled

最终，apk减小了188k。

补充：
在4.0 ~ 4.2.1的设备上无法显示带有透明度的webp，比如，把png转成webp则无法显示，但是如果把png先转成jpg再转成webp则能正常显示了，但会丢失透明度。参考链接：http://developer.android.com/guide/appendix/media-formats.html

4. 大图缩小

如果经过上面的步骤，依然存在大图的话，说明确实图有点大了，可能真的有点大了！
所以，要考虑的问题是，是否有必要保证如此的大小？能否缩小？
如果这方面能减小的话，apk瘦身的效果必然又会上一个档次。
这种情况下的apk的减小是不可估量的。

5. 覆盖aar里的一些默认的大图

一些aar库里面包含根本就没有用的图。最典型的是support-v4兼容库中包含一些“可能”用到的图片，实际上在你的app中不会用到。

我没有把所有图都替换掉，只是把几张大一点点的图（选中的那些图）用1x1的图片替换，如果9patch图的话，要做成3x3的9patch图替换。
support库可能还算好的，就怕有些库引用了一些大图而不自知，可以在/build/intermediates/exploded-aar/下的各个aar库的res目录查找检验。
apk减小了18k。

6. 删除armable-v7包的so

感谢@杨辉__ ,@kymjs张涛的提醒，armable-v7和armable文件夹可以只保留armable。
当然，armable-v7a的库会对图形渲染方面有很大的改进，因为我们主要是一些业务上动态库，所以删掉无大碍。

apk减小了191k。

7. 微信资源压缩打包

这个方案网上一直在说，之前一直没有需求或者动力实践，在这里感谢一下@裸奔的凯子哥的推荐和交流，他那边的apk可以压小1M，效果还是比较惊人的。
这个步骤我是在后面很多步压缩之后测试的，每个阶段的压缩结果都会有些许出入，所以数据仅供参考。

通过正常压缩，apk包减小了464k。
如果开启7zip，apk包减小了594k。
apk减小了594k。

PS: 关于这个压缩，我集成到了gradle脚本中了，新建了一个Task，大概代码如下：

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

task compressReleaseApp { // 在现有release的版本上生成到compressed目录下 def appid = "appid" def channel = "abcdefghijkl" def guardJarFile = file('../AndResGuard/andresguard-1.1.jar') def guardConfigFile = file('../AndResGuard/config.xml') def originApkFile = file("../app.${appid}/build/outputs/apk/release/${appid}-release-${rootProject.ext.versionName}-${rootProject.ext.versionCode}-${channel}.apk") def outputDir = file("../app.${appid}/build/outputs/apk/compressed/") def keystoreFile = file(RELEASE_STORE_FILE) // 开始执行压缩命令 def proc = "java -jar ${guardJarFile} ${originApkFile} -config ${guardConfigFile} -out ${outputDir} -signature ${keystoreFile} ${RELEASE_STORE_PASSWORD} ${RELEASE_KEY_PASSWORD} ${RELEASE_KEY_ALIAS}".execute(); proc.waitFor(); println "return code: ${ proc.exitValue()}" + ", stderr: ${proc.err.text}" + " stdout: ${proc.in.text}" }

config开启了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>

详情参考：Android资源混淆工具使用说明
原理介绍：安装包立减1M–微信Android资源混淆打包工具

8. proguard深度混淆代码

之前为了简单起见，很多包都直接忽略了，现在启动严格模式，把能混淆的都混淆了：

采用微信压缩方案最终效果比较：

apk减小了215k。

PS:混淆后，一定要经过严格测试，有时候甚至很难发现错误，比如我开启严格混淆，用了一段时间之后慢慢发现了两个bug，排除了两个包程序才正常。

9. 深度清理代码和资源

有意思的是，无论何时何地去清理代码和资源，总能有新的发现:

• 新发现或者新引入的无用图片
• 这几张图怎么一样
• 这个类好像没有用
• 没用的类相关的图片也没用
• 有些图片可以用着色方案替换
• 有些图片可以用shape来代替
• hdpi里的ic_luancher.png好像也可以删掉
• …

apk减小了66k。

10. proguard去符号表

之前为了保留调试信息，我们是在Proguard保留了符号表的：

1	-keepattributes SourceFile,LineNumberTable

官方渠道我觉得还是尽量保留这个，现在针对推广渠道，只能采用特殊手段，注释这一行。
apk减小了230k。
ps:以后友盟上看推广渠道的bug要辛苦一点，手动上传mapping.txt了。

11. provided关键字

可以对仅在运行时需要的库设置provided关键字，实际并不被打包：

1	provided 'com.android.support:support-annotations:22.0.0'

我没有发现这样的场景，如果说有的话，就是support-annotations，但是经过后来的测试验证，support-annotations本来就会在release版本中被minifyEnabled掉，所以对support-annotations设置provided是没有意义的。
如果有实际场景，欢迎留言说明，不甚感激。
apk没有减小。

12. 表情包在线化

虽然应用的表情不多，只有50来个，但是如果能把这部分表情放到网上，不仅能有效减小apk大小，还可以方便后期扩展支持：

打包成emoji_v1.zip, 大小是202k。
现在把emoji_v1.zip放到网上，按需下载后使用，最终对比结果如下：

apk减小了193k。

13. 全版本兼容的着色方案

考虑着色方案主要目的是更方便支持多主题，减轻UI工作量，减少工程里一大堆selector文件等，然后才是，顺便的减小一下apk大小。
通过着色方案，我们去除了10多张纯色的按下状态图片和对应的xml等等。
apk减小了15k。

PS: 具体实现可以参考 http://www.race604.com/tint-drawable/ ，而我也把它集成到了我的LessCode库中了：DrawableLess.java

14. 去除重复库

发现两个地方：

• 现在发现七牛的SDK引用了android-async-http-1.4.6.jar，虽然不大，只有95.4k，但是感觉完全可以写一个轻量级的jar，控制在10～20k就足够了，具体可以在现有的网络库上实现。
• 自己工程使用的是UIL，但是引入的第三方库引用了picasso，两个重复的图片下载库也是完全没用必要的。

现在还没有处理这块，新任务介入，延期优化，敬请期待。

15. 去除无用库

这是一个很基本的点，但是确很容易被人忽视，当你仔细回顾的时候，有一些鸡肋的功能或者库，是几无用处的。不如干脆去掉。
比如，在很早的时候，我就把我们app里的sharesdk删除了，因为对于我们的产品定位和推广来看，这毫无意义。
这种情况下的apk的减小是不可估量的。

16. 去除百度统计

这个视具体情况决定。
因为我们的APP里面包含友盟和百度两套统计系统，早期老板要求，事实上后面已经很少看这方面的数据，百度统计的数据几乎没用人去看，可以暂时先去除。
原本的百度统计的jar有130多k，去除之后的apk的减小会远远没有这么多。
apk减小了20k。

17. 使用更小的库

使用更小的库不应该成为你选择方案的决定性因素，但是可以作为参考因素（freso确实太大了，这个大小也可以成为决定性因素）。
图片下载，网络请求，json解析等等的库和它的竞品都有多大，你心里有数吗？
以工具库为例，网上有很多工具库，但是往往它们的大小很难控制。

• xutils-3.2.6.aar – 843.8k
• lite-common-1.1.3.jar – 148.1k
• lesscode-core-0.8.2.aar – 64k
• …

上面最后一个库LessCode是我自己收集的工具类集合，非常小：LessCode，混淆后只有不到50k大小。
不仅提高了开发效率，减少了冗余代码，而且能避免引用一些其他大型的库，有效避免包的增大。
比如，我们碰到过这样的一个bug，快速点击按钮多次触发跳转，现在RxJava结合RxBind有这样的一个场景解决方案，如果引入这些库的话必然会增大apk大小，实际上就几行代码，我把这样的解决方案集成到了LessCode，下次别的项目碰到这样的问题不用再犹豫是否要引入一个这么大的库了。
这些小的工具库，建议根据自己的经验人手总结一个，不求全，但求精！
这种情况下的apk的减小是不可估量的。

18. 插件化

尴尬的是，我们所呈现的功能大部分都是重要的不可分割的功能，很难从业务上分离出来。
今年预计要实践一个轻量级的插件化方案，用别人的也好，自己写也好，希望能解决或者优化一些安装包加载多模块，或者主题切换，或者热修复的问题。
这里作为候选方案备用。
这种情况下的apk的减小是不可估量的。

19. 功能业务取舍

一开始考虑瘦身，领导是允许适当的砍掉一些功能，因为4M的目标我们已经实现了，所以现在还没有到砍功能的地步。
这里作为候选方案备用。
这种情况下的apk的减小是不可估量的。

补充

文章发出后，收到了一些朋友的建议，补充几点。

1. 去除无用的语言资源

感谢@牧志轩的建议，通过配置resConfigs可以选择只打包哪几种语言，进而去掉各种aar包中全世界的语言，尤其是support包中的。

选择保留什么语言要根据产品的用户和市场来定，如果只选择默认英语和中文语言，配置如下

1 2 3 4 5

android { defaultConfig { resConfigs "zh" } }

看看效果：

如果不采用微信压缩方案结果对比，apk减小了197k。
如果采用微信压缩（开启7zip）对比结果，apk只减小了16k，因为微信对resources.arsc进行了强力压缩，厉害！
apk减小了16k。

2. 删除x86包的so

再次感谢@杨辉__的建议，x86的包删除了之后，测试反应好像有些机器容易崩溃，未能经过严格测试，所以主版本又复原了，只在个别渠道执行这条措施。
一般情况下不会有问题，测试了一下效果，apk减小了78k。
这里作为候选方案备用。

3. 其他人的经验分享（持续更新）

• 蘑菇街伯约写了篇文章《如何将apk大小减少6M》，有些细节说的更清楚，特此记录。

小结

最终，我们成功的把apk压到了2.9M，如果把上面遗漏的步骤继续再做，应该还能再减小一点。
客户反应压的好小，领导简直不敢相信～
瘦身不难，难的是魔鬼瘦身！

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的官方网站：http://tinypng.com/

第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极大的瘦身下去。
考虑到一定的风险性，建议挑选适合自己的方法就行；同时，我也会跟踪最新的瘦身技巧，及时补充更新。