映像存储性能反应本机(Base64与URI路径) [英] Images storage performance react native (base64 vs uri path)

问题描述

我有一个应用程序来创建一些数据和图像的报告(最小1 img，最多6)。此报告保存在我的应用程序中，直到用户将其发送到API(这可以在他注册报告的同一天完成，也可以在一周后完成)。

但我的问题是：存储此图像的正确方式是什么(我使用的是Realm)，它是保存路径(Uri)还是Base64字符串？我当前的版本保留了此镜像的Base64(500~~800 kb img大小)，然后在我的用户将他的报告发送到API后，我删除了这个Base64散列。

我正在开发一种方法来保存图像的路径，然后显示它。但返回的图像拾取器URI是暂时的。为此，我需要将该文件复制到另一个位置，然后保存路径。但这样做后，我在手机上(使用内存)存储了2倍的图像。

所以在我开发所有这些东西之前，我在想，它(将图像复制到另一个路径然后保存路径)是比保存Base64哈希(存储在手机上)性能更高，还是应该没有太大区别？

推荐答案

我尽量避免纯文本答案；包括代码是最佳做法，但有关存储图像的问题经常出现，并且文档中并未真正介绍它，因此我认为应该在较高级别上解决该问题。

一般而言，领域不是存储BLOB类型数据的解决方案-图像、PDF等。这有许多技术原因，但最重要的是，图像可能远远超出领域字段的容量。此外，它还会显著影响性能(尤其是在同步用例中)

如果这是仅限本地的应用程序，则将图像存储在设备中的磁盘上，并保留对它们在领域中存储位置(它们的路径)的引用。这将使应用程序以最小的占用空间快速响应。

如果这是一个同步解决方案，其中您希望跨设备或与其他用户共享图像，则有几个基于云的解决方案可以支持图像存储，然后将图像的URL存储在领域中。

一个选项是名为GridFS的MongoDB产品系列(还包括MongoDB领域)的一部分。另一种选择是我们利用多年的可靠产品称为Firebase Cloud Storage。

现在我已经做了这些陈述，我将稍微回顾一下，并向您推荐这篇文章Realm Data and Partitioning Strategy Behind the WildAid O-FISH Mobile Apps，这是一篇关于在实际使用的应用程序中实现领域，特别是如何处理图像的精彩文章。

在那篇文章中，注意到他们确实在领域中存储了很短时间的图像。然而，他们遗漏了一件事(这是在一个论坛帖子中透露的)，即图像被压缩，以确保它们不会超过领域字段大小限制。

我并不完全赞同该技术的一般用法，但它适用于该特定用例。

再注意一点：问题中提到的图像大小非常小(500~~800 kb img大小)，这是真正不会产生影响的极少量数据，因此将它们作为数据对象存储在领域中将很好地工作。需要注意的是未来的扩展；如果您决定稍后存储更大的图像，则需要完全重写代码；因此，为什么不提前做好计划。

这篇关于映像存储性能反应本机(Base64与URI路径)的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！