本来没打算写这篇文章，毕竟项目工程规模并不复杂，网上也有很多分析 Booster 的文章，但大多都只是对工程的结构介绍一下，加上总有同学问起，索性详细的介绍一下。如果说 Booster 框架在设计上有什么亮点的话，大致罗列一下：

v0.28.0 版本更新内容：

1. 解决 transform 过程中个别 JAR 存在重复的 Zip Entry 导致编译失败的问题^1

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

在我的职业生涯中，目前为止，在滴滴的这段经历算是我最长的一段履历了，历时四年有余，终于还是选择了离开，回想起来，一切仿佛似昨天。尽管离开的比较坚决，但往昔的点点滴滴，历历在目，难免有些伤感，却未曾遗憾，能跟一群靠谱的小伙伴共事，也是人生一大幸事。

背景

在 booster v0.1.5 版本其实就已经提供了针对 SharedPreferences 的优化，只不过优化的幅度比较小，毕竟 SharedPreferences 在 Android 中应用得过于广泛，所以，对它的优化非常非常谨慎，以至于我们经过了线上好几个版本的验证，才推出最新的优化方案。

在上一篇文章中已经介绍过 booster 正在做的 Layout Transpiler —— 将 XML 布局文件翻译成 class 的转译器，在实现的过程中发现了 Android 系统在设计上的各种坑，而且是天坑，几乎是绕不过去了，最近 Android 官方发布了 JetPack Compose 让我眼前一亮，这不就是我想要达到的效果么，只不过是换了一种形式罢了。

做过开发的同学都深有体会，用 XML 来撸 UI 的效率简直是吊打手写代码，在 Anko (Kotlin 库) 还没有流行之前，大家对 XML 还是亲睐有加，虽然性能上偶尔会有卡顿，但是总体来说，还是勉强能接受，但是 Anko 的流行，也让我们开始思考，有没有办法既能享受 XML 撸 UI 的快感，又能享受像 Anko 一样的性能呢？

许多 Android 开发者可能经常遇到这样的情况：测试的时候好好的，一上线，各种系统的 crash 就报上来了，而且很多是偶现的，比如：

• WindowManager$BadTokenException

一般 assets 出现大量重复的情况是不多见的，只有多业务线的大体量 APP 才有可能遇到。然而非常不幸的是，我们就遇到了这样的问题，虽然对包体积的影响不是很明显（也就几百 KB），但是几百 KB 对于做包体积优化的同学来说，蚊子肉也是肉啊。

对于开发者来说，线程管理一直是最头疼的问题之一，尤其是业务复杂的 APP，每个业务模块都有着几十甚至上百个线程，而且，作为业务方，都希望本业务的线程优先级最高，能够在调度的过程中获得更多的 CPU 时间片，然而，过多的竞争意味着过多的资源浪费在了线程调度上。