文档目的与读者

本文要说明什么

• 多屏场景下，debug.sf.follower_display_backpressure 如何在 Scheduler::onFrameSignal 里让某一帧跳过从屏（follower）的整帧工作。
• 即便从屏被跳过，CompositionEngine::postComposition 仍可能在合成末尾兑现 LayerFE 的 release-fence 承诺，常见结果是 Fence::NO_FENCE。
• 上述组合如何与较慢从屏上的画面撕裂（tearing） 或花屏风险挂钩。

立场与范围

• 根因按 Trace on release fence 已能认定。
• 已验证复现：主屏 VSync 90 Hz、从屏物理刷新 45 Hz、从屏上应用仍按 90 Hz 节奏绘制（相当于在 45 Hz 屏上跑 90 FPS 产线）时出现撕裂。

代码与链接

• 文中摘录来自 AOSP platform/frameworks/native 分支 android16-qpr2-release。
• 浏览器可点开 Android Code Search（cs.android.com）上 android-latest-release 的链接；具体行段只在 URL 的 ;l=… 里，便于在网页里对照，正文不重复行号。

核心结论（一页读懂）

调度侧：从屏被跳过（代码摘录见 §2 — Scheduler.cpp，onFrameSignal）

• 多屏时 pacesetter 先 beginFrame，随后 onFrameSignal 遍历各 follower。
• 打开 follower_display_backpressure 后，每个从屏会查 countPresentFencesPendingAt（尚未完成的 present 相关 fence 数量）。
• 背压跳过只关心「从屏是否还有未完成的 present fence」：若 countPresentFencesPendingAt 为 0，不会因此跳过，从屏照常 beginFrame。
• 若待处理 fence 数量大于 0，代码默认对本从屏 continue（本帧不调用 targeter.beginFrame）。
• 唯一例外（代码里的“容忍”分支）：待处理 fence 恰好 1 个，并且从屏下一次 vsync 的 deadline 早于主屏当前的 expectedVsyncTime（即从屏下一帧会比主屏下一帧更“早到”）——此时不 continue，仍会 beginFrame。除此之外，只要还有待处理 fence，就会跳过。
• 被跳过的从屏本帧不会进入 targets，也就不会按正常路径参与 compositor.commit。

释放链路与症状（与 §4 — CompositionEngine.cpp，postComposition 中的兜底逻辑对应）