我想在一个活动中实现onTrimMemory(int level)，将内存中的一些Bitmap对象写入硬盘，并回收它们。但我不确定这是否会阻塞 UI 线程，我应该在另一个线程中运行代码吗？或者该方法可能已经默认在另一个线程上运行？
另一个相关问题是：当活动在前台时，onTrimMemory 会被调用吗？医生说：
换句话说，如果我正确实现onTrimMemory（释放足够的内存），我是否需要担心OOM错误？
或者onTrimMemory只有在activity进入后台时才被调用，所以当app在前台时仍然会发生OOM？
【问题讨论】：
标签： android memory-management android-lifecycle
1. onTrimMemory 会在 UI 线程上调用吗？
是的。来自docs：
...响应系统回调的方法（例如用于报告用户操作的 onKeyDown() 或生命周期回调方法）始终在进程的 UI 线程中运行。
如果您想从源代码中获得保证，请注意调用的根发生在 here；一个Runnable 发布到ActivityThread's 主Handler。
2。当活动在前台时，onTrimMemory 会被调用吗？
我不确定。文档没有明确禁止它，因此设计良好的应用程序应该允许这种可能性。
看起来源代码中的this call 可能适用于前台应用程序。
3.如果我正确实现onTrimMemory（释放足够的内存），我是否需要担心OOM错误？
您总是需要担心 OOM 错误。总是可以请求比系统提供的更大的分配。 onTrimMemory() 方案反映了一种在“尽力而为”的基础上释放资源的方法；无法保证您的应用或系统上的其他应用会合作达到任何特定的内存阈值。
如果您的应用在后台，它可能不会做太多事情，尤其是在分配方面。也许是您设备上的其他应用程序获得了您应该担心的 OOM（如果您的应用程序未能释放“足够”的内存以响应 onTrimMemory() 调用）。
4.或者onTrimMemory只有在activity进入后台时才被调用，所以当app在前台时仍然会发生OOM？
如前所述，OOM 可能在您尝试进行分配的任何时候发生。希望您设备上的其他应用程序能够真诚地努力减少它们的内存消耗（在onTrimMemory() 之后），以便为您的前台应用程序提供最大数量的资源。如果不这样做，它们很可能会被终止（从 ActivityManagerService.java 中的逻辑可以看出），这会释放更多资源。
系统将尽最大努力确保您的前台应用程序拥有它所请求的资源。也就是说，您应该以合理的方式规划您的内存使用，并且能够在发生错误 (OOM) 时从容地恢复。
【讨论】：