问题描述
我正在 Swift 4 中开发一个图像加载库，例如 Kingfisher 并带有一些扩展以支持加载图像从 URL 到 UIImageView .
Im developing an image loading library in Swift 4 something like Kingfisher with some extensions to support loading images from URL into an UIImageView .
那么我可以在 UICollection 或 UITableview 单元格上使用这个扩展，并带有这样的 UIImageView:
So then i can use this extension on a UICollection or UITableview cell with an UIImageView like this :
let cell = collectionView.dequeueReusableCell(withReuseIdentifier:
"collectioncell", for: indexPath)
if let normal = cell as? CollectionViewCell {
normal.imagview.loadImage(fromURL:imageURLstrings[indexPath.row])
}
基本上这是我的扩展代码，实现基本的 URLSession 数据任务和缓存
Basically this is my extension Code , implementing the basic URLSession dataTask and Caching
public extension UIImageView {
public func loadImage(fromURL url: String) {
guard let imageURL = URL(string: url) else {
return
}
let cache = URLCache.shared
let request = URLRequest(url: imageURL)
DispatchQueue.global(qos: .userInitiated).async {
if let data = cache.cachedResponse(for: request)?.data, let
image = UIImage(data: data) {
DispatchQueue.main.async {
self.image = image
}
} else {
URLSession.shared.dataTask(with: request,
completionHandler: { (data, response, error) in
print(response.debugDescription)
print(data?.base64EncodedData() as Any)
print(error.debugDescription)
if let data = data, let response = response, ((response as? HTTPURLResponse)?.statusCode ?? 500) < 300, let image = UIImage(data: data) {
let cachedData = CachedURLResponse(response: response, data: data)
cache.storeCachedResponse(cachedData, for: request)
DispatchQueue.main.async {
self.image = image
}
}
}).resume()
}
}
}
}
最后我发现，有时如果我的 URL 损坏或我得到 404，或者即使我在所有图像完全下载之前滚动 UICollectionView，图像也会加载到错误的单元格中，或者我有时会在 collectionView 中找到重复的图像，但这如果我使用 Kingfisher，则不会发生.
Concluding i found out that sometimes if my URL is broken or i get 404 or even if i scroll the UICollectionView before all the images are completely downloaded, images are loaded into the wrong cell or i sometimes find duplicate images in collectionView but this does not happen if i use Kingfisher.
这是我的结果
这是翠鸟
如何防止我的扩展程序将错误的图像加载到单元格中或复制图像?
How do i prevent my extension from loading the wrong image into a cell or duplicating images?
推荐答案
您正在异步更新您的图像视图，无论该图像视图是否已被另一个单元格重新使用.
You are asynchronously updating your image view, regardless of whether the image view has been re-used for another cell.
当您开始对图像视图的新请求时，假设您没有立即在缓存中找到图像，在开始网络请求之前，您应该 (a) 删除任何先前的图像(如 Brandon 建议的那样)；(b) 可能加载占位符图像或 UIActivityIndicatorView；(c) 取消对该图像视图的任何先前图像请求.只有这样你才能开始一个新的请求.
When you start a new request for an image view, assuming you didn’t find an image in the cache immediately, before starting network request, you should (a) remove any prior image (like Brandon suggested); (b) possibly load a placeholder image or UIActivityIndicatorView; and (c) cancel any prior image request for that image view. Only then should you start a new request.
关于如何在扩展中保存对先前请求的引用，您不能添加存储的属性，但可以使用 objc_setAssociatedObject 在启动会话时保存会话任务，设置为 nil 时请求完成，并且 objc_getAssociatedObject 检索会话对象时，查看是否需要取消前一个.
In terms of how you save a reference to the prior request in an extension, you can’t add stored properties, but you can use objc_setAssociatedObject to save the session task when you start the session, set it to nil when the request finishes, and objc_getAssociatedObject when retrieving the session object to see if you need to cancel the prior one.
(顺便说一句，Kingfisher 在他们的 任务标识符的计算属性.这是保存和检索此任务标识符的好方法.
(Incidentally, Kingfisher wraps this associated object logic in their computed property for the task identifier. This is a fine way to save and retrieve this task identifier.
就失败的请求而言，您正在执行肆无忌惮的图像请求这一事实可能会导致该问题.滚动一下，您的请求将被积压并超时.取消(见上文)会减少这个问题，但它可能最终还是会发生.如果您在修复上述问题后仍然有请求失败，那么您可能需要限制并发请求的数量.一种常见的解决方案是将请求包装在异步 Operation 子类中，并使用 maxConcurrentOperationCount 将它们添加到 OperationQueue.或者，如果您正在寻找一种便宜且令人愉快的解决方案，您可以尝试提高请求中的超时阈值.
In terms of failed requests, the fact that you are performing unbridled image requests could cause that problem. Scroll around a bit and your requests will get backlogged and timeout. Doing the cancelation (see above) will diminish that problem, but it might still eventually happen. If you continue to have requests fail after fixing the above, then you might need to constrain the number of concurrent requests. A common solution is to wrap requests in asynchronous Operation subclass and add them to OperationQueue with a maxConcurrentOperationCount. Or if you’re looking for a cheap and cheerful solution, you could try bumping up the timeout threshold in your requests.