最近在准备 Booster 的 v3.0.0 发布前的测试，为了保证 Booster 的质量，对 Android Gradle Plugin 从 3.0.0 到 4.1.0 挨个版本进行了适配，并写了大量的集成测试，在跑测试用例的过程中，刚开始跑 debug 的构建测试用例一切挺顺利的，后来脑子一抽，把 release 构建也加上吧，没想到，整个测试用例就卡在 Android Gradle Plugin 3.5.0 的用例上不动了，试了很多次，也一直这样，后来一看，原来已经是 OOM 了，还 dump 了一堆 hprof 文件，看了一下 JUnit 的测试报告才发现，原来是 Metaspace 爆了。
每当我跟 IT 圈内的朋友说我是生物专业的时候，对方都会大吃一惊，身边的朋友都说我是一个被代码耽误的厨师 😂 ，说心里话，我确实对烹饪挺感兴趣的，很多不喜欢做饭的朋友表示无法理解，一方面可能是基因遗传的缘故，另一方面可能是大量的实践（从我6岁开始，我妈就开始教我煮饭，在我13岁的时候便能独立待客了）。尽管煎炒煮炸难不倒我，但 20 多年的烹饪经历，我始终没能成为真正的大厨，充其量只能算朋友圈的大厨罢了，烹饪之于我，无论是中式还是西式，基本功都很熟练，为什么却一直止步于此呢？
周末在家正刷着 GitHub 呢，微信收到一条消息：“森哥，像 ksp , allopen 这些 Kotlin 的编译器插件，它们是怎么 run 起来的，看了半天一头雾水”，我心想，“不应该呀，十有八九是通过 SPI 来实现插件的加载的”，于是，我赶紧瞅了一眼 JetBrains/Kotlin 的代码，找到了 KotlinGradleSubplugin.kt，于是，假装很懂的样子，发了一个 KotlinGradleSubplugin.kt 的代码截图给他。
最近做字节码相关的朋友求救：“森哥，ASM 怎么才能识别 kotlin 的 data class?”，我想，这是啥需求还要区分 data class 和非 data class ，后来一问，原来是要把工程中所有实现了 Serializable 接口的 Java 类和 Kotlin 的 data class 单独提取出来，将 Redis 中的 POJO 缓存进行可视化。
昨天晚上正在刷朋友圈，突然就被拉到一个群里，仔细一看，都是以前滴滴的同事，“啥情况？”我问道，扫了一眼成员，除了涛哥，都已经离职了，心想：“不会是涛哥拿了个大 offer 请大家喝酒吧”，突然，画风不对了，群名被修改为“架构组散架群”，当时就一口茶喷到屏幕上，笑到肚子疼，看着聊天记录，一幕幕往事不禁浮现在脑海中。
以前总有人问我：“森哥，我怎么才能成为像你一样的大牛？”，我一般就一句话“多折腾”搪塞过去，主要是懒得大费口舌，后来想想，这样也不太好，毕竟有些人还是很有诚意，真的渴望自己能够快速成长的，从我个人的经历来看，「多折腾」其实是包含了很多方面：
Booster 最近的两个版本主要是以修 bug 为主，所以，未发布正式的 Release Note ，本次发布的 2.3.0 版本可谓是一个重量级的版本，主要的更新内容如下：
Andriod Gradle Plugin 从 3.5 开始进行了一系列的重构，一些原来在 3.5 中的实验方案，在 3.6 版本中开始默认启用，所以，3.6 对于大多数 Gradle 插件来说，简直就是噩梦一样的存在，Booster 的一些模块和特性也受到了影响，如：
前不久 Android 官方终于正式发布了 Android Gradle Plugin v4.0，在体验了一把 Android Studio 4.0 的构建速度之快后，Booster 团队决定加速 Android Gradle Plugin 版本适配工作，一方面，为了解决现有的特性在 Android Gradle Plugin v4.0 上的问题，另一方面，推出自 Android Gradle Plugin v3.0 以来全版本适配方案，以解决开发者对 Android Gradle Plugin 的适配问题。