简介这份资源面向iOS开发者尤其是需要优化UITableView滚动流畅度的初中级工程师聚焦列表场景下网络图片异步加载这一常见性能瓶颈。包内共33个文件以Objective-C源码.m/.h为主体配合xib界面文件、plist配置、pbxproj工程文件及若干png图标资源压缩包约73KB结构完整可直接编译运行。示例工程围绕LazyTableImages展开涵盖图片下载器、数据解析、记录模型与根视图控制器等模块演示了后台线程下载、主线程刷新、缓存复用与占位图处理等关键思路并附ReadMe说明。已有309人学习下载适合对照源码理解异步加载流程、排查cell复用导致的图片错位问题并在此基础上扩展SDWebImage或Kingfisher等方案。1. iOS TableView 异步加载图片从卡顿到丝滑的实战拆解滑动 UITableView 时列表像被胶水粘住手指离开屏幕才一格格蹦出图片——这个场景几乎每个 iOS 开发者都遇到过。标题里的「异步加载图片」要解决的就是这件事把图片下载、解码、渲染从主线程挪走让滚动保持 60fps 甚至 120fps。它适合两类人一是刚接触 UIScrollView 复用机制、发现同步加载直接卡死的新手二是已经用了 SDWebImage 却仍遇到闪烁、错位、内存暴涨的老手。核心矛盾在于 UITableViewCell 的复用机制与异步任务的时序冲突——cell 被复用时上一个异步任务可能还在跑回来时已经贴到了错误的 cell 上。异步编程在这里不是可选项是必选项。下面从原理到代码把这条链路拆开讲透。2. 为什么同步加载必卡主线程、复用与解码的三重账2.1 主线程阻塞的量化账UIKit 的渲染和触摸响应都跑在主线程。一次UIImage(contentsOfFile:)同步读取一张 1MB 的 JPEG在 iPhone 13 上大约耗时 815ms看起来不多。但 TableView 一屏通常有 68 个 cell每个 cell 一张图滚动时每秒要处理几十次复用累计就是几百毫秒的主线程占用。主线程被占满RunLoop 没机会处理触摸事件表现就是滑动掉帧、手指跟不上的「粘滞感」。更隐蔽的是解码。JPEG/PNG 文件在磁盘上是压缩格式真正渲染前必须解码成位图。这个解码默认发生在图片第一次被绘制到屏幕时也就是主线程。一张 4000×3000 的图解码后占内存约 48MB解码耗时可能超过 50ms。很多人只把下载放到子线程却忘了解码这一步结果还是卡——这是最常见的翻车点。2.2 Cell 复用带来的时序错位UITableView 的复用机制是性能的基石也是异步加载的麻烦源头。假设 cell A 正在请求图片 1用户快速滑动cell A 被回收并复用给图片 5。此时图片 1 的异步任务完成回调里直接cell.imageView.image image1就会把图片 1 贴到本该显示图片 5 的 cell 上。这就是「图片错位」现象。解决思路有两条一是取消机制cell 复用时取消未完成的任务二是绑定校验回调时检查当前 cell 是否仍对应这个数据源。生产环境通常两条一起用。理解这一点后面所有代码才有落脚点。2.3 异步加载的完整链路一张网络图片从 URL 到屏幕要经过发起请求 → 下载数据 → 解码成位图 → 缩放裁剪 → 主线程赋值 → 渲染。异步方案要决定每一步放在哪个线程、用什么队列、缓存到哪一层。常见做法是下载和解码放全局并发队列赋值回主队列缓存分内存和磁盘两级。下面这张表把各阶段归属理清阶段执行线程常用工具注意点发起请求主线程URLSession只创建 task不阻塞下载数据后台队列URLSession 回调注意超时与重试解码位图后台队列CGImageSource强制解码避免主线程解码缩放裁剪后台队列UIGraphicsImageRenderer按显示尺寸裁剪省内存赋值渲染主线程DispatchQueue.main必须校验 cell 对应关系内存缓存任意NSCache自动响应内存警告磁盘缓存后台队列FileManager注意清理策略3. 手写一个可复现的异步加载器从 URLSession 到 NSCache3.1 最小可用版本URLSession 加主队列回调先不引入任何第三方库用系统 API 跑通最小闭环。下面这段代码可以直接放进一个 UIViewController 里测试import UIKit final class ImageLoader { static let shared ImageLoader() private let cache NSCacheNSString, UIImage() private let queue DispatchQueue(label: com.demo.imageloader, qos: .userInitiated, attributes: .concurrent) private init() { cache.countLimit 100 // 最多缓存 100 张 cache.totalCostLimit 50 * 1024 * 1024 // 上限 50MB } 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. 强制解码避免主线程解码卡顿 let decoded ImageLoader.forceDecode(image) self.cache.setObject(decoded, forKey: key, cost: data.count) DispatchQueue.main.async { completion(decoded) } } } // 强制解码把位图提前渲染到内存 private static func forceDecode(_ image: UIImage) - UIImage { guard let cgImage image.cgImage else { return image } let width cgImage.width let height cgImage.height let colorSpace CGColorSpaceCreateDeviceRGB() guard let context CGContext(data: nil, width: width, height: height, bitsPerComponent: 8, bytesPerRow: 0, space: colorSpace, bitmapInfo: CGImageAlphaInfo.premultipliedFirst.rawValue) else { return image } context.draw(cgImage, in: CGRect(x: 0, y: 0, width: width, height: height)) guard let decodedCG context.makeImage() else { return image } return UIImage(cgImage: decodedCG, scale: image.scale, orientation: image.imageOrientation) } }逻辑说明NSCache是线程安全的可以在任意队列读写它会在系统内存紧张时自动释放对象比字典更合适。queue用并发队列多个图片可以并行下载。forceDecode是关键——它通过CGContext把压缩数据提前渲染成位图这样主线程拿到的是已解码的图赋值时不再触发解码。参数说明countLimit控制缓存张数太大占内存太小命中率低一般 100200 张。totalCostLimit按字节算50MB 是移动端比较稳的阈值。qos: .userInitiated表示用户触发的任务优先级高于默认但别用.userInteractive那会跟主线程抢资源。3.2 在 cellForRowAt 里正确绑定与取消有了加载器还要在数据源方法里处理复用。下面是一个带取消逻辑的写法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 placeholderImage cell.tag indexPath.row // 用 tag 标记当前行 ImageLoader.shared.loadImage(url: url) { [weak cell] image in // 回调时校验cell 还在且 tag 没变 guard let cell cell, cell.tag indexPath.row else { return } cell.imageView?.image image cell.setNeedsLayout() } return cell }逻辑说明cell.tag indexPath.row是轻量级的绑定校验。当 cell 被复用给新行时tag 会被更新旧回调进来发现 tag 不匹配就丢弃。[weak cell]避免闭包持有 cell 导致无法释放。占位图先赋值防止复用残留上一张图造成闪烁。参数说明indexPath.row作为 tag 在数据量大时可能重复比如多个 section更严谨的做法是用indexPath整体做 key或者给 cell 加一个representedURL属性存当前 URL回调时比对 URL。tag 方案适合单 section 的简单列表。3.3 用 URLSession 替换 Data(contentsOf:) 的完整版Data(contentsOf:)是同步阻塞调用放在后台队列虽然不卡主线程但无法取消、无法设置超时、无法复用连接。生产环境应该用URLSessionprivate var tasks: [String: URLSessionDataTask] [:] private let session URLSession(configuration: .default) func loadImage(url: URL, completion: escaping (UIImage?) - Void) { let key url.absoluteString if let cached cache.object(forKey: key as NSString) { completion(cached) return } // 避免同一 URL 重复请求 if tasks[key] ! nil { return } let task session.dataTask(with: url) { [weak self] data, _, _ in guard let self self else { return } self.tasks[key] nil guard let data data, let image UIImage(data: data) else { DispatchQueue.main.async { completion(nil) } return } let decoded ImageLoader.forceDecode(image) self.cache.setObject(decoded, forKey: key as NSString, cost: data.count) DispatchQueue.main.async { completion(decoded) } } tasks[key] task task.resume() } func cancel(url: URL) { let key url.absoluteString tasks[key]?.cancel() tasks[key] nil }逻辑说明tasks字典记录进行中的请求同一 URL 不重复发起这在快速滑动时能省掉大量重复下载。cancel方法供 cell 复用时调用。注意URLSession的回调本身在后台队列所以解码可以直接在里面做最后再切主队列赋值。参数说明URLSessionConfiguration.default自带磁盘缓存可以再设requestCachePolicy .returnCacheDataElseLoad优先用缓存。超时用configuration.timeoutIntervalForRequest一般设 15 秒。4. 避坑与排查异步加载图片最常见的 5 个翻车现场4.1 图片错位回调贴到了错误的 cell现象快速滑动后停下发现某张图显示的是别的行的图过一会儿又自己变回来。原因异步回调没有校验 cell 与数据源的对应关系旧任务完成后直接赋值。解决在回调里比对cell.tag或representedURL不匹配就丢弃同时在prepareForReuse里取消未完成任务并重置图片。4.2 内存暴涨解码后的位图没被释放现象滑动几十屏后收到内存警告甚至被系统杀掉。原因只缓存了原始 Data 或 UIImage但 UIImage 持有的 CGImage 解码后位图很大NSCache 的 cost 按 Data 大小算导致低估。解决setObject时 cost 用cgImage.bytesPerRow * cgImage.height计算真实内存占用同时给 NSCache 设totalCostLimit并在didReceiveMemoryWarning时调用cache.removeAllObjects()。4.3 主线程仍在解码只异步了下载没异步解码现象下载确实在后台但滚动还是偶尔卡顿。原因UIImage(data:)只是创建了 image 对象真正解码发生在首次绘制时也就是主线程。解决用第 3 章的forceDecode在后台队列提前解码或者用CGImageSourceCreateThumbnailAtIndex配合kCGImageSourceShouldCacheImmediately强制立即解码。4.4 磁盘缓存无上限沙盒被撑爆现象App 用久了占用几个 GB用户投诉。原因自己实现的磁盘缓存没有清理策略图片只增不减。解决给缓存目录设大小上限比如 200MB每次写入后检查总大小超了就按最后访问时间删除最旧的或者直接用系统的URLCache它自带容量管理。4.5 快速滑动时请求风暴同一 URL 重复下载现象滑动很快时同一个 URL 被发起了多次请求流量浪费。原因没有对进行中的请求去重cell 复用导致同一 URL 被多个 cell 同时请求。解决用第 3.3 节的tasks字典记录进行中的请求同一 URL 只保留一个 task其他回调挂到同一个 task 上可以用数组存多个 completion。5. 进阶技巧用预取与降采样把体验再拉一档5.1 UITableViewDataSourcePrefetching 提前铺路iOS 10 引入的预取协议能在 cell 即将进入可视区域前就发起请求进一步减少白屏。实现很简单extension ViewController: UITableViewDataSourcePrefetching { func tableView(_ tableView: UITableView, prefetchRowsAt indexPaths: [IndexPath]) { for indexPath in indexPaths { let url imageURLs[indexPath.row] ImageLoader.shared.loadImage(url: url) { _ in } } } func tableView(_ tableView: UITableView, cancelPrefetchingForRowsAt indexPaths: [IndexPath]) { for indexPath in indexPaths { ImageLoader.shared.cancel(url: imageURLs[indexPath.row]) } } }逻辑说明prefetchRowsAt在 cell 还没显示时就预加载cancelPrefetchingForRowsAt在用户快速滑过、预取的行不再需要时取消避免浪费。注意预取只是「提前」不能保证一定在显示前完成所以 cellForRowAt 里仍要正常走加载逻辑命中缓存就秒回。参数说明预取的行数由系统决定通常比可视区域多几行。不要在这里做重活只发起请求即可。5.2 降采样按显示尺寸解码省内存一张 4000×3000 的图显示在 100×100 的 imageView 上全尺寸解码纯属浪费。用CGImageSourceCreateThumbnailAtIndex按目标尺寸解码func downsample(data: Data, to pointSize: CGSize, scale: CGFloat) - UIImage? { let options [kCGImageSourceShouldCacheImmediately: true] as CFDictionary guard let source CGImageSourceCreateWithData(data as CFData, options) else { return nil } let maxDimension max(pointSize.width, pointSize.height) * scale let downsampleOptions [ kCGImageSourceCreateThumbnailFromImageAlways: true, kCGImageSourceShouldCacheImmediately: true, kCGImageSourceThumbnailMaxPixelSize: maxDimension ] as CFDictionary guard let cgImage CGImageSourceCreateThumbnailAtIndex(source, 0, downsampleOptions) else { return nil } return UIImage(cgImage: cgImage) }逻辑说明kCGImageSourceThumbnailMaxPixelSize指定解码后的最大边长系统会按这个尺寸解码内存占用从 48MB 降到几百 KB。kCGImageSourceShouldCacheImmediately确保解码立即发生不拖到主线程。这个函数要放在后台队列调用传入 cell 的实际显示尺寸乘以屏幕 scale。参数说明pointSize传 imageView 的 bounds.sizescale传UIScreen.main.scale。注意如果图片要支持点击放大降采样尺寸要按放大后的尺寸算或者放大时重新加载原图。5.3 验证方法用 Instruments 看真实数据改完代码别凭感觉说「流畅了」用 Instruments 验证。打开 Xcode 的 Instruments选 Time Profiler 看主线程占用选 Allocations 看内存曲线。重点看两个指标滚动时主线程有没有超过 16ms 的连续占用60fps 的帧预算以及内存是否随滑动持续上升不回落。如果内存只涨不降说明缓存没生效或解码位图没释放。我自己的习惯是每次改完异步逻辑都跑一遍 Instruments 的 Animation Hitches看 hitch ratio 有没有降到 5ms/s 以下。这个数字比肉眼靠谱得多。希望帮到你。本文还有配套的精品资源点击获取