我有一个应用程序可以创建包含一些数据和图像的报告（最少 1 个图像，最多 6 个）。此报告会一直保存在我的应用中，直到用户将其发送到 API（可以在他注册报告的同一天或一周后完成）。
但我的问题是：存储这些图像的正确方法是什么（我正在使用 Realm），它是保存路径 (uri) 还是 base64 字符串？我当前的版本保留了这个图像的 base64（500 ~~ 800 kb img 大小），然后在我的用户将他的报告发送到 API 后，我删除了这个 base64 哈希。
我正在开发一种方法来保存图像的路径，然后我将其显示出来。但是返回的图像选择器 uri 是暂时的。所以要做到这一点，我需要将此文件复制到另一个地方，然后保存路径。但是这样做，我得到了（大约 2 或 3 天）2x 图像存储在手机上（使用内存）。
所以在我开发所有这些东西之前，我想知道，它（将图像复制到另一个路径然后保存路径）是否比保存 base64 哈希（存储在手机中）更高效，或者它应该没有太大区别？
答案 0 :(得分：1)
我尽量避免纯文字回答；包含代码是最佳实践，但有关存储图像的问题经常出现，而且文档中并未真正涵盖它，因此我认为应该在较高级别解决这个问题。
一般来说，Realm 不是存储 blob 类型数据（图像、pdf 等）的解决方案。这有很多技术原因，但最重要的是，图像可以远远超出 Realm 字段的容量。此外，它会显着影响性能（尤其是在同步用例中）
如果这是一个仅限本地的应用程序，将图像存储在设备的磁盘上，并保留对它们在 Realm 中存储位置（它们的路径）的引用。这将使应用能够以最小的占用空间快速响应。
如果这是一种同步解决方案，您希望在其中跨设备或与其他用户共享图像，则有多种基于云的解决方案可以容纳图像存储，然后将图像的 URL 存储在 Realm 中。
一个选项是名为 GridFS 的 MongoDB 系列产品（其中还包括 MongoDB Realm）的一部分。另一种选择是我们多年来一直利用的可靠产品Firebase Cloud Storage。
既然我已经做出了这些陈述，我将稍微回溯一下并让您参考这篇文章 Realm Data and Partitioning Strategy Behind the WildAid O-FISH Mobile Apps，这是一篇关于在实际使用应用程序中实现 Realm 的绝妙文章，特别是如何处理图片。
在那篇文章中，请注意他们确实在 Realm 中存储了很短的时间。然而，他们忽略的一件事（在论坛帖子中透露）是图像被压缩以确保它们不会超过 Realm 字段大小限制。
我并不完全了解该技术的一般用途，但它适用于该特定用例。
还要注意：问题中提到的图像大小非常小（500 ~~ 800 kb img 大小），这是一小部分数据，实际上不会产生影响，因此将它们作为数据对象存储在领域中会工作得很好。对此的警告是未来的扩张；如果您决定稍后存储更大的图像，则需要完全重新编写代码；那么为什么不提前计划呢。