Google 的官方 Codelab 合集，哪些值得刷

Google 的官方 Codelab 合集，哪些值得刷

Android 开发者对 Codelab 的态度挺分裂的。一部分人觉得这是官方出的"手把手教程"，权威、路径清晰，适合快速上手新 API；另一部分人刷过几个之后就放弃了，理由是"太浅了，跟着点下一步就能跑，关掉页面就忘"。这两种看法都有道理，但问题不在 Codelab 这种形式本身，而在于你选的是哪些、以及怎么刷。Google 的 Codelab 库现在攒了上百个，覆盖 Android、Flutter、Web、ML、Cloud 各个领域，质量参差不齐，有些确实就是 PR 性质的 Demo，有些则是理解某个复杂 API 的最佳入口。这篇文章把我这些年刷过的、带团队刷过的、以及踩过坑的挑出来，按实际价值排个优先级，顺便说说哪些可以跳过。

先泼冷水：Codelab 的设计局限

Codelab 这个形式的基因决定了它的天花板。它诞生于 Google 的开发者关系团队，核心目标是降低新技术的试用门槛，让你在一小时内跑通一个"能看"的结果。所以它的典型结构是：环境准备 → 复制粘贴代码块 → 解释一两句原理 → 看效果 → 下一步。这种设计对"体验"友好，对"理解"未必友好。

一个具体的问题：很多 Codelab 的代码片段是高度简化的，甚至为了教学目的故意回避了生产环境要考虑的边界情况。比如早期的 Jetpack Compose Codelab 里，状态管理用的是最简单的 remember，对于配置变更（configuration change）的处理只字不提，新手跟着做完会误以为 remember 能扛住旋转屏幕，直到真上了设备才一脸懵。这不是 Codelab 的错，但如果你只刷 Codelab 不读文档、不自己改着玩，就会带着这种半吊子认知进项目。

另一个坑是版本漂移。Codelab 的代码仓库更新频率远低于对应的库本身。Compose 从 1.0 到 1.5 再到现在的 BOM 管理，很多 API 都变了，但 Codelab 里的 build.gradle 可能还在用旧版的依赖声明方式。我去年带新人刷 "Jetpack Compose Navigation" 那个 Codelab，里面用的 navigation-compose 版本还是 2.4.x，而最新稳定版已经是 2.7.x，NavHost 的某些 lambda 参数签名都变了，跟着抄会报编译错误。这种情况需要自己对照迁移指南修，对新手不友好。

所以我的建议是：把 Codelab 当成"有向导的实验课"，不是"系统课程"。刷的时候必须同时开着官方文档和 API reference，遇到不懂的立刻跳出去查，不要闭着眼睛点下一步。

第一梯队：值得认真刷的精品

Jetpack Compose Basics

这是 Compose 的入门 Codelab，链接在 developer.android.com/courses/android-basics-compose/course，属于 Android Basics with Compose 课程的一部分。但单独把这个 Codelab 拎出来也值得。

它的价值在于结构非常克制。没有一上来就堆 Material Design 组件，而是先讲 @Composable 函数的本质、重组（recomposition）的基本机制、状态提升（state hoisting）的模式。代码量不大，但每个改动都有明确的意图说明。比如它在引入 rememberSaveable 的时候，会明确对比 remember 和 rememberSaveable 在配置变更时的行为差异，让你用 Logcat 自己验证——这比很多博客文章讲得清楚。

我推荐的刷法：不要复制粘贴，手敲。Compose 的语法对习惯了传统 View 系统的开发者有思维转换成本，by remember 这种委托属性写法、Slot API 的嵌套模式，手敲三遍和复制一遍的记忆深度完全不同。另外，这个 Codelab 最后会引导你做一个简单的列表页面，建议在这里自己加需求：加个下拉刷新、加个空状态、加个错误重试。Codelab 没要求你做的，才是检验理解的地方。

局限也很明显：它停在"能写 UI"这一层，对性能优化、自定义 Layout、Compose 与既有 View 系统的互操作（比如 AndroidView）完全没有涉及。刷完这个你够写 Demo，不够写生产代码。需要继续跟 "Jetpack Compose Advanced State and Side Effects" 以及官方文档的 Performance 章节。

Advanced State and Side Effects

这个是 Compose 进阶的必刷项，链接在 developer.android.com/codelabs/jetpack-compose-advanced-state-side-effects。它处理的是真实应用里最头疼的问题：副作用管理。

Codelab 的核心案例是一个"带搜索的列表"，涉及到 LaunchedEffect、rememberUpdatedState、DisposableEffect、SideEffect 这几个容易混淆的 API。它的教学设计很聪明：先给你一个"看起来能跑但有 bug"的版本，让你遇到实际问题（比如快速输入时搜索请求竞态），然后逐步引入正确的副作用 API 解决。

这里有个细节值得注意：它对 derivedStateOf 的讲解是在性能优化语境下的，而不是简单介绍 API 签名。很多开发者知道 derivedStateOf 能缓存计算结果，但不知道它应该用在什么粒度。Codelab 给了一个具体场景：列表的滚动状态衍生出一个"是否显示返回顶部按钮"的布尔值，这个计算很轻但触发频繁，用 derivedStateOf 避免不必要的重组。这种"什么时候用"比"怎么用"更重要的教学思路，是这个 Codelab 高出平均水准的地方。

坑在于它对 produceState 的涉及很浅，而这个 API 在桥接非 Compose 的异步数据源时非常实用。刷完这个建议直接去读 produceState 的源码和官方文档里的 Use case 部分。

WorkManager Codelab

后台任务一直是 Android 开发的痛点，JobScheduler、Firebase JobDispatcher、AlarmManager 的历史包袱让选择困难。WorkManager 统一了这部分 API，但本身的复杂度也不低：约束条件（Constraints）、重试策略、链式任务、输入输出数据传递、前台服务（Foreground Service）的集成，每个点都能单独讲一小时。

"Background Work with WorkManager" 这个 Codelab（developer.android.com/codelabs/android-workmanager）是我见过讲 WorkManager 最清晰的入门材料。它的案例是"模糊处理图片并上传"，覆盖了 OneTimeWorkRequest、链式调用（then）、输入输出（setInputData/outputData）、以及进度通知。

特别值得看的是它对 Worker 生命周期和线程模型的说明。很多开发者踩过的坑：把 Room 数据库操作直接写在 doWork() 里，没意识到默认是在后台线程执行的，但如果用了 ListenableWorker 的变体，线程模型又不一样。Codelab 在这里有明确的代码注释和解释。

局限是案例太"理想"了。真实场景里，你的后台任务可能要处理网络状态波动、用户中途杀死应用、Doze 模式的限制、以及 Android 12+ 对前台服务的严格管控。Codelab 里的"上传成功"假设了网络稳定，没有涉及 NetworkType.CONNECTED 约束的细粒度配置，也没有讲 WorkManager 的调试和观测（WorkManager.getInstance(context).getWorkInfosByTagLiveData 这类 API）。刷完需要再读一遍官方文档的 "Guide to background processing" 和 "WorkManager 的高级概念"。

Macrobenchmark 性能测试

Android 性能测试的工具链在过去几年变化很大，从早期的 Systrace、Android Studio Profiler，到现在的 Baseline Profiles、Macrobenchmark、Microbenchmark，门槛越来越高但收益也越来越明确。

"Macrobenchmark" 这个 Codelab（developer.android.com/codelabs/android-macrobenchmarks）是理解这套工具的最佳起点。它教你用 MacrobenchmarkRule 测量应用的启动时间和帧率（jank），并且自动生成 Baseline Profile。

这里要提一个具体的操作细节：Codelab 要求你在 build.gradle 里配置 testInstrumentationRunner，并且把基准测试放在 benchmark 这个 product flavor 里。很多新手在这里卡住，因为 Android Studio 的默认项目模板不会创建这个 flavor，需要手动改 build.gradle 的 android 块。Codelab 的说明文字在这个步骤上有点跳跃，我第一次跟着做的时候漏了 benchmark 的 buildType 配置，导致编译报错 Benchmark targets must use a non-debuggable buildType。这个错误信息在 Stack Overflow 上有不少讨论，Google Issue Tracker 里也有相关 ticket（issuetracker.google.com/issues/20399...），本质上是因为 benchmark 需要 release 签名的变体才能测出真实性能。

Codelab 本身没讲 Baseline Profile 的生成原理，只是让你跑 ./gradlew :app:generateBaselineProfile。如果你想理解 Baseline Profile 是怎么工作的——本质上是在 APK 里打包一个 baseline.prof 文件，ART 在首次安装时根据这个文件做 AOT 编译——需要额外去读文档。但这个 Codelab 作为"让你跑起来"的入口，价值足够。

坑在于它推荐的测试设备。Codelab 说"建议使用物理设备"，但没有解释为什么。实际上 Macrobenchmark 在模拟器上的结果非常不可靠，因为模拟器的 CPU 调度、GPU 渲染路径和真机差异巨大。如果你用 ARM 模拟器（Apple Silicon 上的 Android Emulator），结果可能比真机好 50% 以上，完全误导优化方向。我们团队内部的规定是：所有 Macrobenchmark 必须在 Pixel 6 或以上的真机上跑，且要清掉后台应用、固定 CPU 频率（需要 root 或特定的测试模式）。

第二梯队：有特定场景价值

Paging 3

Paging 库从 2 到 3 是重写级别的变更，API 完全不一样了。Paging 3 的 Codelab（developer.android.com/codelabs/android-paging-basics）讲的是 Pager、PagingSource、RemoteMediator 的协作模式。

这个 Codelab 值得刷的场景很明确：你在做一个需要无限滚动列表的应用，且数据源来自网络 + 本地缓存。它把 Room 和 Retrofit 的集成讲得很清楚，RemoteMediator 的 load 方法里怎么判断是 prepend、append 还是 refresh，这个状态机的理解是 Paging 3 最绕的地方。

但我要说一个不太认同的教学点：Codelab 推荐在 ViewModel 里直接创建 Pager 实例，用 viewModelScope 收集。这在简单场景没问题，但如果你的列表页面有复杂的筛选条件（比如电商应用的多维度筛选），Pager 的重新创建和旧数据流的取消逻辑会变得很脏。实际项目中我更倾向于把 Pager 的创建封装到 Repository 层，用 Flow 的 flatMapLatest 响应筛选条件变化，而不是让 ViewModel 直接操作 Paging 的构造。Codelab 为了简化教学省略了这层抽象，但新手容易误以为这就是标准架构。

另外，Paging 3 对 RecyclerView 的 Adapter 有要求，必须用 PagingDataAdapter，且 DiffUtil.ItemCallback 的实现要正确。Codelab 里的案例数据类很简单，主键是 Int，但真实项目里如果主键是复合的、或者后端返回的数据没有稳定主键，需要自己设计 ItemCallback，这里很容易出"列表闪烁"的 bug。Codelab 没覆盖这个痛点。

Data Store

SharedPreferences 的替代方案，DataStore 有两个实现：Preferences DataStore（键值对）和 Proto DataStore（强类型）。Codelab 在 developer.android.com/codelabs/android-preferences-datastore。

这个 Codelab 的亮点是明确对比了 SharedPreferences 的线程安全问题。它让你用 StrictMode 检测 SharedPreferences 的磁盘读取阻塞主线程，然后切换到 DataStore 的 Flow API 看差异。这种"先让你疼再给你药"的教学方式很有效。

但 DataStore 本身有个设计上的坑：它的 edit 操作是事务性的，但事务冲突的处理策略不够灵活。Codelab 里的案例是单进程写，没有涉及多进程场景。实际上如果你的应用有多个进程（比如带了 :push 进程的推送服务），DataStore 的线程安全保证会失效，这时候需要回退到 MMKV 或者自己加文件锁。这个限制在官方文档里有小字说明，但 Codelab 完全没提，容易让人误以为 DataStore 是万能替换。

CameraX

Camera2 API 的复杂度是公认的，CameraX 做了封装，但自己的 API 面也不小。"Getting Started with CameraX" 这个 Codelab（developer.android.com/codelabs/camerax-getting-started）能让你在 30 分钟内实现预览 + 拍照 + 图像分析的基础功能。

它的价值在于展示了 ProcessCameraProvider 的绑定生命周期模式，以及 ImageAnalysis 的 setAnalyzer 怎么和 ML Kit 或自定义算法对接。我们团队做扫码功能的时候，新人就是先刷这个 Codelab，再去看 zxing 的集成。

坑在于它对性能优化的涉及为零。CameraX 的默认配置在高端机上跑得挺顺，到中低端机上预览帧率掉、图像分析延迟，需要手动调 setTargetResolution 和 BackpressureStrategy。Codelab 里的分辨率是硬编码的，没有讲怎么根据 CameraCharacteristics 动态选择。另外，它用的 ImageAnalysis.Analyzer 默认回调在分析线程，如果你在这里做 heavy ML inference，会阻塞预览，需要自己做线程桥接。这些生产环境要考虑的问题，Codelab 不会教你。

第三梯队：可以跳过或只浏览

各种 "Build a XXX app" 的完整项目 Codelab

Google 喜欢出一类 Codelab，标题是 "Build a Weather app" 或者 "Build a Chat app"，号称从零到一。这类我通常建议跳过，或者只看架构相关的部分。

原因是它们为了"完整"而牺牲了深度。一个典型的结构是：前十步讲 UI，中间十步讲网络层，最后十步讲数据库。每一步都很浅，且技术栈是强绑定的（比如必须用某个特定的架构组件）。你跟着做完，得到一个能跑但看不懂为什么这样设计的项目。更糟的是，有些 Codelab 的架构选择本身就有争议，比如把 Repository 直接暴露给 Activity，或者 ViewModel 里持有 Context 引用。

如果你需要看一个完整的参考实现，直接去 GitHub 搜 Google 的 android-architecture-components 或 nowinandroid 仓库，后者是官方现在的"标杆项目"，用到了 Kotlin DSL、版本目录（Version Catalog）、模块化、Hilt、以及最新的 Compose 最佳实践。Codelab 形式的"完整项目"在信息密度上不如直接读源码。

大部分 ML Kit 的 Codelab

ML Kit 的 Codelab 数量很多，人脸检测、文本识别、条码扫描、智能回复... 但它们的共性是：让你跑通 Demo 很容易，改到生产环境很难。

一个具体问题是模型大小和精度权衡。ML Kit 的 Codelab 默认用云端模型（Cloud-based model），延迟高、需要网络，但精度好。实际移动端应用通常需要设备端模型（On-device model），这时候要换 API、处理模型下载、处理失败回退。Codelab 不会讲这些决策过程。另外，ML Kit 的某些 API（比如 Pose Detection）在低端机上的帧率只有 5-10fps，Codelab 的测试设备通常是 Pixel 旗舰，你不会意识到性能问题。

如果你确实要做端侧 ML，建议跳过 ML Kit Codelab，直接看 TensorFlow Lite 的文档和 tensorflow/examples 仓库，自己训练量化模型、用 NNAPI delegate 加速。

较早的 Architecture Components Codelab

Room、LiveData、ViewModel 刚出来那几年的 Codelab，现在看已经过时了。不是因为这些组件本身不能用，而是推荐用法变了。比如早期的 Room Codelab 推荐在 AsyncTask 里做数据库操作，后来是 Executors，现在是 Kotlin Coroutines 和 suspend 函数。LiveData 的 Codelab 大量用 Transformation.map，而现在更推荐 Flow 和 StateFlow。

这些旧 Codelab 没有被删除，只是加了"deprecated"标记，但搜索引擎还是会把它们排在前面。注意看页面顶部的版本声明，如果提到的是 Android 8 或 API 26 作为 target，基本可以关掉。

怎么刷最高效：我个人的习惯

带团队的时候，我会把 Codelab 分成两类： mandatory 和 optional。Mandatory 的是上面说的第一梯队，要求手敲代码、做笔记、提三个问题。Optional 的是第二梯队，允许只看关键步骤。

一个具体的操作：刷 Codelab 的时候同时开一个 Git 仓库，每一步 commit。Codelab 通常不会教你 Git 操作，但自己维护 commit history 有几个好处：一是可以 diff 看每一步改了什么，二是可以 checkout 到中间状态做实验（比如 Codelab 让你用方案 A，你可以回退到上一步自己试方案 B），三是最后留一个可以参考的代码基底。

另外，我要求团队在刷完一个 Codelab 的 48 小时内，做一个"破坏实验"：故意改错一个参数、删掉一行看起来不重要的代码、或者加一个边界条件，看系统怎么反应。比如刷完 WorkManager Codelab 后，把 setRequiredNetworkType(NetworkType.CONNECTED) 改成 UNMETERED，然后在蜂窝网络下测试，观察任务延迟行为。这种"破坏性学习"比顺着 Codelab 走一遍印象深刻得多。

最后，Codelab 的评论区和对应的 GitHub 仓库 issue 是宝藏。很多你遇到的坑，别人已经踩过并且有 workaround。比如 Compose Navigation Codelab 的代码仓库（github.com/googlecodelabs/android-compose-codelabs）里，closed issue 里有大量关于版本兼容性、动画配置、深层链接（deep link）的讨论，比官方文档更新更快。

关于付费和替代方案

Google 的 Codelab 本身是免费的，但背后依赖的工具链不一定。比如 Macrobenchmark 需要物理设备，CameraX 的完整测试需要多部不同厂商的手机，这些硬件成本是隐性的。另外，某些 Codelab 会推荐 Firebase 的服务（Cloud Storage、Firestore、Authentication），这些有免费额度但超了要付费。

如果 Codelab 满足不了深度学习的需求，有几个付费或社区资源可以补充：

几个具体的链接备忘

把文中提到的核心资源整理一下，方便直接访问：

最后说几句

Codelab 不是学习 Android 的终点，甚至不是主要路径。它更像是一个个精心设计的"实验入口"，让你以最低成本验证某个技术点是否值得深入投入。真正掌握一个技术，是在 Codelab 结束之后开始的：读源码、看 issue、在真实项目里踩坑、再回来看文档。

我见过的成长最快的开发者，都有一个共同习惯：不把官方教程当圣经。Codelab 让你跑通的代码，他们会追问"如果我不按这个方式写呢"；Codelab 回避的边界情况，他们会主动构造测试。这种"对抗性学习"的态度，比刷完一百个 Codelab 都管用。

Google 的 Codelab 库还在膨胀，每年 I/O 和 Dev Summit 都会有一批新的出来。我的筛选标准很简单：看它处理的是不是真实痛点、代码能不能直接放到生产环境审视、以及刷完之后我能不能回答"为什么这样设计"而不仅是"怎么实现"。按这个标准，值得刷的其实不多，但够精。