性能优化是 Android 工程师晋升高位的必备能力，但也是最容易被玄学化的领域。 我听过太多错误的说法： "把 WebView 换成 X5 就快了"——其实你的卡顿和 WebView 关系不大。 "加 LruCache 内存就够了"——其实 LruCache 救不了真正的内存泄漏。 "上 Prof
过去三篇我们谈的是"具体技术"——生命周期、Compose、协程。这一篇开始，我们谈"如何把这些技术组织起来"，也就是架构。 很多工程师对架构有一种误解：以为它只是"换名字"——把 Controller 叫 ViewModel，把 View 叫 Composable……确实只是命名游戏，但更核心的是
最近我团队面试了 14 个 Android 工程师，只有 3 个人能讲清楚"协程的挂起到底在挂什么"。 这个数字让我有点意外。协程已经是 Android 官方推荐的并发方案，Compose、Room、Retrofit、WorkManager 的官方文档全部基于协程。即便如此，它依然被大量工程师当作"
上一篇文章末尾，我说 Compose 是"真正的范式转移"。这句话听起来像吹牛，今天我要把它拆开给你看。 三年前，我也持怀疑态度。XML 不是好好的吗？findViewById 的"啰嗦"我们都已经习惯了，DataBinding 不是也能省掉 findViewById 吗？Compose 这套东西，
写 Android 代码的第三年，我依然会在 onCreate 里犯蠢。 听起来不可思议，但这事真发生过——我曾经在 Activity 的 onCreate 里 new 了一个 Handler，然后用 postDelayed 做了一个延时任务，期望页面销毁时这个任务能"自动消失"。结果用户从 A 页
