背景
Java是垃圾回收语言的一种,其优点是开发者无需特意管理内存分配,降低了应用由于局部故障导致崩溃,同时防止未释放的内存把堆栈(heap)挤爆的可能,所以写出来的代码更为安全。
不幸的是,在Java中仍存在很多容易导致内存泄漏的逻辑可能。如果不小心,你的Android应用很容易浪费掉未释放的内存,轻则应用卡顿,重则导致内存用光抛出OOM。
泄露场景
- 临时性内存泄漏
1.context引用
context引用 况会持有外部类的引用,一旦执行耗时操作,会造成内存回收不及时,从而造成OOM。典型例子就是Handler,当Handler声明为非静态内部类时会持有外部类(例如Activity)的引用。
2.非静态内部类
这种情况会持有外部类的引用,一旦执行耗时操作,会造成内存回收不及时,从而造成OOM。典型例子就是Handler,当Handler声明为非静态内部类时会持有外部类(例如Activity)的引用。
3.匿名类
相似地,匿名类也维护了外部类的引用。所以内存泄漏很容易发生,当你在Activity中定义了匿名的AsyncTsk。当异步任务在后台执行耗时任务期间,Activity不幸被销毁了,这个被AsyncTask持有的Activity实例就不会被垃圾回收器回收,直到异步任务结束。
4.监听器
App开发中我们都需要和监听器打交道,通常一个应用当中会用到很多监听器,我们会调用一个控件的诸如addXXXListener()等方法来增加监听器,但往往在释放对象的时候却没有记住去删除这些监听器,一旦监听器里执行了耗时操作,对象就无法回收,从而增加了内存泄漏的机会。
5.资源对象未关闭
资源性对象比如(Cursor游标,Stream流,BroadCastReceiver等)往往都用了一些缓冲,我们在不使用的时候或者在使用完之后,应该及时关闭它们比如close()方法,以便它们的缓冲及时回收内存。Bitmap要先recyler(),在置为null。
6.不要在执行频率高的方法中创建对象
在自定义View中onDraw和onMesaure这两个方法一般执行频率很高,一旦使用不当,会创建大量对象,频繁GC,会导致应用变卡顿。
7.WebView造成的泄露
当我们不要使用WebView对象时,应该调用它的destory()函数来销毁它,并释放其占用的内存,否则其占用的内存长期也不能被回收,从而造成内存泄露。
8.构造Adapter时,没有使用缓存的ConvertView
ListView在加载布局时如果不使用缓存的ConvertView,而是每次重新加载,就容易造成内存泄漏,应用卡顿。
- 永久性内存泄漏
1.全局变量
全局变量的内存永远不会被回收,一般app中都会定义一个常量类来存放这些数据,但是能少用全局变量就少用,毕竟要一直占用内存,如果使用建议只存储一些基本数据类型,切记不要持有context,activity,fragment,view的引用。这种错误一般在单例模式中比较常见。
2.属性动画
从Android3.0开始,Google提供了属性动画,属性动画中有一类无限循环的动画,如果在Activity中播放此类动画并且在onDestroy()方法中没有停止该动画,那么动画会一直循环下去,尽管在界面上已经无法看不到动画了,但这个时候Activity的View会被动画持有,而View又持有Activity,最终Activity无法释放。
3.系统服务
当你使用系统服务的时候,可以注册监听器,会导致服务持有Context的引用,如果在Activity销毁的时候,没有注销掉监听器,就会导致内存泄漏。
解决方法
- 弱引用(耗时操作持有的context等引用可以用弱引用)
- 使用LeakCanary工具查找内存泄漏(该工具会会自动分析context是否引起内存泄漏)
- Android Studio自带分析工具Profiler(使用该工具可以实时查看内存使用状况)