标签:
OOM可能是因为Memory Leak,也可能是你的应用本身就比较耗内存(比如图片浏览型的)。所以,出现OOM不一定是Memory Leak。
同样,Memory Leak也不一定就会导致OOM,如果泄露的速度很慢,可能还没用完可用内存应用就被重启了,那就不会OOM咯。当然了,有bug解决了最好。
GC的时候,是从这些节点开始遍历,不停的寻找其子节点直到结束。然后把不能遍历到的节点释放。这些遍历的起点(注意,可不是一个哦)就叫做GC roots。
那,对于java来说,谁是GC roots?简单点说(不是那么准确)包括以下几种:
4.1 看Histogram(类统计图)
对于Android程序来说,内存泄露通常都会牵扯到activity。因此,dump之前,可以多旋转几次屏幕并反复的进出可能有问题的activity,让问题尽可能的凸现。
通过Histogram我们可以看每个类有多少个实例,shallow和retained heap分别有多大。如果只是看java的基础类型和framework的类,没有什么意义,一定要过滤出自己的类型,如下图
发现LeakInnerClassActivity产生了9个实例,一定是被hold住了。
4.2 看Dominator Tree
怎样使用还没弄清楚,感觉和histogram比没啥特色捏,嘿嘿
4.3 对比heap dumps,可以更快的定位内存泄露的位置。操作步骤:
参考:Memory Analysis for Android Applications
//首先,静态类
static class IncomingHandler extends Handler {
//其次,弱引用
private final WeakReference<UDPListenerService> mService;
IncomingHandler(UDPListenerService service) {
mService = new WeakReference<UDPListenerService>(service);
}
@Override
public void handleMessage(Message msg) {
UDPListenerService service = mService.get();
if (service != null) {
service.handleMessage(msg);
}
}
}
8. 什么时候需要手动将变量设置为NULL?
标签:
原文地址:http://www.cnblogs.com/melody-emma/p/4552517.html