Android 内存泄露的几中场景

Android 内存泄漏

java 存在一个垃圾回收机制，发生泄漏的原因就是应该被回收的垃圾没有被回收，这种情况就叫做内存泄漏

解决内存泄漏的方法的思路：让不易回收的内存可以在不需要继续使用单情况下被系统回收掉。

怎么做在能让某些内存可以被及时回收呢？这里就需要了解 java 的一个知识点，这就是引用类型。java 分 四 种引用类型，分别是：强引用，软引用，弱引用，虚引用。这从这四种引用点名称可以推测，系统对于不用类型引用有不同的回收机制。为方便对比列出下方的表格

合理点使用不同的引用类型，可以避免出现内存泄露的情况

在Android开发中，出现内存泄露我认为可以分为两大部分，一部分是 java 相关的，另一部分是 Android Api使用容易出现内存泄露

常见有以下场景

1. 单例模式

单例模式生成的静态对象因为生命周期和应用的进程一致，一般只有当应用退出或者运行的进程被结束，对象才能结束对象的生命周。例如当一个单例对象引用一个 activity 变量，即便 activity 可能已经退出了，但是因为单例对象还持有 activity ，所以系统不能回收这个 activity 造成了内存泄露

解决方案
使用弱应用，例如
private WeakReference wr = null;
wr = new WeakReference(myActivity);

2. 匿名内部类使用(Threads , TimerTasks)

非静态内部类，匿名类阅读，可以轻易访问外围类的变量，也就是说匿名内部类可以持有外部类的的变量，当外部类的变量可以被回收的时候，当时因为内部类持有外部类的引用，这样就造成了内存泄露。但是静态内部类就不会引用外部变量

解决方案
1.使用静态内部类
2.用弱引用就是引用到的变量
3.可以的话，在结束外部类时及时关闭匿名内部类(Thread)

3. context 的使用

Context 是 Android 开发中经常传递的变量，但是某些情况下本该被回收的 Context 却因为某些对象依然持有 Context 的引用，进而发生内存泄露

解决方案
1.使用 ApplicationContext 代替 Context ，因为 ApplicationContext 的生命周期和应用(进程)一样长。
2.对于 Context 变量慎用 Static 修饰，

4. handler 的使用

Handler 用于延时的一个作用，熟悉 Handler 机制的都应该清楚，我们会把一下需要的一些操作放在 Messagequeue 里面，等待 用户的 handler 对象按队列顺序发送消息。

会存在这样一个场景，当一个 Activity 需要销毁，但是 MessageQueue 还存在一些消息为处理，消息持有 Handler 引用，Handler 持有外部类的引用，这时 Activity 就无法正常回收了。这种情况和非静态内部类引起的原因差不多。

解决方案
1.把 Handler 实现做一个独立的类或者使用静态修饰
2.在 Handler 内部调用到 acivity 等外部变量是可以用弱引用修饰作为 activity 引用类型

5. Cursor Bitmap Stream 没及时释放

打开资源文件，会把文件缓存在内存和 jvm 虚拟机中，在使用结束后如果没有 close() 则会发生内存泄露。

解决方案
1.使用结束后及时调用 close()

6. 监听器的没及时注销(Sensor Manager)

Android 系统提供了一些服务，要获取这些服务的对象都要使用到 Context 这个变量 当一个 activity 关闭后，这些系统级别的服务都会继续持有 Context 引用

解决方案
1.在退出 Activity 后及时注销监听器
2.使用 ApplicationContext 代替 Context

7. listView 的 adpater 没使用 ConvertView 缓存

ListView 会缓存一部分 View ，没用使用 getview() 里面的参数 ConvertView

8. 静态集合对象没有清理

静态集合里数据多，生命周期与应用一样长，但是依然占据了一部分内存，不需要时没有进行清理的动作

解决方案
1.退出后 clear 掉集合里面的所有数据，然后赋值 null

9. webview 没有及时释放

webview 使用完毕后一样需要 destroy 掉，否者一直常驻内存

解决方案
因为 webView 耗费大量内存，可以为 WebView 分配一个独立的线程，也主线程做通讯。不需要时也要记得销毁掉。

10.监听器

使用监听者模式，我们会添加一些监听器，但是移除被监听对象时，往往忘记取消设置的监听器