android系统如何管理内存溢出,Android:内存控制及OOM处理

1. OOM(内存溢出)和Memory Leak(内存泄露)有什么关系?

OOM可能是因为Memory Leak,也可能是你的应用本身就比较耗内存(比如图片浏览型的)。所以,出现OOM不一定是Memory Leak。

同样,Memory Leak也不一定就会导致OOM,如果泄露的速度很慢,可能还没用完可用内存应用就被重启了,那就不会OOM咯。当然了,有bug解决了最好。

2. 什么是shallow heap与retained heap?

shallow heap:你自身占了多少内存,比如你有一个int属性,就占4字节。不包括你引用的其他对象。

retained heap:如果你被销毁,总共会释放多少内存。这些因你存在被占据的空间就是retained heap。

3. 什么是GC roots?

GC的时候,是从这些节点开始遍历,不停的寻找其子节点直到结束。然后把不能遍历到的节点释放。这些遍历的起点(注意,可不是一个哦)就叫做GC roots。

那,对于java来说,谁是GC roots?简单点说(不是那么准确)包括以下几种:

栈上面的局部变量

栈上面的函数参数变量

所有由Bootstrap Loader加载的类变量

另外,JNI相关的也会有

4. 怎样使用MAT定位内存泄露?

4.1 看Histogram(类统计图)

e9eb8504788ec3c8462d52366f1820ed.png

对于Android程序来说,内存泄露通常都会牵扯到activity。因此,dump之前,可以多旋转几次屏幕并反复的进出可能有问题的activity,让问题尽可能的凸现。

通过Histogram我们可以看每个类有多少个实例,shallow和retained heap分别有多大。如果只是看java的基础类型和framework的类,没有什么意义,一定要过滤出自己的类型,如下图

b65908d9886dc7af67cf1af51cd3618e.png

发现LeakInnerClassActivity产生了9个实例,一定是被hold住了。

4.2 看Dominator Tree

7d492485d513c740691bd0c929b6bf0a.png

怎样使用还没弄清楚,感觉和histogram比没啥特色捏,嘿嘿

4.3 对比heap dumps,可以更快的定位内存泄露的位置。操作步骤:

打开一个HPROF文件,切换到histogram视图

在Navigation View中右键点击histogram,选择Add to compare basket

打开另一个HPROF文件,并重复上一个步骤

对比两次heap dumps的内容,看下图,LeakInnerClassActivity的实例又增加了一个。而我仅仅是又启动了一次该Activity,所以问题显而易见。

a4e18da83679296d7094cf8ea7181497.png

5. 内部类怎样使用才会产生内存泄露,以及由此衍生的AsyncTask、Handler问题如何解决?

如果非静态内部类的方法中,有生命周期大于其所在类的,那就有问题了。比如:AsyncTask、Handler,这两个类都是方便开发者执行异步任务的,但是,这两个都跳出了Activity/Fragment的生命周期。

为什么?因为非静态内部类会自动持有一个所属类的实例,如果所属类的实例已经结束生命周期,但内部类的方法仍在执行,就会hold其主体。也就使主体不能被释放,亦即内存泄露。

静态类呢?静态类编译后和非内部类是一样的,有自己独立的类名。不会悄悄引用所属类的实例,所以就不容易泄露。

//首先,静态类

static class IncomingHandler extends Handler {

//其次,弱引用

private final WeakReference mService;

IncomingHandler(UDPListenerService service) {

mService = new WeakReference(service);

}

@Override

public void handleMessage(Message msg) {

UDPListenerService service = mService.get();

if (service != null) {

service.handleMessage(msg);

}

}

}

6. 图片导致的OOM如何解决?

加载时使用option,用多大,载入多大。

res目录下的图片也是一样,及时清理过大的图片资源。

如果还有问题,就想办法把不可见的资源释放掉,比如,TabActivity中不可见的Tab,ViewPager中的Fragment。

如果activity的图片资源较多,需要考虑屏幕旋转时,销毁已有资源。请参考这篇文章

7. 需要context的时候用activity还是application?

看使用的周期是否在activity周期内,如果超出,必须用application;常见的情景包括:AsyncTask,Thread,第三方库初始化等等。

还有些情景,只能用activity:比如,对话框,各种View,需要startActivity的等。

总之,尽可能使用Application。参考stackoverflow

8. 什么时候需要手动将变量设置为NULL?

类变量,一旦用完,尽快释放。因为类的存活时间最长,所以,占用的资源越少越好;

比较耗时且耗内存的方法内的局部变量,比如,图片处理的方法,每个bitmap对象用完就及时丢弃。尽可能让gc介入。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
当出现OOM(Out of Memory)内存溢出错误时,可以采取以下步骤来进行分析: 1. 查看错误日志:首先,检查应用程序或服务器的错误日志,查找与内存溢出相关的错误消息。错误消息通常会提供一些有关问题的线索。 2. 检查内存使用情况:使用监控工具(如JConsole、VisualVM等)来监视应用程序的内存使用情况。观察内存使用量是否持续增长,以及峰值内存使用量是否接近系统可用内存。 3. 内存分析工具:使用内存分析工具(如Eclipse Memory Analyzer、Java VisualVM等)来分析堆内存中的对象分布和引用关系。这些工具可以帮助你找到内存泄漏或者过多使用内存的地方。 4. 堆转储文件分析:如果应用程序发生了OOM错误并生成了堆转储文件(heap dump),可以使用堆转储文件分析工具进行分析。这些工具可以帮助你找到导致内存溢出的对象和其引用链。 5. 代码审查:仔细检查应用程序的代码,特别是与内存管理相关的部分。检查是否有不必要的对象创建、未及时释放的资源、循环引用等问题。 6. 调整JVM参数:根据应用程序的需求和硬件资源,适当调整JVM的堆内存大小(-Xmx和-Xms参数)、垃圾回收器算法(-XX:+UseParallelGC、-XX:+UseConcMarkSweepGC等)等参数。 通过以上步骤,你应该能够定位并解决OOM内存溢出问题。但请注意,内存溢出的原因可能有多种,需要根据具体情况进行分析和解决。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值