通用Android垃圾收集

Question

我不想制造一个模糊的问题，所以我会尽量把这个问题弄清楚(我会尽我最大的努力)。

我知道垃圾收集一直是编程中的一个灰色地带。我不确定android或其他手机的情况。

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

1. 它收集类系统类ojbects(根据答案进行更正)。
2. Edit* "GC只在活动被破坏后才收集活动项。活动生命周期由清单中的属性驱动，也由启动它的意图的标志驱动。“- Seva Alekseyev。正如评论所言，
3. 您可以强制使用"System.gc()“进行垃圾收集，尽管这是不推荐的，因为它可能会删除一些重要的类项。

现在，我从堆栈溢出(现在知道它不再是垃圾收集的灰色区域)获得了这些信息。

来问我的问题：

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的并发标记和清除垃圾收集器。Android的垃圾收集器没有那么好的表现，但它相当不错。大多数情况下，我不担心GC，除非有问题，所以主要是放手。

垃圾收集也不是灰色地带。这一点很容易理解，自Java于1994年引入以来，业界已经扩展了相当多的领域。