上周的 #195071 我们才聊过，在 Snapdragon 8 Elite 这类 Little Core 的 CPU 上，然后没想道后面还能继续折腾，类似的问题其实不止一个：
- Android： Snapdragon 的 Performance Core 明明不弱，但是 Flutter 之前把 Raster Thread 限制在两颗 Prime Core 上，所以选择放开亲和性后反而变快，因为大核不代表就快，它需要持久才能热起来
- iOS 之前 #190815 也类似，就算 Flutter UI/Raster Thread 设置了 QoS，也可能长期被匹配到 E-core 上，只有人为增加工作负载之后，线程才会被系统挪动到 P-core，卡顿才会消失
也就是其实都可以看出来一个问题：：
Flutter 的 UI/Raster Thread 是短时、周期性、对延迟敏感的任务，而 CPU 调度器通常还要兼顾吞吐量、功耗、温度和整个系统的负载，所以所谓的最优选择不一定就可以在不同平台完全一致。
比如 Android 上两颗 4.61 GHz 的 Prime Core 反而可能比六颗 3.63 GHz 的 Performance Core 慢，因为虽然 4.61 GHz 是最高可达频率，但是线程每次唤醒的成本高啊，而 Flutter Raster Thread 的工作经常非常短，比如某帧只需要处理 1–2 ms 的光栅化工作，也就是假设线程每隔 16.7 ms 被唤醒一次，做完任务马上休眠，而如果 Prime Cluster 就可能因为空闲降到最低频率，这时候线程被唤醒，CPU 频率还没爬升上升，任务就已经执行完了。
但是如果把 Raster Thread 跑到其他 Performance Core，那里可能正好有别的任务让 Cluster 保持在较高频率，Flutter 反而可以直接有更好的调度。
但是问题出现在这里，修复之后，官方 Benchmark 反而出现 2 倍回退，因为在 #195826 里面提到，合入 #195071 后官方 fading_child_animation_perf Benchmark 的 average_frame_rasterizer_time_millis 出现 2 倍性能回退，所以选择回滚。
也就是方案还是带来其他负面影响。
其实如果把时间往回拉，你会发现 Flutter 已经在这个问题上反复踩坑，不知道官方有没有感受出来，这次很像一轮 CPU 亲和性策略的循环：
| 时间 | 问题 | 当时的处理思路 |
|---|---|---|
| 2023 年，#134452 | Pixel 6 Pro 上 UI/Raster 可能被调度到慢核，产生卡顿 | 通过亲和性限制，倾向性能核 |
| 2024 年，#153690 | Pixel 8 上 UI、Raster、部分 Dart Worker 可能挤在同一颗最快核心 | 扩大可用核心集合，避免过度集中 |
| 2026 年 10 月，#195070 | 没有传统小核的 Snapdragon 被错误分类，6 颗 Performance Core 被排除 | 使用 cpu_capacity 识别无小核设备 |
| 2026 年 11 月，#195826 | 扩大核心范围后，官方 Benchmark 出现回退 | 回滚改动，重新评估策略 |
从最初限制核心，是因为 Android 调度器会把关键渲染线程安排到较慢的核心，影响帧率，但限制以后在 Pixel 8 这类设备上，又出现了 UI、Raster 和部分 Worker 竞争同一颗核心的情况。
然后继续修正，到了没有传统 Little Core 的 Oryon 架构，Flutter 还是依靠最高频率分组，导致又把六颗性能核排除了。
然后这次放开以后，SM8850 上确实变快，但官方测试又遇到了回退。
所以我感觉更合理的方向应该重新考虑整个核心选择和调度机制，这样缝缝补补简直就是屎山堆积。
所以你觉得应该是 Flutter 到底应该自己选核心，还是让操作系统决定？
目前官方有个 ADPF 集成 RFC #45 的提案，对应 #195992，就是希望可以设计一个告诉 Android 帧截止时间的支持，然后让系统自己调度，也就是 Fllutter 可能可以不需要再根据 CPU 的静态参数判断哪些核心适合 Raster，而是告诉 Android：
- 哪些线程负责 UI Build 和 Raster
- 每帧需要在多久以内完成
- 上一帧实际上花了多久
- 当前是否刚从较长时间的空闲状态恢复
这样 Android 就能结合 CPU 频率、调度策略和功耗预算作决定。
目前 RFC 作者用 Pixel 8、Pixel 9、Lenovo Tab 做了多轮 Profile Benchmark，特别关闭了测试环境的 Fixed Performance Mode，让设备采用正常动态调频策略，大概情况如下：
| Benchmark | 原型前 Raster Avg | ADPF 原型 | 改善 |
|---|---|---|---|
| Pixel 8，复杂布局滚动 | 4.18 ms | 2.65 ms | 36% |
| Pixel 8，Tiles 滚动 | 4.62 ms | 2.91 ms | 37% |
| Pixel 9，复杂布局滚动 | 4.15 ms | 2.59 ms | 38% |
| Pixel 9，Tiles 滚动 | 4.28 ms | 2.42 ms | 44% |
不过目前原型也存在回退的情况，比如某些轻负载场景在 Pixel 8 和 Lenovo Tab 上更慢，Hybrid Composition 下还有特殊的线程合并处理问题。
但是我感觉这套方案的方向更合理，至少交给系统处理比这样维护屎上更稳定，你这个规则又不支持外部自己更新配置，还不如直接交给系统更合理。
