SwiftUI发布至今已经多个版本迭代，但官方始终没有提供一个原生GIF播放组件。<Image>只能显示静态帧，<AsyncImage>也只针对静态图片加载。很多开发者在迁移到SwiftUI之后才发现，原本在UIKit里通过第三方库轻松实现的GIF播放，现在需要自己重新设计。本文将从GIF的编码结构讲起，分析原生解码API的使用方式，再深入讨论逐帧播放时的内存问题与优化方案，最后给出一个可以直接集成到项目中的完整实现。
一、GIF的内部结构与原生解码API
要理解GIF播放为什么消耗内存，首先要知道GIF文件的组织方式。GIF本质上是一系列帧的集合，每一帧由局部图像数据、延迟时间和 disposal method（处置方式）三部分描述。帧与帧之间通常采用增量绘制：后一帧只记录与前一帧的差异区域，这意味着解码某一帧时必须依赖之前所有帧的合成结果。
ImageIO框架提供了完整的GIF解码能力。你可以通过CGImageSourceCreateWithData创建图像源，再用CGImageSourceCopyPropertiesAtIndex读取每一帧的元信息，其中kCGImagePropertyGIFDictionary字典里的kCGImagePropertyGIFDelayTime就是这一帧的展示时长。逐帧解码使用CGImageSourceCreateImageAtIndex即可。
值得重点关注的是iOS 13之后系统提供的CGAnimateImageAtURL函数，它直接在系统层面完成GIF的逐帧解码与调度，调用方式非常简洁：
import ImageIO
func playGif(at url: URL) {
let options = [
kCGImageSourceShouldCache: false
] as CFDictionary
CGAnimateImageAtURL(with: url, options: options) { _, cgImage, error in
guard error == nil else { return }
// 每帧回调，cgImage为当前帧
DispatchQueue.main.async {
self.currentFrame = cgImage
}
}
}
这个API的优点是解码调度完全交给系统，帧间隔按GIF文件定义精确执行；缺点是回调驱动模式下，你需要自己把每帧塞进SwiftUI的视图层级，而SwiftUI频繁的状态更新本身就有性能开销。另外它对内存的控制粒度有限，遇到超大尺寸GIF时依然可能出现峰值过高的问题。
二、在SwiftUI中实现AnimatedImage视图
有了逐帧解码的回调，接下来要做的就是封装一个SwiftUI视图。核心思路是维护一个@State属性持有当前帧，然后用CADisplayLink或Timer按照每帧的延迟时间推进播放。下面是一个基础实现：
import SwiftUI
import ImageIO
struct AnimatedImage: View {
let data: Data
@State private var currentFrame: CGImage?
@State private var displayLink: CADisplayLink?
@State private var frameSources: [CGImage] = []
@State private var frameDurations: [Double] = []
@State private var currentIndex: Int = 0
var body: some View {
Group {
if let frame = currentFrame {
Image(decorative: frame)
.resizable()
.scaledToFit()
}
}
.onAppear(perform: startPlaying)
.onDisappear(perform: stopPlaying)
}
private func startPlaying() {
decodeFrames()
currentFrame = frameSources.first
let link = CADisplayLink(target: self, selector: #selector(tick))
link.add(to: .main, forMode: .common)
displayLink = link
}
@objc private func tick() {
let duration = frameDurations[currentIndex]
// 根据duration判断是否切换到下一帧
currentIndex = (currentIndex + 1) % frameSources.count
currentFrame = frameSources[currentIndex]
}
}
注意上面的代码把CADisplayLink和@State直接绑在一起在实际项目里会有引用循环风险，正式实现中应该拆出一个独立的Animator类，通过ObservableObject或@Observable对外暴露当前帧。结构上把解码、调度、渲染三层分离，后续做内存优化时才有介入的空间。
渲染环节还有一个容易被忽略的细节：GIF帧通常带透明通道，如果使用Image(decorative:)之外的初始化方式，SwiftUI可能对图像做额外的色彩管理处理。对于纯展示场景，decorative初始化器跳过了无障碍描述和元数据解析，开销更小。
三、内存暴涨的根源与优化策略
很多团队接入GIF播放后收到的第一个性能报告就是内存告警。假设一个500x500像素的GIF有60帧，解码后每帧位图占用约1MB（500x500x4字节），一次性全部解码并缓存就是60MB，而GIF文件本身可能只有2MB。这就是GIF内存问题的本质：文件体积小不代表解码后的位图小。
第一个优化手段是降低缓存帧数量。绝大多数场景下不需要预解码全部帧，只需要维持一个固定大小的环形缓存，比如只保留当前帧前后各3帧，其余帧在需要时即时解码。配合kCGImageSourceShouldCache: false禁止ImageIO内部缓存，可以把峰值内存压到个位数MB级别。
let options = [
kCGImageSourceShouldCache: false
] as CFDictionary
let source = CGImageSourceCreateWithData(data, options)!
let frame = CGImageSourceCreateImageAtIndex(source, index, options)
第二个手段是降采样。如果展示区域只有200x200点，而GIF原始尺寸是1000x1000，那么解码时就应该按比例缩小。可以在解码后使用CGContext重绘，或者借助ImageIO的thumbnail接口一步到位：
let thumbOptions = [
kCGImageSourceCreateThumbnailFromImageAlways: true,
kCGImageSourceCreateThumbnailWithTransform: true,
kCGImageSourceThumbnailMaxPixelSize: 400
] as CFDictionary
let downsampled = CGImageSourceCreateThumbnailAtIndex(source, index, thumbOptions)
降采样配合环形缓存通常能把内存降低一个数量级，同时因为位图更小，Core Animation上传纹理的速度也更快，动画反而更流畅。
第三个手段是按需暂停。当视图滚出屏幕时立即调用invalidate销毁displayLink，并清空帧缓存。SwiftUI的onDisappear并不保证及时触发（比如视图被透明度遮挡），更稳妥的做法是结合Transaction或者在UIViewRepresentable包装层监听didMoveToWindow来精确控制生命周期。
四、方案对比与选型建议
目前社区常见的SwiftUI GIF方案有三类：直接使用第三方库（如SwiftGif、Kingfisher的GIF扩展）、调用系统的CGAnimateImageAtURL、以及上文的自研AnimatedImage。三者各有适用场景。
| 方案 | 内存可控性 | 接入成本 | 适用场景 |
|---|---|---|---|
| 第三方库 | 较低 | 低 | 快速原型、低频展示 |
| CGAnimateImageAtURL | 中 | 中 | 本地文件、尺寸适中 |
| 自研AnimatedImage | 高 | 高 | 列表大量展示、大尺寸GIF |
如果你的应用只是在详情页展示一个表情GIF，直接用Kingfisher扩展就够了；但如果是在信息流列表里同时展示几十个GIF，内存和CPU都会成为瓶颈，自研方案配合降采样与环形缓存几乎是必选项。另外提醒一点，网络GIF务必先完整下载到本地再交给解码器，边下载边解码会因为文件不完整导致解码失败或闪烁。
最后，上线前建议用Instruments的Allocations模板实测峰值内存，用Core Animation FPS工具确认帧率稳定。GIF播放看似简单，但把内存控制在合理范围、保证列表滚动流畅，才是这个功能真正考验工程能力的地方。