Android内存泄漏、内存溢出、ANR【总结】

内存泄漏 Memory Leak

对象在内存heap堆中中分配的空间,进程中某些对象已经没有使用价值了,但还是可以直接/间接的引用到GcRoot,导致无法回收,总结一句话就是:本该回收的对象不能被回收而停留在堆内存中,从而产生了内存泄漏。

内存溢出 Out Of Memory

内存溢出是指APP向系统申请超过最大阀值的内存请求,系统不会再分配多余的空间,从而造成内存溢出。总结起来就是,当应用的heap资源超过了Dalvik虚拟机分配的内存就会内存溢出。

关于Android APP的所能申请的最大内存大小是多少, google原生OS的默认值是16M,但是各个厂家的OS会对这个值进行修改。由于Android是开源系统, 不同的手机厂商其实是拥有修改这部分权限能力的,所以就造成了不同品牌和不同系统的手机,对于APP的内存支持也是不一样的,和IOS的恒久100MB是 不同的。一般来说,手机内存的配置越高,厂商也会调大手机支持的内存最大阀值,Oppo find7实测最大内存分配为192MB;小米也有100MB。我们自己可以通过Runtime rt=Runtime.getRuntime();long maxMemory=rt.maxMemory();测试看看不同机型的内存限制。

ANR Application Not Responding

应用无响应

———————分割线

(接下来具体分析这三个的产生原因、典型场景、解决或避免的方法)

【Android内存泄漏出现的典型场景】

1.单例–生命周期

分析:因为单例的生命周期和应用程序一样,如果单例对象持有了某个不再需要的对象的引用,(比如Activity的context),那么这个Activty在单例没有被释放前将不会被释放。

解决:我们可以让单例的引用为Application的context

2.Handler

我们经常会在activity中这样使用handler:

class MyHandler extends Handler{
...
}
//使用
MyHandler mHandler=new MyHandler(this);

分析:由于myHandler是Handler的非静态匿名内部类的实例,所以它持有外部类Activity的引用,Looper线程不断轮询处理消息,Activity退出时如果消息队列里还有未处理的消息,消息队列的Message持有mHandler的引用,mHandler又持有Activity的引用,所以导致Activity无法及时被GC回收。从而造成内存泄漏

解决方法:
  • 1.创建静态Handler的匿名内部类 static class MyHandler extends Handler
  • 2.把对Handler持有的对象的使用弱引用 WeakReference context;
  • 3.在Activity销毁时移除消息队列中的任务或消息 handler.removeCallbacksAndMessages(null);取消所有的消息的处理

3.非静态内部类创建静态实例

分析:非静态内部类可以自由使用外部类的所有变量和方法,非静态内部类,它默认持有外部类的引用,此时如果在外部类创建静态static的内部类的实例,或是声明为static静态成员变量,这样就导致内部类的生命周期和应用程序一样长,导致Activity无法正常销毁。

解决方法:将非静态内部类转为静态内部类,这样就不会隐式持有外部类。

4.线程造成的内存泄漏

分析:我们常用的异步任务(如:AsyncTask)和Runnable都是匿名内部类,所以它们对当前的Activity都有一个隐式引用,若Activity销毁,但是线程的任务还没有完成,就会造成Activity的gc无法回收。

解决方法:
  • 1.使用静态内部类 将Runnable内部类、AsyncTask内部类声明为静态。
  • 2.销毁时取消相应的任务。

5.资源未关闭

BroadcastReceiver、File、Cursor、Stream、Bitmap 及时关闭和注销、否则不会被回收造成内存泄漏。

6.系统服务、监听器未注销/移除

有一些系统服务或监听器在不需要使用的时候再及时移除或注销

7.动画

对于有一些属性动画,属性为无限循环,这时候我们可以在onStop中停止动画。

【什么导致内存溢出OOM】

1.对象内存过大(图片、Bitmap、XML)造成内存超出

2.布局重复加载(比如列表控件adapter中没有复用view等)、界面横竖屏切换。应用资源过多,来不及加载。

3.还有我们上面介绍的内存泄漏,过多的内存泄漏,也会导致虚拟机可分配的内存越来越少,这样也是容易出现OOM。

关于避免OOM:

A:减少OOM最重要的就是要尽量减少新分配出来的对象占用内存的大小,尽量使用更加轻量的对象。
  • 避免内存泄漏,见上面我们总结的一些情况(比如:善用static、避免无关引用无法释放、善用SoftReference/WeakReference/LruCache、谨慎handler、线程等、及时关闭无用服务、监听。)
  • 如果代码中有大量字符串拼接操作,使用StringBuilder代替”+”。
  • Bitmap的不当处理极可能造成OOM,其实很多OOM的原因都来源于此,所以一定要十分重视对Bitmap的优化。
B:一直说OOM的出现是因为应用占用的内存(主要是指的heap)超出了系统给我们分配内存的最大值,那有没有可能增加系统为我们的App分配的内存大小。—>使用largeHeap,会请求系统为Dalvik虚拟机分配更大的内存空间。使用起来也很方便,只需在manifest文件application节点加入android:largeHeap=“true”即可。作为验证,可以通过打印两者的值。ActivityManager.getMemoryClass()获得应用正常情况下内存的大小,ActivityManager.getLargeMemoryClass()可以获得使用largeHeap最大的内存大小。

慎用largeHeap:天下没有免费的午餐,当内存很大的时候,对GC的时间也会有一些影响,性能相比下降,对于本身对内存要求过大的图片或者视频应用,我们可以使用largeHeap。除上面的情况,如果仅仅是为了解OOM这样的问题,而尝试使用largeHeap分配更大内存的这种指标不治本的方法不可取。作为程序员的我们应该努力减少内存的使用,避免内存泄漏,多优化,考虑各种回收和复用,而不是想方设法的增大内存。

【关于ANR】

备注:只有在主线程才会产生ANR,ANR的直观体验是用户在操作App的过程中,感觉界面卡顿,出现ANR对话框。

ANR的产生原因主要为以下三点:

  • 1.主线程View的点击事件或者触摸事件在特定的时间(5s)内无法得到响应。
  • 2.BroadcastReceiver的onReceive()函数运行在主线程中,在特定的时间(10s)内无法完成处理。
  • 3.Service的各个生命周期函数在特定时间(20s)内无法完成处理。

典型的ANR问题场景

  • 应用程序UI线程存在耗时操作。例如在UI线程中进行联网请求,数据库操作或者文件操作等。
  • 应用程序的UI线程等待子线程释放某个锁,导致UI线程等待超时,从而无法处理用户的输入。
  • 耗时的动画需要大量的计算工作,可能导致CPU负载过重。

ANR的避免

  • 主线程避免耗时操作(网络或数据库操作,或者高耗时的计算如改变位图尺寸)把耗时操作放在子线程
  • 主线程不能阻塞,等待子线程的完成——也不是调用 Thread.wait()或是Thread.sleep()。替代的方法是,主线程应该为子线程提供一个Handler,以便完成时能够提交给主线程。
  • 应用程序应该避免在BroadcastReceiver里做耗时的操作或计算。如果响应Intent广播需要执行一个耗时的动作的话,应用程序应该启动一个 Service。
  • 如果你的应用程序在响应Intent广 播时需要向用户展示什么,你应该使用Notification Manager来实现。

【最后】

欢迎大家补充开发中遇见的内存泄漏、内存溢出、ANR的问题场景。
❤️❤️然后给个小心心鼓励一下吧❤️❤️

    原文作者:芒果味的你呀
    原文地址: https://www.jianshu.com/p/e509fb90b0e1
    本文转自网络文章,转载此文章仅为分享知识,如有侵权,请联系博主进行删除。
点赞