简介针对UITableView在网络图片加载时容易出现的卡顿问题这份iOS源码工程提供了完整的异步加载方案。资源以LazyTableImages项目为基础面向希望掌握图片异步下载与列表性能优化的初中级开发者压缩包共33个文件体积仅73KB涵盖Objective-C源码、xib界面布局、png图标占位图、plist配置以及Xcode工程文件结构紧凑在Xcode中直接打开即可运行。内容既包含异步加载基本原理解析也演示了SDWebImage、Kingfisher等第三方库的简短接入方式同时给出了不依赖第三方库的自定义实现通过URLSession在后台下载图片再切换主线程刷新cell并兼顾占位图、缓存机制、并发控制等优化技巧。工程中ParseOperation、IconDownloader等模块清晰分离了解析与下载职责便于读者对照学习从数据解析到图片显示形成完整闭环。已有309人学习下载适合作为iOS列表性能优化的入门实战参考。1. TableView 异步加载图片卡顿不在“加载”在收尾做 iOS 开发的几乎都会遇到这么一天TableView 要展示网络图片直接同步下载主线程卡成幻灯片改成异步之后又开始串图、闪烁隔三差五还崩一次。ios tableview 异步加载图片这个需求看着简单坑全在“异步”二字上——回调什么时候回主线程、cell 被复用之后这个回调还认不认账、内存缓存到底设多大任何一条没想清楚交付出去的列表就是翻车现场。这篇文章不灌鸡汤按选型、接入、自研、排错、验证的顺序把成熟库的参数和自研方案的代码一次性讲透。适合正在写或准备接手列表图片加载需求的开发者新手能照着抄熟手能查缺补漏。2. 两条路线怎么选第三方库替你管了三件脏活自研也有章法接到需求先别急着写代码先回答一个问题用成熟库还是自研。我见过太多人一上来就自己封装一个 ImageLoader三个月后开始一边补内存泄漏一边骂当初的自己。成熟库不等于黑匣子它解决的是图片加载最脏的三件事缓存怎么管、取消怎么做、解码在哪里做。把这三件事想清楚选哪条路都不会走偏。2.1 第三方库的核心价值缓存、取消、解码都替你管好了先看一张对比表列的是自研时需要自己补的活能力项SDWebImageYYWebImage自研工作量内存缓存NSCache 内存警告自动清自带 LRU 缓存封装 NSCache 监听警告磁盘缓存LRU 淘汰 过期清理文件 / SQLite 双通道文件缓存 手动清理并发控制下载队列上限自带并发控制OperationQueue 自己调解码线程子线程解码子线程解码手动挪后台复用取消自动取消旧任务自动取消旧任务token 校验兜底这张表列的是核心差异。SDWebImage 这类库真正值钱的地方不在下载器——下载这件事 30 行也能写——而在缓存策略和生命周期管理。以 cell 复用为例自己写要记得在 prepareForReuse 里清图片、在回调里做复用校验这些库内部已经处理了你调用一次 sd_setImageWithURL它会先取消上一次关联的下载任务再按内存、磁盘、网络的顺序查找最后回到主线程赋值一次都搭好了。YYWebImage 和 Kingfisher 也是同一类思路区别在主线程占用和缓存实现细节上。对绝大多数业务来说选 SDWebImage 就够用了它社区最大、遇到问题查得到答案奇葩需求也有现成方案。这里不展开源码分析你只需要把它的生命周期当作自己的设计蓝图先查缓存再发请求回调校验主线程赋值。后面第 4 章的自研代码就是照着这条链实现的。2.2 自研最小方案URLSession 内存缓存先跑通如果出于体积或定制需求必须自研先看最朴素的一版写法——也是网上刷屏最多、翻车也最多的写法func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) - UITableViewCell { let cell tableView.dequeueReusableCell(withIdentifier: MediaCell, for: indexPath) as! MediaCell let urlString dataSource[indexPath.row].imageUrl DispatchQueue.global().async { guard let url URL(string: urlString), let data try? Data(contentsOf: url), let image UIImage(data: data) else { return } DispatchQueue.main.async { // 没有做任何校验快速滑动时会把旧图赋给复用后的 cell cell.coverImageView.image image } } return cell }这段代码有三个问题个个致命。第一Data(contentsOf:) 是同步阻塞接口遇到慢网络会一直挂住线程没有超时概念第二没有缓存滚动列表时同一张图会被反复请求第三回调里直接捕获 cell没有做复用校验——快速滑动下 A 行的回调回来时cell 可能已经被复用到 B 行A 的图就贴到了 B 上。这三点就是整个异步加载话题的核心矛盾。我一般会把这三件事拆开处理URLSession 负责网络并带超时参数NSCache 负责内存缓存cell 上挂一个标识符做复用校验。三件事互相独立拆清楚之后后面加磁盘缓存、加解码子线程都是往里插一层的问题。这里先记住主线缓存、取消、回调时序。2.3 并发与取消NSOperationQueue 控制的是 CPU 密集活URLSession 本身自带并发连接池网络请求不需要你再套一层 OperationQueue。真正需要 OperationQueue 的是图片解码和缩略图生成这类 CPU 任务。快速滑动时一秒可能触发几十次下载回调如果每个回调都在后台线程直接跑 UIImage(data:)线程瞬间打满主线程照样掉帧。常见做法是把解码任务收敛到一个受控的队列里private let decodeQueue: OperationQueue { let queue OperationQueue() // 解码是 CPU 密集任务并发开 2 就够开多了反而频繁切换线程 queue.maxConcurrentOperationCount 2 queue.qualityOfService .userInitiated return queue }() session.dataTask(with: url) { data, _, error in guard error nil, let data data else { return } decodeQueue.addOperation { // 解码放到子线程主线程只收结果 let image UIImage(data: data) DispatchQueue.main.async { imageView.image image } } }参数说明maxConcurrentOperationCount 建议 2 到 4开大了不会更快只会增加线程切换成本qualityOfService 设成 userInitiated表示用户正在等这个结果别用 Utility 或 Background否则系统会拖后线程调度滚动时图片半天出不来。取消这件事要分清粒度。网络任务用 URLSessionTask.cancel() 取消解码任务用 Operation.cancel() 取消。常见误操作是cell 复用就 cancel 网络任务结果同一个 URL 被好几个 cell 反复请求流量翻倍。正确做法是让网络请求继续只在回调赋值时校验 tokenCPU 解码任务倒是可以取消反正数据已经不会被消费了。我习惯把“取消”设计成两级网络层做请求去重视图层做 token 兜底。3. 接入 SDWebImage 做异步加载最小集成与四个必调参数大多数项目不需要自研。用 SDWebImage 的话集成和调参是两件事集成五分钟调参见功底。下面从 cellForRowAt 里的最小调用讲起再给四个我每次必看必调的参数。3.1 一行代码背后的完整生命周期import SDWebImage func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) - UITableViewCell { let cell tableView.dequeueReusableCell(withIdentifier: MediaCell, for: indexPath) as! MediaCell let item dataSource[indexPath.row] cell.coverImageView.sd_setImage(with: URL(string: item.imageUrl), placeholderImage: UIImage(named: cover_placeholder), options: [.retryFailed], completed: nil) return cell }这一行代码的内部顺序是固定的先同步设置占位图再用 URL 字符串处理后的 key 查内存缓存命中直接赋值没命中查磁盘缓存命中就解码后赋值并回写内存都没有才创建下载任务。下载完成后解码、落盘、回写内存最后切回主线程赋值。如果这一步发生时 cell 已经被复用它内部会自动取消上一次关联的下载任务避免串图。这个顺序就是前面说的设计蓝图。不管用不用这个库你脑子里都应该有这条链占位、内存、磁盘、网络、回写、主线程校验。排查问题时基本上就是按这个链路逐层打日志看卡在哪一层。placeholderImage 我一般用纯色或极小的图最好离屏渲染一次之后就不用再解码了如果塞一张大图进去每次复用 cell 都要重新绘制占位图等于给列表额外加了一层负担。3.2 四个必调参数options、completed 与 contextoptions 不是装饰品每个值都有明确的适用场景参数 / 选项作用使用建议placeholderImage加载期间显示的占位图纯色或小图别用大图.retryFailed失败的任务后续自动重试弱网场景常开.progressiveLoad渐进式 JPEG 边下边显示大图列表开普通图不开.refreshCached缓存也重新向服务端校验图片内容会变时用否则别开.avoidAutoSetImage只下载缓存不自动赋值需要先做圆角、模糊等处理时context[.imageThumbnailPixelSize]按目标尺寸下载缩略图封面、头像类列表强烈建议.retryFailed 很实用库会把下载失败的 URL 记下来下次遇到同一个 key 会再试一次不用你手动写重试循环但要注意它也会让弱网下的失败请求反复发起所以还要配合下载器的超时配置见 3.3。.progressiveLoad 只对渐进式 JPEG 有意义普通 PNG/JPG 开了也没效果。.refreshCached 是个后悔药式的选项它会让每次显示都回头向服务端发一次带缓存的校验请求服务端返回 304 就继续用缓存。图片内容会变的场景比如用户头像隔段时间换可以开静态资源永远别开否则每次显示都要等一次网络往返。completed 回调里有一个 cacheType 参数这是排查缓存命中率最好的抓手cell.coverImageView.sd_setImage(with: url, placeholderImage: placeholder, options: [.retryFailed]) { _, _, cacheType, _ in // cacheType: .none 表示网络下载.disk 和 .memory 表示缓存命中 if cacheType .none { // 网络下载统计耗时并上报 } }我一般会在这里把三种 cacheType 的比例记下来。如果 .none 占比超过两成说明预加载没做到位或者缓存 key 不稳定如果 .disk 占比很高但滚动还是掉帧问题就不在缓存而在解码线程。context 里的 imageThumbnailPixelSize 对列表内存的影响比缓存上限大得多一张 2000x3000 的图解码后占 24MB缩到 400x300 再放进列表内存占用直接差两个数量级。3.3 缓存容量与清理策略别让缓存变成内存炸弹// App 启动后、首次加载列表前配置一次 SDImageCache.shared.config.maxMemoryCost 100 * 1024 * 1024 // 内存缓存总成本上限 100MB SDImageCache.shared.config.maxMemoryCount 300 // 最多缓存 300 张 SDImageCache.shared.config.maxDiskSize 200 * 1024 * 1024 // 磁盘缓存上限 200MB SDWebImageDownloader.shared.config.downloadTimeout 15 // 单次下载超时 15 秒参数说明maxMemoryCost 是内存缓存的总成本上限单位是字节库内部按图片像素大小计算成本超过就按 LRU 淘汰maxMemoryCount 是张数兜底两个都设以先命中的为准。downloadTimeout 是下载器级别的超时15 秒是列表场景比较舒服的值设太短弱网下全失败太长失败请求会挂住连接。内存警告这块库已经处理了收到 didReceiveMemoryWarning 会自动清空内存缓存磁盘缓存不动你不需要重复清理。真正要盯的是 maxDiskSize否则列表类 App 刷几个月caches 目录能涨到几个 G最后被系统清掉冷启动又全部重新下载。我现在只要项目里接了图片列表就会在设置页加一个“清理图片缓存”的入口顺手把磁盘缓存大小算出来展示给用户既省存储又省流量。4. 自研异步加载链路从 URLSession 到 NSCache 的落地实现自研不是造轮子是当库满足不了需求时的降级方案比如要做私有化协议、要跟业务缓存联动。下面这套方案拆成三步复用校验、磁盘缓存、后台解码。核心原则只有一个网络和缓存全部与视图解耦视图层只认 token。4.1 防串图的核心token 校验 同一 URL 请求去重先定义 cell 上的标识和系统自带的复用机制配合final class MediaCell: UITableViewCell { /// 当前 cell 期望显示的图片 URLprepareForReuse 时清空 var imageToken: String? IBOutlet weak var coverImageView: UIImageView! override func prepareForReuse() { super.prepareForReuse() imageToken nil coverImageView.image nil } }cell 里只存一个 token 和 imageView 引用prepareForReuse 负责作废旧回调。下面是加载器的完整实现final class ImageLoader { static let shared ImageLoader() private let memoryCache NSCacheNSString, UIImage() private var runningTasks: [String: URLSessionDataTask] [:] private var pendingCallbacks: [String: [(UIImage?) - Void]] [:] private let session: URLSession init() { let config URLSessionConfiguration.default config.timeoutIntervalForRequest 15 config.timeoutIntervalForResource 30 session URLSession(configuration: config) memoryCache.countLimit 200 memoryCache.totalCostLimit 100 * 1024 * 1024 } func load(_ urlString: String, completion: escaping (UIImage?) - Void) { // 内存缓存命中直接回调不经过网络 if let cached memoryCache.object(forKey: urlString as NSString) { completion(cached) return } // 同一个 URL 已经在下载中把回调挂进队列不重复发请求 pendingCallbacks[urlString, default: []].append(completion) if runningTasks[urlString] ! nil { return } guard let url URL(string: urlString) else { flushCallbacks(urlString, image: nil) return } let task session.dataTask(with: url) { [weak self] data, _, error in guard error nil, let data data, let image UIImage(data: data) else { DispatchQueue.main.async { self?.flushCallbacks(urlString, image: nil) } return } self?.memoryCache.setObject(image, forKey: urlString as NSString, cost: image.cost) DispatchQueue.main.async { self?.flushCallbacks(urlString, image: image) } } runningTasks[urlString] task task.resume() } private func flushCallbacks(_ urlString: String, image: UIImage?) { runningTasks[urlString] nil let callbacks pendingCallbacks.removeValue(forKey: urlString) ?? [] callbacks.forEach { $0(image) } } } private extension UIImage { /// 用像素数据估算内存占用供 NSCache 的 totalCostLimit 使用 var cost: Int { Int(size.width * size.height * scale * scale * 4) } }然后 cellForRowAt 里这样使用token 校验放在回调里func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) - UITableViewCell { let cell tableView.dequeueReusableCell(withIdentifier: MediaCell, for: indexPath) as! MediaCell let urlString dataSource[indexPath.row].imageUrl cell.imageToken urlString cell.coverImageView.image nil ImageLoader.shared.load(urlString) { [weak cell] image in // 回调回来后再次核对 token防止复用串图 guard let cell cell, cell.imageToken urlString else { return } cell.coverImageView.image image } return cell }这段代码里有两个关键点。一是 pendingCallbacks 去重十个 cell 同时要同一张封面时只会发一个请求这是性能和流量的双赢等回调回来后统一派发后面挂进来的调用也能拿到图。二是 token 校验imageToken 存的是 URL 字符串而不是 indexPath因为 indexPath 会随复用变化URL 不会。NSCache 的 cost 按像素大小估算这样 totalCostLimit 才有意义——如果每张图 cost 都是 1上限就退化成张数限制大图照样把内存撑爆。别忘了在 init 里监听 UIApplication.didReceiveMemoryWarningNotification收到警告就调 memoryCache.removeAllObjects()。4.2 磁盘缓存的最小实现hash 文件 后台读写内存缓存扛不住冷启动。磁盘缓存的落地做法是每个 URL 对应一个文件private func cachedData(for key: String) - Data? { let fileURL Self.diskFileURL(for: key) return try? Data(contentsOf: fileURL) } private func storeData(_ data: Data, for key: String) { let fileURL Self.diskFileURL(for: key) try? data.write(to: fileURL, options: .atomic) } private static func diskFileURL(for key: String) - URL { let folder FileManager.default.urls(for: .cachesDirectory, in: .userDomainMask)[0] .appendingPathComponent(ImageCache, isDirectory: true) try? FileManager.default.createDirectory(at: folder, withIntermediateDirectories: true) // 生产环境建议用 MD5/SHA 生成文件名hashValue 只在本进程内可复现 return folder.appendingPathComponent(String(key.hashValue) .img) }read 和 write 都只放在后台队列执行绝不能在主线程碰 Data(contentsOf:)。文件名用 hash 值只是演示真实项目建议做 MD5否则 URL 带 query 参数时文件名会很长而且 String.hashValue 在 App 重启后可能变化磁盘缓存会全部失效等于每次启动都重新下载。在 load 的流程里插一层内存 miss 后先走 cachedData命中就解码回写内存并回调没命中才发网络请求。网络返回后先 storeData 落盘再进内存缓存。磁盘清理我一般不做复杂 LRU启动时扫描目录超过 200MB 就按修改时间删最旧的文件。成熟库做的是分级淘汰自研做到“能清、能限、不至于爆”就够了别把时间耗在缓存算法上。4.3 解码与缩略图真正的性能大头在解码不在下载import ImageIO /// 用 ImageIO 直接生成指定最大边长的缩略图避免先解码原图 func downsampleImage(at url: URL, maxPixelSize: CGFloat) - UIImage? { let source CGImageSourceCreateWithURL(url as CFURL, nil) let options [ kCGImageSourceCreateThumbnailFromImageAlways: true, kCGImageSourceThumbnailMaxPixelSize: maxPixelSize, kCGImageSourceCreateThumbnailWithTransform: true ] as CFDictionary guard let source source, let cgImage CGImageSourceCreateThumbnailAtIndex(source, 0, options) else { return nil } return UIImage(cgImage: cgImage) }为什么说大头在解码UIImage(data:) 只是建立对象像素真正解出来要等到第一次 draw。如果你在主线程把一张大图赋给 imageView首帧绘制的解码卡顿就会落在滚动上。用 CGImageSource 的 thumbnail 接口可以直接从压缩数据生成缩略图全程不解码原图内存占用小一个量级。参数建议maxPixelSize 取 ImageView 显示宽度的 2 倍2x 屏幕下 200pt 宽的封面给 400px 就够了。配合 4.1 的 cost 计算内存缓存的压力会小到可以忽略不计。5. 异步加载图片避坑五个高频翻车现场与排查方法下面是实战里出现频率最高的五个问题按现象、原因、解决的顺序写。排查的时候有个通用套路先在 completed 回调或自研的缓存命中回调里打日志判断图片是来自内存、磁盘还是网络顺着链路找是哪一层出了问题比对着代码猜快得多。5.1 快速滑动后 A 行显示 B 行的图片现象列表快速滚到底再滚回来部分 cell 显示的不是自己那行的图要滚动刷新几下才纠正。这个问题出现频率最高九成异步加载新手都遇到过。原因下载是异步的回调回来时 cell 已经被系统复用到另一行旧回调直接把 image 赋给了新行的 imageView。本质是闭包里捕获了 cell 而没有做任何校验系统不会帮你判断这个 image 是不是当前这行想要的。解决赋值前校验当前 cell 期望的 URL 和回调返回的 URL 是否一致也就是第 4 章的 imageToken urlString 判断使用 sd_setImageWithURL 时库内部会取消旧任务并清空 imageView所以成熟库里串图问题已经很少见。自研方案里 prepareForReuse 把 token 置空等于给所有在途回调发了“作废”指令这一步不能省。5.2 图片先闪占位图再跳成原图现象往上回滚已经看过的 cell先显示灰底占位图约 100ms 后跳成原图视觉上闪烁很刺眼。用户会以为是网络问题其实大部分是缓存策略问题。原因内存缓存没命中走了磁盘读或重新下载。常见原因有三个URL 每次拼接多了随机参数导致缓存 key 不一致列表用 reloadData 整体刷新所有 cell 重新走了占位图赋值占位图带淡入动画每次复用都重新播放。解决先把 URL 标准化去掉无意义的 query 参数保证同一张图的 key 稳定局部更新用 reloadRows 而不是 reloadData占位图用静态小图或纯色。还有一招自研方案里缓存命中时不要带动画只有网络下载完成才做淡入能消掉大部分闪烁。5.3 长时间滑动内存一路涨最后收到内存警告现象列表刷 20 分钟内存从 100MB 涨到 400MB收到内存警告后 App 卡顿甚至被杀。这类问题在 iOS 上属于比较严重的线上事故用户体感就是“刷着刷着就白了”。原因内存缓存没设上限更常见的是缓存里存的是原图一张 2MB 的 JPEG 解码后占 24MB100 张就是 2.4GB。NSCache 只设 countLimit 不设 totalCostLimit 时大图的成本没有真正被计算等于没限制。解决内存缓存两个上限都设cost 按像素宽乘高乘 4 估算列表封面一律走缩略图下载或缩略图解码别把原图塞进内存监听内存警告清空内存缓存。这一步做好内存曲线基本是一条平线。5.4 下载成功但 cell 显示空白现象日志里 data 下载成功、代码也赋值了但界面该位置是空的。这种问题最让人崩溃因为看起来每个环节都正常。原因回调里在非主线程给 imageView 赋了值UIKit 的界面操作在非主线程有时候“看起来没生效”实际上状态不可控或者 UIImage(data:) 对某些格式解出来是 nil但 data 本身有内容还有一种情况是 cell 离屏时完成了赋值之后被复用imageView 被 prepareForReuse 清掉了。解决主线程统一赋值是底线所有 view 操作必须回主线程对解密失败的 data 要打日志并回调 nil别吞掉错误离屏下载完成的回调一定要带 token 校验cell 被复用后 token 变了就自动放弃赋值。最容易踩的暗坑是在 URLSession 的代理队列里直接赋值这里必须强制派发回主线程。5.5 弱网下 cell 一直转圈、列表拖动发卡现象信号差时图片转圈很久列表上下拖动掉帧明显。排查时发现请求只是挂着既没失败也没成功。原因URLSession 默认超时是 60 秒任务长时间挂起占用连接并发下载数没有限制几十个请求同时抢带宽失败后没有重试策略用户等来的只有永远转圈。解决timeoutIntervalForRequest 设 15 秒、timeoutIntervalForResource 设 30 秒下载并发限制在 4 左右自研用 OperationQueue 控制SDWebImage 用 downloader 的 maxConcurrentDownloads失败重试交给 .retryFailed但必须配合超时配置否则每张失败图都会卡足 60 秒。弱网下占位图不要用带动画的加载样式动画本身就是主线程的额外负担。6. 进阶验证帧率、缓存命中率与预加载的实操技巧6.1 用 Instruments 验证流畅度别靠手感帧率这东西靠手感是玄学用 Instruments 一看数据就知道差距。打开 Xcode 的 Instruments选 Core Animation 模板跑列表滚动重点看 FPS 曲线有没有掉到 55 以下以及 Main Thread 的占用率。再叠加 Time Profiler看有没有哪一行代码在主线程上累计耗时异常——图片解码、layout、圆角离屏渲染都藏在这里。我现在的习惯是改动前后各跑一遍把 FPS 最低值和主线程占用率记下来对比数据而不是凭印象做优化。6.2 预加载与缓存命中率把耗时挪到滚动之前UITableView 从 iOS 10 开始支持 prefetchDataSource在 cell 还没出现时提前下载图片。SDWebImage 自带 ImagePrefetcher配合起来很顺extension ViewController: UITableViewDataSourcePrefetching { func tableView(_ tableView: UITableView, prefetchRowsAt indexPaths: [IndexPath]) { let urls indexPaths.compactMap { dataSource[$0.row].imageUrl } ImagePrefetcher(urls: urls).start() // 预取后仍按正常链路走缓存 } func tableView(_ tableView: UITableView, cancelPrefetchingForRowsAt indexPaths: [IndexPath]) { // 用户滑出预取范围时会触发SDWebImage 会丢弃对应任务省流量 } }预加载值不值得开看缓存命中率。在 completed 回调里统计 cacheType 的比例内存命中率三成以下说明缓存 key 或容量有问题网络命中率高于两成说明预加载没吃透磁盘命中率高但滚动仍然掉帧问题在解码线程而不在缓存层。用数据说话比拍脑袋调参靠谱。我现在的习惯是任何列表加载图片的需求先问三个问题——展示尺寸多大、图片内容会不会变、弱网占比高不高。答案决定用成熟库还是自研、用缩略图还是原图、要不要开预加载。不要一上来就写一个万能的图片加载器SDWebImage 这类成熟方案改参数就够用的场景占了大多数真到需要自研那一天token 校验、解码后台化、缓存上限这三条底线守住翻车概率就小了很多。希望帮到你。本文还有配套的精品资源点击获取
