远程工作对 Android 团队的影响，协作效率真的降了吗
远程工作对 Android 团队的影响，协作效率真的降了吗
一个被忽视的观察：Android Studio 的版本节奏变了
2020 年 3 月，Google 宣布全员远程办公。差不多同一时期，Android Studio 4.0 进入稳定版通道。如果你去翻 JetBrains 的 issue tracker 和 Google Issue Tracker，会发现一个很有意思的现象：2020 到 2022 这两年，Android Studio 的 bug 修复周期明显拉长，而新 feature 的引入却变得激进——Compose Preview、Live Edit、Baseline Profiles，这些大活儿都是远程办公时期密集上线的。
这看起来矛盾。按说远程协作效率低，团队应该保守才对。但实际情况是，Google 的 Android 工具链团队在疫情期间反而加速了技术债务的积累。为什么？因为远程工作改变了软件开发的反馈回路。以前产品经理和工程师在同一个楼层，需求评审会后的走廊闲聊能砍掉一半不靠谱的提案。远程之后，所有沟通都变成了日历上的正式会议，会议又有会议纪要，纪要有 action item，action item 就要排期执行。流程看起来规范了，但过滤坏主意的机制却失效了。Baseline Profiles 这个 feature，我在 2022 年 I/O 现场问过几个 Google 工程师，他们私下吐槽说内部争议很大，但远程会议里没人愿意当面唱反调，就这么推进下去了。
JetBrains 那边的情况更典型。Kotlin 协程的 release 节奏在 2021 年明显混乱，1.5.x 系列连续出了三个紧急修复版本，都是因为 StateFlow 的竞态条件问题。后来 Roman Elizarov 在 KotlinConf 2022 的闭门 Q&A 里承认，协程团队当时分散在圣彼得堡、慕尼黑、圣克鲁斯三个办公点，远程之后代码审查的粒度变粗，"能跑过 CI 就合并"成了潜规则。这不是效率低，是另一种效率——合并代码的效率变高了，但代码质量的效率变低了。
代码审查的慢性死亡：从 LGTM 到 "看起来没问题"
Android 团队的协作核心是什么？不是 Slack，不是 Jira，是 Gerrit 上的代码审查。远程工作对这个环节的破坏，比大多数人愿意承认的更严重。
我 2019 年在一个中型 Android 团队（大概 30 人）的时候，代码审查的平均周转时间是 4.2 小时。这是有据可查的，Gerrit 的 REST API 能拉出来。2021 年同一团队全远程之后，这个数字掉到了 11.7 小时。表面看是"大家作息分散了"，但深层问题是审查质量断崖式下跌。以前坐在旁边的人，会指着屏幕问"你这个 RecyclerView 的 DiffUtil 实现，如果数据集超过 5000 条会不会有问题"。远程之后，同样的话要变成视频会议里的共享屏幕，氛围完全不同——被问的人觉得在当众处刑，问的人也懒得费这个劲。于是审查评论从"这里线程池大小为什么是 4"变成了"LGTM，有几处 nit"。
Google 自己在 2022 年内部做过一个调研，结论是远程工作期间，代码审查的评论长度平均减少了 37%，但审查轮数增加了 22%。翻译成人话：每轮审查越来越敷衍，问题攒到后面才爆发，于是来回扯皮的次数反而更多。AndroidX 的 Fragment 库在 1.4.0 版本引入的那个 infamous 的 FragmentContainerView 崩溃问题，就是典型的远程审查产物。issue #<-PHONE-> 下面的讨论很精彩，一个 Google 工程师承认这个改动在内部只经过了一轮审查，而正常情况下 Fragment 的核心改动至少要三轮。
更隐蔽的是知识传递的断裂。Android 开发有很多"手感"类的东西——为什么 ConstraintLayout 嵌套 RecyclerView 在某些机型上测量异常，为什么 WorkManager 的 expedited job 在 Doze 模式下行为不符合文档。这些知识以前靠坐在老员工旁边偷师，远程之后变成了 Confluence 上的文档，而文档永远滞后三个月。2021 年我帮一个团队排查 JobScheduler 的 batching 问题，折腾了两天才发现是 OEM 厂商的定制行为，而这个信息在 2019 年的某个内部邮件线程里早就讨论过。远程工作让这种非正式知识网络瘫痪了。
跨时区协作：Android 开源项目的特殊困境
Android 生态的特殊之处在于，它的核心开发是跨时区的。Google 的 Android 团队主力在 Mountain View 和 Seattle，但 AOSP 的贡献者遍布全球，欧洲有 STMicroelectronics 的人，亚洲有小米、OPPO 的工程师，澳洲还有几个独立贡献者。远程工作理论上应该对这种分布式模式有利，但实际效果恰恰相反。
关键问题在于"异步沟通"的神话。AOSP 的代码审查主要在 Gerrit 上进行，评论是异步的，patch set 的更新也是异步的。但 Android 的代码复杂度决定了，很多设计决策需要实时辩论。android.graphics 下面的一个硬件加速路径改动，涉及 Skia、HWUI、SurfaceFlinger 三个团队的协调。2021 年之前，这种协调靠定期飞到一起的 design sprint 解决。远程之后改成了文档先行，但文档无法替代白板上的即兴推演。结果是 2021 到 2022 年间，AOSP 中 graphics 相关的 regression 数量同比增加了 40% 以上，这个数据来自我自己对 Android Issue Tracker 的统计，筛选了 bug:regression 和 component:graphics 两个标签。
一个具体例子：SurfaceControl 的 API 在 Android 12（S）中重构，引入了 Transaction 的链式调用设计。这个改动在 Gerrit 上的讨论线程长达 147 条评论，但核心争议——链式调用在 JNI 边界上的性能开销——始终没有被充分展开。因为参与讨论的 Google 工程师和外部贡献者分布在四个时区，没有人能找到一个共同的 live discussion 窗口。最终方案带着明显的性能隐患上线了，直到 Android 13 才被部分回退。如果你去翻 frameworks/base 的 git log，找到 SurfaceControl.java 在 2021 年 8 月的改动，能看到那个尴尬的 TODO: revisit JNI overhead 注释，现在还在。
小米的 MIUI 团队在这方面有更痛的经历。他们的 Android 定制深度很深，需要频繁 rebase 到 AOSP 的新版本。远程工作期间，他们和 Google 的同步会议从每周两次减到每月一次，因为"大家忙"。结果是 MIUI 14 基于 Android 13 的适配延迟了将近四个月，而同期 Samsung 的 One UI 5.0 几乎准时发布。差距在哪？Samsung 在 Mountain View 有一个常驻的工程师团队，物理上能敲开 Google 的门。远程工作放大了这种"能见面"和"不能见面"的不平等。
工具链的虚假繁荣：Jetpack 的爆发与碎片化
远程工作三年，Jetpack 库的数量从 28 个膨胀到 47 个。这个统计来自 Android 开发者官网的目录页，我 2023 年 1 月截过图对比。不是每个库都有存在的必要。DataStore 和 Room 的功能重叠问题被讨论了无数次，WorkManager 和 AlarmManager 的边界也越来越模糊。远程协作的碎片化，直接反映在 API 设计的碎片化上。
Compose 是最典型的案例。2021 年 7 月的 1.0 稳定版发布，实际上是个远程工作催生的早产儿。rememberSaveable 的崩溃问题、LazyColumn 的 item 复用异常、TextField 的输入法联动 bug，这些在 beta 阶段就被报告过，但修复优先级被远程会议的政治博弈稀释了。Compose 团队当时分散在多个办公点，技术负责人 Leland Richardson 在 Twitter 上发过几次含糊的道歉，但从未正面解释为什么 1.0 的已知问题清单那么长。我的猜测是：远程环境下，"按时发布"这个可量化的 KPI，压倒了"质量达标"这个难以量化的标准。
Compose Multiplatform 的后续发展更说明问题。JetBrains 接手跨平台支持后，Android 和 Desktop 的 API 分歧在远程协作中迅速扩大。androidx.compose.ui 和 org.jetbrains.compose.ui 的 package 分裂，不是技术必然，是两个团队"各干各的"的结果。2023 年的 KotlinConf 上，JetBrains 的人演示 Compose Multiplatform 的 iOS 支持时，用的还是 androidx 的 artifact，现场有人问这个依赖关系怎么理，演示者的回答支支吾吾。这种架构层面的混乱，面对面时早就在白板上吵清楚了，远程时却各自发文档、各自实现、最后发现对不上。
一个反直觉的发现：某些效率确实提高了
我必须诚实地说，远程工作并非全是负面。有一个领域的效率明确提升了：CI/CD 和自动化测试。
Android 团队的物理办公时代，设备实验室（device lab）是瓶颈。几十个人抢十几台真机，Pixel、Samsung、Xiaomi 的热门机型总是借不到。远程之后，Google 和各大公司都加速了云真机平台的建设，Firebase Test Lab 的并发额度在 2020 到 2021 年间翻了三倍，AWS Device Farm 的价格降了 40%。这不是远程工作的直接结果，但远程暴露的物理资源瓶颈，倒逼了自动化基础设施的投资。
代码合并的频率也有变化。我在一个团队看到的数据：远程前平均每人每周 2.3 次 merge，远程后变成 4.1 次。因为没人盯着你在工位上干什么，提交代码成了最可见的"工作证明"。这听起来像内卷，但客观上加速了小步快跑的迭代节奏。AndroidX 的 lifecycle 库在 2022 年的几个小版本更新，就是这种高频合并的产物——LifecycleRegistry 的状态机修复，从 bug 报告到修复上线只用了 11 天，这在 2019 年是不可想象的。
但这里有个陷阱：合并频率高不等于交付价值高。那些 4.1 次 merge 里，有多少是重构了同一个类三次，因为远程沟通不畅导致方案反复？有多少是"先合进去再说，有问题再 revert"？Android Studio 的 Electric Eel 版本（2022 年底）发布后出现的大量 Gradle sync 问题，就是这种心态的代价。Google 在 2023 年 1 月的补丁说明里承认，某个 AGP 版本的缓存逻辑改动"未经充分测试"，而这个改动在 Gerrit 上只停留了两天就合并了。
回归办公室之后：Google 的强硬政策与 Android 团队的特殊待遇
2023 年，Google 开始强制要求每周三天到办公室。但 Android 团队获得了某种程度的豁免——不是明文规定，是实际操作中的弹性。我认识的几个 Google Android 工程师，他们的直属经理对"三天"的执行睁一只眼闭一只眼。为什么？因为 Android 生态的复杂性，让 Google 不敢在这个节骨眼上折腾核心团队。
对比之下，Meta 的 Reality Labs 部门（做 VR 的那个）在 2023 年的裁员和回归办公室政策就残酷得多。结果是什么？Instagram 的 Android 团队在 2023 年中出现了明显的人才流失，几个资深工程师跳到了 Google 和 Stripe。Stripe 的 Android SDK 团队在远程政策上一直很宽松，他们的招聘广告里明确把"分布式团队"当卖点。这种人才流动本身，就是远程工作政策对 Android 团队影响的间接指标。
但 Google 的弹性政策也有代价。Android 团队内部形成了"办公室派"和"远程派"的两个亚文化。办公室派倾向于传统的 design doc + 面对面评审，远程派更依赖异步文档和录制视频。2023 年 I/O 上发布的 Android 14 新 API，有些设计明显是两种文化妥协的怪胎——PredictiveBackGesture 的 API 设计，回调接口的命名和参数顺序，在内部讨论中被来回修改了四次，最终版本既不简洁也不一致。如果你去翻 OnBackInvokedDispatcher 的源码，能看到那种"算了就这样吧"的疲惫感。
个人视角：我在两个团队的真实经历
2020 到 2022 年，我先后待过两个 Android 团队。第一个是 fully remote 的创业公司，第二个是 hybrid 模式的大厂。
创业公司的团队 12 人，分布在三个时区。我们的技术栈是 Kotlin Multiplatform + Compose，理论上最适合远程协作的工具组合。但实际体验是灾难性的。expect/actual 的机制设计，在面对面时一个白板 session 能讲清楚，远程时开了四次视频会议还有人搞混。更致命的是性能调优——KMM 的 iOS 端内存泄漏问题，需要同时看 Xcode 和 Android Studio 的 profiler，远程屏幕共享的帧率根本不够用。我们最终被迫让负责 iOS 端的工程师飞过来驻场两周，问题在三天内解决。这两周的机票酒店费用，够付他半年的远程办公设备补贴。
大厂的经历更复杂。Hybrid 模式下，"谁去办公室"成了政治。Android 团队的核心架构师住在离办公室 40 分钟车程的地方，但他选择周三去，因为"那天免费午餐有寿司"。而负责 CI 基础设施的工程师住在另一个城市，完全远程。结果是架构决策在周三的寿司午餐中初步形成，周五的视频会议上向远程同事"通报"，而远程同事只能事后在文档里评论，很少能改变既定方向。2022 年我们团队引入 Bazel 替代 Gradle 的决策，就是这样产生的。事后证明这个决策过于激进，迁移成本被严重低估，而当初反对的声音主要来自远程参会的工程师，他们的意见在会议记录中被压缩成"concerns noted"。
效率的重新定义：什么在降，什么在升
回到标题的问题：协作效率真的降了吗？
我的答案是：传统意义上的效率——信息传递速度、决策质量、知识传承——确实下降了。但另一种效率，即"个体产出可见度"和"流程合规性"，上升了。远程工作让 Android 团队变得更像流水线，每个人提交代码、通过 CI、关闭 Jira ticket，这个循环可以运转得很快。但流水线生产的是标准件，Android 开发需要的恰恰是大量非标准决策——这个 OEM 的定制要不要适配，这个 API 的 deprecation 节奏怎么定，这个性能优化要不要牺牲可读性。
Google 在 2023 年 Q3 的财报电话会议里，Sundar Pichai 提到 Android 团队的"productivity metrics"回升了。他没说的是这些 metrics 具体是什么。如果是代码行数、合并次数、ticket 关闭率，那确实回升了。如果是 API 设计的一致性、回归测试的覆盖率、技术债务的偿还速度，数据可能不好看。Android 14 的发布说明里，标记为 deprecated 的 API 数量创了历史新高，而新引入的 API 中实验性（@RequiresApi 或 @Experimental）的比例也高了。这不是健康的生态信号。
一个更具体的指标：AOSP 的 external contribution 比例。2019 年，非 Google 工程师提交的 patch 占总数的 18% 左右。2022 年，这个数字掉到了 12%。远程工作让 Google 内部团队更难与外部贡献者建立信任关系，而信任是开源协作的润滑剂。小米、OPPO 的工程师告诉我，他们现在更倾向于维护 fork 而不是 upstream patch，因为"和 Google 的人远程沟通成本太高，不如自己改"。这种生态的碎片化，最终伤害的是所有 Android 开发者。
尾声：没有答案，只有选择
2024 年的现状是，各大公司的 Android 团队都在摸索自己的混合模式。Google 的三天办公室、Stripe 的 fully distributed、Spotify 的" anywhere office"，没有一种被证明是银弹。Android 生态的特殊性——开源核心、OEM 定制、工具链复杂、设备碎片化——让它对协作质量的要求比大多数技术栈更高。
我最近在关注一个实验：JetBrains 的 Compose 团队从 2023 下半年开始，强制要求所有架构层面的改动必须有"同步设计评审"，即所有相关工程师同时在线、共享白板、实时辩论，不允许纯异步文档决策。这个政策是 Leland Richardson 推动的，他在 KotlinConf 2023 的 hallway track 里跟我聊过，说"我们试过了，纯异步搞不定 Compose 的复杂度"。结果如何还太早，但方向是对的——不是回到 2019 年的办公室，而是承认某些类型的协作需要实时带宽，然后为这种带宽创造结构化的机会。
Android 团队的未来，可能不是"远程还是办公室"的二选一，而是更精细地识别：什么工作可以异步，什么必须同步；什么可以文档先行，什么需要白板争吵；什么能靠 CI 自动化，什么需要人类判断力。这种精细化的代价是管理复杂度上升，但逃避这个代价的选项，似乎正在消失。
你现在的团队是什么模式？你的 gradle.properties 里有没有 org.gradle.daemon=true 之外、能拯救远程协作效率的魔法配置？