第 3 篇我们讲过 Kotlin 协程的入门用法。到了高级篇，光会 launch 和 withContext 已经不够了。面试官会追问： Dispatchers.Default 和 Dispatchers.IO 到底有什么区别？ Job 和 SupervisorJob 的差异是什么？ 协程异常为什么
几乎所有 Android 项目都会遇到一个共同问题：对象该在哪里创建？ 一开始我们用单例：Repository.getInstance()。然后发现测试困难、生命周期混乱、Mock 麻烦。再后来项目变大，模块之间互相引用，改动一处可能引发连锁反应。 依赖注入（DI）就是解决这个问题的方法论，而 Hi
当你开始做大型 App，或者接入 SDK、插件化、多进程保活时，跨进程通信（IPC）是绕不开的坎。 Android 系统里几乎所有核心服务都在 SystemServer 进程里运行，你的 App 要和它们打交道，全靠 Binder。但很多工程师工作了几年，对 Binder 的理解还停留在“一个跨进程
上一篇我们聊了启动、内存、卡顿的整体方法论。从这一篇开始，进入高级篇，我们选择一个当下最热门也最容易被误用的方向深入：Jetpack Compose 性能。 Compose 的声明式 UI 极大地提升了开发效率，但“写起来爽”和“跑起来顺”是两件事。我见过太多团队： 把 XML 直接翻译成 Comp
性能优化是 Android 工程师晋升高位的必备能力，但也是最容易被玄学化的领域。 我听过太多错误的说法： "把 WebView 换成 X5 就快了"——其实你的卡顿和 WebView 关系不大。 "加 LruCache 内存就够了"——其实 LruCache 救不了真正的内存泄漏。 "上 Prof
首先需要能够调用 LLM，但这些模型动辄几百亿甚至几千亿参数，对算力要求极高，就算是 DeepSeek、Llama 这类开源模型，普通电脑也很难跑得动。 所以我们开发者一般使用 LLM 方式是：由模型服务商把模型部署在他们的服务器上，我们通过网络请求调用它，按用量付费。这个请求接口就是 LLM 的
过去三篇我们谈的是"具体技术"——生命周期、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 页
