使用Base64将Android图像上载/下载到JSON会导致内存不足错误

我目前将图像编码和解码到Base64。我克服了OOM的最初问题，使用流将图像编码成字符串

我现在的问题是，我无法理解如何通过Gson将多分辨率图像（5620 x 3747-4.92MB或3264 x 1836-1.35MB）的多个Base64编码字符串添加到JSON对象。目前，Gson仅对5312 x 2988-4.95 MB映像中的2个Base64字符串引发OOM异常

我知道android可能只能为每个应用程序留出16/20Mb的空间，所以这种转换必须远远超出限制

如何将流中的Base64字符串写入JSON对象，该对象将包含发布到服务器所需的特定值

将我的服务器更改为接受多部分请求而不是使用多个Base64字符串的基于JSON的POJO会更容易吗？我目前使用截击，没有正式的多部分请求以及IO流

如果这是一个压缩的问题，在编码成Base64字符串之前，我应该对图像应用多少压缩？理想情况下，我希望几乎不损失任何质量，但有最佳的压缩级别

更多信息

我上传多个不同分辨率的图像，因为这是一个兼容性测试。例如，我发送的所有图像都是在低分辨率和极高分辨率的设备上拍摄的，因为我的应用程序依赖这些图像来实现功能。我试图证明我的应用程序可以处理任何图像（在一定程度上，主要是在移动设备上捕获的图像）

我知道有些图像可能太大，将它们加载到内存中会导致异常。这是我稍后会尝试处理的事情

在某些情况下，将上载的图像范围从1到200

我正在努力寻找最理想的解决方案，它可以很好地扩展

。。。对于多分辨率图像（5620 x 3747-4.92MB或3264 x 1836-1.35MB）

不确定这是在内存中分配图像所需的文件大小还是内存，但查看以下链接：，我看到了：

对于4000 x 2500像素的图像

然后：4000 x 2500像素=4000x2500=1000万像素

4000x2500 x 3=3000万字节（如果为24位RGB）

30000000字节/（1024 x 1024）=28.61兆字节（MB）

这就是数据的大小——对于任何24位1000万像素 图像，但JPG文件将其压缩得更小（仅在文件中）

我认为你处理的图像比你想象的要占用更多的内存

另外，看看这个问题和答案：，我们知道图像的base64表示比原始图像大小多占用37%的内存

如何将流中的Base64字符串写入JSON对象，该对象将包含发布到服务器所需的特定值

我认为您可以通过简单地在JSON对象中添加图像的base64表示，然后将其发布到服务器来实现这一点（对于小图像而不是大图像）

将我的服务器更改为接受多部分请求而不是使用多个Base64字符串的基于JSON的POJO会更容易吗

在我看来，这将是你实现你想要实现的目标的最佳选择

我目前使用截击，没有正式的多部分请求以及IO流

你可以看看这个答案：，你肯定可以用截击来完成，但是如果你想要一个替代方案，你可以尝试改型（），它们支持盒子的多部分

例如：

@Multipart
@放置（“用户/照片”）
调用updateUser（@Part（“photo”）RequestBody photo、@Part（“description”）RequestBody description）；

我研究了使用Volley作为将大型JSON对象传输到服务器的机制，发现了这一点。这个答案基本上证明了凌空抽射对于我想要的是个坏主意

我切换到并使用了他们的流式方法，允许JSON流式传输到服务器，然后以简化的方式读取响应。我使用GSON库解析响应，因为OKHttp允许将响应JSON/对象流式传输到读卡器对象中，然后GSON使用读卡器对象进行内部流式传输并解析到POJO类

我没有切换到多部分请求的唯一原因是服务器端实现非常严格，不可更改，无法覆盖多部分请求，它严格要求数据和文件的JSON表示

为了在Android上处理Base64图像，我强烈建议使用

字符串

表示法查找not，并仅转换为字节以节省过多的内存。我读了一篇关于

String

内存使用和管理的文章。使用字节，您可以轻松地传输数据，而不会在内存上留下大量的内存占用

---

对于显示图像，我仍然通过使用图像库避免字节到字符串的转换。它们允许您传入一个

字节[]

，这非常方便。

如果您想在截取时使用多部分请求，IMO，您可以参考我的示例代码。在@kevinkl3答案中，我也有一个答案

@Multipart
@PUT("user/photo")
Call<User> updateUser(@Part("photo") RequestBody photo, @Part("description") RequestBody description);