详解Android内存泄露及优化方案
一、常见的内存泄露应用场景？
1、单例的不恰当使用
单例是我们开发中最常见和使用最频繁的设计模式之一，所以如果使用不当就会导致内存泄露。因为单例的静态特性使得它的生命周期同应用的生命周期一样长，如果一个对象已经没有用处了，但是单例还持有它的引用，那么在整个应用程序的生命周期这个对象都不能正常被回收，从而导致内存泄露。
如：
public class app {
private static app sinstance;
private context mcontext;
private app(context context) {
this.mcontext = context;
}
public static app getinstance(context context) {
if (sinstance == null) {
sinstance = new app(context);
}
return sinstance;
}
}
调用getinstance(context context)方法时传入的上下文如果为当前活动activity或者当前服务的service以及当前fragment的上下文，当他们销毁时，这个静态单例sintance还会持用他们的引用，从而导致当前活动、服务、fragment等对象不能被回收释放，从而导致内存泄漏。这种上下文的使用很多时候处理不当就会导致内存泄漏，需要我们多注意编码规范。
2、静态变量导致内存泄露
静态变量存储在方法区，它的生命周期从类加载开始，到整个进程结束。一旦静态变量初始化后， 它所持有的引用只有等到进程结束才会释放。
如下代码：
public class mainactivity extends appcompatactivity {
private static info sinfo;
@override
protected void oncreate(bundle savedinstancestate) {
super.oncreate(savedinstancestate);
setcontentview(r.layout.activity_main);
if (sinfo != null) {
sinfo = new info(this);
}
}
}
class info {
public info(activity activity) {
}
}
info 作为 activity 的静态成员，并且持有 activity 的引用，但是 sinfo 作为静态变量，生命周期 肯定比 activity 长。所以当 activity 退出后，sinfo 仍然引用了 activity，activity 不能被回收， 这就导致了内存泄露。 在 android 开发中，静态持有很多时候都有可能因为其使用的生命周期不一致而导致内存泄露， 所以我们在新建静态持有的变量的时候需要多考虑一下各个成员之间的引用关系，并且尽量少地 使用静态持有的变量，以避免发生内存泄露。当然，我们也可以在适当的时候讲静态量重置为 null， 使其不再持有引用，这样也可以避免内存泄露。
3、非静态内部类导致内存泄露
非静态内部类（包括匿名内部类）默认就会持有外部类的引用，当非静态内部类对象的生命周期 比外部类对象的生命周期长时，就会导致内存泄露。这类内存泄漏很典型的handler的使用，这么一说大家应该就很熟悉了吧，大家都知道怎么处理这类内存泄漏。
handler的使用示例：
private void start() {
message msg = message.obtain();
msg.what = 1;
mhandler.sendmessage(msg);
}
private handler mhandler = new handler() {
@override
public void handlemessage(message msg) {
if (msg.what == 1) {
// ui更新
}
}
};
handler 消息机制，mhandler 会作为成员变量保存在发送的消息 msg 中，即 msg 持有 mhandler 的引用，而 mhandler 是 activity 的非静态内部类实例，即 mhandler 持有 activity 的引 用，那么我们就可以理解为 msg 间接持有 activity 的引用。msg 被发送后先放到消息队列 messagequeue 中，然后等待 looper 的轮询处理（messagequeue 和 looper 都是与线程相关联的， messagequeue 是 looper 引用的成员变量，而 looper 是保存在 threadlocal 中的）。那么当 activity 退出后，msg 可能仍然存在于消息对列 messagequeue 中未处理或者正在处理，那么这样就会导致 activity 无法被回收，以致发生 activity 的内存泄露。
如何避免：
1、采用静态内部类+弱引用的方式
private static class myhandler extends handler {
private weakreference<mainactivity> activityweakreference;
public myhandler(mainactivity activity) {
activityweakreference = new weakreference<>(activity);
}
@override
public void handlemessage(message msg) {
mainactivity activity = activityweakreference.get();
if (activity != null) {
if (msg.what == 1) {
// 做相应逻辑
}
}
}
}
mhandler 通过弱引用的方式持有 activity，当 gc 执行垃圾回收时，遇到 activity 就会回收并释 放所占据的内存单元。这样就不会发生内存泄露了。但是 msg 还是有可能存在消息队列 messagequeue 中。
2、activity 销毁时就将 mhandler 的回调和发送的消息给移除掉。
@override
protected void ondestroy() {
super.ondestroy();
mhandler.removecallbacksandmessages(null);
}
非静态内部类造成内存泄露还有一种情况就是使用 thread 或者 asynctask异步调用：
如示例：
thread ：
public class mainactivity extends appcompatactivity {
@override
protected void oncreate(bundle savedinstancestate) {
super.oncreate(savedinstancestate);
setcontentview(r.layout.activity_main);
new thread(new runnable() {
@override
public void run() {
try {
thread.sleep(2000);
} catch (interruptedexception e) {
e.printstacktrace();
}
}
}).start();
}
asynctask：
public class mainactivity extends appcompatactivity {
@override
protected void oncreate(bundle savedinstancestate) {
super.oncreate(savedinstancestate);
setcontentview(r.layout.activity_main);
new asynctask<void, void, void>() {
@override
protected void doinbackground(void... params) {
// ui线程处理
try {
thread.sleep(2000);
} catch (interruptedexception e) {
e.printstacktrace();
}
return null;
}
}.execute();
}
}
以上新建的子线程 thread 和 asynctask 都是匿名内部类对象，默认就隐式的持有外部 activity 的引用， 导致 activity 内存泄露。要避免内存泄露的话还是需要像上面 handler 一样使用采用静态内部类+弱引用的方式（如上面hanlder采用静态内部类+弱引用的方式）。
4、未取消注册或回调导致内存泄露
比如我们在 activity 中注册广播，如果在 activity 销毁后不取消注册，那么这个刚播会一直存在 系统中，同上面所说的非静态内部类一样持有 activity 引用，导致内存泄露。因此注册广播后在 activity 销毁后一定要取消注册。
this.unregisterreceiver(mreceiver);
在注册观察则模式的时候，如果不及时取消也会造成内存泄露。比如使用 retrofit+rxjava 注册网络请求的观察者回调，同样作为匿名内部类持有外部引用，所以需要记得在不用或者销毁的时候 取消注册。
5、定时器timer 和 timertask 导致内存泄露
当我们 activity 销毁的时，有可能 timer 还在继续等待执行 timertask，它持有 activity 的引用不 能被回收，因此当我们 activity 销毁的时候要立即 cancel 掉 timer 和 timertask，以避免发生内存 泄漏。
6、集合中的对象未清理造成内存泄露
这个比较好理解，如果一个对象放入到 arraylist、hashmap 等集合中，这个集合就会持有该对象 的引用。当我们不再需要这个对象时，也并没有将它从集合中移除，这样只要集合还在使用（而 此对象已经无用了），这个对象就造成了内存泄露。并且如果集合被静态引用的话，集合里面那 些没有用的对象更会造成内存泄露了。所以在使用集合时要及时将不用的对象从集合 remove，或 者 clear 集合，以避免内存泄漏。
7、资源未关闭或释放导致内存泄露
在使用 io、file 流或者 sqlite、cursor 等资源时要及时关闭。这些资源在进行读写操作时通常都 使用了缓冲，如果及时不关闭，这些缓冲对象就会一直被占用而得不到释放，以致发生内存泄露。 因此我们在不需要使用它们的时候就及时关闭，以便缓冲能及时得到释放，从而避免内存泄露。
8、动画造成内存泄露
动画同样是一个耗时任务，比如在 activity 中启动了属性动画（objectanimator），但是在销毁 的时候，没有调用 cancle 方法，虽然我们看不到动画了，但是这个动画依然会不断地播放下去， 动画引用所在的控件，所在的控件引用 activity，这就造成 activity 无法正常释放。因此同样要 在 activity 销毁的时候 cancel 掉属性动画，避免发生内存泄漏。
@override
protected void ondestroy() {
super.ondestroy();
manimator.cancel();
}
9、webview 造成内存泄露
关于 webview 的内存泄露，因为 webview在加载网页后会长期占用内存而不能被释放，因此我 们在 activity 销毁后要调用它的 destory()方法来销毁它以释放内存。
另外在查阅 webview 内存泄露相关资料时看到这种情况： webview 下面的 callback 持有 activity 引用，造成 webview 内存无法释放，即使是调用了 webview.destory()等方法都无法解决问题（android5.1 之后）
最终的解决方案是：在销毁 webview 之前需要先将 webview 从父容器中移除，然后在销毁 webview。
@override
protected void ondestroy() {
super.ondestroy();
// 先从父控件中移除
webview mwebviewcontainer.removeview(mwebview);
mwebview.stoploading();
mwebview.getsettings().setjavascriptenabled(false);
mwebview.clearhistory();
mwebview.removeallviews();
mwebview.destroy();
}
总结
构造单例的时候尽量别用 activity 的引用；
静态引用时注意应用对象的置空或者少用静态引用；
使用静态内部类+软引用代替非静态内部类；
及时取消广播或者观察者注册；
耗时任务、属性动画在 activity 销毁时记得 cancel；
文件流、cursor 等资源及时关闭； activity 销毁时 webview 的移除和销毁。
下一篇继续：详解android内存优化策略
ps：内存泄漏是开发中的一个痛点，需要我们有很好的良好编码习惯。奥里给！！！！！！！！！
到此这篇关于详解android内存泄露及优化方案一的文章就介绍到这了,更多相关android内存优化内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！