简介这是一份面向iOS初中级开发者的UITableView异步加载图片实战示例工程针对列表滚动时同步下载网络图片导致主线程阻塞、界面卡顿的常见痛点给出可运行的解决方案。压缩包共33个文件、约73KB包含Objective-C源码.m/.h、XIB界面文件、plist配置、Xcode工程文件及占位图等PNG素材结构完整可直接打开编译运行。工程以LazyTableImages为蓝本演示了后台线程下载、主线程刷新cell、图片缓存与占位图处理等关键环节并配有ReadMe说明便于对照理解异步加载的完整链路。目前已有309人学习下载适合希望掌握列表图片异步加载与性能优化思路、或需要参考轻量级实现代码的开发者研读借鉴。1. iOS TableView 异步加载图片从卡顿到丝滑的那条分界线滑动一个列表图片还没加载出来手指一停界面就僵住半秒——这是很多 iOS 开发者第一次做带图列表时都会遇到的场景。UITableView本身只负责复用 cell它不会帮你管图片从哪来、什么时候回来、回来之后该塞给谁。一旦在cellForRowAt里同步发起网络请求或者同步读磁盘主线程就被堵死滑动掉帧、点击无响应接踵而至。异步加载图片要解决的核心问题就一句话把耗时的取图动作挪出主线程同时保证图片回来时能正确落到对应的 cell 上而不是错位或者闪一下旧图。这套方案适合所有做列表展示的 iOS 开发者无论你是刚接触UITableView的新手还是想把手写缓存换成更稳方案的老手下面从原理到代码一步步拆开讲。2. 为什么同步取图一定会翻车主线程、复用与竞态的三角关系2.1 主线程只该干 UI 这件事iOS 的渲染和事件响应都跑在主线程上cellForRowAt这个代理方法本身也在主线程被调用。如果你在里面写Data(contentsOf:)去读一个远程 URL或者用UIImage(contentsOfFile:)读一张大图这个调用会阻塞当前 runloop直到数据读完才返回。列表快速滑动时系统会连续调用cellForRowAt每一次阻塞叠加起来帧率直接掉到个位数。异步编程的第一原则在这里体现得很直接网络请求、磁盘 IO、图片解码全部放到后台队列主线程只负责把最终拿到的UIImage赋给imageView。2.2 cell 复用带来的错位问题UITableView为了省内存会把滑出屏幕的 cell 回收再给新行用。假设第 3 行发起了一个图片请求用户快速滑到第 30 行第 3 行的 cell 被复用给了第 30 行这时候第 3 行的图片请求回来了如果你直接cell.imageView.image image第 30 行就会显示第 3 行的图。这就是典型的复用错位。解决办法是在异步回调里重新确认这个 cell 当前对应的 indexPath或者用取消机制在 cell 被复用时取消掉旧请求。2.3 竞态同一张图被请求多次列表里多个 cell 可能指向同一张图或者用户来回滑动导致同一个 indexPath 被反复请求。如果没有缓存和请求合并同一张图会被下载多次浪费流量也拖慢速度。一个带内存缓存的异步加载器在发起请求前先查缓存命中就直接返回未命中才走网络并且把进行中的请求记录下来避免重复发起。提示理解这三者的关系后面所有代码和参数调整都是围绕「不堵主线程、不错位、不重复请求」展开的。3. 手写一个可复现的异步图片加载器从缓存到取消的完整链路3.1 最小可用版本GCD 加 NSCache先看一个能跑起来的最小实现。核心是用DispatchQueue把网络请求放到全局并发队列用NSCache做内存缓存回调时切回主线程赋值。import UIKit final class ImageLoader { static let shared ImageLoader() private let cache NSCacheNSString, UIImage() private let queue DispatchQueue(label: com.demo.imageLoader, qos: .utility, attributes: .concurrent) private init() { cache.countLimit 100 // 最多缓存 100 张图 } func loadImage(url: URL, completion: escaping (UIImage?) - Void) { let key url.absoluteString as NSString // 1. 先查内存缓存 if let cached cache.object(forKey: key) { completion(cached) return } // 2. 后台队列发起请求 queue.async { guard let data try? Data(contentsOf: url), let image UIImage(data: data) else { DispatchQueue.main.async { completion(nil) } return } // 3. 写入缓存并回主线程 self.cache.setObject(image, forKey: key) DispatchQueue.main.async { completion(image) } } } }这段代码里NSCache的countLimit控制缓存张数qos: .utility表示这个队列优先级低于用户交互避免抢占主线程资源。Data(contentsOf:)在这里是同步读但因为它跑在后台队列不会阻塞 UI。回调统一用DispatchQueue.main.async切回主线程保证imageView的赋值安全。3.2 在 cellForRowAt 里正确调用有了加载器接下来在cellForRowAt里调用它。关键点是赋值前要确认这个 cell 还是当前 indexPath 对应的 cell。override func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) - UITableViewCell { let cell tableView.dequeueReusableCell(withIdentifier: ImageCell, for: indexPath) let url imageURLs[indexPath.row] // 先占位避免复用显示旧图 cell.imageView?.image UIImage(named: placeholder) ImageLoader.shared.loadImage(url: url) { [weak tableView] image in // 关键重新获取当前 indexPath 的 cell guard let tableView tableView, let currentIndexPath tableView.indexPath(for: cell), currentIndexPath indexPath else { return } cell.imageView?.image image cell.setNeedsLayout() } return cell }tableView.indexPath(for: cell)会返回这个 cell 当前实际对应的 indexPath如果和发起请求时的indexPath不一致说明 cell 已经被复用直接丢弃这次回调结果。[weak tableView]避免闭包持有 tableView 造成循环引用。setNeedsLayout触发重新布局让图片尺寸变化能正确显示。3.3 加上取消机制让滑走的请求停下来上面的版本已经能跑但滑走的 cell 请求还在后台跑浪费资源。更完整的做法是给每个 cell 关联一个可取消的任务。可以用URLSessionDataTask的cancel或者自己维护一个任务字典。final class CancellableImageLoader { static let shared CancellableImageLoader() private let cache NSCacheNSString, UIImage() private var tasks: [String: URLSessionDataTask] [:] private let lock NSLock() func loadImage(url: URL, completion: escaping (UIImage?) - Void) { let key url.absoluteString if let cached cache.object(forKey: key as NSString) { completion(cached) return } lock.lock() if let existing tasks[key] { lock.unlock() existing.cancel() } let task URLSession.shared.dataTask(with: url) { [weak self] data, _, _ in guard let self self, let data data, let image UIImage(data: data) else { DispatchQueue.main.async { completion(nil) } return } self.cache.setObject(image, forKey: key as NSString) self.lock.lock() self.tasks.removeValue(forKey: key) self.lock.unlock() DispatchQueue.main.async { completion(image) } } lock.lock() tasks[key] task lock.unlock() task.resume() } func cancel(url: URL) { let key url.absoluteString lock.lock() tasks[key]?.cancel() tasks.removeValue(forKey: key) lock.unlock() } }在prepareForReuse里调用cancel就能在 cell 被复用前停掉旧请求。override func prepareForReuse() { super.prepareForReuse() if let url currentURL { CancellableImageLoader.shared.cancel(url: url) } imageView?.image UIImage(named: placeholder) }NSLock保证tasks字典在多线程下的读写安全。URLSession的cancel会中断正在进行的网络请求释放连接资源。这套组合下来滑动列表时只有当前可见区域的图片在加载滑走的自动取消内存和流量都省。4. 参数怎么调、缓存怎么设让加载器真正扛住真实列表4.1 缓存策略的三个关键参数NSCache有几个参数直接影响表现。countLimit控制缓存对象数量设太小会导致频繁重新下载设太大占用内存。一般列表场景设 100 到 200 比较稳。totalCostLimit按字节数限制配合setObject(_:forKey:cost:)使用可以更精确地控制内存占用。evictsObjectsWithDiscardedContent默认是 true在内存警告时自动清理一般不用改。参数作用推荐值countLimit缓存图片张数上限100~200totalCostLimit缓存总字节数上限50MB~100MBqos后台队列优先级.utility4.2 磁盘缓存要不要加内存缓存解决的是当前会话内的重复加载App 重启后就没了。如果列表图片固定加一层磁盘缓存能显著提升二次启动的加载速度。常见做法是用FileManager把图片数据写到Caches目录key 用 URL 的 MD5 值。读取时先查内存再查磁盘最后才走网络。磁盘缓存要注意设置过期时间避免无限增长。func diskCachePath(for key: String) - String { let hash key.md5 let caches NSSearchPathForDirectoriesInDomains(.cachesDirectory, .userDomainMask, true)[0] return (caches as NSString).appendingPathComponent(hash) }md5需要自己扩展String或者用CryptoKit的SHA256替代。磁盘读写同样要放在后台队列不要在主线程做。4.3 图片解码时机的选择UIImage(data:)返回的图片在第一次渲染时才解码如果直接在主线程赋值解码动作可能卡住 UI。更稳的做法是在后台队列强制解码把UIImage渲染到UIGraphicsImageRenderer里生成一张已解码的图再回主线程。func decodedImage(from data: Data) - UIImage? { guard let image UIImage(data: data) else { return nil } let format UIGraphicsImageRendererFormat() format.scale image.scale let renderer UIGraphicsImageRenderer(size: image.size, format: format) return renderer.image { _ in image.draw(in: CGRect(origin: .zero, size: image.size)) } }这段代码在后台队列执行返回的UIImage已经完成解码主线程赋值时不再有额外开销。代价是多一次内存拷贝对于大图来说值得。5. 避坑与排查异步加载图片最常见的五个翻车现场5.1 图片错位滑到第 30 行显示第 3 行的图现象是快速滑动后某些 cell 的图片和内容对不上。原因通常是回调里没有校验 indexPath或者 cell 复用时没有重置 imageView。解决方法是回调里用tableView.indexPath(for: cell)重新确认不一致就丢弃同时在prepareForReuse里把 imageView 置为占位图。5.2 内存暴涨滑动几屏后收到内存警告现象是列表滑动一段时间后 App 内存占用飙升甚至被系统杀掉。原因一般是缓存没有上限或者大图没有压缩直接缓存原图。解决方法是给NSCache设countLimit和totalCostLimit对大图在后台做缩略图再缓存不要直接存原图。5.3 图片闪烁先显示旧图再跳成新图现象是 cell 复用时先闪一下上一行的图然后才变成正确的图。原因是prepareForReuse里没有清空 imageView或者占位图设置得太晚。解决方法是在prepareForReuse里立即把 imageView 设为占位图并且在cellForRowAt里赋值前也先设占位图。5.4 请求不取消滑走的 cell 还在后台下载现象是流量消耗比预期大或者后台线程数量持续增长。原因是只做了异步加载没有在 cell 复用时取消旧请求。解决方法是用URLSessionDataTask的cancel在prepareForReuse里取消当前 cell 关联的请求。5.5 主线程卡顿回调里做了耗时操作现象是图片回来赋值时界面还是会卡一下。原因是回调虽然在主线程但赋值前做了图片裁剪、圆角处理等耗时操作。解决方法是把所有图片处理放到后台队列主线程只做最终的image赋值。注意这五个问题往往不是单独出现而是互相叠加。排查时先用 Instruments 的 Time Profiler 看主线程耗时再用 Allocations 看内存增长定位到具体环节再针对性修改。6. 进阶技巧用预取和优先级让列表真正丝滑UITableViewDataSourcePrefetching是 iOS 10 引入的预取机制能在 cell 即将进入可视区域前提前发起请求。实现prefetchRowsAt和cancelPrefetchingForRowsAt两个方法配合前面的加载器可以做到滑动时图片几乎无等待。extension ViewController: UITableViewDataSourcePrefetching { func tableView(_ tableView: UITableView, prefetchRowsAt indexPaths: [IndexPath]) { for indexPath in indexPaths { let url imageURLs[indexPath.row] CancellableImageLoader.shared.loadImage(url: url) { _ in } } } func tableView(_ tableView: UITableView, cancelPrefetchingForRowsAt indexPaths: [IndexPath]) { for indexPath in indexPaths { let url imageURLs[indexPath.row] CancellableImageLoader.shared.cancel(url: url) } } }预取的核心价值是把加载时机提前到 cell 可见之前用户滑到那一行时图片已经在缓存里直接命中。cancelPrefetchingForRowsAt则在用户快速滑动改变方向时取消掉不再需要的预取请求避免浪费。另一个技巧是给请求设优先级。URLSessionDataTask有priority属性范围 0.0 到 1.0默认 0.5。可视区域的请求设 1.0预取的设 0.1这样网络资源会优先服务当前屏幕。配合URLSessionConfiguration的httpMaximumConnectionsPerHost控制并发连接数避免同时发起太多请求拖慢整体速度。let config URLSessionConfiguration.default config.httpMaximumConnectionsPerHost 4 let session URLSession(configuration: config)httpMaximumConnectionsPerHost设 4 到 6 比较合适太小会导致请求排队太大反而增加调度开销。这套预取加优先级的组合是我在多个列表项目里验证下来最稳的方案。血泪经验是不要等到 cell 显示才开始加载也不要一次性把所有图都请求出来预取窗口的大小交给系统判断你只需要在回调里做好缓存和取消。我自己现在做任何带图列表第一件事就是把加载器封装好缓存上限、取消机制、后台解码三样缺一不可。每次偷懒省掉取消后面总要在流量和卡顿上还回来。希望帮到你。本文还有配套的精品资源点击获取