Booster 3.0 正式发布，支持 AGP 4.1
在 Booster 3.0.0 版本中，所有模块和特性已完全支持 Android Gradle Plugin 4.1.0，本次更新内容如下：
在 Booster 3.0.0 版本中，所有模块和特性已完全支持 Android Gradle Plugin 4.1.0，本次更新内容如下：
两周前，我就向 Booster 用户承诺 10 月底会发布 3.0.0 ，集成测试在 10 月中旬其实就已经完成了，后来把集成测试框架 testkit-gradle-plugin 又重写了一遍（已经是第 3 次重写了），加上 Travis-CI 正在从 https://travis-ci.org 迁移到 https://travis-ci.com ，而 Booster 还是在 https://travis-ci.org 上，导致 CI 长时间的排队，加上跑集成测试时间过长（超过 50 分钟)，任务被 Travis-CI 强行终止，所以，直到 10 月的最后一天才发布 v3.0.0-alpha-3，其实，在发布 alpha 版本的时候，任务被 Travis-CI 强行终止的问题都还没解决，只好把集成测试从 CI 中暂时移除掉，不过，这个问题已经有了解决方案。
最近在撸一个测试 Gradle Plugin 的 Plugin – bootstage/testkit-gradle-plugin，由于跑 Gradle Plugin 的 Unit Test 必须要使用 Gradle 的 plugins DSL 来启用插件，所以，万般无奈之下，只好用了 Gradle 官方推荐的最佳实践，结果掉进了坑里。
最近在准备 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 请大家喝酒吧”，突然，画风不对了，群名被修改为“架构组散架群”，当时就一口茶喷到屏幕上，笑到肚子疼，看着聊天记录，一幕幕往事不禁浮现在脑海中。