android - 通用Android垃圾回收

Question

我不想提出一个模糊的问题，所以我将尽力使这个问题尽可能清楚（尽力而为）。

我知道很长一段时间以来，垃圾回收一直是编程中的灰色地带。我不确定Android或其他手机的情况。

我对android中的垃圾收集的了解：


它收集类系统的类对象（通过对答案的更正制成）。
编辑*“ GC仅在销毁活动后才收集活动项目。活动生命周期由清单中其属性驱动，也由启动活动的意图标志驱动。” – Seva Alekseyev。正如评论员所说。
您可以使用“ System.gc（）”强制进行垃圾回收，尽管不建议这样做，因为它可能会删除一些重要的类项目。


现在我从stackoverflow获得了此信息（现在知道它不再是用于垃圾收集的灰色区域）

我的问题：


您如何从中获取有关过程的信息或有关垃圾收集的一般信息（书籍，互联网文章等）？
如果没有问题1的答案，那么在开发需要不断使用内存的应用程序时，应提醒开发人员的其他方法有哪些？

Answer 1

我不确定您的信息是否正确。


  它收集类系统类。


否。它收集从任何系统根目录不再可访问的对象的实例。系统根目录包括任何静态引用，来自线程的活动堆栈框架的任何引用，任何活动的同步监视器以及由本机代码段（全局或本地）保存的任何内容。如果存在从对象到根的路径（追溯到参考图），则该对象被视为活动对象（因此无法回收）。没有根目录路径的任何对象都可以由垃圾收集器回收。类由ClassLoader引用，并且从不重载，因此系统不会将其回收，除非收集了ClassLoader并收集了这些类的所有实例。因此Android永远不会收集类系统类，因为永远不会收集ClassLoader。


  如果android清单文件指出活动为hasNoHistory或singleTop，则它仅从活动中收集项目


否。活动只不过是对象的实例。当对活动的引用消失时，它所指向的所有引用都会消失，除非其他一些根指向该对象。通过设置singleTop =“ true”，您只是告诉Android实例化此活动的单个实例，并且所有发送的意图将由该单个实例处理。它对GC没有任何影响。当活动松开其到根目录的路径时，无论该活动上的设置是什么，都将对其进行回收。


  您可以使用“ System.gc（）”强制进行垃圾回收，尽管不建议这样做，因为它可能会删除一些重要的类项目。


没有垃圾收集算法不会删除任何活动对象。根据上面的定义，这意味着GC可以收集您使用的不正确的对象。如果这样做的话，那就是个大错误。这也是垃圾回收算法的优点，因为它们可以保证完美清理垃圾。如果您的内存不足，程序员会忘记删除引用，或者您对内存的使用很粗心。您不应该调用System.gc（）的原因是，当最佳时间是回收内存时，您/您的程序就不知道了。垃圾收集器试图最大化（程序运行的时间）与（它花费在收集垃圾上的时间）之比。它保留非常详细的统计信息，并估计何时运行垃圾回收而不是简单地分配更多内存的好时机。

这就像打扫房子。您不能一直清洁，因为这会使您花费更长的时间来做事（例如烹饪）。但是，如果您从不打扫房屋，则可能需要整天打扫。因此，您必须在清洁之前花费多长时间来平衡它，而不是执行任务。

这就是为什么您不应该在程序中计算/猜测/强制GC的原因，因为Android已经为您实现了它，并且将做得比您希望的更好。

这对开发人员意味着什么？


让Android处理何时应运行GC。
清理引用以帮助GC知道何时可以回收某些内容。对静态引用要非常小心，绝不要让静态对象将对活动，服务等的引用保存到一个引用中。
不要分配大量的短期内存。这将迫使更多的GC时间进行清理。通过保守地分配内存，可以定义该比例。


在大多数情况下，GC都非常实用。开发人员遇到的唯一问题是不能为寿命长的对象与UI对象建立界限。如果一个寿命很长的对象具有对UI的引用，则必须注销该UI，否则您将泄漏内存。 UI可以保存对长期存在的对象的引用，但不能相反。

Android的真正问题是您使垃圾收集器工作了多少。如果将要使用的内存量保持较小，则垃圾收集器将不必执行大量工作。这并不意味着您应该重用对象或创建对象池等。但是，您应该知道哪些语句正在创建内存，以及这些对象的生存期。

通常，有关垃圾收集的信息很多，尤其是Java的并发标记和清除垃圾收集器。 Android的垃圾收集器的性能不佳，但是相当不错。在大多数情况下，除非有问题，否则我通常不会担心GC，因此大多数情况下它不会动手。

而且垃圾回收并不是一个灰色地带。自从1994年Java推出以来，它已经非常广泛地理解了这一行业，并且该行业在很大程度上扩展了该领域。