在Android的垃圾收集(手动完成)

我有一个奇怪的疑惑。 我知道垃圾收集器有其自身的局限性。 如果分配不好,则可能会导致应用程序以不寻常的方式进行响应。

所以我的问题是,在每个活动结束时强制调用垃圾收集器( System.gc() )是不是很好的编程习惯?

更新

每个人都说,调用system.gc()根本就没有好处。那么我想知道为什么它现在在这里.DVM将决定什么时候运行垃圾回收器。那么需要什么方法呢?

更新2

感谢社区帮助我。 但老实说,我从这个链接的Java性能优化了解垃圾收集真正的波伏娃的知识

Solutions Collecting From Web of "在Android的垃圾收集(手动完成)"

在每个活动结束时强制调用垃圾收集器(System.gc()) 不好的编程习惯

因为它是无用的,只有DVM决定什么时候应该打电话,尽pipe你叫它…

虚拟机有时忽略的System.gc()在两种情况下最为有用:

  1. 你正在吞噬内存,就像没有明天(通常是位图)一样。
  2. 您怀疑内存泄漏(例如意外保留旧的上下文),并且希望将虚拟机内存置于静止状态,以查看内存使用量是否正在逐渐增加以进行debugging。

在名义上的情况下,不应该使用它。

调用System.gc() ,没有任何伤害。 但是你不能确定它会有用处。 因为你要求 DVM做垃圾收集,但不能命令它…它完全依赖于DVM。 它调用时内存不足或可能在任何时间..

我真的觉得这取决于你的情况。

因为堆是分代的,所以GC在其第一遍中可能没有摆脱某些大对象或位图,并且其启发式可能不会指示额外的垃圾收集是必要的,但肯定存在启发式可能是错误的情况,并且我们因为开发人员有一个模式的知识,或者可以预测GC不能使用的用法,因此调用system.gc()会使我们受益。

我曾经在特定场景中看到过这种情况,例如处理地图平铺或其他graphics密集型行为,Android中的本地GC(即使在3.0以上的设备上)也无法正确处理,导致内存不足错误。 但是,通过添加一些GC调用,可以防止内存不足错误,并且系统继续处理,尽pipe速度较慢(由于垃圾收集)。 在graphics密集型操作中,这通常是应用程序崩溃所需的状态(有点滞后),因为它无法将额外资源加载到内存中。

为什么在某些情况下发生这种情况,我唯一的解释似乎是时机。 如果用户操作很慢,那么原生的Android GC似乎做得很好。 但是,如果你的用户快速滚动,或者快速缩放,这就是我看到的Android GC滞后的原因,一些深思熟虑的System.gc()导致我的应用程序不会崩溃。

没有; 如果系统需要内存,它将自行调用GC。

任何其他地方没有引用的实例使用的任何内存,当实例消失时,都将变为符合条件的GC。

实例本身使用的内存(如果不再引用)也适用于GC。 你可以做一个代码审查或分析,看看你是否不必要地记住了内存,但这是一个不同的问题。

Patrick Dubroy在Google IO 2011上展示了一个关于内存pipe理的会议。 自从他讨论了堆的分配和GC的工作以来,值得一看。 你可以在这里看内存pipe理

我试图把System.gc()放在我的Android应用程序中创build位图的行之前。 垃圾收集器在某些情况下释放了几兆字节,并放置并终止到我的OutOfMemoryError条件。 它并没有干扰正常的垃圾收集,但它确实使我的应用程序运行得更快。

手动调用GC 一种糟糕的编码习惯

开发人员文档在RAM使用状态:


GC_EXPLICIT

一个显式的GC,比如当你调用gc() ( 你应该避免调用 ,而是相信GC在需要的时候运行)。

我突出强调了这里最重要和最重要的部分。