Heads up：
本文主要记录本人开发中所遇到内存泄漏情况，然后介绍相关内存泄漏的检测方法，并搜集了一些大神的理论分析，从而由浅到深、实际结合理论，尽可能减少内存泄漏的出现，并提醒大家和我自己写代码时多注意内存泄漏的情况。
遇到过泄漏的场景:
==小注：我是用LeakCanary来检测的，下面会介绍 ==
1. Volley网络请求中的泄漏
代码如下:
public class ScrollingActivity extends AppCompatActivity {
private String mUrl = "http://www.jianshu.com/users/dd2b86a1f116/latest_articles";
@Override
protected void onCreate(Bundle savedInstanceState) {
super.onCreate(savedInstanceState);
setContentView(R.layout.activity_scrolling);
// do a volley request
RequestQueue queue = Volley.newRequestQueue(this);
// 内部类Listener的对象持有外部类实例的引用
StringRequest request = new StringRequest(Request.Method.GET, mUrl, new Response.Listener() {
@Override
public void onResponse(String response) {
Log.i("Log", "onResponse: " + response);
}
}, new Response.ErrorListener() {
@Override
public void onErrorResponse(VolleyError error) {
}
});
queue.add(request);
}
}
检测到泄漏，如图：
volley_leak by keith
原因分析:
a. 在Activity或Fragment中进行网络请求，在宿主生命周期结束时未对相应的request进行cancel，由于volley中的listener对象仍然持有宿主一些属性的引用，使得GC不会回收，从而导致leak
b. 在官方的volley包中，NetworkDispatcher中的run方法中，当请求队列里面无请求时，本地request仍然持有最后一个请求的引用，使得GC不会回收，导致leak
//NetworkDispatcher
public void run() {
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
while (true) {
long startTimeMs = SystemClock.elapsedRealtime();
Request request;
try {
// Take a request from the queue
request = mQueue.take(); //PriorityBlockingQueue
} catch (InterruptedException e) {
// We may have been interrupted because it was time to quit.
if (mQuit) {
return;
}
continue;
}
...
------------------------------------
// PriorityBlockingQueue
public E take() throws InterruptedException {
final ReentrantLock lock = this.lock;
lock.lockInterruptibly();
E result;
try {
//这是关键，当request==null的时候，当前线程处于等待状态，
//也就造成了NetworkDispatcher的run方法中的局部request变量一直
//带有最后一个request的引用，直到有新的请求进来或者线程被打断
while ( (result = dequeue()) == null)
notEmpty.await();
} finally {
lock.unlock();
}
return result;
}
解决方案:
a. 及时调用volley quene的cancel方法
b. 使用改良版的volley包,如mcxiaoke
public void run() {
Process.setThreadPriority(Process.THREAD_PRIORITY_BACKGROUND);
Request request;
while (true) {
long startTimeMs = SystemClock.elapsedRealtime();
// release previous request object to avoid leaking request object when mQueue is drained.
// 这个就是关键的制空
request = null;
try {
// Take a request from the queue.
request = mQueue.take();
} catch (InterruptedException e) {
// We may have been interrupted because it was time to quit.
if (mQuit) {
return;
}
continue;
}
2. 单例Dialog导致的泄露
这个是我自己写的一个ProgressDialog工具类，主要用在网络请求时的等待显示，我觉得挺好用，直到检查内存泄漏，真是too naive了，代码如下：
public class ProgressUtils {
public static ProgressDialog progressDialog = null;
public static void dismissProgressDialog() {
if (null != progressDialog && progressDialog.isShowing()) {
progressDialog.dismiss();
}
}
public static void showProgressDialog(Context context, String message) {
if (null != progressDialog && progressDialog.isShowing()) {
return;
}
if (progressDialog == null || progressDialog.getContext() != context) {
progressDialog = new ProgressDialog(context);
}
progressDialog.setMessage(message);
progressDialog.show();
}
}
检测到泄漏，如图
progress_dialog_singleton_leak by keith
原因分析:
由于在Activity生命周期结束之后，单例Dialog内部的变量mContext中的mBase仍然持有该Activity对像的引用，虽然下次其他Activity来调用Dialog时上个Activity对象的引用会被踢掉，但是还是会有一个Activity对象的泄漏，简单的代码分析如下:
// 1. ProgressUtils
progressDialog = new ProgressDialog(context);
// 2. 一路点击构造方法下去，会到Dialog的这个方法中(createContextThemeWrapper为true)
Dialog(@NonNull Context context, @StyleRes int themeResId, boolean createContextThemeWrapper) {
if (createContextThemeWrapper) {
if (themeResId == 0) {
final TypedValue outValue = new TypedValue();
context.getTheme().resolveAttribute(R.attr.dialogTheme, outValue, true);
themeResId = outValue.resourceId;
}
// 走这一步
mContext = new ContextThemeWrapper(context, themeResId);
} else {
mContext = context;
}
···
}
// 3. 接着是mContext指向的对象的创建,会走到ContextWrapper中
public class ContextWrapper extends Context {
//就是这个拿着Activity的引用
Context mBase;
public ContextWrapper(Context base) {
mBase = base;
}
···
解决方案：
由于Dialog比较特别(如下图)，只能用Activity才能启动(当然有一些用其他context也可以，但是要申请权限什么的，不适用于一般app)，所以不要这种单例ProgressDialog工具类,在Activity或Fragment的生命中控制dialog的show和dismiss;
注: 图片来自reference-2
3. 单例Toast导致的泄露(同单例dialog)
使用全局ApplicaitonContext
4. 百度地图LocationClient定位服务内存泄漏
使用全局ApplicaitonContext
5. Handler内存泄漏
原因就不说，也是内部引用的没有跟引用对象的生命周期同步，具体可以看reference中大神分析；
解决方案:
- 用静态Handler和WeakReference,例如:
//子类继承这个类，然后正常用就好了
public abstract class WeakReferenceHandler extends Handler {
private WeakReference mReference;
public WeakReferenceHandler(T reference) {
mReference = new WeakReference(reference);
}
@Override
public void handleMessage(Message msg) {
if (mReference.get() == null) {
return;
}
handleMessage(mReference.get(), msg);
}
protected abstract void handleMessage(T reference, Message msg);
}
- 在引用对象生命周期结束时，调用Handler的removeCallbacksAndMessages()或removeCallbacks()或removeMessages();
5. Thread造成的内存泄漏
也是一样，注意引用对象的生命周期
Toooooooooools
- MAT(有点麻烦，无爱，就不说了)
- LeakCanary
下面说下LeakCanary的简单使用，真的很简单
使用方法
- 在build.gradle中加依赖
dependencies {
debugCompile 'com.squareup.leakcanary:leakcanary-android:1.4-beta2'
// release 中的版本里面就9个空方法,放心大胆的去用吧，用proguard这些就会被剥掉为0，更不用担心了
releaseCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2'
testCompile 'com.squareup.leakcanary:leakcanary-android-no-op:1.4-beta2'
}
- 在Application中添加如下代码,别忘了在AndroidManifest.xml中使用
public class ExampleApplication extends Application {
public static RefWatcher getRefWatcher(Context context) {
ExampleApplication application = (ExampleApplication) context.getApplicationContext();
return application.refWatcher;
}
private RefWatcher refWatcher;
@Override public void onCreate() {
super.onCreate();
refWatcher = LeakCanary.install(this);
}
}
- 在需要监控的地方加如下代码(以Fragment为例)
public abstract class BaseFragment extends Fragment {
@Override public void onDestroy() {
super.onDestroy();
RefWatcher refWatcher = ExampleApplication.getRefWatcher(getActivity());
refWatcher.watch(this);
}
}
总之，注意引用对象的生命周期，注意引用对象的生命周期，注意引用对象的生命周期这个是重点。
经验总结----来自Bugly
- 对 Activity 等组件的引用应该控制在 Activity 的生命周期之内;如果不能就考虑使用 getApplicationContext 或者 getApplication，以避免 Activity 被外部长生命周期的对象引用而泄露。
- 在代码复审的时候关注长生命周期对象：全局性的集合、单例模式的使用、类的 static 变量等等。
- 尽量不要在静态变量或者静态内部类中使用非静态外部成员变量（包括context )，即使要使用，也要考虑适时把外部成员变量置空；也可以在内部类中使用弱引用来引用外部类的变量。
- Handler 的持有的引用对象最好使用弱引用，资源释放时也可以清空 Handler 里面的消息。比如在 Activity onStop 或者 onDestroy 的时候，取消掉该 Handler 对象的 Message和 Runnable,removeCallbacks(Runnable r) 或removeMessages(int what)，或 removeCallbacksAndMessages（null）等。
- 线程 Runnable 执行耗时操作，注意在页面返回时及时取消或者把 Runnable 写成静态类。
a) 如果线程类是内部类，改为静态内部类。
b) 线程内如果需要引用外部类对象如 context，需要使用弱引用。 - 在 Java 的实现过程中，也要考虑其对象释放，最好的方法是在不使用某对象时，显式地将此对象赋空，如清空对图片等资源有直接引用或者间接引用的数组（使用 array.clear() ; array = null），最好遵循谁创建谁释放的原则。
Reference
- Android 内存泄漏总结
- Android性能优化之常见的内存泄漏
- 内存泄露从入门到精通三部曲之基础知识篇
- 内存泄露从入门到精通三部曲之排查方法篇
- 内存泄露从入门到精通三部曲之常见原因与用户实践