通用Android垃圾回收 [英] Generic Android Garbage Collection
问题描述
我不想提出一个模糊的问题，所以我将尽力使这个问题尽可能清楚(尽力而为).
I don't want to create a vague question so I will try to make this as clear as possible (Going to try my best).
我知道很长一段时间以来，垃圾收集一直是编程中的灰色地带.对于Android或其他手机，我不确定.
I know garbage collection has been a grey area in programming for a very long time. I am not certain with the case of android or other mobile phones.
我对android中垃圾收集的了解:
What I know of garbage collection in android:
- 它收集类系统的类对象(由答案改正而成).
- Edit *只有在销毁活动后，GC才会收集活动项目.活动生命周期由清单中其属性驱动，也由启动它的意图标志来驱动. –塞瓦·阿列克谢耶夫(Seva Alekseyev).正如评论员所说.
- 尽管不建议使用"System.gc()"强制进行垃圾收集，因为它可能会删除一些重要的类项目.
现在我从stackoverflow获得了此信息(现在知道它不再是用于垃圾收集的灰色区域)
Now I obtained this information from stackoverflow(Now knowing that it is no longer a grey area for garbage collection)
我的问题:
- 您如何获得有关垃圾收集过程的此类信息或一般信息(书籍，网络文章等)?
- 如果没有问题1的答案，那么在开发需要不断使用内存的应用程序时，应该提醒开发人员的其他方式是什么?
推荐答案
我不确定您的信息是正确的.
I'm not sure your information is correct.
它收集类系统类.
It collects class system classes.
不.它收集从任何系统根目录不再可访问的对象的实例.系统根目录包括任何静态引用，来自线程的活动堆栈框架的任何引用，任何活动的同步监视器以及由本机代码段(全局或本地)保存的任何内容.如果存在从对象到根的路径(追溯到参考图)，则该对象被视为活动对象(因此无法回收).没有根目录路径的任何对象都可以由垃圾收集器回收.类由ClassLoader引用，并且从不重载，因此系统不会将其回收，除非收集了ClassLoader并收集了这些类的所有实例.因此Android永远不会收集类系统类，因为从未收集过ClassLoader.
No. It collects instances of objects that are no longer reachable from any of the system roots. System roots include any static reference, any reference from a thread's active stack frame, any active synchronization monitor, and anything held by a native piece of code (global or local). An object is considered live (and hence cannot be reclaimed) if there is a path from it to a root tracing the reference graph backwards. Any object that doesn't not have a path to a root can be reclaimed by the garbage collector. Classes are referenced by a ClassLoader and are never reloaded and hence are not reclaimed by the system unless that ClassLoader is collected and all instances of those classes are collected. So Android never collects class system classes because that ClassLoader is never collected.
如果android清单文件指出活动为hasNoHistory或singleTop，则仅"收集活动中的项目
It collects items from activity "only" if android manifest file states that the activity is either hasNoHistory or singleTop
不.活动只不过是对象的实例.当对活动的引用消失时，它所指向的所有引用都会消失，除非其他一些根指向该对象.通过设置singleTop ="true"，您只是告诉Android实例化此活动的单个实例，并且所有发送的意图将由该单个实例处理. 它对GC没有任何影响.当某个活动失去其根目录路径时，无论该活动的设置是什么，都将对其进行回收.
No. An activity is nothing more than an instance of an object. And when the reference to the activity is gone so goes all of the references it pointed to unless some other root points to that object. By setting singleTop="true" you are only telling Android to instantiate a single instance of this activity, and all intents sent will be handle by that single instance. It doesn't have any impact on GC. When an activity looses its path to a root it will be reclaimed regardless of what the settings on that activity were.
尽管不建议您使用"System.gc()"强制进行垃圾回收，因为它可能会删除一些重要的类项目.
You may force a garbage collection using "System.gc()" although this is not recommended as it may delete something important class item.
没有垃圾收集算法不会删除任何活动对象.根据上面的定义，这意味着GC可以收集您使用的不正确的对象.如果这样做的话，那是一个大错误.这也是垃圾回收算法的优点，因为它们可以保证完美清理垃圾.如果您的内存不足，程序员会忘记删除引用，或者您对内存的使用很粗心.您不应该调用System.gc()的原因是，当最佳时间是回收内存时，您/您的程序就不知道了.垃圾收集器正在尝试最大化(程序运行的时间)与(它花费在收集垃圾上的时间)之比.它保留了非常详细的统计信息，并估计了何时运行垃圾回收而不是简单地分配更多内存的好时机.
No Garbage collection algorithms do not delete any live object. Under your definition above it implies GC can collect an object you were using which is incorrect. If it did that's a big bug. That is also the beauty of Garbage Collection algorithms in that they are guaranteed to clean up garbage perfectly. If you are running out of memory the programmer has forgotten to remove a reference or you are being careless with your use of memory. The reason you aren't suppose to call System.gc() is that you/your program has no clue when the best time is to reclaim memory. The garbage collector is trying to maximize the ratio of (the time your program runs) vs. (the time it spends collecting garbage). It keeps very detailed statistics and makes estimations about when its a good time to run garbage collection vs simply allocating more memory.
这就像打扫房子.您不能一直清洁，因为这会使您花费更长的时间来做事(例如烹饪).但是，如果您从不打扫房屋，则可能需要一整天的时间来打扫房屋.因此，在清理之前需要花费的时间比执行任务要长.
It's like cleaning your house. You can't clean at all times because it makes doing things take longer sometime you have to let it get dirty (Like cooking). However, if you never clean your house it can take all day to clean it. So there is a balance that you must strike between how dirty can it become before cleaning it up takes longer than performing the task.
这就是为什么您不应该在程序中计算/猜测/强制GC，因为Android已经为您实现了它，并且将做得比您希望的要好.
This is why you shouldn't calculate/guess/force GC in your program because Android has already implemented it for you, and will do a better job than you can ever hope to.
这对开发人员意味着什么?
What does this mean for you the developer?
- 让GC处理应在何时运行的Android句柄.
- 清理引用以帮助GC知道何时可以回收某些内容.对静态引用要非常小心，绝不要让静态对象将对活动，服务等的引用保存到一个静态引用.
- 不要分配大量的短期内存.这将迫使您花费更多的GC时间进行清理.通过保守地分配内存，可以定义该比例.
在大多数情况下，GC都是非常实用的.开发人员遇到的唯一问题是不能为寿命长的对象与UI对象建立边界.如果一个寿命很长的对象具有对UI的引用，则必须注销该UI，否则就会泄漏内存. UI可以保留对长期存在的对象的引用，但不能相反.
Most of the time GC is very hands off. The only problems developers get into is not establishing boundaries for long living objects vs. UI objects. If a long living objects has a reference back to the UI that's a place you'll have to unregister or else you'll leak memory. It's ok for the UI to hold references to long living objects, but not the other way around.
Android真正的问题是您使垃圾收集器工作了多少.如果将要使用的内存量保持较小，则垃圾收集器将不必执行大量工作.这并不意味着您应该重用对象或创建对象池等.但是，您应该知道哪些语句正在创建内存，以及这些对象的生存期.
The real issue with Android is how much you make the garbage collector work. If you keep the amount of memory you are using small then the garbage collector doesn't have big jobs it has to do. That doesn't mean you should reuse objects or create object pools, etc. But, you should be aware of what statements are creating memory, and how long those objects live for.
一般而言，有大量有关垃圾收集的信息，尤其是Java的并发标记和清除垃圾收集器. Android的垃圾收集器性能不佳，但是相当不错.在大多数情况下，除非有问题，否则我通常不会担心GC，因此大多数情况下它不会动手.
There are volumes of information on Garbage collection in general and particularly Java's Concurrent Mark and Sweep garbage collector. Android's garbage collector is not as performant, but it's pretty darn good. Most of the time I don't worry about GC unless there is a problem so it's mostly hands off.
垃圾收集不是灰色区域.自从1994年Java推出以来，它已经广为人知，并且该行业已经在该领域进行了相当大的扩展.
And garbage collection isn't a grey area. It's very much well understood, and the industry has expanded the field quite a bit since Java was introduced in 1994.
这篇关于通用Android垃圾回收的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
