Android-APK瘦身实践：二次瘦身如何再减少大小？，2021年安卓开发进阶课程

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包减

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》

【docs.qq.com/doc/DSkNLaERkbnFoS0ZF】完整内容开源分享

小了594k。

apk减小了594k。

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

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}/build/outputs/apk/release/appid/build/outputs/apk/release/{appid}-release-rootProject.ext.versionName−{rootProject.ext.versionName}-rootProject.ext.versionName−{rootProject.ext.versionCode}-channel.apk")defoutputDir=file("../app.{channel}.apk") def outputDir = file("../app.channel.apk")defoutputDir=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, 部分配置如下：

<?xmlversion="1.0"encoding="UTF-8"?>

<issueid=“property”>

<seventzipvalue=“true”/>

<issueid="whitelist"isactive=“true”>

<pathvalue=“com.xxx.yyy.R.drawable.emoji_*”/>

<pathvalue="com.xxx.yyy…
/>

详情参考
原理介绍

8. proguard深度混淆代码

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

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

apk减小了215k。

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

9. 深度清理代码和资源

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

新发现或者新引入的无用图片

这几张图怎么一样

这个类好像没有用

没用的类相关的图片也没用

有些图片可以用着色方案替换

有些图片可以用shape来代替

hdpi里的ic_luancher.png好像也可以删掉

…

apk减小了66k。

10. proguard去符号表

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

-keepattributes SourceFile,LineNumberTable

官方渠道我觉得还是尽量保留这个，现在针对推广渠道，只能采用特殊手段，注释这一行。

apk减小了230k。

ps:以后友盟上看推广渠道的bug要辛苦一点，手动上传mapping.txt了。

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

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: 具体实现可以参考，而我也把它集成到了我的LessCode库中了：DrawableLess.java

14. 去除重复库

发现两个地方：

现在发现七牛的SDK引用了android-async-http-1.4.6.jar，虽然不大，只有95.4k，但是感觉完全可以写一个轻量级的jar，控制在10～20k就足够了，具体可以在现有的网络库上实现。

自己工程使用的是UIL，但是引入的第三方库引用了picasso，两个重复的图片下载库也是完全没用必要的。

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

15. 去除无用库

这是一个很基本的点，但是确很容易被人忽视，当你仔细回顾的时候，有一些鸡肋的功能或者库，是几无用处的。不如干脆去掉。

比如，在很早的时候，我就把我们app里的sharesdk删除了，因为对于我们的产品定位和推广来看，这毫无意义。

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，下次别的项目碰到这样的问题不用再犹豫是否要引入一个这么大的库了。

这些小的工具库，建议根据自己的经验人手总结一个，不求全，但求精！

18. 插件化

尴尬的是，我们所呈现的功能大部分都是重要的不可分割的功能，很难从业务上分离出来。

今年预计要实践一个轻量级的插件化方案，用别人的也好，自己写也好，希望能解决或者优化一些安装包加载多模块，或者主题切换，或者热修复的问题。

这里作为候选方案备用。

####19. 功能业务取舍
一开始考虑瘦身，领导是允许适当的砍掉一些功能，因为4M的目标我们已经实现了，所以现在还没有到砍功能的地步。

这里作为候选方案备用。

补充

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

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

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

android{

defaultConfig{

resConfigs"zh"

}

看看效果：

。