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

这里作为候选方案备用。

本文已被CODING开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》收录

最后

都说三年是程序员的一个坎，能否晋升或者提高自己的核心竞争力，这几年就十分关键。

技术发展的这么快，从哪些方面开始学习，才能达到高级工程师水平，最后进阶到Android架构师/技术专家？我总结了这 5大块；

我搜集整理过这几年阿里，以及腾讯，字节跳动，华为，小米等公司的面试题，把面试的要求和技术点梳理成一份大而全的“ Android架构师”面试 Xmind（实际上比预期多花了不少精力），包含知识脉络 + 分支细节。

**[CodeChina开源项目：《Android学习笔记总结+移动架构视频+大厂面试真题+项目实战源码》](

)**

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

-1kulp9cH-1631343266528)]

[外链图片转存中…(img-xo7kMiXj-1631343266528)]

[外链图片转存中…(img-xaHl18hc-1631343266529)]

网上学习 Android的资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。希望这份系统化的技术体系对大家有一个方向参考。

2021年虽然路途坎坷，都在说Android要没落，但是，不要慌，做自己的计划，学自己的习，竞争无处不在，每个行业都是如此。相信自己，没有做不到的，只有想不到的。祝大家2021年万事大吉。