在 Android 上打开 jpeg - 我收到 OutOfMemoryException
在我的应用程序中，我需要处理 Android 内置应用程序拍摄的图像。它们保存为 JPEG 格式，我需要访问每个像素。我尝试从 jpeg 图像创建 Bitmap 实例，但经常收到 OutOfMemoryException。我无法调整图像大小或裁剪图像。是否存在解决方案？
In my application I need to process images taken by Android's built-in applications. They're saved into JPEG format, and I need to get access to each pixel. I tried to create a Bitmap instance from the jpeg image, but very often I get an OutOfMemoryException. I can't resize or crop image. Does a solution exist?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
查看 BitmapRegionDecoder。它从 API 级别 10 开始可用。您可以解码图像文件的部分内容并处理每个块。
Check out BitmapRegionDecoder. It is available since API level 10. You can decode parts of an image file and process each chunk.
BitmapFactory 经常会抛出 OutOfMemoryExceptions，恐怕我从未真正发现过任何解决方法。它似乎正在进行自己的内存管理，有时它确实无法解析图像。在我开发的几个需要大量处理图像的应用程序中，我只需要捕获异常，然后在无法解析图像时在 UI 中留下空白点。有时，如果您稍后重试，这些图像将会解析，大概是在 BitmapFactory 的内部内存状态工作得更好时。
当我开发 J2ME 应用程序时，我试图找到一个纯 Java 开源 JPEG 解析器，这样我就可以在没有内置 JPEG 支持的手机上使用它。事实证明，这样的东西很难找到，我能找到的最接近的东西被埋在 Eclipse 源代码的深处。我能够获取该来源，将其去Eclipsify并尝试一下。它确实具有逐行读取内容的优点（尽管我不确定使用逐行扫描 JPEG 会怎样），但在我们的 J2ME 设备上速度慢得离谱（特别是因为它们大多是低端设备）所以我们最终没有用它来做任何事情。
BitmapFactory will often throw OutOfMemoryExceptions and I'm afraid that I've never really discovered any workarounds. It seems to be doing its own memory management, and sometimes it really isn't capable of parsing an image. In a couple of applications I've worked on that had to deal with images heavily, I just had to catch the exception and then leave blank spots in the UI when I couldn't get an image parsed. Sometimes, if you try again later, those images will parse, presumably when the internal memory state of BitmapFactory is working better.
When I was working on a J2ME application, I tried to find a pure Java open source JPEG parser so I could use it on phones that didn't have built-in JPEG support. Turns out that such a thing is difficult to find, and the closest I could find was buried in the depths of the Eclipse source. I was able to take that source, de-Eclipsify it and try it out. It did have the virtue of reading in things line by line (although I'm not sure how it would have done with progressive scan JPEGs), but it was ridiculously slow on our J2ME devices (particularly since they were mostly the lower end ones) so we didn't end up using it for anything.