前言
内存泄漏其实是用户无感的，可能一次或几次的泄漏危害可以忽略，但内存泄漏堆积后，会影响app的性能，严重可能会导致oom，内存溢出。
小伙伴们在实际开发中，要防止内存泄漏的产生。大家可以通过内存检测工具，来查看你的项目是否有内存泄漏的产生。
防止内存泄漏的方法有许多，这里只列举了handler与Asyntask防止内存的产生，因为比较实用，未了解的小伙伴可以收藏一下。
一、举个栗子
这是某内存检测工具，是handler引起的内存泄漏错误信息
In com.ophone.reader.ui:6.8.3:118.
* com.cmread.bplusc.reader.ui.share.ShareToFXActivity has leaked:
* GC ROOT static com.cmread.bplusc.httpservice.http.HttpMessageQueue.mSelf
* references com.cmread.bplusc.httpservice.http.HttpMessageQueue.mCallback
* references com.cmread.bplusc.httpservice.http.HttpQueueCallback.mICallBack
* references com.cmread.bplusc.presenter.AbsPresenter$1.this$0 (anonymous class implements com.cmread.bplusc.httpservice.aidl.ICallBack)
* references com.cmread.bplusc.presenter.GetShareLinkPresenter.mUIHandler
* references com.cmread.bplusc.reader.ui.share.ShareToFXActivity$1.this$0 (anonymous class extends android.os.Handler)
* leaks com.cmread.bplusc.reader.ui.share.ShareToFXActivity instance
从上述日志中可以得出，ShareToFxActivity有泄漏的产生，这里的mSelf指的就是ShareToFxActivity，因为在其他地方有mSelf的引用，从而导致改Activity在finish的时候无法被GC回收。在mCallback是通过handler做的异步回调，在回调时，finish当前activity，但是mSelf还在指向其他引用。
其实光从app的功能实现上，并不会产生感官上的差异，但是上面也说了，内存泄漏堆积后，会影响你的app性能，严重造成oom。所以在实际开发中，一定要防止此错误的产生。
二、解决方案
简单来说，用户在退出当前界面，即销毁当前activity时，如果此时handler对象有message在排队，无法释放，就会导致activity无法正常销毁，从而造成内存泄漏。
解决方案很简单：在onDestroy()生命周期中，将handler所有的消息全都移除，可以有效解决由handler引起的内存泄漏。
- 可以查看谷歌的官方api
public final void removeCallbacksAndMessages([Object] token)
Added in [API level 1]
Remove any pending posts of callbacks and sent messages whose obj is token. Iftoken
is null, all callbacks and messages will be removed.
意思是当传入的参数为null时，则会移除所有的callbacks和message，这样就有效避免了Handler引起的内存泄漏。
具体代码
@Override
protected void onDestroy() {
if(mHandler != null){
mHandler.removeCallbacksAndMessages(null);
}
//do something
super.onDestroy();
}
三、AsynTask引起的内存泄漏
其实AsynTask引起的原因与handler类似，在activity结束的时候就结束了任务。但是相对于其他情况（比如说操作网络的时候），doInBackground方法里面还是会继续执行，并且执行完之后还会继续onPostExecute方法，此时如果用户网络较慢，还在进行网络请求中，用户没耐心了，不想等，退出当前activity，那么必定会因为AsynTask引起的内存泄漏，导致activity无法正常销毁。
- 解决方案
@Override
protected void onDestroy() {
if(mMyTask != null && mMyTask.isCancelled()){
//及时结束异步任务
mMyTask.cancel(true);
mMyTask = null;
}
//do something
super.onDestroy();
}
总结
虽然内存泄漏可能是无感知的，但是长期如此危害是相当的。解决内存泄漏要从细节做起，一定要受到开发者的足够重视。
解决内存泄漏有许多入手，这里举的两个例子是非常使用，解决方案也非常简单。但是非常让人忽略，如果没有工具，可能还无法知道这种现象产生，所以未了解的童鞋，可以正好涨涨姿势……
