最近 Google 官方宣布，把 AutoFDO（Automatic Feedback-Directed Optimization）用到了 Android kernel ，也就是内核编译优化里，从而提升了 4%-21% 的不同场景系统性能。
一般来说，在之前编译器（如 LLVM）通常需要基于静态代码分析，或者通过规则进行优化，例如猜哪条分支更容易执行，而 AutoFDO 就不一样了，它通过在实验室环境中采集设备在真实运行热门 App（Top 100）时的 CPU 执行流数据（Branch History），然后让编译器根据这些真实的「运行画像」重新编译内核，它能精准识别代码中的"热点"（Hot paths），从而进行更智能的函数内联（Inlining）和代码布局（Code Layout）优化。
说人话就是：以前编译器只能靠静态去猜哪些函数该内联、哪些分支更热，而现在先通过采样 profiler 收集真实执行路径，再把这些 " Hot paths " 反馈给编译器，让它下次构建时做更智能的函数内联（Inlining）和代码布局（Code Layout）优化。
AutoFDO 在这里主要影响的是编译器启发式，比如内联、代码布局等，所以它不会改到源码语义，而对没有 profile 覆盖到的冷函数，会退回标准优化路径，这一点很关键，因为 kernel 优化最怕 corner case 回归，所以 Google 这里的态度是：先稳态收益，再逐步扩大覆盖面。
所以，AutoFDO 做的就是优化内核，而在 Android 系统中，内核代码执行占用了约 40% 的 CPU 时间，所以就算内核性能提升不是特别大，但也会对冷启动、系统响应和电池续航等场景产生连锁般的正面影响，在Pixel 设备（内核版本 6.1, 6.6, 6.12）上的测试：
- 冷启动速度： 提升约 4%
- 开机时间 ：减少约 2%
- 用户感知 ：界面更流畅、应用切换更快、续航更久
目前这个调整已经在 android16-6.12 和 android15-6.6 分支部署，同时计划扩展到更新的 android17-6.18 ，会作为 GKI（通用内核镜像） 普惠到所有厂商。
因为是不改变代码逻辑，仅改变编译决策，因此不会引入逻辑 Bug。
同时 Google 也提到了，未来想继续拓展到 GKI modules 和 vendor modules，还提到 Kleaf 和 simpleperf 已经具备支持基础，也就是未来 profile-guided kernel optimization 会扩大到更多 Android 底层组件。
那么有人可能就要问，如果 App 不是这 Top 100 的呢 ？因为谷歌明确说了，这个优化是通过 Top 100 apps + AI crawling + Pixel 实机采样 + ARM ETE/TRBE branch history 来生成 profile ，那对我的 App 有用吗？
但是实际上 AutoFDO 不是优化 App binary，而是优化 kernel binary，kernel 的热点不是某个 App 专属，例如 scheduler/binder/syscalls/page fault 这些路径几乎所有 App 都会走，所以这里的 Top 100 主要是找到 Android 用户最常走的系统路径，这要是为什么 Google 强调：
profile 和内部 fleet workload 有 85% 相似度 ，所以这个优化不是针对单个 App 的行为，而是统计分布。
所以对于大部分情况来说，这个调整都能起到正向作用，当然，如果存在 vendor 改了 kernel / drive 等场景，或者你的 App 有什么对内核的深度 Hook，又或者你的自研引擎对内核有强依赖的情况下，也可能出现反效果。
另外其实这种优化方式，也许未来 KMP 的 Kotlin/Native 部分，理论上可以借鉴这种"采样反馈"模式，针对特定设备生成更优的代码？
总的来说，这个优化还是挺有意义的，可以让 Android 15-16 的机器享受到普惠升级，并且未来还会进一步拓展优化范围，最重要是这个升级是安全的，至少官方表示这个升级不会带来 Bug 。
那么，你觉得呢？