背景

在 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 时间片，然而，过多的竞争意味着过多的资源浪费在了线程调度上。

对于一款 APP 来说，卡顿率、ANR 率是衡量这个 APP 质量的两个重要指标，目前已经有很多成熟的 APM 工具和平台来统计 APP 的运行时性能，但是对于实行敏捷开发的产品来说，从 APP 开发，到灰度发布，再到全量，要经历一个漫长的过程，等到收集到上报的卡顿和 ANR，再去修复，又要经历灰度、全量这一漫长的过程。

Booster 是一款专门为移动应用设计的易用、轻量级且可扩展的质量优化框架，其目标主要是为了解决 APP 复杂度的提升而带来的性能、稳定性、包体积等问题。

为什么是 Booster?

质量优化是所有应用开发者都要面临的问题，对于 DAU 千万级的 APP 来说，万分之一的崩溃率就意味着上千的用户受到影响，对于长时间在线的司机来说，司机端 APP 的稳定性关乎着司机的安全和收入，所以更是不容小觑。