Android-APK 瘦身实践：二次瘦身如何再减少大小？，ffmpeg 音视频开发实战 5

当然，armable-v7a 的库会对图形渲染方面有很大的改进，因为我们主要是一些业务上动态库，所以删掉无大碍。

apk 减小了 191k。

7. 微信资源压缩打包

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

通过正常压缩，apk 包减小了 464k。如果开启 7zip，apk 包减小了 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('../And

《Android学习笔记总结+最新移动架构视频+大厂安卓面试真题+项目实战源码讲义》
浏览器打开：qq.cn.hn/FTe 免费领取

ResGuard/config.xml')def originApkFile = file("../app.$appid/build/outputs/apk/release/${appid}-release-$rootProject.ext.versionName-${rootProject.ext.versionCode}-$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} $RELEAS{E}_{K}E{Y}_{P}ASSWORD${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"?>

<resproguard>

<issueid="property">

<seventzipvalue="true"/>

</issue>

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

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

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

</issue>

<issue id ="compress"isactive="true">

</issue>

</resproguard>

详情参考原理介绍

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 的目标我们已经实现了，所以现在还没有到砍功能的地步。