Rust 写 Android 系统服务，Google 的新尝试
Rust 写 Android 系统服务，Google 的新尝试
AOSP 主线的 Rust 代码正在变多
去年刷 AOSP 的代码仓库时，我注意到一个挺有意思的变化：system/core 目录下冒出了几个 .rs 文件。不是某个工程师的个人实验，是正经的 init 进程相关代码在引入 Rust。当时我就截了张图丢到群里，说 Google 这回好像来真的了。群里有人回 "Rust 写驱动不是新鲜事"，但 Android 系统服务和 Linux 内核驱动是两码事。AOSP 的代码风格保守得要命，C++ 都用了这么多年，Google 突然开始往系统层塞 Rust，背后肯定有具体的痛点在推动。
这件事的标志性节点是 Android 14。Google 在官方博客和 I/O 演讲里开始公开讲 Rust 在 AOSP 的采用，不再是偷偷摸摸试点。到了 Android 15，Rust 模块的数量明显膨胀，虽然跟整个 AOSP 的代码量比起来还是九牛一毛，但增长曲线很陡。我拉了一下 AOSP 的提交记录，从 2021 年到 2024 年，Rust 代码的提交数每年翻倍都不止。这个增速放在 Google 这种体量的项目里，说明不是某个小团队的兴趣项目，而是有顶层支持的迁移策略。
让我真正觉得 "这事要成" 的，是 keystore2 的实现。Android 的密钥存储服务以前全是 C++，安全关键代码，漏洞历史一长串。Google 在 Android 14 里把 keystore2 的核心逻辑用 Rust 重写了一遍，还发了篇挺详细的技术博客讲迁移过程。博客里提到的一个数字很扎眼：用 Rust 重写后，某类内存安全相关的 CVE 直接归零。Google 的工程师原话是 "eliminated an entire class of vulnerabilities"，语气很硬，不是那种 "有望改善" 的模糊说法。
为什么是系统服务，不是应用层
这里有个关键的分界线。Google 推 Rust 不是让你用 Rust 写 App，Android 应用开发的主力语言还是 Kotlin，Compose 也是 Kotlin first。Rust 的战场在 AOSP 本身，在 system_server、init、各种 native daemon 里。这个选择很务实，也跟 Google 公开讲的安全战略对得上。
Android 系统服务的崩溃代价极高。system_server 挂了，整个系统重启，用户看到的是 "System UI isn't responding"。某个 native daemon 内存泄漏，可能拖垮整机的流畅度。这些代码跑在特权模式，漏洞的利用面比应用层大得多。Google 的年度安全报告里，内存安全漏洞长期占据 CVE 的三分之二以上，C/C++ 的指针算术和手动内存管理是重灾区。
Rust 的所有权模型和编译期检查，理论上能在不牺牲性能的前提下干掉这类漏洞。这个 "理论上" 在系统服务场景特别值钱，因为这里性能确实敏感，你没法像某些应用层框架那样靠 GC 和运行时检查来兜底。Google 的工程师在演讲里提到，keystore2 的 Rust 版本性能跟 C++ 原版持平，延迟分布甚至略好，这打消了很多人 "Rust 编译期检查有运行时开销" 的顾虑。
不过我要泼点冷水。Rust 的内存安全保证是有前提的：你得写 "正常" 的 Rust 代码，不滥用 unsafe。而 AOSP 的系统服务要跟内核打交道，要跟硬件抽象层（HAL）交互，要跟现有的 C/C++ 代码库对接，这些边界上 unsafe 几乎是避不开的。Google 的解决方案是搞了一套 FFI 绑定生成工具，叫 bindgen 的 Android 定制版，尽量把 unsafe 隔离在薄层的封装里。但 "尽量隔离" 不等于消除，keystore2 的代码里我数过，unsafe 块还是有几十个，集中在跟 TEE（可信执行环境）通信的接口。这些位置依然是潜在的漏洞点，只是比原来满篇指针的 C++ 好审计一些。
C++ 的债，Google 还得很痛苦
AOSP 的 C++ 代码库是个历史包袱的博物馆。从 Android 1.0 一路堆到现在，兼容性问题、硬件适配的 ifdef 海洋、各厂商的私有补丁，层层叠叠。Google 不可能像某些创业公司那样 "rewrite it in Rust" 一把梭，只能渐进式替换，而且替换的优先级得跟安全影响挂钩。
这个渐进策略的具体形态，在 Android 15 里看得比较清楚。Google 选了几个攻击面大、历史漏洞多的模块优先 Rust 化：keystore2 是一个，DNS 解析的 netd 部分组件是另一个，还有 init 进程里的某些配置解析逻辑。这些选择的共同点是：边界相对清晰，跟 C++ 老代码的交互可以限制在接口层，内部逻辑能相对独立地用 Rust 重写。
但更多模块的迁移卡在 FFI 的复杂度上。比如 surfaceflinger，Android 的合成器，性能极其敏感，跟 GPU 驱动、HWC HAL 的交互错综复杂。我跟一个做显示框架的朋友聊过，他说 surfaceflinger 的 Rust 化 "五年内看不到希望"，不是 Rust 语言的问题，是现有架构的耦合度太高，任何改动都要过兼容性测试的山。Google 的 Gerrit 上确实有 surfaceflinger 相关的 Rust 实验分支，但提交频率很低，更像是有人在保持 "技术储备"，而不是正经的迁移计划。
还有一个现实障碍是工程师储备。Google 内部能写系统层 C++ 的老兵很多，但 Rust 的系统编程经验不是自动转换的。所有权模型、生命周期标注、async 运行时选择，这些坑需要实打实地踩过。Google 的解决方式是内部培训和招聘双管齐下，但培养周期摆在那里。我注意到 AOSP 的 Rust 代码审查特别严格，某些模块的 OWNERS 文件里明确要求 "Rust 变更需要两名有经验的审阅者"，这个门槛在 C++ 模块里是不存在的，侧面反映了 Google 对 Rust 代码质量的谨慎，或者说，对内部 Rust 经验的信心不足。
跟 Fuchsia 的关系，Google 没讲透
讲到 Google 的系统级 Rust 采用，绕不开 Fuchsia。这个 Google 秘密开发了多年的微内核操作系统，Rust 是主力语言之一，内核外的很多组件默认用 Rust 写。Fuchsia 和 Android 的关系，Google 官方口径一直是 "面向不同场景"，但技术层面的资源共享是明摆着的。
AOSP 的 Rust 工具链、某些库的实现，明显有 Fuchsia 项目的痕迹。比如 AOSP 用的 Rust 标准库定制版，跟 Fuchsia 的 fork 有共同的补丁集。Google 的工程师在两个项目的邮件列表里都有交叉参与。我怀疑 AOSP 的 Rust 迁移策略，很大程度上吸取了 Fuchsia 的经验，尤其是 FFI 边界的设计和 unsafe 代码的审计流程。
但 Fuchsia 的教训同样值得注意。Fuchsia 的 Rust 代码比例很高，但项目整体推进缓慢，2021 年公开后到现在，消费级设备上的部署依然有限，Nest Hub 那批之后没有大规模铺开。一个核心原因是 Rust 的编译时间长、工具链体积大，对嵌入式和资源受限场景不够友好。Android 的构建系统虽然比 Fuchsia 成熟，但 Rust 模块的加入还是拖慢了整体编译速度。我在一台 32 核的工作站上编译 AOSP 15，启用 Rust 模块后，clean build 的时间增加了大概 15%。这个比例会随着 Rust 代码量的增长而恶化，Google 需要在构建优化上持续投入，否则内部开发效率的反弹会很大。
厂商跟进的速度，比 Google 慢半拍
AOSP 主线推 Rust，不代表 OEM 厂商就能跟上。实际上，大部分厂商的定制系统（MIUI、ColorOS 这些）在系统服务层还是 C++ 的天下，Rust 代码主要来自 AOSP 的强制合并，自己的新增逻辑很少用 Rust 写。
这个滞后有几个原因。一是厂商的工程师栈深度绑定 C++，招聘和培训 Rust 人才的成本要自己扛。二是厂商的代码审查和发布流程跟 Google 不同，引入新语言的风险评估更保守。三是很多厂商的 "定制" 其实是给 AOSP 的服务打补丁、加 hook，原有代码是 C++，补丁用 Rust 写会引入 FFI 的复杂度，得不偿失。
我翻了几个主流厂商公开的内核仓库和系统服务代码（能看到的部分），Rust 的占比远低于 AOSP 主线。Google 在 Android 15 的兼容性定义文档（CDD）里，没有强制要求厂商使用 Rust，只是 "鼓励" 在安全关键模块考虑内存安全语言。这个 "鼓励" 的约束力很弱，跟当年推 Treble 架构、推 GSI 时的强制要求完全不同。Google 显然知道步子不能迈太大，先把 AOSP 自己的代码整理好，给厂商打个样，剩下的慢慢来。
但这里有个潜在的风险：AOSP 主线和厂商定制的代码，在系统服务层是深度交织的。如果 Google 把某个核心服务用 Rust 重写，而厂商的定制补丁还是 C++，两者的接口兼容性需要额外维护。Google 的解决方案是保持 C++ 的 ABI 稳定，Rust 模块通过 C 接口暴露，但这对架构设计的限制很大，某些 Rust 的优化（比如零拷贝的数据结构传递）在 C ABI 的边界上施展不开。
对 Android 开发者生态的实际影响
说了这么多 AOSP 内部的事，普通 Android 应用开发者可能会问：这跟我有什么关系？
直接关系确实有限。你不会因为 AOSP 用了 Rust 就能用 Rust 写 App，NDK 的 Rust 支持依然 experimental，Google 没有官方推荐。Kotlin 和 Java 的应用层地位不动摇。
但间接影响有几个层面。一是系统稳定性。如果 Rust 化确实减少了系统服务的崩溃和漏洞，用户的整体体验会提升，应用被系统杀后台的概率可能降低。这个影响很难量化，属于 "润物细无声" 的类型。二是安全更新的节奏。Rust 代码的 CVE 减少，理论上让 Google 和厂商的安全补丁压力减轻，可以把资源投到功能开发或其他漏洞类型上。但现实中，Android 的安全更新瓶颈在厂商的推送意愿，不在漏洞本身的数量，所以这个逻辑链条有点理想化。
对系统开发者和 ROM 开发者来说，影响更直接。想参与 AOSP 的底层开发，Rust 正在成为硬技能。某些模块的代码审查已经要求 Rust 能力，纯 C++ 背景的老工程师需要补课。我注意到 AOSP 的文档站点上，Rust 相关的开发指南在快速扩充，从工具链配置到 unsafe 代码的最佳实践，覆盖面越来越全。这个投入说明 Google 不是临时起意，是在长期建设 Rust 的系统开发能力。
跟行业趋势的对比，Google 不算激进
把 Google 的 Rust 采用放在整个行业里看，其实不算激进。Microsoft 在 Windows 内核和系统组件里推 Rust 的力度更大，公开演讲里直接说 "所有新代码应该考虑 Rust"，某些模块的 Rust 比例已经很高。Linux 内核的 Rust 支持虽然争议不断，但 Linus 的态度从排斥转向谨慎接受，6.x 版本里已经有了 Rust 编写的驱动示例。
Google 的步调相对保守，"渐进替换" 和 "安全关键优先" 的策略很清晰，没有 Microsoft 那种 "all in" 的宣言。这个保守跟 Android 的生态系统复杂度有关。Windows 是微软一家说了算，Android 是开放生态，Google 的每一个技术决策都要考虑兼容性和厂商的接受度。Rust 在 AOSP 的推进速度，某种程度上是 Google 对生态控制力的一个指标——能推多快，取决于它能在多大程度上让厂商和开发者跟随。
一个比较有意思的对照是 Apple。Apple 的系统层语言策略是 Swift 和 C/C++/Objective-C 的混合，没有 Rust 的位置。Swift 的内存安全特性（ARC、可选类型）在一定程度上对标 Rust 的目标，但实现方式完全不同，编译期保证弱很多，运行时开销大一些。Apple 没有动力引入 Rust，因为 Swift 是自己的生态核心，跟 Xcode、iOS 开发深度绑定。Google 没有这种 "亲儿子" 语言的包袱，Kotlin 是应用层的，系统层用 Rust 还是 C++ 都是 "外来语言"，选择更自由。
我怎么看这件事
个人来说，我对 Rust 进 AOSP 持谨慎乐观，但有几个具体的质疑。
第一，Rust 的编译期保证被过度神话了。AOSP 的系统服务里，unsafe 代码和 FFI 边界是真实存在的漏洞来源，Rust 不能自动解决这些。Google 的 "eliminated an entire class of vulnerabilities" 说法，严格来说只适用于纯 Rust 代码的内部逻辑，不包括边界。而系统服务的漏洞，往往就出在边界上——输入校验、协议解析、跨进程通信。Rust 把这些边界代码写对，需要工程师有同等的安全意识，语言本身帮不上太多。
第二，构建系统和开发体验的摩擦被低估了。AOSP 的编译已经够慢了，Rust 的加入雪上加霜。Google 在内部可以用顶级硬件缓解，但外部贡献者和中小厂商的开发者体验会明显变差。AOSP 的社区贡献率本来就不高，语言门槛的提高可能进一步压缩参与面。一个健康的开源项目需要外部贡献，Rust 化如果把这个口子收窄，长期代价可能超过安全收益。
第三，Google 的执行力需要观察。Fuchsia 的 Rust 采用比例高，但项目整体推进缓慢，说明 Google 在系统级语言迁移上的执行有历史包袱。AOSP 的代码量和生态复杂度远超 Fuchsia，同样的策略能不能复制成功，我存疑。尤其是 Android 的版本发布节奏是固定的，每年一个大版本，Rust 迁移不能拖慢这个节奏，只能在有限的时间窗口里挤进变更，这种压力下的代码质量需要持续审视。
但我也认可 Google 的方向选择。内存安全漏洞确实是 Android 安全记录的污点，C/C++ 的根治方案不存在，Rust 是目前最现实的替代路径。渐进式迁移比激进重写更可持续，跟 Fuchsia 的技术共享也降低了探索成本。keystore2 的 CVE 归零案例，虽然范围有限，但给了内部和外部足够的信心继续推进。
一个还没答案的问题
最后我想留一个问题。Google 在 AOSP 推 Rust 的同时，自家的服务端基础设施（Search、Ads、YouTube 这些）几乎全是 C++、Java、Go 的天下，Rust 的占比极低。系统层和服务层的语言策略如此分裂，到底是 "Android 特殊所以 Rust"，还是 "Google 内部对 Rust 的价值判断并不统一"？
如果是后者，那 AOSP 的 Rust 迁移可能只是一个部门的局部最优，不是公司层面的战略方向。这意味着资源投入的持续性和跨项目的技术共享，都可能不如表面看起来那么稳固。Android 16 的 Rust 代码比例会是一个观察指标——如果增速放缓或停滞，说明内部的优先级在调整；如果继续陡峭上升，那 Google 可能是认真的，至少在 Android 这条线上。
等明年 I/O 看数字吧。