Android-APK瘦身实践：二次瘦身如何再减少大小？

最终，apk减小了188k 。
4. 大图缩小
如果经过上面的步骤，依然存在大图的话，说明确实图有点大了，可能真的有点大了！
所以，要考虑的问题是，是否有必要保证如此的大小？能否缩小？如果这方面能减小的话，apk瘦身的效果必然又会上一个档次。
5. 覆盖aar里的一些默认的大图
一些aar库里面包含根本就没有用的图。最典型的是-v4兼容库中包含一些“可能”用到的图片，实际上在你的app中不会用到。
我没有把所有图都替换掉，只是把几张大一点点的图（选中的那些图）用1×1的图片替换，如果图的话，要做成3×3的图替换。
库可能还算好的，就怕有些库引用了一些大图而不自知，可以在/build//-aar/下的各个aar库的res目录查找检验。
apk减小了18k 。
有问题可以加下[技术交流群](()一起来讨论~
6. 删除-v7包的so
感谢@杨辉__ ,@kymjs张涛的提醒，-v7和文件夹可以只保留。
当然，-v7a的库会对图形渲染方面有很大的改进，因为我们主要是一些业务上动态库，所以删掉无大碍。
apk减小了191k 。
7. 微信资源压缩打包
这个方案网上一直在说，之前一直没有需求或者动力实践，在这里感谢一下@裸奔的凯子哥的推荐和交流，他那边的apk可以压小1M，效果还是比较惊人的。
这个步骤我是在后面很多步压缩之后测试的，每个阶段的压缩结果都会有些许出入，所以数据仅供参考。
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img--17)(%/2/w/1240)]
通过正常压缩，apk包减小了464k 。
如果开启7zip，apk包减小了594k 。
apk减小了594k 。
PS: 关于这个压缩，我集成到了脚本中了，新建了一个Task，大概代码如下：
task{
// 在现有的版本上生成到目录下
def appid = “appid”

文章插图
def= “”
def= file(’…//-1.1.jar’)
def= file(’…//.xml’)
def= file("…/app. a p p i d / b u i l d / o u t p u t s / a p k / r e l e a s e / {appid}/build//apk// appid/build//apk//{appid}-- r o o t P r o j e c t . e x t . v e r s i o n N a m e ? {.ext.}- .ext.?{.ext.}- c h a n n e l . a p k " ) d e f o u t p u t D i r = f i l e ( " . . / a p p . {}.apk") def= file("../app. .apk")=file("../app.{appid}/build//apk//")
def= file()
// 开始执行压缩命令
def proc = “java -jar ${} ${} - ${} -out ${} - ${} ${RD} ${} ${}”.();
proc.();
“ code: ${ proc.()}” + “, : ${proc.err.text}” + " : ${proc.in.text}"
开启了7zip, 部分配置如下：
开源项目《//P7//git》 t"=“true”>
/>
[详情参考](()
[原理介绍](()
8. 深度混淆代码
之前为了简单起见，很多包都直接忽略了，现在启动严格模式，把能混淆的都混淆了：
采用微信压缩方案最终效果比较：
apk减小了215k 。
PS:混淆后，一定要经过严格测试，有时候甚至很难发现错误，比如我开启严格混淆，用了一段时间之后慢慢发现了两个bug，排除了两个包程序才正常。
9. 深度清理代码和资源
有意思的是，无论何时何地去清理代码和资源，总能有新的发现:
apk减小了66k 。
10. 去符号表
之前为了保留调试信息，我们是在保留了符号表的：
- ,

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