自 AGP 8.0 正式版本发布以来已经一个多月了，Booster 适配 AGP 8.0 还在持续进行中，主要是 AGP 8.0 删除了很多之前只是 deprecated 的 API，包括部分 Transform API，而且 Legacy Variant API 也即将删除，取而代之的是 Instrumentation API、Artifacts API 和 New Variant API，虽然新的 API 从 AGP 7.0 开始就已经出现，但是这些新的 API 从 AGP 7.0 到 AGP 7.4 都一直在改，并没有完全稳定下来，加上跟以前的 API 完全不兼容，我们也不确定最终稳定下来会是什么样子，加上 Booster 已经支持了从 AGP 3.3 到 AGP 7.4 的 12 个版本，贸然变动 API，对于 Booster 的使用者来说，迁移也是一项非常有挑战性的事情，看到 AGP 8.0 终于删除了之前标记为废弃的 API，我们认为它的 API 也稳定下来了，是时候干一票大的了。
在做架构设计的过程中，我们经常会提到一个概念——“标准化”。标准化，通过设定最佳实践和创建统一的标准，确保企业在所有业务领域中实现一致的性能。然而，当我们完成了标准化之后，我们应该怎么做呢？下一步又是什么？是否存在一个通用的框架，能够指导架构师和技术负责人进一步优化和发展？经过一番思考，这个框架在我脑海中变得逐渐清晰——从「规范化」到「标准化」再到「平台化」的三段式进阶模式。
I was at Amazon for about six and a half years, and now I’ve been at Google for that long. One thing that struck me immediately about the two companies – an impression that has been reinforced almost daily – is that Amazon does everything wrong, and Google does everything right. Sure, it’s a sweeping generalization, but a surprisingly accurate one. It’s pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn’t let me show it to anyone, even though recruiting loved it.
随着移动互联网的普及，移动应用逐渐成为人们生活中不可或缺的一部分。为了满足用户对于高品质应用的需求，移动工程师们在不断探索如何提高开发效率、降低开发成本的同时，实现更好的用户体验。本文将从移动应用开发的角度，从 UX 一致性和研发效率出发，探讨设计系统的重要性及其最佳实践。
在前一篇 Kotlin 填坑记之 FunctionReference 中有提到关于如何解决 Kotlin 从 1.3 升级到 1.5 时由 FunctionReference 引发的兼容性问题，其实，Kotlin 的兼容性问题远不只这一个，如何系统性的解决 Kotlin 的兼容性问题呢？
在 Booster 4.15.0 之前，一直使用的是 Kotlin 1.3，之所一直用比较低的 Kotlin 版本，主要的原因还是考虑到 Kotlin 版本的兼容性问题，但要支持 AGP 7.3 就不得不升级 Kotlin 版本，因为 AGP 7.3 就依赖了 Kotlin 1.5，所以，Booster 4.15.0 花了很长的时间来解决兼容性的问题。
最近看了很多工程师写的文档，发现工程师们普通存在的问题，要么通篇都是文字一个图也没有，要么技术规划全是一堆的 task，根本看不清楚这些 task 跟整体的目标是什么关系，等等，即便是高级工程师，有类似问题的也大有人在。