我应该将图像保存在 Core Data 中还是应该使用 SDWebImage答案

【问题标题】：Should I save my images in Core Data or should I use SDWebImage我应该将图像保存在 Core Data 中还是应该使用 SDWebImage
【发布时间】：2014-11-04 09:05:38
【问题描述】：

我一直在开发具有云/服务器数据源的应用程序。所以很自然，这个过程是一次一件事。所以目前，为了填充我的表，我查询返回数组的服务器。该数组包含图像的 url，然后我使用 SDWebImage 从这些 url 加载图像。

现在我进入了开发阶段，我需要为我的表中的所有数据（即文本和图像）实现 Core Data。到目前为止，我正在考虑以下方法：

我可以将数组从服务器加载到核心数据中（想象属性为：firstName、lastName、photoUrl、shortBio），然后将核心数据中的照片 url 传递给 SDWebImage 以在表格单元格中显示图像。或
我可以将数组和图像加载到核心数据中（即在后台将数组加载到核心数据中，然后为每一行将图像加载到核心数据中）

当然，这里的重点是，如果我使用 SDWebImage，它会将图像保存在自己的缓存系统中，根据我有限的理解，这可能与核心数据中的内容完全一致，也可能不完全一致。另一方面，我对核心数据的了解不够，无法知道它在性能方面是否能很好地处理保存图像（即知道它是图像，因此处理文件链接）。

那么最好的方法是什么？ SDWebImage 可以与 Core Data 协调工作吗？还是因为核心数据本身就足够好，所以 SDWebImage 是多余的？

要注意的另一件事是，目前，我的数据立即从服务器加载，然后图像随着 SDWebImage 加载到其 UIImageView 中。这可能不是 Core Data 的问题，因为理想情况下图像将在本地数据库中。有什么想法吗？

【问题讨论】：

不满投票并要求关闭的人，你有什么要给我的吗？
@Almo 有那么难吗？我只是认为解释你为什么投票否决或关闭是尊重和有帮助的。如果我没有发布滑稽的评论，你就不会提供解释。
还要注意你的推理是一个逻辑谬误。请注意，问题在于两种方法或一种方法是否足以解决缓存图像的问题。问题是要求一个事实答案：具有两个输入的真值表。说这是一个意见问题，实际上就是承认“任何选择都足够了”。所以你真的误读了这个问题。但是感谢您指出它们都是等价的。进一步解释为什么选择是平等的会很好。但这又是解释投票结束的重要性。
StackOverflow 真的应该让人们为他们的反对票或关闭投票提供解释。这是为什么需要解释的一个很好的例子。
“补充”很棒！感谢那。修复系统的另一种方法。

标签： ios image core-data xcode5 sdwebimage

【解决方案1】：

根据您的问题和 cmets，您似乎正在尝试在本地缓存通过 HTTP 请求检索到的图像。

URL loading system is already caching the images。无需在此之上实现另一层缓存，无论是 SDWebImage 还是 CoreData。当从服务器接收到 HTTP 响应时，服务器会包含“新鲜度”信息，告知客户端该响应在多长时间和什么条件下有效。默认情况下，URL 加载系统遵循这些规则。您可以使用Charles 或REDBot 等工具检查回复的新鲜度信息。服务器是此对话中唯一方可以知道响应的有效期。

默认情况下，URL 加载系统不会缓存到文件系统 - 仅在内存中。这很容易改变：

cache = [[NSURLCache alloc] initWithMemoryCapacity:(1024*1024*512) diskCapacity:(1024*1024*1024 * 100) diskPath:@"Cache.db"];
[NSURLCache setSharedURLCache:cache];

或者当使用NSURLSession时：

cache = [[NSURLCache alloc] initWithMemoryCapacity:(1024*1024*512) diskCapacity:(1024*1024*1024 * 100) diskPath:@"Cache.db"];
[sessionConfiguration setURLCache:cache];
session = [NSURLSession sessionWithConfiguration:sessionConfiguration];

在Core Data 中存储图像数据通常是要避免的，至少在NSSQLiteStoreType 持久存储中是这样。即使很小的图像在 SQLite 数据库中也很大，并且会导致碎片等影响性能。如果您要在 Core Data 中存储图像数据，最好使用外部存储 - 通过使用 Core Data 自己的外部记录存储，或者通过将图像数据存储在文件系统上并使用 URL 在托管对象中引用它。

但是，如果您使用 Core Data 或 SDWebImage 来“缓存”图像，您将忽略服务器响应中返回的新鲜度信息，除非您实现自己的验证层 - URL 加载系统已经为您做！

【讨论】：

非常感谢您的回答。这里有很多东西可供我或其他任何人细细品味。我对您的回复感到不舒服的一个原因是 SDWebImage 被广泛使用并强烈推荐。然而你似乎认为缓存图像是多余的。所以这让我有点停顿。
某事物被广泛使用并不意味着它是必要的或有用的。许多人使用 SDWebImage 只是为了它的 UIImageView 类别，并没有真正考虑库的其余部分实际上在做什么。
确实是这样。在深入挖掘您的回复（链接和所有）的基础上，似乎得出以下结论：If caching is all that is needed for a certain table's data source (i.e. model), then Core Data is not necessary; it is in such case sufficient to cache the http response; core data is really for further filtering. 但是随后流行课程online.stanford.edu/course/developing-ios7-apps-fall-2013 的第 12 课似乎不同意上述结论，因为教授只是使用 Core Data以免过于依赖服务器。一个想法？
如果你对讲座不熟悉，你只需要看前2到3分钟，你就会听到他提出使用Core Data作为本地缓存的论据。
他关于“限制从远程服务获取”的信息表明他不知道 URL 加载系统如何处理缓存，或者它可以保留在文件系统上。当响应被缓存时，如果您再次发出请求，它将从缓存中提供服务，直到它失效，而不是“从服务器获取”。我会向您推荐我的答案。

【解决方案2】：

不管问题的语义如何，我认为您需要更多硬性信息来为您的决定提供依据。

了解不推荐存储大图像（例如，大于缩略图）会导致性能问题，这对您很有帮助。 Core Data 有一个用于大数据的选项，您可以在其中选中“存储在外部记录文件中”。或者，您可以管理自己的缓存数据（通过这种方式，您可以根据需要在每个共享相同数据的设备上灵活地通过下载更新图像）。公认的最佳实践是仅将图像 URL 存储在 Core Data 中（通常相对于应用程序目录）并单独处理文件存储/显示。

我不知道 SDWebImage，但根据上述情况，这可能会提供您需要的一些功能。

我希望这可以帮助您做出有关数据架构的决定。

【讨论】：

感谢您的回复。你提到的性能问题，只有我不检查Store in External Record File吗？还是只要图像大于缩略图就存在问题 - 无论我是否检查外部存储？
我猜外部记录应该负责数据库性能，但只有使用您自己的数据进行测试才能给出结论性的答案。
另一个响应被证明是极难实现的。理论上听起来不错，但这个更容易使用，至少在我的初级水平。