2019 年 4 月 23 日 Booster 正式开源，短短一半年不到的时间，star 数已经 2.3k 了，说实话，还真有点超出预期，也给自己无限的动力，不断的完善它，希望能真的能帮助大家解决实实在在的问题，而不是为了开源吸粉赚 star，无奈下半年忙着车载的业务，也只有周末的时候偶尔提交几个 commit 和处理志国提交的 PR，还得抽空写写 Booster 项目中的一些想法、实现思路和细节，如果多抽点时间来完善 Booster 的话，估计现在已经 3k 以上的 star 了。

最近终于有精力来想想明年 Booster 该做些什么了，从自己了解到的一些信息和反馈来看，目前 Booster 除了框架本身比较稳定，其实很多优化 feature 可能或多或少的存一些不适用的情况，所以，接下来，想把一个 feature 拆得更细，更好的适应各种情况，做到开箱即用，而且用起来还很香。

资源

针对资源的优化是最能体现收益的，比什么字节码、指令优化对于包体积的减少要来得快，而且相对更容易一些，所以，想把原来资源优化分成以下几个模块：

  1. pngquant 压缩 resource
  2. pngquant 压缩 assets
  3. webp 压缩 resource
  4. webp 压缩 assets
  5. 去重复 resource
  6. 去重复 assets
  7. 资源索引内联
  8. ButterKnife 资源索引内联

由于 pngquant 的 license 问题，所以，跟 pngquant 相关的模块都得采用 GPL License 跟 Apache License 分开，将 pngquant 内置到 JAR 包中。

线程

针对线程的优化容易踩坑，所以，把重命名单独抽出来，毕竟重命名对于 APM 采样是非常有价值的，所以，拆成以下两个模块：

  1. 线程重命名
  2. 线程池优化

性能瓶颈检测

静态分析技术算是最难的一部分了，所以放到了最后，先把容易的事情做了（万一太难搞不定），Booster 目前的性能瓶颈检测做得比较简陋，对 Handler 、多线程、接口等一些复杂的情况支持得不是很好，所以，这块的思路是引入 IR 来解决

功能服务化

将性能分析与检测的能力部署到服务端，上传 APK 进行分析，然后得出分析报告，报告中包含几个部分：

  1. 现存的问题
  2. 可以优化项及预期收益
  3. ...

感觉这些已经够折腾一年了（可能还不够），如果能有志同道合的小伙伴一起为开源社区贡献一份力量，是最好不过的了，如果您有兴趣的话，可以在评论区留言或者直接联系我，期待更多的小伙伴的加入...