我使用 ZXing 库编写了一个 Android 应用程序，我得到了一个java.lang.OutOfMemoryError.
首先，我确信错误已经结束，所以我使用了 Eclipse Memory Analyzer (MAT)，根据 Patrick Dubroy Google I/O 2011: Memory management for Android Apps和其他几个关于如何追踪内存泄漏的教程，比如Android 内存泄漏或不同的泄漏方式。
在 MAT 中，我发现随着时间的推移，数百个实例com.google.zxing.common.BitMatrix占用了我的大部分堆内存。
令人惊讶的是，我在原来的ZXing测试程序“CaptureActivity”中遇到了同样的问题！
经过一番调查，我知道DecodeHandler类中的活动引用可能会阻止垃圾收集器释放BitMatrix. 但我的经验太少，无法验证这一点。此外，我很惊讶在原来的 ZXing 库（2.1 版）中发现了这个问题。
任何人都可以重现这种现象或曾经经历过这种现象吗？
我认为你在正确的轨道上。您需要继续查看 MAT 堆配置文件，以确定用户代码的哪一部分持有DecodeHandler对BitMatrix. 尝试跟踪来自BitMatric, 计算支配树的传入引用并检查泄漏嫌疑人。
尝试分析应用程序以查看代码的哪一部分负责BitMatrix分配，尝试将其跟踪回应用程序代码。
CaptureActivity 示例遇到同样的问题，可能是由于库的使用不当造成的，因此并不一定证明该库有内存泄漏。例如，库可能已经更新，而示例保持不变。
我在 Android 模拟器（Intel 版本）上发现了同样的问题（在 ZXing 的 2.3 版本中）。根本原因似乎如下：在selectBestPatternsclass 的方法中，当没有找到有效的 (QR) finder 模式时抛出FinderPatternFindera 。NotFoundException这个异常在decodeInternal类的方法中被捕获MultiFormatReader。因此，此异常跳过了一些方法调用的正常返回。我发现由于这个“异常返回”，实例FinderPatternFinder没有被释放，而该实例又保留了一个引用BitMatrix，这使用了相当多的内存。听起来很疯狂，而且我认为这不符合 Java 规范，所以我称它为模拟器中的错误。解决方法是不依赖异常来表示未找到查找器模式。我通过在结束方法调用堆栈的同时返回一些空结果来做到这一点。这完全解决了内存泄漏。