概念根搜索算法Android虚拟机的垃圾回收采用的是 根搜索算法相比引用计数法很好的解决了循环引用的问题。举个例子,Activity有View的引用,View也有Activity的引用,之前我还尝试去源代码里找Activity何时和View断开连接是大错特错了。当Activity finish掉之后,Activity和View的循环引用已成孤岛,不再引用到GC Roots,无需断开也会被回收掉。 内存泄漏
场景
静态变量长期维持到大数据对象的引用,阻止垃圾回收。 非静态内部类会维持一个到外部类实例的引用,如果非静态内部类的实例是静态的,就会间接长期维持着外部类的引用,阻止被回收掉。 资源性对象如Cursor、File、Socket,应该在使用后及时关闭。未在finally中关闭,会导致异常情况下资源对象未被释放的隐患。 未反注册会导致观察者列表里维持着对象的引用,阻止垃圾回收。 Handler 临时性内存泄露Handler通过发送Message与主线程交互,Message发出之后是存储在MessageQueue中的,有些Message也不是马上就被处理的。在Message中存在一个 target,是Handler的一个引用,如果Message在Queue中存在的时间越长,就会导致Handler无法被回收。如果Handler是非静态的,则会导致Activity或者Service不会被回收。 由于AsyncTask内部也是Handler机制,同样存在内存泄漏的风险。 此种内存泄露,一般是临时性的。 预防
context-application 代替context-activity WeakReference 代替。检测静态检测静态检测主要是检测资源未关闭的情况,Eclipse和Android Studio都可以检测出IO或者Socket未关闭的情况,然后在finally中关闭即可。 动态监测动态检测主要是依靠MAT这个工具。2011年Google IO有一个主题演讲,非常详细地讲解了内存泄露的检测,包含MAT工具的使用,值得一看。 ![]() Histogram ![]() 此处输入图片的描述 很明显,静态变量 instance 长期持有context 的引用,造成内存泄露。所以动态检测内存泄露的一个简单思路就是随意操作APP,最后返回首页,然后用MAT检测,查看是否存在Activity多于一个或者Activity不正常存在的问题。 参考资料 |
|
来自: icecity1306 > 《开发资料》