Android 中内存泄漏的原因分析及解决方案
2017年11月13日 10:40:08阅读数：91 本篇来自 风魔龙郎 的投稿，分享了 Android 中常见的内存泄漏场景和解决方案，希望大家喜欢！
风魔龙郎 的博客地址：
http://www.jianshu.com/u/dda4c8a68009
Java 内存分配策略
Java 程序运行时的内存分配策略有三种,分别是静态分配,栈式分配,和堆式分配，对应的，三种存储策略使用的内存空间主要分别是静态存储区（也称方法区）、栈区和堆区。
- 静态存储区（方法区）：主要存放静态数据、全局 static 数据和常量。这块内存在程序编译时就已经分配好，并且在程序整个运行期间都存在。
- 栈区 ：当方法被执行时，方法体内的局部变量（其中包括基础数据类型、对象的引用）都在栈上创建，并在方法执行结束时这些局部变量所持有的内存将会自动被释放。因为栈内存分配运算内置于处理器的指令集中，效率很高，但是分配的内存容量有限。
- 堆区 ： 又称动态内存分配，通常就是指在程序运行时直接 new 出来的内存，也就是对象的实例。这部分内存在不使用时将会由 Java 垃圾回收器来负责回收。
* 栈与堆的区别*
在方法体内定义的（局部变量）一些基本类型的变量和对象的引用变量都是在方法的栈内存中分配的。当在一段方法块中定义一个变量时，Java 就会在栈中为该变量分配内存空间，当超过该变量的作用域后，该变量也就无效了，分配给它的内存空间也将被释放掉，该内存空间可以被重新使用。
堆内存用来存放所有由 new 创建的对象（包括该对象其中的所有成员变量）和数组。在堆中分配的内存，将由 Java 垃圾回收器来自动管理。在堆中产生了一个数组或者对象后，还可以在栈中定义一个特殊的变量，这个变量的取值等于数组或者对象在堆内存中的首地址，这个特殊的变量就是我们上面说的引用变量。我们可以通过这个引用变量来访问堆中的对象或者数组。
举个例子
public class Sample {
int s1 = 0;
Sample mSample1 = new Sample();
public void method() {
int s2 = 1;
Sample mSample2 = new Sample();
}
}
分析
Sample mSample3 = new Sample();
Sample 类的局部变量 s2 和引用变量 mSample2 都是存在于栈中，但 mSample2 指向的对象是存在于堆上的。 mSample3 指向的对象实体存放在堆上，包括这个对象的所有成员变量 s1 和 mSample1，而它自己存在于栈中。
总结
局部变量的基本数据类型和引用存储于栈中，引用的对象实体存储于堆中。—— 因为它们属于方法中的变量，生命周期随方法而结束。
成员变量全部存储与堆中（包括基本数据类型，引用和引用的对象实体） —— 因为它们属于类，类对象终究是要被 new 出来使用的。
Java 是如何管理内存
Java 的内存管理就是对象的分配和释放问题。在 Java 中，程序员需要通过关键字 new 为每个对象申请内存空间 (基本类型除外)，所有的对象都在堆 (Heap)中分配空间。另外，对象的释放是由 GC 决定和执行的。在 Java 中，内存的分配是由程序完成的，而内存的释放是由 GC 完成的，这种收支两条线的方法确实简化了程序员的工作。但同时，它也加重了JVM的工作。这也是 Java 程序运行速度较慢的原因之一。因为，GC 为了能够正确释放对象，GC 必须监控每一个对象的运行状态，包括对象的申请、引用、被引用、赋值等，GC 都需要进行监控。
监视对象状态是为了更加准确地、及时地释放对象，而释放对象的根本原则就是该对象不再被引用。
为了更好理解 GC 的工作原理，我们可以将对象考虑为有向图的顶点，将引用关系考虑为图的有向边，有向边从引用者指向被引对象。另外，每个线程对象可以作为一个图的起始顶点，例如大多程序从 main 进程开始执行，那么该图就是以 main 进程顶点开始的一棵根树。在这个有向图中，根顶点可达的对象都是有效对象，GC将不回收这些对象。如果某个对象 (连通子图)与这个根顶点不可达(注意，该图为有向图)，那么我们认为这个(这些)对象不再被引用，可以被 GC 回收。 以下，我们举一个例子说明如何用有向图表示内存管理。对于程序的每一个时刻，我们都有一个有向图表示JVM的内存分配情况。以下右图，就是左边程序运行到第6行的示意图。
什么是Java中的内存泄漏
在 Java 中，内存泄漏就是存在一些被分配的对象，这些对象有下面两个特点：首先，这些对象是可达的，即在有向图中，存在通路可以与其相连；其次，这些对象是无用的，即程序以后不会再使用这些对象。如果对象满足这两个条件，这些对象就可以判定为Java中的内存泄漏，这些对象不会被 GC 所回收，然而它却占用内存。
Android 中内存泄漏的原因
在 Android 中内存泄漏的原因其实和在 Java 中是一样的，即某个对象已经不需要再用了，但是它却没有被系统所回收，一直在内存中占用着空间，而导致它无法被回收的原因大多是由于它被一个生命周期更长的对象所引用。其实要分析 Android 中的内存泄漏的原因非常简单，只要理解一句话，那就是生命周期较长的对象持有生命周期较短的对象的引用。
举个例子，如果一个 Activity 被一个单例对象所引用，那么当退出这个 Activity 时，由于单例的对象依然存在（单例对象的生命周期跟整个 App 的生命周期一致），而单例对象又持有 Activity 的引用，这就导致了此 Activity 无法被回收，从而造成内存泄漏。
知道了内存泄漏的根本原因，再分析为什么会出现内存泄漏就很简单了，下面就针对一些常见的内存泄漏进行分析。
单例造成的内存泄漏
public class SingleTon { private static SingleTon singleTon; private Context context; private SingleTon(Context context) { this.context = context; } public static SingleTon getInstance(Context context) { if (singleTon == null) { synchronized (SingleTon.class) { if (singleTon == null) { singleTon = new SingleTon(context); } } } return singleTon; } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
这是单例模式饿汉式的双重校验锁的写法，这里的 singleTon 持有 Context 对象，如果 Activity 中调用 getInstance 方法并传入 this 时，singleTon 就持有了此 Activity 的引用，当退出 Activity 时，Activity 就无法回收，造成内存泄漏，所以应该修改它的构造方法：
private SingleTon(Context context) { this.context = context.getApplicationContext(); }
通过 getApplicationContext 来获取 Application 的 Context，让它被单例持有，这样退出 Activity 时，Activity 对象就能正常被回收了，而 Application 的 Context 的生命周期和单例的生命周期是一致的，所有再整个 App 运行过程中都不会造成内存泄漏。
非静态内部类造成的内存泄漏
非静态内部类会持有外部类的引用，如果这个非静态的内部类的生命周期比它的外部类的生命周期长，那么当销毁外部类的时候，它无法被回收，就会造成内存泄漏。
外部类中持有非静态内部类的静态对象
假设 Activity 的代码是这样的：
public class MainActivity extends AppCompatActivity { private static Test test; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); if (test == null) { test = new Test(); } } private class Test { } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
这个其实和单例的原理是一样的，由于静态对象 test 的生命周期和整个应用的生命周期一致，而非静态内部类 Test 持有外部类 MainActivity 的引用，导致 MainActivity 退出的时候不能被回收，从而造成内存泄漏，解决的方法也很简单，把 test 改成非静态，这样 test 的生命周期和 MainActivity 是一样的了，就避免了内存泄漏。或者也可以把 Test 改成静态内部类，让 test 不持有 MainActivity 的引用，不过一般没有这种操作。
Handler 或 Runnable 作为非静态内部类
handler 和 runnable 都有定时器的功能，当它们作为非静态内部类的时候，同样会持有外部类的引用，如果它们的内部有延迟操作，在延迟操作还没有发生的时候，销毁了外部类，那么外部类对象无法回收，从而造成内存泄漏，假设 Activity 的代码如下：
public class MainActivity extends AppCompatActivity { @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); new Handler().postDelayed(new Runnable() { @Override public void run() { } }, 10 * 1000); } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
上面的代码中，Handler 和 Runnable 作为匿名内部类，都会持有 MainActivity 的引用，而它们内部有一个 10 秒钟的定时器，如果在打开 MainActivity 的 10 秒内关闭了 MainActivity，那么由于 Handler 和 Runnable 的生命周期比 MainActivity 长，会导致 MainActivity 无法被回收，从而造成内存泄漏。
那么应该如何避免内存泄漏呢？这里的一般套路就是把 Handler 和 Runnable 定义为静态内部类，这样它们就不再持有 MainActivity 的引用了，从而避免了内存泄漏:
public class MainActivity extends AppCompatActivity { private Handler handler; private Runnable runnable; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); handler = new TestHandler(); runnable = new TestRunnable(); handler.postDelayed(runnable, 10 * 1000); } private static class TestHandler extends Handler { } private static class TestRunnable implements Runnable { @Override public void run() { Log.d(TAG, "run: "); } } private static final String TAG = "MainActivity"; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
最好再在 onDestory 调用 handler 的 removeCallbacks 方法来移除 Message，这样不但能避免内存泄漏，而且在退出 Activity 时取消了定时器，保证 10 秒以后也不会执行 run 方法：
@Override protected void onDestroy() { super.onDestroy(); handler.removeCallbacks(runnable); }
还有一种特殊情况，如果 Handler 或者 Runnable 中持有 Context 对象，那么即使使用静态内部类，还是会发生内存泄漏:
public class MainActivity extends AppCompatActivity { private Handler handler; private Runnable runnable; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); handler = new TestHandler(this); runnable = new TestRunnable(); handler.postDelayed(runnable, 10 * 1000); } private static class TestHandler extends Handler { private Context context; private TestHandler(Context context) { this.context = context; } } private static class TestRunnable implements Runnable { @Override public void run() { Log.d(TAG, "run: "); } } private static final String TAG = "MainActivity"; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
上面的代码，使用 leakcanary 工具会发现依然会发生内存泄漏，而且造成内存泄漏的原因和之前用非静态内部类是一样的，那么为什么会出现这种情况呢？
这是由于在 Handler 中持有 Context 对象，而这个 Context 对象是通过 TestHandler 的构造方法传入的，它是一个 MainActivity 对象，也就是说，虽然 TestHandler 作为静态内部类不会持有外部类 MainActivity 的引用，但是我们在调用它的构造方法时，自己传入了 MainActivity 的对象，从而 handler 对象持有了 MainActivity 的引用，handler 的生命周期比 MainActivity 的生命周期长，因此会造成内存泄漏，这种情况可以使用弱引用的方式来引用 Context 来避免内存泄漏，代码如下:
public class MainActivity extends AppCompatActivity {
private Handler handler; private Runnable runnable; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); handler = new TestHandler(new WeakReference(this)); runnable = new TestRunnable(); handler.postDelayed(runnable, 10 * 1000); } private static class TestHandler extends Handler { private Context context; private TestHandler(WeakReference weakContext) { context = weakContext.get(); } } private static class TestRunnable implements Runnable { @Override public void run() { Log.d(TAG, "run: "); } } private static final String TAG = "MainActivity";
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
}
线程造成的内存泄漏
最早时期的时候处理耗时操作多数都是采用Thread+Handler的方式，后来逐步被AsyncTask取代，直到现在采用RxJava的方式来处理异步。这里以AsyncTask为例，可能大部分人都会这样处理一个耗时操作然后通知UI更新结果：
public class MainActivity extends AppCompatActivity { private AsyncTask asyncTask; private TextView mTextView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mTextView = (TextView) findViewById(R.id.text); testAsyncTask(); finish(); } private void testAsyncTask() { asyncTask = new AsyncTask() { @Override protected Integer doInBackground(Void... params) { int i = 0; while (!isCancelled()) { i++; if (i > 1000000000) { break; } Log.e("LeakCanary", "asyncTask---->" + i); } return i; } @Override protected void onPostExecute(Integer integer) { super.onPostExecute(integer); mTextView.setText(String.valueOf(integer)); } }; asyncTask.execute(); }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
对于上面的例子来说，在处理一个比较耗时的操作时，可能还没处理结束MainActivity就执行了退出操作，但是此时AsyncTask依然持有对MainActivity的引用就会导致MainActivity无法释放回收引发内存泄漏。
如何解决这种内存泄漏呢？在使用AsyncTask时，在Activity销毁时候也应该取消相应的任务AsyncTask.cancel()方法，避免任务在后台执行浪费资源，进而避免内存泄漏的发生
public class MainActivity3 extends AppCompatActivity { private AsyncTask asyncTask; private TextView mTextView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); mTextView = (TextView) findViewById(R.id.text); testAsyncTask(); finish(); } private void testAsyncTask() { asyncTask = new AsyncTask() { @Override protected Integer doInBackground(Void... params) { int i = 0; while (!isCancelled()) { i++; if (i > 1000000000) { break; } Log.e("LeakCanary", "asyncTask---->" + i); } return i; } @Override protected void onPostExecute(Integer integer) { super.onPostExecute(integer); mTextView.setText(String.valueOf(integer)); } }; asyncTask.execute(); } private void destroyAsyncTask() { if (asyncTask != null && !asyncTask.isCancelled()) { asyncTask.cancel(true); } asyncTask = null; } @Override protected void onDestroy() { super.onDestroy(); destroyAsyncTask(); }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
- 31
- 32
- 33
- 34
- 35
- 36
- 37
- 38
- 39
- 40
- 41
- 42
- 43
- 44
- 45
- 46
- 47
- 48
- 49
- 50
- 51
- 52
- 53
由WebView引起的内存泄漏
在目前的开发中多多少少会用到Hybrid开发方式，这样我们就会用WebView去承载Html网页，就如下面这种方式：
public class MainActivity5 extends AppCompatActivity { private WebView mWebView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_web); mWebView = (WebView) findViewById(R.id.web); mWebView.loadUrl("http://blog.csdn.net/sky1373516909/article/details/78517912"); } @Override protected void onDestroy() { super.onDestroy(); LApplication.getRefWatcher().watch(this); }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
WebView解析网页时会申请Native堆内存用于保存页面元素，当页面较复杂时会有很大的内存占用。如果页面包含图片，内存占用会更严重。并且打开新页面时，为了能快速回退，之前页面占用的内存也不会释放。有时浏览十几个网页，都会占用几百兆的内存。这样加载网页较多时，会导致系统不堪重负，最终强制关闭应用，也就是出现应用闪退或重启。及时Activity关闭时在onDestroy中调用如下代码也是没有任何作用。
private void destroyWebView() { if (mWebView != null) { mLinearLayout.removeView(mWebView); mWebView.pauseTimers(); mWebView.removeAllViews(); mWebView.destroy(); mWebView = null; } }
这个查了不少资料，其中一种就是使用getApplicationgContext作为参数构建WebView，然后动态添加到一个ViewGroup中，最后退出的时候调用webView的销毁的函数，虽然也达到了防止内存溢出的效果，但是在有些网页弹出时候需要记住密码的对话框的时候，会出现Unable to add window – token null is not for an application 的错误，所以这里采用的解决办法是通过把使用了WebView的Activity(或者Service)放在单独的进程里。然后在检测到应用占用内存过大有可能被系统干掉或者它所在的Activity(或者Service)结束后，调用android.os.Process.killProcess(android.os.Process.myPid());，主动Kill掉进程。由于系统的内存分配是以进程为准的，进程关闭后，系统会自动回收所有内存。
public class MainActivity5 extends AppCompatActivity { private WebView mWebView; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_web); mWebView = (WebView) findViewById(R.id.web); mWebView.loadUrl("http://blog.csdn.net/sky1373516909/article/details/78517912"); } @Override protected void onDestroy() { destroyWebView(); android.os.Process.killProcess(android.os.Process.myPid()); super.onDestroy(); LApplication.getRefWatcher().watch(this); } private void destroyWebView() { if (mWebView != null) { mWebView.pauseTimers(); mWebView.removeAllViews(); mWebView.destroy(); mWebView = null; } }}
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
- 27
- 28
- 29
- 30
资源未关闭造成的内存泄漏
对于使用了BraodcastReceiver，ContentObserver，File，Cursor，Stream，Bitmap等资源的使用，应该在Activity销毁时及时关闭或者注销，否则这些资源将不会被回收，造成内存泄漏。例如获取媒体库图片地址代码在查询结束的时候一定要调用
Cursor 的关闭方法防止造成内存泄漏。
String columns[] = new String[]{ MediaStore.Images.Media.DATA, MediaStore.Images.Media._ID, MediaStore.Images.Media.TITLE, MediaStore.Images.Media.DISPLAY_NAME } Cursor cursor = this.getContentResolver().query(MediaStore.Images.Media.EXTERNAL_CONTENT_URI, columns, null, null, null) if (cursor != null) { int photoIndex = cursor.getColumnIndexOrThrow(MediaStore.Images.Media.DATA) //显示每张图片的地址，但是首先要判断一下，Cursor是否有值 while (cursor.moveToNext()) { String photoPath = cursor.getString(photoIndex) Log.e("LeakCanary", "photoPath---->" + photoPath) } cursor.close() }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
应用
在 MVP 的架构中，通常 Presenter 要同时持有 View 和 Model 的引用，如果在 Activity 退出的时候，Presenter 正在进行一个耗时操作，那么 Presenter 的生命周期会比 Activity 长，导致 Activity 无法回收，造成内存泄漏：
public class MainActivity extends AppCompatActivity implements TestView { private Presenter presenter; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.activity_main); presenter = new Presenter(this); presenter.request(); } }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
public class Presenter { private TestView view; private Model model; public Presenter(TestView view) { this.view = view; model = new Model(); } public void request() { new Thread(new Runnable() { @Override public void run() { try { Thread.sleep(10 * 1000); } catch (InterruptedException e) { e.printStackTrace(); } Log.d(TAG, "run: "); } }).start(); } private static final String TAG = "Presenter"; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
public class Presenter { private TestView view; private Model model; public Presenter(TestView view) { this.view = view; model = new Model(); } public void request() { new Thread(new Runnable() { @Override public void run() { try { Thread.sleep(10 * 1000); } catch (InterruptedException e) { e.printStackTrace(); } Log.d(TAG, "run: "); } }).start(); } private static final String TAG = "Presenter"; }
- 1
- 2
- 3
- 4
- 5
- 6
- 7
- 8
- 9
- 10
- 11
- 12
- 13
- 14
- 15
- 16
- 17
- 18
- 19
- 20
- 21
- 22
- 23
- 24
- 25
- 26
上面的代码中，假设 request 是一个需要耗时 10 秒的操作，那么在 10 秒之内如果退出 Activity 就会内存泄漏。解决方法也很简单，在 onDestory 方法中把 presenter 中的 view 对象置为空就可以了:
@Override protected void onDestroy() { super.onDestroy(); presenter.detachView(); }public void detachView() { view = null; }
也就是在退出 Activity 的时候，让 Presenter 不再持有 Activity 的引用，避免了内存泄漏。
总结
LeakCanary工具捕获常见的内存泄露
通过前面的分析我们可以发现，造成 Android 内存泄漏的最根本原因就是生命周期较长的对象持有生命周期较短的对象的引用，只要理解了这一点，内存泄漏问题就可迎刃而解了。
- Android内存泄露浅析
- Android进程通信Binder(1)-Binder进程通信的思想
- 如何避免Android内存泄漏 .
- Android(安卓)那些你所不知道的Bitmap对象详解
- Android(安卓)浅析 ContentProvider (三) 获取原理
- Android中实现Launcher功能之二 ----- 添加窗口小部件以及AppWid
- fackbook的Fresco （FaceBook推出的Android图片加载库-Fresco）
- 关于Android(安卓)Activity之间传递数据的6种方式
- ArcGIS for Android示例解析之FeatureLayer服务-----SelectFeatu
随机推荐
-
Android如何平移一个View
-
android:launchMode="singleTask" 与 onN
-
Android(安卓)webkit 事件传递流程
-
android 开发中判断网络是否连接的代码
-
android 启动页与数据保存
-
android Button 颜色的变化（点击，放开，点击
-
Android(安卓)中常用的五种布局
-
manifest中的 android:name
-
android 图片双缓存，开源框架 universali
-
如何检查后台服务（Android的Service类）是否
