通用Android垃圾收集

Question

我不想创建一个模糊的问题，所以我会尽量让它尽可能清晰（尽力而为）。

我知道垃圾收集在编程中已经很长时间了。我不确定Android或其他手机的情况。

我对android中的垃圾收集知道了什么：

1. 它收集类系统类ojbects（通过答案修正）。
2. 编辑*“只有在活动被销毁后，GC才会收集活动项目。活动生命周期由清单中的属性驱动，也可以通过启动它的意图标志来驱动。” - Seva Alekseyev。评论者说。
3. 您可以使用“System.gc（）”强制进行垃圾收集，但不建议这样做，因为它可能会删除重要的类项目。

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

回答我的问题：

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

Answer 1

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

  

它收集类系统类。

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

  

如果android清单文件声明活动是hasNoHistory或singleTop

，它仅从“活动”中收集项目

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

  

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

没有垃圾收集算法不会删除任何活动对象。根据您在上面的定义，它意味着GC可以收集您正在使用的不正确的对象。如果它确实是一个大错误。这也是垃圾收集算法的美妙之处在于它们可以保证完美地清理垃圾。如果您的内存不足，程序员忘记删除引用，或者您对使用内存不小心。您不打算调用System.gc（）的原因是您/您的程序在最佳时间回收内存时没有任何线索。垃圾收集器正试图最大化（程序运行的时间）与（收集垃圾的时间）的比率。它保留了非常详细的统计信息，并估算了何时运行垃圾收集与分配更多内存的好时机。

这就像打扫你的房子。你无法随时清洁，因为它会让你做的事情需要更长的时间，你必须让它弄脏（就像烹饪一样）。但是，如果你从不打扫你的房子，可能需要一整天的时间来清理它。因此，在清理它之前需要花费多长时间才能完成任务之间的平衡需要达到平衡。

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

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

1. 让GC在运行时处理。
2. 清理参考文献以帮助GC知道什么时候可以回收。要非常小心静态引用，并且永远不要允许静态将活动，服务等的引用保存到一个。
3. 不要分配大量的短暂内存。这将迫使更多GC时间进行清理。通过保守地分配内存，你可以根据定义帮助这个比例。

大多数时候，GC非常热闹。开发人员遇到的唯一问题是没有为长生活对象与UI对象建立边界。如果一个长生命对象有一个引用回UI，那么你必须取消注册，否则你会泄漏内存。 UI可以保存对长生命对象的引用，但不是相反。

Android的真正问题在于您使垃圾收集器的工作量有多大。如果你保持使用的内存量很小，那么垃圾收集器就不会有大的工作量。这并不意味着您应该重用对象或创建对象池等。但是，您应该知道哪些语句正在创建内存，以及这些对象的生存时间。

有关垃圾收集的大量信息，尤其是Java的Concurrent Mark和Sweep垃圾收集器。 Android的垃圾收集器效率不高，但它非常好。大部分时间我都不担心GC，除非出现问题，所以大多数都是放手。

垃圾收集不是灰色区域。这是非常好理解的，自从Java于1994年推出以来，该行业已经大大扩展了这个领域。