Chapter 174: Apple Deep Path Frame Rendering

一个 Apple 平台上的“掉帧”现象，表面看是按钮动画卡了一下、列表滚动抖了一下、页面切换延迟了一拍，系统路径上却横跨状态更新、布局、绘制、layer transaction、Core Animation 合成、Metal command buffer、display server、显示控制器和面板刷新。读完本章，读者应能把一帧从 App 代码追踪到屏幕扫描输出，并能判断一次卡顿应优先归因到主线程、layout / drawing、layer 合成、GPU workload、drawable / buffering，还是显示刷新约束。

本章以一次典型 UI 更新为贯穿材料：用户触发状态变化，UIKit 或 SwiftUI 更新页面，某些 view 需要重新布局或重新绘制，Core Animation 收集 layer 变化并提交 transaction，系统合成可显示内容，最后在下一次刷新机会把新画面送到面板。这个过程在 iOS、iPadOS、macOS 和 visionOS 上共享 Core Animation / Metal / display pipeline 的许多公开概念，但具体服务进程、驱动路径和硬件调度属于平台实现细节。正文把公开文档、可观察行为和合理工程推断分开处理。

版本边界如下：UIKit view 绘制、Core Animation layer tree、Metal drawable / command buffer、MTKView frame rate、Instruments 图形分析等以 Apple 公开文档为依据；ProMotion、可变刷新率、HDR、EDR、tile-based GPU 细节会随设备、系统版本和显示硬件变化；iOS 的 display server 和部分合成实现未提供完整公开源码，本章使用“display server / compositor”表示公开 API 背后的系统合成责任边界。Apple 的归档文档说明 UIView 采用按需绘制模型，Core Animation 会缓存 view 内容并复用 layer backing store，Metal 文档说明 drawable 由 Core Animation 管理并通过 command buffer 注册 present；这些公开事实足以建立本章的跨层路径判断，私有调度细节保留为不可验证边界。

需要先建立一个核心结论：一帧的 deadline 由显示刷新节奏决定，但 deadline miss 可以发生在多处。主线程如果迟迟没有完成状态更新、layout 或 transaction commit，Core Animation 拿不到新的 layer 状态；GPU 如果仍在执行昂贵 shader、过多 render pass 或纹理读写，drawable 赶不上 present；display server 如果要合成大量透明、模糊、HDR 或跨进程 layer，合成阶段会增加负载；刷新率如果从 120Hz 降到 60Hz 或 30Hz，视觉连续性、功耗和热预算也会一起变化。

174.1 Frame Rendering 的 Apple 跨层路径总览

Frame Rendering 在本章中的工作定义是：App 把一次可见 UI 变化转换成显示硬件下一次扫描输出可使用的像素状态的完整链路。这个定义覆盖三类工作：CPU 侧决定“画什么”，Core Animation / compositor 决定“哪些 layer 如何合成”，GPU 和显示硬件决定“何时把结果呈现在屏幕上”。如果只看 draw(_:)、layoutSubviews() 或 drawInMTKView(_:)，会把一帧误缩小成某个函数调用；如果只看 GPU frame capture，又会漏掉主线程在 deadline 前是否提交了可用状态。

贯穿路径可以拆成八个责任点：输入或定时器触发状态变化；UIKit / SwiftUI 更新 view graph；layout 决定几何关系；drawing 或已有 backing store 提供内容；CALayer 保存几何、透明度、transform、contents 等状态；Core Animation 在 transaction commit 后生成提交给 render/composition 侧的数据；Metal / GPU 执行应用显式渲染或系统合成渲染；display server 和显示控制器在刷新节奏上完成 present、scanout 和面板更新。

这张图的边界是“公开 API 可推导的责任链”，它不声明 iOS 内部某个私有进程或驱动函数的固定名称。对工程排查而言，责任链比私有名称更有用：当列表滚动卡顿时，先确认主线程是否在处理 Auto Layout、图片解码、文本排版或同步 I/O；再确认 layer 是否触发离屏渲染、透明混合或大量 backing store 更新；再确认 Metal / GPU 是否有过长 command buffer、drawable 等待或过高 fragment workload；最后确认设备刷新率、温控和电源状态是否改变了可用帧预算。

从公开文档可以得到几个稳定事实。Apple 的 View Programming Guide for iOS 说明 UIView 使用按需绘制模型，内容变化通过 setNeedsDisplay 或 setNeedsDisplayInRect: 标记，系统在后续机会执行绘制；Core Animation Programming Guide 说明 layer 会保存 geometry、contents、visual attributes，并把 view 内容缓存成 bitmap 供图形硬件操作；Metal Best Practices Guide: Drawables 说明 CAMetalLayer 提供 CAMetalDrawable，drawable 的 present 应随 command buffer 完成而发生。把这三组事实连起来，Apple frame pipeline 的主线就是 view / layer state、backing store、GPU work、drawable present 和 display refresh 的时序协作。

这条路径中存在两种帧。第一种是“由系统 UI 框架驱动的帧”：应用改 view 或 layer 属性，Core Animation 负责把状态变化变成动画和合成结果。第二种是“由应用显式渲染驱动的帧”：游戏、相机预览、视频特效、Metal 视图通过 MTKView 或自定义 CAMetalLayer 生成 drawable 内容，再交给系统合成。实际 App 常常混合两者，例如一个 Metal 内容区域嵌在 UIKit 页面里，系统还要合成导航栏、弹窗、键盘、状态栏和手势反馈。

跨层路径的判断顺序可以固定为：先看 App 是否在本帧产生了必要状态；再看主线程是否及时完成 layout、drawing invalidation 和 transaction commit；再看 layer 变化是否主要是 transform / opacity 这类可复用 backing store 的合成变化，还是触发 CPU drawing / texture upload 的内容变化；再看 GPU 是否执行了过多 render pass、fragment shading、blend、blur 或 resolve；最后看 present 是否等到了可用 drawable 与刷新时机。这个顺序能避免把所有掉帧直接归咎于 GPU，也能避免把所有卡顿都归咎于主线程。

本章后续各节按这条路径展开：App Layer 负责产生变化，Layer Layer 负责把变化纳入 transaction，Render Layer 负责执行渲染和命令提交，Composition Layer 负责跨窗口和系统 UI 合成，Display Layer 负责刷新率与面板输出，Deadline 小节负责解释时序，最后用 Instruments 把现象回溯到责任边界。

174.2 App Layer：View、Layout、Drawing、State Update

App Layer 的责任是决定本帧的 UI 语义：哪些数据变了，哪些 view 需要重新计算尺寸，哪些内容需要重新绘制，哪些动画需要启动。UIKit 语境下，状态变化通常来自 target-action、gesture callback、delegate、data source、notification、timer 或 async callback；SwiftUI 语境下，状态变化来自 @State、@Binding、Observable 数据、environment 或 transaction。无论入口形式如何，最终都要落到视图树差异、布局差异和绘制差异。

UIKit 的 view 是交互和布局对象，CALayer 是显示和动画状态对象。公开文档明确说明 UIView 与 Core Animation layer 协作完成渲染与动画，每个 UIKit view 都有对应 layer，view 负责事件、层级、layout 和高层属性，layer 负责 backing store、几何、动画和可合成状态。这个分工解释了为什么滚动时改变 frame、transform 或 alpha 往往比频繁触发 draw(_:) 更容易保持帧率：前者主要修改可合成状态，后者可能要求 CPU 重新绘制内容并更新 backing store。

Layout 是本帧 CPU 预算中的高风险阶段。Auto Layout 需要解约束，手写 layoutSubviews() 需要遍历子 view 并计算 frame，SwiftUI 需要根据父子 proposal 与 layout protocol 计算尺寸。如果某次状态变化导致大量 cell 重新测量文本、图片比例、约束优先级或 intrinsic content size，主线程可能在本帧 deadline 前一直运行 layout。此时 GPU 甚至可能空闲，画面仍会卡，因为 transaction commit 发生得太晚，Core Animation 没有新 layer 状态可提交。

Drawing 是另一类主线程或 CPU 侧开销。Apple 的 Drawing and Printing Guide for iOS 建议每次更新只绘制实际变化区域，并谨慎调用 setNeedsDisplay:；原因是 drawRect: / draw(_:) 会进入图形上下文、执行路径、文字、图片和混合等 CPU 工作。对于静态图标、圆角背景、阴影和文本，优先使用系统 view、layer 属性、预渲染图片、异步解码或缓存，通常比在滚动过程中反复绘制更稳定。

一个最小 UIKit 状态变化可以这样理解：

final class CounterView: UIView {
    private var value = 0

    func updateValue(_ newValue: Int) {
        value = newValue
        setNeedsLayout()
        setNeedsDisplay()
    }

    override func layoutSubviews() {
        super.layoutSubviews()
        // 只计算子视图位置和尺寸，不做网络、磁盘、图片解码等非布局工作。
    }

    override func draw(_ rect: CGRect) {
        // 只绘制当前 rect 需要的内容，不在这里修改业务状态。
    }
}

这段代码说明三个边界。updateValue(_:) 只是声明状态变化和失效区域；layoutSubviews() 负责几何计算；draw(_:) 负责像素内容生成。把图片解码、数据库读取、同步网络请求或复杂文本排版塞进 layout / drawing，会直接占用本帧主线程预算。更隐蔽的情况是状态变化触发父 view、子 view、collection view cell、SwiftUI body 和 Auto Layout 级联更新，单个回调看起来很短，整体 run loop 周期却已经错过 commit 时机。

SwiftUI 的风险点形式不同，责任边界相同。body 重新求值本身通常只是描述视图结构，真正的成本来自 identity 变化、过宽的 state invalidation、复杂 layout、频繁 bridge 到 UIKit/AppKit、图片和文本准备、以及动画 transaction 范围过大。判断 SwiftUI 卡顿时，应追踪“哪个 state 改变导致哪些子树重新求值”，再追踪“这些子树是否触发 layout、drawing 或 layer 更新”。把 SwiftUI 视为完全独立的渲染系统会丢失后半段路径，因为最终可见内容仍要进入 Apple 平台的 layer、Core Animation、Metal 和 display pipeline。

App Layer 的可见失败表现通常有三类。第一类是输入响应延迟：主线程正在做 layout、drawing 或业务同步工作，触摸事件处理和 transaction commit 一起延后。第二类是滚动或动画抖动：某些帧产生了过多 cell 更新、图片解码、文本排版或 view 创建。第三类是画面内容更新落后一帧或多帧：数据已经变更，但 display invalidation 或 transaction commit 没有及时到达 Core Animation。排查时先记录主线程调用栈和 frame timeline，再决定是否继续进入 layer 和 GPU 层。

174.3 Layer Layer：CALayer、Layer Tree、Animation Transaction

Layer Layer 的责任是把 App Layer 的视觉变化整理成可提交、可动画、可合成的状态。CALayer 保存 bounds、position、transform、opacity、backgroundColor、contents、cornerRadius、shadow、mask、sublayers 等属性。对系统来说，这些属性是合成输入；对 App 来说，这些属性是比像素更高层的视觉描述。高效动画通常依赖这个差异：移动一个已有 layer 可以复用 backing store，重新绘制同一内容则需要更新 backing store。

Apple 的 Core Animation 文档把 layer tree 分成 model tree、presentation tree 和 render tree。model tree 是 App 直接修改的目标状态；presentation tree 表示动画过程中屏幕上正在呈现的中间状态；render tree 属于 Core Animation 的私有渲染表示。这个划分解释了一个常见现象：代码读取 layer.position 得到的是目标值，读取 presentationLayer()?.position 才能得到动画进行中的可见值。交互动画、手势驱动中断和命中测试经常需要区分这两者。

Animation transaction 是 layer 变化进入渲染管线的提交单位。一次 run loop 周期内，App 可能多次改 view 和 layer 属性；Core Animation 会把这些修改收集在 transaction 中，随后在合适时机提交。隐式动画也依赖 transaction：当某个 animatable property 变化时，Core Animation 根据 action 搜索规则决定是否创建动画对象；开发者可以通过 CATransaction 设置 duration、timing function、completion block 或关闭 implicit actions。Apple 的 Changing a Layer’s Default Behavior 说明 layer action、implicit action 和 CATransaction 的关系。

可以用一个简化时序描述 transaction：

CATransaction.begin()
CATransaction.setAnimationDuration(0.25)
view.layer.opacity = 0.0
view.layer.transform = CATransform3DMakeScale(0.92, 0.92, 1.0)
CATransaction.commit()

这段代码的实质是提交目标 layer 状态与动画参数。App 并不逐帧计算 0.25 秒内每个时间点的 opacity 和 transform；Core Animation 根据 transaction 中的目标值、presentation state 和 timing 生成动画。这里的性能收益来自“动画期间复用 backing store 并由 compositor / GPU 处理几何与透明度变化”。如果同一动画还伴随 draw(_:) 重绘、动态阴影、复杂 mask 或实时 blur，帧成本会从合成状态变化扩展到内容更新和更重的 GPU 合成。

Layer Tree 也承担内存和资源边界。每个有内容的 layer 可能关联 backing store；高分辨率图片、Retina scale、离屏渲染、mask、shadowPath 缺失、group opacity、rasterization 缓存都会影响纹理大小、带宽和合成成本。shouldRasterize 这类属性有适用条件：当复杂子树在多帧内相对静止，只做整体 transform / opacity 变化时，缓存可能减少重复合成；当内容每帧都变或 scale 持续变化时，缓存会增加内存占用、重采样和失效开销。

Layer Layer 的关键判断是区分“状态型变化”和“内容型变化”。状态型变化包括 position、bounds、transform、opacity、zPosition 等；这些变化通常可以由 compositor 使用已有纹理完成。内容型变化包括 contents 更新、文本变化、图片重新解码、draw(_:) 重绘、CAShapeLayer path 高频变化、CATiledLayer tile 更新等；这些变化会引入 CPU drawing、texture upload 或新的 backing store。掉帧排查中，这个区分能快速缩小范围：如果动画只改 transform 仍掉帧，优先看合成复杂度、GPU 或主线程阻塞；如果动画每帧都改文本、路径或图片，优先看内容生产成本。

Layer transaction 的失败表现也有清晰边界。主线程阻塞会让 transaction 迟交；大量 layer 属性变化会增加 commit 前后的编码和同步成本；动画 action 配置错误会造成意外 implicit animation；presentation tree 读取时机错误会导致交互动画跳变；backing store 频繁失效会造成内存带宽和绘制压力。Frame trace 中看到 Core Animation commit 延迟时，应先从主线程调用栈和 layer invalidation 回溯，而非直接进入 shader 优化。

174.4 Render Layer：Core Animation、Metal、GPU Command

Render Layer 的责任是把 layer 状态和显式 GPU 渲染工作转成 GPU 可执行命令与可呈现资源。这里有两条路径：系统 Core Animation 路径负责普通 UIKit / AppKit / SwiftUI layer 的渲染和合成；应用 Metal 路径负责游戏、可视化、相机特效、视频处理或自定义 3D 内容。两条路径最终都要和 Core Animation drawable、系统 compositor、display refresh 协作。

Core Animation 路径的公开模型可以这样理解：App 提交 layer tree 变化后，Core Animation 生成内部 render tree，并把各 layer 的 backing store、geometry、opacity、transform、mask、filter、color space 等信息交给合成侧。普通动画中，GPU 不需要重新运行 App 的绘制代码，而是对已有纹理进行采样、变换、混合和合成。由于 Apple 对 iOS 内部 render server 细节公开有限，本章只把它当作系统服务层责任：它接收 App 进程提交的 layer 状态，参与跨进程显示内容合成，并协调 GPU 与 display present。

Metal 路径更显式。MTKView 或自定义 CAMetalLayer 提供 drawable；App 创建 command buffer，编码 render pass 或 compute pass，把 drawable texture 作为最终可显示 render target，然后在 command buffer 上注册 present 并 commit。Apple 的 Metal Best Practices Guide: Drawables 强调 drawable 是由 Core Animation 创建和维护的有限资源，应尽量晚获取、尽快释放；同一文档说明 presentDrawable: 会把 drawable presentation 注册到 command buffer，实际呈现要等待 GPU work 完成。

一个简化 Metal frame loop 可以这样描述：

func draw(in view: MTKView) {
    guard let descriptor = view.currentRenderPassDescriptor,
          let drawable = view.currentDrawable,
          let commandBuffer = commandQueue.makeCommandBuffer(),
          let encoder = commandBuffer.makeRenderCommandEncoder(descriptor: descriptor) else {
        return
    }

    updatePerFrameUniforms()
    encoder.setRenderPipelineState(pipelineState)
    encoder.setVertexBuffer(vertexBuffer, offset: 0, index: 0)
    encoder.drawPrimitives(type: .triangle, vertexStart: 0, vertexCount: 3)
    encoder.endEncoding()

    commandBuffer.present(drawable)
    commandBuffer.commit()
}

这段代码包含 Render Layer 的核心边界。CPU 负责更新 uniform、编码命令、提交 command buffer；GPU 负责执行 render pass；drawable 是本帧最终呈现资源；present 注册在 command buffer 上，表示“这块 drawable 的内容在 GPU 完成后进入呈现队列”。如果在获取 drawable 之前做完 CPU 准备，可以减少持有 drawable 的时间；如果过早获取 drawable 又被 CPU 工作阻塞，drawable pool 会更容易耗尽，下一帧可能等待可用 drawable。

GPU command 的成本来自多类资源。顶点数量、fragment 覆盖面积、overdraw、透明混合、模糊、阴影、MSAA、HDR/EDR 格式、纹理采样、render target load/store、resolve、跨 pass 依赖都会影响 GPU 时长。Apple 的 Metal Best Practices Guide: Load and Store Actions 解释了 render target load / store action 对开销的影响；在 tile-based GPU 上，避免无意义 load、store 和中间纹理往返，通常会直接减少带宽和 tile memory 压力。

Command buffer 数量也影响 CPU/GPU 协作。Apple 的 Command Buffers 建议每帧提交尽量少的 command buffer，同时保持 GPU 不空闲；过多 command buffer 会增加 CPU 提交和同步开销，过少或提交过晚又可能让 GPU 等待。实际判断要看 GPU timeline：如果 CPU 长时间编码，GPU 前面空闲，瓶颈在 CPU 生成命令；如果 GPU 长时间执行，CPU 等完成 handler 或 drawable，瓶颈在 GPU workload 或资源同步。

Render Layer 还有一个常见误区：Core Animation 动画和 Metal 渲染共用显示预算。一个 Metal 游戏 view 即使自身稳定 60 FPS，如果外层 UIKit 同时做复杂 blur、透明导航栏、弹窗转场或大量 layer 更新，系统最终合成仍可能错过 deadline。反过来，UIKit 页面中嵌入一个每帧刷新但内容简单的 Metal view，如果 drawable 获取和 command buffer 很轻，真正瓶颈可能仍在主线程 cell layout。排查时要把 Metal trace 与 Core Animation trace 放在同一时间轴上观察。

174.5 Composition Layer：WindowServer / Display Server、Layer Composition

Composition Layer 的责任是把来自应用、系统 UI 和显示服务的多个 layer 树或 surface 合成为最终显示内容。macOS 上 WindowServer 是公开可观察的窗口合成责任主体；iOS / iPadOS 对内部显示服务细节公开较少，但从应用行为可以确认系统需要合成 App 内容、状态栏、Home indicator、键盘、通知、控制中心、截图保护、隐私指示器、系统手势动画和外接显示内容。本章用 display server / compositor 表示这层系统边界。

合成输入来自多个 App surface 与系统 surface。即使前台只有一个 App，系统也可能叠加状态栏、动态岛、键盘、指针、辅助功能放大、录屏提示、画中画、系统 alert、Spotlight、Stage Manager 或窗口阴影。每个输入都有位置、裁剪、透明度、颜色空间、安全策略和 z-order。Composition Layer 要根据这些信息决定哪些 surface 可直接 scanout，哪些需要 GPU 合成，哪些需要颜色转换、HDR tone mapping 或透明混合。

Layer composition 的成本主要来自四类因素。第一是层级数量和覆盖面积：大量透明 layer、半透明背景、阴影和模糊会增加采样与混合。第二是 offscreen pass：mask、group opacity、某些 shadow、blur、filter 可能先把子树渲染到中间纹理，再参与最终合成。第三是颜色与动态范围：P3、HDR、EDR、视频内容和普通 UI 混合时需要颜色空间管理和 tone mapping。第四是跨进程资源同步：App、系统 UI、视频解码器、相机预览和屏幕录制可能各自产生 surface，compositor 需要在 present 时序上拿到一致版本。

opaque 这类属性体现了 App 对 Composition Layer 的影响。Apple 的视图文档说明，如果 view 内容完全不透明，设置 opaque 可以减少背后内容的绘制和合成工作。工程上这意味着：一个全屏白色列表背景如果被错误标成半透明，compositor 可能还要处理后方 layer；一个圆角卡片如果阴影、mask、透明背景、动态 blur 同时存在，合成成本会远高于纯色矩形。UI 设计中的视觉效果会直接变成 composition workload。

HDR 和 EDR 增加了 Composition Layer 的判断复杂度。视频播放、相机预览、照片查看和游戏可能使用比普通 sRGB UI 更宽的动态范围；系统需要把不同来源的色彩和亮度映射到当前屏幕能力、系统亮度、录屏路径、外接显示和电源策略。App 可通过公开框架表达内容格式和颜色空间，但最终 tone mapping、亮度限制和多 surface 合成受系统与硬件策略控制。这里应保持边界：公开 API 能说明 App 提供了什么内容属性，内部显示策略的全部细节不可从公开文档完整还原。

Composition Layer 的 present 也涉及安全和隐私。系统可能阻止受保护内容进入截图、录屏或外接显示；隐私指示器和系统提示要覆盖在 App 内容之上；键盘和系统手势区域由系统控制。对 frame rendering 来说，这些策略会影响 layer z-order、surface 可见性和合成输入，但普通 App 无权直接控制系统 UI 的最终合成顺序。

当卡顿出现在 Composition Layer，App trace 可能显示主线程和自身 GPU command 都不重，但 Core Animation 或 system trace 仍出现 missed frame。常见原因包括大量透明叠层、实时 blur、圆角 + shadow + mask 组合、视频 / UI / HDR 混合、外接显示、录屏、系统动画叠加、窗口缩放或多窗口合成。此时优化方向应转向合成输入：减少参与合成的 layer 数量，缩小透明覆盖面积，缓存静态效果，降低实时 blur 范围，明确 opaque，并避免在滚动过程中频繁改变高成本视觉属性。

174.6 Display Layer：Display Controller、Panel、Refresh Rate

Display Layer 的责任是把 compositor 提供的可显示结果按照硬件刷新节奏送到面板。它涉及 display controller、scanout buffer、panel timing、亮度、色彩、可变刷新率、电源和热管理。应用通常无法直接控制这一层，但可以通过 frame rate preference、drawable present、动画节奏和 workload 稳定性影响系统选择。

刷新率决定帧预算上限。60Hz 屏幕每次刷新间隔约 16.67ms，120Hz 屏幕约 8.33ms，30Hz 约 33.33ms。这个预算会被输入处理、main run loop、layout、drawing、transaction commit、render server、GPU 执行、composition、present scheduling 共同占用。120Hz 提供更低触控到显示延迟和更细腻动画，但也把每帧预算压缩到一半；同一段代码在 60Hz 稳定，在 120Hz 上可能暴露主线程或 GPU 的尖峰。

ProMotion 和可变刷新率使问题更接近调度策略。系统可以根据滚动、动画、视频帧率、静止画面、电池状态、热状态和外接显示能力调整刷新行为。App 的职责是表达期望，并在功耗、热量和稳定性约束下选择合适刷新目标。UIKit / QuartzCore 公开了 CADisplayLink、preferredFramesPerSecond、preferredFrameRateRange、CAFrameRateRange 等入口；MetalKit 公开了 MTKView.preferredFramesPerSecond。具体可用范围随设备和系统版本变化，工程判断应以当前设备能力、系统 API availability 和实际 trace 为准。

Apple 的 Metal Best Practices Guide: Frame Rate 使用 60 FPS / 16.67ms 和 30 FPS / 33.33ms 解释 frame interval，并建议保持稳定帧率；这条建议在 ProMotion 设备上依然成立，只是目标间隔可能变成 8.33ms、16.67ms 或系统允许的其他因子。比“追求最高 FPS”更可迁移的判断是：选择一个设备可支持、workload 能稳定完成、功耗和热量可接受的刷新目标。

Display Controller 还要处理扫描输出。传统解释里，scanout 表示显示控制器按面板时序从显示缓冲读取像素并送往屏幕；现代移动设备还会结合压缩、tile、partial update、variable refresh、HDR metadata 和面板自刷新等机制。App 无需掌握私有硬件细节，但要知道显示输出存在队列和扫描过程：present 进入队列后，像素仍要等待刷新边界、合成结果和面板扫描。触控延迟分析中，输入事件时间戳、主线程处理时间、GPU completion、present time 和 scanout time 都可能贡献总延迟。

显示功耗与帧率、亮度、像素内容和 GPU workload 相关。高亮 HDR、全屏白色、复杂透明混合、持续 120Hz 动画和高 GPU 占用会同时增加能耗和热压力。系统可能通过降低刷新率、限制亮度、改变调度优先级或触发 thermal state 变化来保护体验和硬件。工程上应把“稳定低成本帧”视为目标：静止内容停止 display link，视频按源帧率呈现，动画使用合适 duration 和 timing，列表滚动期间避免实时重绘和高成本 blur。

Display Layer 的失败表现通常体现为用户感知变化：刷新率下降、滚动变涩、动画从 120Hz 退到 60Hz、视频和 UI 动画节奏不一致、外接显示延迟增加、HDR 内容亮度变化、低电量或发热后帧率波动。排查时应结合设备型号、系统版本、Low Power Mode、热状态、外接显示、录屏、亮度和刷新率设置，避免用单机单次 trace 推导所有 Apple 设备。

174.7 Frame Deadline、VSync、Buffering、Presentation

Frame Deadline 是一帧必须完成关键工作以赶上某次显示刷新的时间边界。VSync 在这里表示显示刷新节奏或系统提供给应用的显示同步时机；Apple 平台上开发者通常通过 CADisplayLink、MTKView draw callback、Core Animation transaction 和 run loop 行为间接感知它。Deadline 的核心在于：本帧的 CPU 更新、transaction commit、GPU 执行和 present scheduling 都要在对应刷新窗口内形成可用结果。

可以用 60Hz 设备的一帧做简化时序：第 0ms 附近收到输入或 display link；主线程处理状态、layout、drawing invalidation；run loop 尾部提交 Core Animation transaction；render / GPU 执行必要工作；command buffer 完成后 drawable 进入 present；下一个刷新边界扫描新内容。如果任何阶段超过预算，新内容会错过本次刷新，系统可能重复上一帧或在后续刷新显示新帧。用户看到的就是 hitch、stutter 或 latency。

Buffering 负责让 CPU 和 GPU 并行工作。双缓冲能避免前台显示内容与后台渲染内容冲突；三缓冲能让 CPU 准备 frame n+2 时 GPU 执行 frame n+1，显示硬件显示 frame n，从而减少互等。Apple 的 Triple Buffering 文档说明，动态 buffer data 需要多个实例来避免 CPU 写入和 GPU 读取冲突，并让处理器并行。这个思想既适用于 uniform buffer，也适用于 frame pipeline 的整体理解：更多缓冲能提升吞吐稳定性，但会增加内存占用和延迟。

Buffering 的取舍是吞吐、延迟和内存之间的平衡。缓冲太少，CPU 或 GPU 容易等待对方释放资源；缓冲太多，CPU 可以跑得过远，用户输入到可见反馈的延迟增加，内存占用也增加。移动 OS 通常在交互延迟和稳定帧率之间做动态取舍：滚动和手势需要低延迟，视频播放需要稳定 cadence，游戏需要稳定 frame pacing，静止页面需要低功耗。App 应避免人为制造额外队列，例如在主线程、渲染线程、GPU command、视频解码和 display link 之间堆积多层未消费帧。

Presentation 是把完成的 frame 注册给显示系统的动作。Metal 中常见形式是 commandBuffer.present(drawable) 后 commit()；Core Animation 动画中则由系统在 transaction commit 后调度内部呈现。Apple 的 drawable 文档强调，drawable 是有限资源；请求 drawable 时如果没有可用对象，调用线程可能阻塞到下一次刷新。这解释了一个典型 trace：主线程或渲染线程卡在获取 drawable，并不表示获取 drawable 本身“慢”，而是前面的 frame 仍占用 drawable pool，或者 present / display cadence 没有释放资源。

Deadline miss 可以分成四类。CPU miss：状态更新、layout、drawing、图片解码、文本排版、锁等待或同步 I/O 占用主线程。Commit miss：layer transaction 在 run loop 后段才完成或被长任务延迟。GPU miss：command buffer 执行超过 frame interval，或者 render pass / compute pass / texture sync 过重。Present miss：drawable 获取过早、drawable pool 耗尽、frame pacing 不稳定，或系统合成和刷新节奏未能在目标时间呈现。每类 miss 的优化方向不同，统一喊“优化渲染”没有操作性。

Frame pacing 比平均 FPS 更能解释体感。一个 App 平均 60 FPS，如果大多数帧 10ms、少数帧 40ms，用户会看到明显 hitch；另一个 App 稳定 30 FPS，在某些内容上反而更平滑。Apple 的 frame rate 文档建议无法稳定完成 60 FPS 时降低目标帧率来避免 jitter，这体现了系统设计中的一致性优先。对动画和滚动而言，稳定间隔通常比偶尔冲到高帧率更可靠。

排查 deadline 问题时，时间轴应按“输入时间 → 主线程更新 → CA commit → GPU start/end → present → display”排列。缺少任何一个阶段，都可能产生错误归因。只看 CPU profile 会漏掉 GPU 延迟；只看 GPU counters 会漏掉主线程 commit；只看 FPS 会漏掉 frame pacing；只看一次设备结果会漏掉刷新率、热状态和电源策略。完整 frame trace 才能回答“哪一层让新画面错过了哪次刷新”。

174.8 Jank、GPU Cost、Main Thread Blocking 与 Frame Trace

Jank 在本章中的工作定义是：连续帧的呈现间隔出现用户可感知的不均匀，导致动画、滚动或交互反馈不连贯。Jank 跨越多层，它是 deadline miss 的可见结果。排查 jank 的目标是把“某一帧卡了”还原成“哪一层在什么时间段超出预算，以及该层为什么超出预算”。

Apple 工具链提供了多条观察路径。Core Animation instrument 可观察 FPS、hitches、颜色标记、offscreen rendering 和 updated regions；Time Profiler 可定位主线程 CPU 热点；Instruments 的 Metal System Trace 可观察 command buffer、GPU workload、drawable 和 CPU/GPU 并行关系；Xcode GPU Frame Capture 可分析单帧 render pass、resource、pipeline state、shader 和 attachment；MetricKit 可在发布后收集 hang、CPU、display 和 animation hitch 相关指标。工具选择应服务于责任定位：主线程疑点用 Time Profiler，layer / 合成疑点用 Core Animation，GPU 疑点用 Metal System Trace 和 GPU capture，线上趋势用 MetricKit。

一套可复用排查顺序如下。先用用户可见现象确定场景：启动转场、列表滚动、手势拖动、相机预览、视频播放、游戏渲染或系统弹窗叠加。再记录同一场景的 frame timeline，标出 hitch 所在时间段。接着看主线程是否在 hitch 前后长时间运行 layout、drawing、图片解码、文本排版、JSON 解析、锁等待或同步 I/O。主线程无明显阻塞时，再看 Core Animation commit、layer 更新数量、offscreen rendering、透明混合和 backing store 失效。仍未解释时，进入 Metal / GPU timeline，确认 command buffer 时长、drawable 等待、render pass、fragment cost、bandwidth 和 store / load 行为。

主线程阻塞的证据通常很直接：Time Profiler 中 main thread 出现长调用栈，RunLoop 活动延迟，Core Animation commit 出现在 deadline 之后。常见调用栈包括 Auto Layout constraint solving、layoutSubviews() 递归、draw(_:)、Core Text 排版、图片解码、同步磁盘读取、数据库查询、JSON 解析、锁等待和主线程等待后台任务。修复方式应回到 App Layer：缩小 invalidation 范围，缓存布局结果，预解码图片，异步准备文本，复用 cell，减少视图创建，把非 UI 工作移出主线程，并把必须同步到 UI 的结果压缩为最小状态变化。

GPU cost 的证据在 Metal / GPU timeline 中体现：command buffer 执行跨过目标 frame interval，fragment 或 tile 时间过长，render pass 数量过多，overdraw 大，MSAA resolve / store 重，纹理采样和 bandwidth 高，GPU counters 显示 shader 或内存瓶颈。修复方式应回到 Render Layer：减少 overdraw，降低实时 blur 和全屏透明混合，合并 pass，选择合适 load/store action，降低目标分辨率或动态分辨率，缓存静态纹理，避免每帧创建 pipeline / texture / buffer，并让 CPU 与 GPU 通过合理 buffering 并行。

Composition cost 的证据常表现为 App 自身 CPU/GPU 不高，但系统合成或 Core Animation timeline 出现 hitches。此时要检查 layer 结构和视觉效果：滚动区域是否叠加半透明导航栏、毛玻璃、阴影、mask、圆角、动态渐变、视频 layer、HDR 内容或系统 overlay；是否存在大面积 alpha blending；是否频繁改变 shadowPath 缺失的 shadow；是否对动态内容使用过大的 rasterization 缓存。修复方式是减少参与合成的 surface 和透明区域，设置准确 opaque，预合成静态背景，限制 blur 范围，给 shadow 提供稳定 path，并在滚动期间降低高成本效果。

Drawable / presentation 问题的证据包括渲染线程阻塞在获取 currentDrawable、drawable pool 耗尽、CPU 等待 GPU completion handler、present 间隔不稳定、display link callback 与实际 present 时间错位。修复方式是晚获取 drawable，先做 CPU 更新和 offscreen pass，再获取 on-screen render pass descriptor；提交 command buffer 后尽快释放引用；限制 in-flight frame 数量；避免在 GPU 完成前覆盖仍被读取的 dynamic buffer；根据 workload 选择稳定目标帧率。这里的关键是把 drawable 看成带有池化限制和显示时序约束的系统资源。

一次合格 frame trace 复盘应输出四类结论。第一，hitch 发生在哪些帧，目标 frame interval 是多少。第二，错过 deadline 的直接阶段是 main thread、CA commit、GPU execution、composition 还是 present。第三，直接阶段背后的根因是什么，例如图片解码、约束爆炸、离屏渲染、fragment workload、drawable 等待或系统刷新率变化。第四，修复动作要改变哪一层的输入，例如减少 state invalidation、缓存布局、改 layer 属性、简化视觉效果、调整 Metal pass、限制 in-flight frames 或降低目标帧率。只有同时给出阶段、证据、根因和修改点，frame rendering 排查才算闭合。

最小自检任务

题目：一个 iOS 页面包含一个可滚动商品列表，顶部有半透明毛玻璃导航栏，列表 cell 中有圆角图片、动态阴影和价格文字。用户快速滚动时出现明显 jank。请按本章路径写出至少四个可能责任边界，并说明每个边界的可观察证据和优先修复动作。要求覆盖 App Layer、Layer Layer、Render / Composition Layer、Display / Deadline Layer，不要求读取 Apple 私有实现或真实设备日志。

答案要点

App Layer 的第一责任边界是主线程状态更新、cell 复用、layout 和 drawing。可观察证据是 Time Profiler 中 main thread 在滚动期间出现 layoutSubviews()、Auto Layout、文本排版、图片解码、同步 I/O 或 draw(_:) 长调用栈，Core Animation commit 推迟到 frame deadline 之后。优先修复动作是复用 cell，缓存文本和布局结果，异步解码图片，缩小 setNeedsDisplay 范围，把非 UI 工作移出主线程，并让滚动期间的状态更新只提交必要变化。

Layer Layer 的责任边界是 layer 属性、backing store 和 animation transaction。可观察证据是滚动期间大量 layer 内容失效，圆角图片、shadow、mask 或 contents 高频变化，presentation tree 与 model tree 之间出现动画跳变，或 Core Animation instrument 显示 updated regions 过大。优先修复动作是复用 backing store，避免每帧重绘图片和文字，给阴影提供稳定 shadowPath，减少 mask 与动态 shadow 组合，控制 implicit animation 范围。

Render / Composition Layer 的责任边界是透明混合、毛玻璃、阴影、offscreen pass 和 GPU 合成成本。可观察证据是 Core Animation 或 GPU trace 显示 offscreen rendering、alpha blending、fragment workload 或 render pass 成本升高，App 主线程并不重但合成阶段出现 hitches。优先修复动作是减少半透明覆盖面积，限制 blur 范围，缓存静态毛玻璃背景，设置准确 opaque，简化滚动期间阴影和圆角效果，并避免大面积动态透明层叠。

Display / Deadline Layer 的责任边界是目标刷新率、frame pacing、drawable / present 和系统调度。可观察证据是 120Hz 设备上 8.33ms 预算无法稳定满足，present 间隔不均匀，滚动过程中刷新率变化，或录屏、低电量、发热、外接显示导致帧间隔波动。优先修复动作是以稳定 frame interval 为目标，必要时降低滚动期间高成本效果或目标帧率，减少 in-flight 队列堆积，并在同一设备状态下复测修复前后 frame timeline。

本章知识点总结

• Frame Rendering 路径：Apple 平台一帧从 App 状态更新进入 view / layout / drawing，再进入 CALayer transaction、Core Animation、Metal / GPU、display server 和 panel scanout。
• 公开边界：UIView 绘制模型、Core Animation layer tree、Metal drawable / command buffer 属于公开可验证材料，iOS 内部 display server 和部分合成调度属于不可完整验证实现。
• App Layer 责任：UIKit 和 SwiftUI 负责产生 UI 语义变化，主线程上的 layout、drawing、图片解码、文本排版和同步工作会直接影响 transaction commit 时机。
• View 与 Layer 分工：View 负责交互、层级和布局，Layer 负责 backing store、几何、动画和可合成状态，二者的分工决定了动画成本边界。
• Layer Tree 判断：Model tree 表示目标状态，presentation tree 表示动画中的可见状态，render tree 属于 Core Animation 私有渲染表示。
• Transaction 作用：Core Animation transaction 把一个 run loop 周期内的 layer 变化整理成提交单位，并决定 implicit animation 的时长、节奏和完成回调。
• 状态型变化成本：Transform、opacity、position 等变化通常可复用 backing store，适合由 compositor 和 GPU 执行高频动画。
• 内容型变化成本：draw(_:)、文本变化、图片更新、path 高频变化和 backing store 失效会引入 CPU drawing、texture upload 或更高内存带宽压力。
• Metal Present 边界：CAMetalLayer 提供有限 drawable，command buffer 注册 present 后要等待 GPU work 完成并配合刷新节奏呈现。
• GPU 成本来源：Render pass 数量、fragment 覆盖、透明混合、blur、MSAA、load/store、resolve、纹理采样和带宽都会影响 frame deadline。
• Composition 责任：Display server / compositor 合成 App 内容、系统 UI、视频、HDR、overlay 和多窗口 surface，透明层级和视觉效果会转化为合成负载。
• Display 约束：刷新率决定帧预算，60Hz 约 16.67ms，120Hz 约 8.33ms，稳定 frame pacing 通常比短时高 FPS 更能保证体感连续。
• Buffering 取舍：多缓冲能提升 CPU/GPU 并行度并减少等待，但会增加内存占用和输入到显示的延迟。
• Deadline Miss 分类：CPU miss、commit miss、GPU miss 和 present miss 对应不同证据与修复动作，排查时应按时间轴定位。
• Jank 复盘格式：一次合格复盘需要说明 hitch 帧、目标 interval、错过 deadline 的阶段、根因证据和对应层的修改动作。