Android Profiler显示“Others”内存占用过高且无法被GC回收问题

核心矛盾点 #

你的应用长时间运行（约20分钟）后被系统杀死，Profiler显示Others内存占用极高且无回收；但用循环测试代码时，内存却稳定在200-220MB（以Native内存为主），这种差异主要来自测试场景与实际运行场景的资源使用逻辑不同，以及Others内存的未明确泄漏点。

可能的原因拆解 #

• 测试循环的局限性：测试代码中重复处理同一张图片，OpenCV和Tesseract可能复用了内部缓存或内存缓冲区；而实际场景中处理的是不同图片，每次操作可能产生新的未释放Native资源，累积后导致Others内存持续升高。
• Others内存的本质：Android Profiler的Others分类通常包含未被系统追踪的Native内存块，比如JNI全局引用未释放、OpenCV的Mat对象未调用release()、Tesseract模型加载后的残留内存、文件缓冲区/句柄未关闭等。
• Tesseract实例重复创建的隐患：测试循环中每次创建MyTesseract实例，虽然短时间内内存稳定，但Tesseract初始化会加载OCR模型到Native内存，若实际场景中频繁创建实例且未正确释放模型资源，长期运行会导致内存累积。
• 实际场景的额外内存消耗：应用实际运行时可能包含UI更新、日志记录、图片存储、其他后台任务等测试循环中没有的操作，这些操作产生的未归类内存会被计入Others，且未及时回收。

排查与解决步骤 #

• 重点排查Others内存：
  • 使用Android Studio的Native Memory Profiler追踪Native内存分配的堆栈，定位未释放的内存块来源；
  • 捕获堆转储（Heap Dump），检查是否存在未被回收的JNI引用、Bitmap对象或第三方库实例。
• 优化OpenCV资源管理：
  • 确保OpenCV预处理过程中创建的Mat对象都调用了release()，避免Native内存泄漏；
  • 处理后的Bitmap及时调用recycle()并置为null，触发Java层GC同时释放关联的Native内存。
• 复用Tesseract实例：
  • 将MyTesseract改为单例模式，避免重复加载OCR模型；调用getText()后若有内部Native资源，确保提供释放接口并在合适时机调用。
• 对比实际场景与测试循环：
  • 记录实际运行时的操作流程，比如是否持续加载新图片、是否有文件读写操作，逐一排查这些操作是否产生未回收的内存。
• 内存泄漏检测：
  • 用LeakCanary检测Java层的内存泄漏；Native层可借助LLDB工具排查内存分配与释放的不匹配问题。

内容的提问来源于stack exchange，提问作者zaxunobi