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(类统计图)

对于Android程序来说,内存泄露通常都会牵扯到activity。因此,dump之前,可以多旋转几次屏幕并反复的进出可能有问题的activity,让问题尽可能的凸现。
通过Histogram我们可以看每个类有多少个实例,shallow和retained heap分别有多大。如果只是看java的基础类型和framework的类,没有什么意义,一定要过滤出自己的类型,如下图

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

4.2 看Dominator Tree

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

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

  • 打开一个HPROF文件,切换到histogram视图
  • 在Navigation View中右键点击histogram,选择Add to compare basket
  • 打开另一个HPROF文件,并重复上一个步骤
  • 对比两次heap dumps的内容,看下图,LeakInnerClassActivity的实例又增加了一个。而我仅仅是又启动了一次该Activity,所以问题显而易见。

参考:Memory Analysis for Android Applications

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

  • 如果非静态内部类的方法中,有生命周期大于其所在类的,那就有问题了。比如:AsyncTask、Handler,这两个类都是方便开发者执行异步任务的,但是,这两个都跳出了Activity/Fragment的生命周期。
  • 为什么?因为非静态内部类会自动持有一个所属类的实例,如果所属类的实例已经结束生命周期,但内部类的方法仍在执行,就会hold其主体。也就使主体不能被释放,亦即内存泄露。
  • 静态类呢?静态类编译后和非内部类是一样的,有自己独立的类名。不会悄悄引用所属类的实例,所以就不容易泄露。
//首先,静态类
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);
         }
    }
}

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介入。
    • 转自:http://m.oschina.net/blog/128309

时间: 2024-10-10 16:52:30

Android:内存控制及OOM处理的相关文章

Android内存优化之OOM

内容大多都是和OOM有关的实践总结概要.理解错误或是偏差的地方,还请多包涵指正,谢谢!本人Q:1524447071 (一)Android的内存管理机制 Google在Android的官网上有这样一篇文章,初步介绍了Android是如何管理应用的进程与内存分配:http://developer.android.com/training/articles/memory.html. Android系统的Dalvik虚拟机扮演了常规的内存垃圾自动回收的角色,Android系统没有为内存提供交换区,它使用

android内存泄露及OOM介绍

1.Android 进程管理&内存 Android主要应用在嵌入式设备当中,而嵌入式设备由于一些众所周知的条件限制,通常都不会有很高的配置,特别是内存是比较有限的.如果我们编写的代 码当中有太多的对内存使用不当的地方,难免会使得我们的设备运行缓慢,甚至是死机.为了能够使得Android应用程序安全且快速的运行,Android 的每个应用程序都会使用一个专有的Dalvik虚拟机实例来运行,它是由Zygote服务进程演变过来的,也就是说每个应用程序都是在属于自己的进程中运行的.一方面,如果程序在运行

Linux -- 内存控制之oom killer机制及代码分析

近期,线上一些内存占用比較敏感的应用.在訪问峰值的时候,偶尔会被kill掉,导致服务重新启动.发现是Linux的out-of-memory kiiler的机制触发的. http://linux-mm.org/OOM_Killer oom kiiler会在内存紧张的时候,会依次kill内存占用较高的进程,发送Signal 15(SIGTERM).并在/var/log/message中进行记录.里面会记录一些如pid,process name.cpu mask,trace等信息,通过监控能够发现类似

Android 内存溢出解决方案(OOM)

众所周知,每个Android应用程序在运行时都有一定的内存限制,限制大小一般为16MB或24MB(视平台而定).因此在开发应用时需要特别关注自身的内存使用量,而一般最耗内存量的资源,一般是图片.音频文件.视频文件等多媒体资源:由于Android系统对音频.视频等资源做了边解析便播放的处理,使用时并不会把整个文件加载到内存中,一般不会出现内存溢出(以下简称OOM)的错误,因此它们的内存消耗问题暂不在本文的讨论范围.本文重点讨论的是图片的内存消耗问题,如果你要开发的是一款图片浏览器应用,例如像And

Android内存溢出解决方案(OOM)

众所周知,每个Android应用程序在运行时都有一定的内存限制,限制大小一般为16MB或24MB(视平台而定).因此在开发应用时需要特别关注自身的内存使用量,而一般最耗内存量的资源,一般是图片.音频文件.视频文件等多媒体资源:由于Android系统对音频.视频等资源做了边解析便播放的处理,使用时并不会把整个文件加载到内存中,一般不会出现内存溢出(以下简称OOM)的错误,因此它们的内存消耗问题暂不在本文的讨论范围.本文重点讨论的是图片的内存消耗问题,如果你要开发的是一款图片浏览器应用,例如像And

最常见的Android内存优化方式及防止泄漏造成OOM总结篇

前言 内存优化目的就是让我们在开发中怎么有效的避免我们的应用出现内存泄漏的问题.内存泄漏大家都不陌生了,简单粗俗的讲,就是该被释放的对象没有释放,一直被某个或某些实例所持有却不再被使用导致 GC 不能回收.既然说到内存泄漏和优化,就不得不先简单了解一下内存分配策略,然后再举常见泄漏例子和解决方法,最后做一下总结,这样更直观全面了解Android内存方面处理. 内存分配 内存分配策略有三种,分别是静态.栈式和堆式.对应的的内存空间主要分别是静态存储区(也称方法区).栈区和堆区.如下: 静态存储区:

android内存优化大全_上

转载请注明本文出自大苞米的博客(http://blog.csdn.net/a396901990),谢谢支持! 写在最前: 本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT,加上把网上搜集的各种内存零散知识点进行汇总.挑选.简化后整理而成. 所以我将本文定义为一个工具类的文章,如果你在ANDROID开发中遇到关于内存问题,或者马上要参加面试,或者就是单纯的学习或复习一下内存相关知识,都欢迎阅读.(本文最后我会尽量列出所参考的文章). 内存简介: RAM(random acc

android内存优化大全_中

转载请注明本文出自大苞米的博客(http://blog.csdn.net/a396901990),谢谢支持! 写在最前: 本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT,加上把网上搜集的各种内存零散知识点进行汇总.挑选.简化后整理而成. 所以我将本文定义为一个工具类的文章,如果你在ANDROID开发中遇到关于内存问题,或者马上要参加面试,或者就是单纯的学习或复习一下内存相关知识,都欢迎阅读.(本文最后我会尽量列出所参考的文章). OOM: 内存泄露可以引发很多的问题:

ANDROID内存优化(大汇总——全)

转载请注明本文出自大苞米的博客(http://blog.csdn.net/a396901990),谢谢支持! 写在最前: 本文的思路主要借鉴了2014年AnDevCon开发者大会的一个演讲PPT,加上把网上搜集的各种内存零散知识点进行汇总.挑选.简化后整理而成. 所以我将本文定义为一个工具类的文章,如果你在ANDROID开发中遇到关于内存问题,或者马上要参加面试,或者就是单纯的学习或复习一下内存相关知识,都欢迎阅读.(本文最后我会尽量列出所参考的文章). OOM: 内存泄露可以引发很多的问题: