Android内存泄露 一篇文章就够了

2019年4月27日 261次阅读 来源: 移动开发

《Android内存泄露 一篇文章就够了》 #####本文整理了市面上现有的所有内存泄露文章，加上个人理解进行归纳总结

##描述 内存泄露简单说就是已经没有用的资源，但是由于被其他资源引用着无法被GC销毁。

##危害

内存泄露是内存溢出OOM的重要原因之一，会导致Crash

如果应用程序在消耗光了所有的可用堆空间(16M到48M），那么再试图在堆上分配新对象时就会引起OOM(Out Of Memory Error)异常，此时应用程序就会崩溃退出。

现在的手机内存越来越大，小的内存泄漏并不会有太大危害，但是我们是有梦想的程序员，我们想要做出精致的APP。

##检测工具

Leaks

傻瓜式的内存检测工具，但是非常好用

当然我们可以用AS Monitor+MAT来自己分析内存泄漏原因

##从根本上解释内存泄露原因 前文已经提到了GC Roots，内存泄露就是因为内存泄露简单说就是已经没有用的资源，但是由于最终被GC Roots引用着无法被GC销毁。

Google官方的两张图，方便理解，最终蓝色的资源就会被回收

《Android内存泄露 一篇文章就够了》

Gc 检测流程1

《Android内存泄露 一篇文章就够了》

Gc 检测流程2

###那么都有哪些资源是GC Roots呢？

  1. Class 由System Class Loader/Boot Class Loader加载的类，这些类不会被回收。注意是类不会被回收，实例还是会被回收的，但是不依赖实例的静态static变量是依赖类的，因此很多内存泄露都是因为被静态变量引用导致的。

  2. Thread 线程，激活状态的线程；

  3. Stack Local 栈中的对象。每个线程都会分配一个栈，栈中的局部变量或者参数都是GC root，因为它们的引用随时可能被用到；

  4. JNI Local JNI中的局部变量和参数引用的对象；可能在JNI中定义的，也可能在虚拟机中定义

  5. JNI Global JNI中的全局变量引用的对象；同上

  6. Monitor Used 用于保证同步的对象，例如wait()，notify()中使用的对象、锁等。

  7. Held by JVM JVM持有的对象。JVM为了特殊用途保留的对象，它与JVM的具体实现有关。比如有System Class Loader, 一些Exceptions对象，和一些其它的Class Loader。对于这些类，JVM也没有过多的信息。

也就是说所有的内存泄漏问题从根本上都是因为被这些GC Root引用着导致的

##常见问题

  1. 非静态内部类，匿名内部类（由于原因1）

  2. Thread（由于原因2）

  3. ContentObserver，File，Cursor，Stream，Bitmap等资源未关闭（由于原因3）

  4. Webview（由于原因3）

  5. BraodcastReceiver，EventBus等观察者注册未注销（由于原因1）

###解决原则

  1. 内部类静态化，内部类里面的资源及时关闭不要静态化

  2. 注意线程的及时关闭

  3. 注意资源的及时关闭

  4. webView单独开线程（下面有具体的例子）

  5. 同样需要及时关闭

##自己遇到实际的内存泄露问题

###一. 单例或一些静态资源导致内存泄漏（影响较小）

  1. InputMethodManager

《Android内存泄露 一篇文章就够了》

主要是Android OS遗留的问题

google官方确认问题

https://code.google.com/p/android/issues/detail?id=171190

因为InputMethodManager是单例，即使泄露也不会有有很大影响，建议忽略

当然也有解决方案 leaks上给的链接

https://gist.github.com/pyricau/4df64341cc978a7de414

亲测6.0没生效

http://www.jianshu.com/p/aa2555628b17亲测生效

  1. 单例Dialog（或则单例View）

一直保有Context引用，销毁不了

《Android内存泄露 一篇文章就够了》

解决方法就是不用单例了，让各个Activity new就可以了

###二. 注册监听广播等没有注销（影响较大）

1.RXBUS EventBus等注册监听之后没有注销，导致内存泄漏

一直保有Context引用，销毁不了

《Android内存泄露 一篇文章就够了》

解决方案就是页面销毁是注销监听

###三.WebView内存泄露（影响较大）

解决方案是用新的进程起含有WebView的Activity

并且在该Activity 的onDestory() 最后加上 System.exit(0); 杀死当前进程。

微信也是这么做的

下面是一些webView常见问题总结

http://www.cnblogs.com/olartan/p/5713013.html

###四.匿名内部类（影响较小）

《Android内存泄露 一篇文章就够了》

我们这个问题是没有应用到contex但是却引用到了

暂时没有好的解决方案，主要是内部类需要提供一些注销等方法

##怎样避免内存泄露

  1. 使用静态变量的时候要小心，尤其要注意Activity/Service等大对象的传值。在单例模式中能用ApplicationContext的都用ApplicationContext，或者把聚合关系改成依赖关系，不在单例对象中持有Context引用；

  2. 养成良好的代码习惯。注册/反注册要成对出现，Activity和Service对象中避免使用非静态内部类/匿名内部类，除非十分清楚引用关系；

  3. 使用多线程的时候留意线程存活时间。尽量将聚合关系改成依赖关系，减少线程对象持有大对象的时间；

  4. 在使用xxxStream,SqlLiteDatabase,Cursor类的时候要注意释放资源。使用Timer,TimerTask的时候要记得取消任务。Bitmap在使用结束后要记得recycler()。

######官方推荐：

In summary, to avoid context-related memory leaks, remember the following:

1.Do not keep long-lived references to a context-activity (a reference to 
an activity should have the same life cycle as the activity itself)

2.Try using the context-application instead of a context-activity

3.Avoid non-static inner classes in an activity if you don’t control their life cycle,
 use a static inner class and make a weak reference to the activity inside

And remember that a garbage collector is not an insurance against memory leaks. 
Last but not least, we try to make such leaks harder to make happen whenever we can.

###欢迎大家关注我的简书

    原文作者：移动开发
    原文地址: https://my.oschina.net/HappySea/blog/826475
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞