我找不到讨论firebase存储文档中三种下载方法之间的区别以及每种方法的优缺点的资源。我想澄清一下有关防火基地储存文件的情况。
我的应用程序
- 在表格视图中显示大小从10 KB-500 KB不等的100个图像
- 将用于互联网连接和/或电话服务可能非常薄弱的地方
- 可供许多用户使用
从Firebase存储下载的3种方法
- 下载到内存中的
NSData这是快速下载文件的最简单方法，但它必须将文件的全部内容加载到内存中。如果您请求的文件大于应用程序的可用内存，则应用程序将崩溃。为了防止内存问题，请确保将最大大小设置为您知道应用程序可以处理的大小，或者使用其他下载方法。
问题：我尝试了这种方法，在我的表视图单元格上显示100个大小为10KB-500KB的图像。虽然我的应用程序没有崩溃，但当我滚动表格时，我的内存使用量增加到了268mb。对于显示大量图像，是否建议使用而这种方法？
- 下载到代表设备上文件的
NSURLwriteToFile:completion:方法将文件直接下载到本地设备。如果您的用户希望在脱机时访问该文件或在其他应用程序中共享，请使用此选项。
问题：这是否意味着来自firebase存储的所有图像都将下载到用户的手机上？这是否意味着该应用程序将占据手机可用存储空间的很大一部分？
- 在线生成代表文件的
NSURL
如果您已经有了基于URL的下载基础结构，或者只想共享一个URL，则可以通过在存储引用上调用
downloadURLWithCompletion:方法来获取文件的下载URL。
问题：此方法是否需要强大的互联网连接和/或电话服务连接才能工作？
通常，您的内存使用率不应该受到检索方法的影响。只要你显示这100张图像，它们的数据就会存储在内存中，如果它们的格式/压缩相同，则应该具有相同的大小。
无论哪种方式，我建议您实现分页(为了方便起见，这个问题的答案可能是一个很好的实现参考/指南)，以可能减少内存和网络使用。
现在，我们来比较一下方法：
-
方法1
。。。但它必须将文件的全部内容加载到内存中。
这句话可能会让一些人误以为这是内存效率低下的解决方案，当它真正意味着无法检索部分数据，只能下载整个文件在存储图像的情况下，您可能希望数据要有意义。
如果您的应用程序需要在每次用户访问它(即，如果您的图像定期更新)，则这种方法可能最适合你。图像将被下载每次应用程序启动时，当你杀了它。
你说你的一部分用户群可能有一个薄弱的互联网连接，因此下一种方法可能更有效用户友好型
-
方法2
首先，你的问题的答案：
- 是的。使用此方法下载的图像将存储在用户的设备上
- 这些图像的大小应该与它们在Firebase存储中的大小大致相同
其次，如果您计划使用此方法，那么我建议您存储数据库中的时间戳(或任何类型的标记)图像发生了更改。然后，每次打开应用程序时以下流程：
- 如果没有下载图像->下载图像并在本地存储数据库时间戳
- 如果本地时间戳不等于数据库上的时间戳->下载图像并在本地存储新的时间戳
- 否则->使用您已经拥有的图像，它们应该与Firebase存储中的图像相同
如果您的网络使用优先级为高于本地存储器的容量。
最后。。。
-
方法3(不是真的)
这是而不是数据下载方法，这只是生成一个提供了对子项的引用的下载URL。然后你可以使用它URL，用于在您的应用程序或其他地方下载数据，只要使用应用程序或API被授权访问您的Firebase存储。
更新：
URL是从Firebase引用(
FIRDatabase.database().reference().child("exampleReference"))生成的，看起来如下：(注意：这是一个假的链接，实际上不起作用，只是用于说明目的)https://firebasestorage.googleapis.com/v0/b/projectName.appspot.com/o/somePathHere%2FchildName%2FsomeOtherChildName%2FimageName.jpg?alt=media&token=1a8f83a7-95xf-4d3s-nf9b-99a274927bcb如果你只是试图访问通过任何常规web浏览器生成的链接(假设你的项目中没有任何与之冲突的Firebase
rule)，你可以直接从任何下载该图像，而不仅仅是通过你的应用程序。因此，总之，这个"方法"不会从Firebase存储中下载数据，它只是返回数据的下载URL，以防您想要直接链接。