Booster 3.1.0 版本更新内容如下：

1. booster-task-compression-cwebp 支持通过 booster.task.compression.cwebp.ignores 属性排除不需要压缩的资源

在日常的需求迭代中，我们经常会遇到 Fragment 之间共享数据的需求，比如 Fragment A 的数据需要给 Fragment B ，有什么样的方案可以实现呢？

前段时间体验了一把在浏览器中使用 Android Studio 开发 Android 应用，感觉到了前所未有的激动，我之所以激动并不是因为 IntelliJ 全家桶都可以在云端运行，而是这种架构模式可能就是整个移动互联网的未来。

这两天，生物学术界炸锅了，困扰了分子（结构）生物学 50 多年的问题被 Google DeepMind 团队在短短数年间给解决了。

自 CASP 成立 20 多年以来，蛋白质结构预测的准确率一直没有超过 50%（感觉还不如抛硬币的概率 🤣🤣🤣），2018 年 DeepMind 团队以初代的 AlphaFold 首次参加 CASP (Critical Assessment of protein Structure Prediction) 比赛，便以 60% 的预测准确率刷新了历史纪录而摘得桂冠。仅仅时隔 2 年（每 2 年举办一次），DeepMind 团队便将 AlphaFold 升级到了 AlphaFold 2 ，在这次的 CASP 比赛中，其成绩再一次刷新了历史记录，而且相较于初代 AlphaFold 超出了近 50%，其整体平均正确率已经达到了 92.4%！即使是最复杂的蛋白质结构，其正确率的中值也达到了 87.0%！简直是吊打其他的参赛团队。一般认为能达到 90% 以上的正确率，基本上就等同于通过实验得到的结果了，那这意味着什么呢？

大家吐槽 Android 构建慢已经不是一天两天了，尽管都已经换成了最新款的 MBP，打个包依然要等一根烟的时间，不是 RD 小哥偷懒不干活儿，本地打包的时候机器卡得一批，实在是啥也干不了呀。

早在 7 年前，云计算刚刚起步，那时候 Docker 还没有流行起来，我们 SAMSUNG 一帮人就开始在捣鼓 Cloud IDE ，当时业界做得最好的是 Cloud 9 ，当然，我们也参考了 Cloud 9 的方案，部分组件参用了 Cloud 9 的开源实现，而 Cloud IDE 的插件系统和一些 UI 视图都是从零开始搭建。

在 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 爆了。