一、GPU vs CPU：图像处理的架构差异

处理一张 × 的照片，每个像素需要独立计算。CPU 与 GPU 在并行度、时钟频率与浮点运算量上相差悬殊：

痛点你是否在每帧渲染中发现 CPU 占用飙升、延迟显著？那正是由于缺乏并行化导致的。

CPU 处理像素： Pixel → 计算 → Pixel → ... GPU 处理像素： Pixel → 同时计算 理论上 N 个核同时工作，实际受限于带宽。

CPU 的优势在于复杂逻辑、分支预测、大缓存;GPU 的优势在于数量庞大的简单主要，适合对每个像素做相同操作.

二、Core Image 处理流水线

Aplle 的 Core Image 框架把 GPU 渲染封装成了一套声明式 API：

原始图像数据 ↓CIImage ↓CIFilter
↓ CIContext 触发渲染CGImage / MTLTexture / UIImage

关键概念这方面。CIImage 不是像素数据

痛点你是不是经常误以为 CIImage 已经包含了所有像素？它只是一份描述，

// 没有任何 GPU 运算
let ciImage = CIImage
// 再加一个滤镜节点
let blurred = ciImage.applyingFilter
// 真正触发 GPU 计算
let result = context.createCGImage

This lazy evaluation lets Core Image fuse multiple filters into a single GPU pass,dramatically reducing memory traffic.

三、CIContext 的创建成本与复用策略

痛点你是否曾因每次渲染都创建新的 CIContext 而导致程序卡顿？ 这段测评说明真实成本，

// iPhone Debug build
let t0 = CACurrentMediaTime
let ctx = CIContext // Metal 默认
let t1 = CACurrentMediaTime
print * 1000) // ~18ms – 32ms

Coding mistake example:

// ❌ 每次调用都创建新 context！func applyBlur -> CGImage {
let context = CIContext
return context.createCGImage!}

The fix is simple: reuse a single CIContextPool.shared.context. Pooling eliminates expensive initialization overhead.

四、CIContextPool 实现细节 & 用例示例

final class CIContextPool {
static let shared = CIContextPool
private init {}
private lazy var metalContext: CIContext?= {
guard let device = MTLCreateSystemDefaultDevice else { return nil }
return CIContext(mtlDevice: device,options: )
}
private lazy var cpuContext: CIContext = {
return CIContext(options:)
}
func context -> CIContext {
if preferCPU { return cpuContext }
return metalContext?，cpuContext
}
}

• Lazy init ensures we don't pay cost at launch.
• Metal优先。fallback to CPU when no GPU available .
• Singleton pattern,so all parts of app share same expensive resource.
• 避免重复创建消耗35‑45ms。>

五、MLBitmap ↔️ CIImage 转换 & 坐标系差异陷阱

坐标系差异导致的上下翻转问题