一、问题引入：从工具提示到实际问题
做苹果生态下的图形开发，不管是做游戏还是复杂的UI动效，肯定都遇到过画面掉帧的情况。很多人第一反应是GPU不够用，但用苹果官方的Metal性能剖析器一查，反而发现问题出在CPU上——编码阶段耗时太高，占了整个渲染循环的大头。这篇文章就专门讲这个问题，以及对应的解决办法。
先给大家说清楚什么是“编码阶段CPU耗时高”：简单讲就是，CPU在每一帧里，要花很多时间把渲染需要的指令、数据整理好，发给GPU用。如果这个过程太慢，GPU就得等着CPU的指令，自然就掉帧了。
二、核心原因拆解：为什么编码阶段会慢
要解决问题，得先搞懂为什么会慢。最常见的原因有两个： 第一个是“重复做无用功”。很多开发者写代码的时候，每一帧都把所有的渲染逻辑重新写一遍，比如每一帧都重新创建渲染管线、重新上传顶点数据、重新生成命令缓冲区。就像你每次做饭都要先种一次菜一样，完全没必要。 第二个是“提交间隙的浪费”。CPU把命令缓冲区发给GPU之后，得等GPU处理完这一帧，才能发下一帧的指令。这个等待的过程就是“提交间隙”，如果这个间隙太长，整个循环的效率就低了。
三、解决方案：预编码与命令缓冲复用
针对上面的两个问题，最有效的解决办法就是“预编码”和“命令缓冲复用”。
3.1 预编码：把重复的工作提前做
预编码的意思就是，把那些不会经常变的渲染逻辑，提前在程序初始化的时候做一次，而不是每一帧都重新做。比如渲染一个不会动的3D模型，它的顶点数据、纹理数据、渲染管线这些，只要程序不重启就不会变，那完全可以在程序启动的时候就把这些数据上传到GPU，把渲染管线提前创建好，不用每一帧都重复操作。
举个具体的例子，我们用Metal的官方API来写一段代码，对比一下传统写法和预编码写法的区别。首先明确这个示例的技术栈：iOS 15+ / Metal API。
传统写法（每一帧都重复创建管线、上传数据）：
// 每一帧都执行的代码
func renderFrame() {
// 1. 每一帧都重新创建渲染管线（完全没必要）
let pipelineDescriptor = MTLRenderPipelineDescriptor()
pipelineDescriptor.vertexFunction = vertexFunction
pipelineDescriptor.fragmentFunction = fragmentFunction
pipelineDescriptor.colorAttachments[0].pixelFormat = .bgra8Unorm
let pipelineState = try! device.makeRenderPipelineState(descriptor: pipelineDescriptor)
// 2. 每一帧都重新上传顶点数据（顶点数据没变）
let vertexData = [
SIMD3<Float>(-1, -1, 0),
SIMD3<Float>(1, -1, 0),
SIMD3<Float>(0, 1, 0)
]
let vertexBuffer = device.makeBuffer(bytes: vertexData, length: MemoryLayout<SIMD3<Float>>.stride * vertexData.count, options: [])!
// 3. 编码命令
let commandBuffer = commandQueue.makeCommandBuffer()!
let renderPassDescriptor = currentRenderPassDescriptor!
let renderEncoder = commandBuffer.makeRenderCommandEncoder(descriptor: renderPassDescriptor)!
renderEncoder.setRenderPipelineState(pipelineState)
renderEncoder.setVertexBuffer(vertexBuffer, offset: 0, index: 0)
renderEncoder.drawPrimitives(type: .triangle, vertexStart: 0, vertexCount: 3)
renderEncoder.endEncoding()
commandBuffer.present(drawable)
commandBuffer.commit()
}
预编码写法（把不变的逻辑提前做）：
// 程序初始化的时候执行一次
func setupPreEncoding() {
// 1. 提前创建渲染管线（只做一次）
let pipelineDescriptor = MTLRenderPipelineDescriptor()
pipelineDescriptor.vertexFunction = vertexFunction
pipelineDescriptor.fragmentFunction = fragmentFunction
pipelineDescriptor.colorAttachments[0].pixelFormat = .bgra8Unorm
self.pipelineState = try! device.makeRenderPipelineState(descriptor: pipelineDescriptor)
// 2. 提前上传顶点数据（顶点数据没变，只做一次）
let vertexData = [
SIMD3<Float>(-1, -1, 0),
SIMD3<Float>(1, -1, 0),
SIMD3<Float>(0, 1, 0)
]
self.vertexBuffer = device.makeBuffer(bytes: vertexData, length: MemoryLayout<SIMD3<Float>>.stride * vertexData.count, options: [])!
}
// 每一帧只做必要的逻辑
func renderFramePreEncoded() {
// 直接用提前创建好的管线和顶点数据
let commandBuffer = commandQueue.makeCommandBuffer()!
let renderPassDescriptor = currentRenderPassDescriptor!
let renderEncoder = commandBuffer.makeRenderCommandEncoder(descriptor: renderPassDescriptor)!
renderEncoder.setRenderPipelineState(pipelineState) // 直接用预编码的管线
renderEncoder.setVertexBuffer(vertexBuffer, offset: 0, index: 0) // 直接用预上传的顶点数据
renderEncoder.drawPrimitives(type: .triangle, vertexStart: 0, vertexCount: 3)
renderEncoder.endEncoding()
commandBuffer.present(drawable)
commandBuffer.commit()
}
大家可以对比一下，预编码的写法把原来每一帧都要做的“创建管线”“上传顶点数据”，变成了只在初始化的时候做一次，每一帧的工作量一下子就少了很多。
3.2 命令缓冲复用：减少提交间隙的浪费
除了预编码，命令缓冲复用也是很重要的优化手段。什么是命令缓冲？简单讲就是CPU发给GPU的指令集合。传统的写法是，CPU每一帧创建一个新的命令缓冲，发给GPU之后就扔掉，下一帧再重新创建。
但问题是，创建新的命令缓冲、销毁旧的命令缓冲，本身也是要花CPU时间的。而且，CPU把命令缓冲发给GPU之后，要等GPU处理完这一帧，才能发下一帧的指令，这个等待的时间就是“提交间隙”。如果我们能复用命令缓冲，就能减少创建和销毁的时间，还能让CPU和GPU更高效地并行工作。
具体怎么复用呢？我们可以提前创建好几个命令缓冲，组成一个“命令缓冲池”。比如我们提前创建3个命令缓冲，分别叫A、B、C。第一帧的时候用A，第二帧用B，第三帧用C，第四帧的时候再用A，这时候A已经被GPU处理完了，就可以直接复用。这样就不用每次都创建新的命令缓冲了。
再给大家举个命令缓冲复用的例子，技术栈还是iOS 15+ / Metal API：
// 提前创建命令缓冲池，3个命令缓冲
var commandBufferPool: [MTLCommandBuffer] = []
func setupCommandBufferPool() {
for _ in 0..<3 {
if let buffer = commandQueue.makeCommandBuffer() {
commandBufferPool.append(buffer)
}
}
}
// 复用命令缓冲的渲染函数
func renderFrameWithReuse() {
// 从池子里取一个已经处理完的命令缓冲
guard let commandBuffer = commandBufferPool.first(where: { $0.status == .completed }) else {
// 如果没有可用的，就等一下（这种情况很少）
commandBufferPool.first?.waitUntilCompleted()
return renderFrameWithReuse()
}
// 重置命令缓冲的状态，准备新的编码
commandBuffer.reset()
// 用预编码的管线和顶点数据，编码命令
let renderPassDescriptor = currentRenderPassDescriptor!
let renderEncoder = commandBuffer.makeRenderCommandEncoder(descriptor: renderPassDescriptor)!
renderEncoder.setRenderPipelineState(pipelineState)
renderEncoder.setVertexBuffer(vertexBuffer, offset: 0, index: 0)
renderEncoder.drawPrimitives(type: .triangle, vertexStart: 0, vertexCount: 3)
renderEncoder.endEncoding()
// 提交命令缓冲
commandBuffer.present(drawable)
commandBuffer.commit()
}
这段代码里，我们提前创建了3个命令缓冲，每一帧从池子里找一个已经被GPU处理完的命令缓冲，重置之后直接用，不用再创建新的。这样就减少了创建和销毁命令缓冲的时间，也缩短了提交间隙。
四、应用场景与技术分析
4.1 应用场景
这两个优化手段不是所有情况都能用，得看具体的场景：
- 适合的场景：渲染静态场景（比如UI界面、静态的3D模型展示）、渲染逻辑变化少的场景（比如游戏里的背景、不会动的物体）、需要稳定帧率的场景（比如实时交互的应用、游戏）。
- 不适合的场景：渲染逻辑变化非常频繁的场景（比如动态生成的顶点数据、每一帧都要改的渲染管线）、简单的演示程序（优化带来的收益太小，没必要增加代码复杂度）。
4.2 技术优缺点
先说说优点：
- 预编码能大幅减少CPU的重复工作量，降低编码阶段的耗时，通常能把CPU的负载降低30%以上，复杂场景甚至能降50%。
- 命令缓冲复用能减少创建和销毁命令缓冲的时间，缩短提交间隙，让CPU和GPU的并行效率更高，进一步提升帧率。
- 这两个优化都是基于Metal本身的特性，不需要额外的第三方库，兼容性好，性能提升是实实在在的。
再说说缺点：
- 预编码会增加代码的复杂度，原来简单的每一帧逻辑，现在要拆成初始化和运行时两部分，还要管理预编码的资源，对新手不太友好。
- 命令缓冲复用需要管理命令缓冲池，还要处理命令缓冲的状态，容易出现逻辑错误，比如不小心复用了还没被GPU处理完的命令缓冲，会导致画面出错。
- 预编码的资源如果管理不好，会导致内存泄漏，比如预编码的管线、顶点数据一直占着内存，程序退出才释放。
4.3 注意事项
用这两个优化的时候，有几个坑一定要注意：
- 预编码的资源要及时更新：如果预编码的逻辑变了（比如要换纹理、换渲染管线），一定要重新编码，不然会出现画面错误。比如你原来渲染的是红色的三角形，后来要改成蓝色的，那就要重新上传纹理数据，不能再用原来预编码的红色纹理。
- 命令缓冲池的大小要合适：命令缓冲池太小，会导致没有可用的命令缓冲，CPU要等GPU；太大，会浪费内存。一般来说，3到5个命令缓冲就足够了，因为GPU处理一帧的时间通常是16毫秒（60帧），CPU编码一帧的时间比这个短，3个命令缓冲就能保证有可用的。
- 要考虑多线程的情况：如果你的渲染逻辑是多线程的，一定要保证预编码的资源是线程安全的，命令缓冲池的访问也要加锁，不然会出现数据竞争的问题。
- 优化后一定要用性能剖析器验证：不能想当然地觉得优化了就一定好，一定要用Metal性能剖析器再测一遍，看看CPU的耗时是不是真的降了，帧率是不是真的稳了。
五、瓶颈分析：优化后还慢怎么办
有时候用了预编码和命令缓冲复用，CPU的耗时还是高，那就要分析新的瓶颈了。常见的瓶颈有几个： 第一个是“动态数据更新太频繁”：如果你的顶点数据、纹理数据每一帧都要更新，那预编码就没用了，这时候就要想办法减少更新的频率，或者把动态数据分成静态部分和动态部分，静态部分预编码，动态部分单独处理。 第二个是“编码逻辑太复杂”：如果你的渲染逻辑本身就很复杂，比如一帧里有几百个渲染调用，那即使预编码了，CPU还是要花很多时间来编码，这时候就要想办法减少渲染调用的数量，比如用实例化渲染、合并渲染批次。 第三个是“提交间隙还是太长”：如果命令缓冲复用了，提交间隙还是长，那可能是GPU的负载太高了，GPU处理一帧的时间太长，导致CPU要等很久，这时候就要优化GPU的负载，比如降低分辨率、简化着色器。
六、总结
编码阶段CPU耗时高是苹果生态图形开发中很常见的问题，用预编码和命令缓冲复用能有效解决这个问题。预编码就是把重复的工作提前做，减少每一帧的工作量；命令缓冲复用就是减少命令缓冲的创建和销毁，缩短提交间隙。
在实际使用的时候，一定要结合自己的场景来选择优化方案，不要盲目优化。优化之后还要用性能剖析器验证效果，及时发现新的瓶颈。只要用对了方法，就能大幅提升帧率，让应用更流畅。
评论
围绕“Metal性能剖析器显示编码阶段CPU耗时过高，在渲染循环中利用预编码与命令缓冲复用削减提交间隙的应对策略与瓶颈分析”参与讨论