最近 Google 官方宣布把AutoFDOAutomatic Feedback-Directed Optimization用到了 Android kernel也就是内核编译优化里从而提升了 4%-21% 的不同场景系统性能。一般来说在之前编译器如 LLVM通常需要基于静态代码分析或者通过规则进行优化例如猜哪条分支更容易执行而 AutoFDO 就不一样了它通过在实验室环境中采集设备在真实运行热门 AppTop 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 binarykernel 的热点不是某个 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。那么你觉得呢链接https://android-developers.googleblog.com/2026/03/BoostingAndroid%20PerformanceIntroducingAutoFDO.html