Android内存泄露分析和处理

什么是内存泄露
Java使用有向图机制，通过GC自动检查内存中的对象，如果GC发现一个或一组对象为不可到达状态，则将该对象从内存中回收。也就是说，一个对象不被任何引用所指向，则该对象会在被GC发现的时候被回收。

内存泄露的原因
1.资源对象没关闭造成的内存泄漏
资源性对象比如 （Cursor，File文件等）往往都用了一些缓冲，我们在不使用的时候，应该及时关闭它们，以便它们的缓冲及时回收内存。它们的缓冲不仅存在于 java虚拟机内，还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们，往往会造成内存泄漏。因为有些资源性对象，比如 SQLiteCursor（在析构函数finalize(),如果我们没有关闭它，它自己会调close()关闭），如果我们没有关闭它，系统在回收它时 也会关闭它，但是这样的效率太低了。因此对于资源性对象在不使用的时候，应该调用它的close()函数，将其关闭掉，然后才置为null.在我们的程序 退出时一定要确保我们的资源性对象已经关闭。
程序中经常会进行查询数据库的操作，但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小，对内存的消耗不容易被发现，只有在常时间大量操作的情况下才会复现内存问题，这样就会给以后的测试和问题排查带来困难和风险。
 示例代码：
    Cursor cursor = getContentResolver().query(uri...);  
    if (cursor.moveToNext()) {  
      ... ...    
    }  
修正示例代码：
    Cursor cursor = null;  
    try {  
      cursor = getContentResolver().query(uri...);  
      if (cursor != null &&cursor.moveToNext()) {  
          ... ...    
      }  
    } finally {  
      if (cursor != null) {  
          try {    
              cursor.close();  
          } catch (Exception e) {  
              //ignore this   
          }  
       }  
    }  
2.构造Adapter时，没有使用缓存的convertView
以构造ListView的BaseAdapter为例，在BaseAdapter中提供了方法：
public View getView(int position, ViewconvertView, ViewGroup parent)
来 向ListView提供每一个item所需要的view对象。初始时ListView会从BaseAdapter中根据当前的屏幕布局实例化一定数量的 view对象，同时ListView会将这些view对象缓存起来。当向上滚动ListView时，原先位于最上面的list item的view对象会被回收，然后被用来构造新出现的最下面的list item。这个构造过程就是由getView()方法完成的，getView()的第二个形参View convertView就是被缓存起来的list item的view对象(初始化时缓存中没有view对象则convertView是null)。由此可以看出，如果我们不去使用 convertView，而是每次都在getView()中重新实例化一个View对象的话，即浪费资源也浪费时间，也会使得内存占用越来越大。 ListView回收list item的view对象的过程可以查看:
Android.widget.AbsListView.java --> voidaddScrapView(View scrap) 方法。
示例代码：
    public View getView(int position, ViewconvertView, ViewGroup parent) {  
      View view = new Xxx(...);  
      ... ...  
      return view;  
    }  
修正示例代码：
    public View getView(int position, ViewconvertView, ViewGroup parent) {  
      View view = null;  
      if (convertView != null) {  
      view = convertView;  
      populate(view, getItem(position));  
      ...  
      } else {  
      view = new Xxx(...);  
      ...  
      }  
      return view;  
    }  
3.Bitmap对象不在使用时调用recycle()释放内存
有时我们会手工的操作Bitmap对象，如果一个Bitmap对象比较占内存，当它不在被使用的时候，可以调用Bitmap.recycle()方法回收此对象的像素所占用的内存，但这不是必须的，视情况而定。可以看一下代码中的注释：
    /**
     * Free up the memory associated with thisbitmap's pixels, and mark the
     * bitmap as "dead", meaning itwill throw an exception if getPixels() or
     * setPixels() is called, and will drawnothing. This operation cannot be
     * reversed, so it should only be called ifyou are sure there are no
     * further uses for the bitmap. This is anadvanced call, and normally need
     * not be called, since the normal GCprocess will free up this memory when
     * there are no more references to thisbitmap.
     */  
4.试着使用关于application的context来替代和activity相关的context
这是一个很隐晦的内 存泄漏的情况。有一种简单的方法来避免context相关的内存泄漏。最显著地一个是避免context逃出他自己的范围之外。使用 Application context。这个context的生存周期和 的应用的生存周期一样长，而不是取决于activity的生存周期。如果 想保持一个长期生存的对象， 并且这个对象需要一个context,记得使用application对象。 可以通过调用 Context.getApplicationContext() or Activity.getApplication()来获得。更多的请看这篇文章如何避免Android内存泄漏 （见 http://www.linuxidc.com/Linux/2012-02/52951.htm ）。
5.注册没取消造成的内存泄漏
一些Android 程序可能引用我们的Anroid程序的对象（比如注册机制）。即使我们的Android程序已经结束了，但是别的引用程序仍然还有对我们的Android 程序的某个对象的引用，泄漏的内存依然不能被垃圾回收。调用registerReceiver后未调用unregisterReceiver。
比如:假设我们希望 在锁屏界面(LockScreen)中，监听系统中的电话服务以获取一些信息(如信号强度等)，则可以在LockScreen中定义一个 PhoneStateListener的对象，同时将它注册到TelephonyManager服务中。对于LockScreen对象，当需要显示锁屏界 面的时候就会创建一个LockScreen对象，而当锁屏界面消失的时候LockScreen对象就会被释放掉。
但是如果在释放 LockScreen对象的时候忘记取消我们之前注册的PhoneStateListener对象，则会导致LockScreen无法被垃圾回收。如果不 断的使锁屏界面显示和消失，则最终会由于大量的LockScreen对象没有办法被回收而引起OutOfMemory,使得system_process 进程挂掉。
虽然有些系统程序，它本身好像是可以自动取消注册的（当然不及时），但是我们还是应该在我们的程序中明确的取消注册，程序结束时应该把所有的注册都取消掉。
6.集合中对象没清理造成的内存泄漏
我们通常把一些对象的引用加入到了集合中，当我们不需要该对象时，并没有把它的引用从集合中清理掉，这样这个集合就会越来越大。如果这个集合是static的话，那情况就更严重了。
7.Android中使用Handler造成内存泄露
Handler mHandler = new Handler() {
    @Override
    public void handleMessage(Message msg) {
        mImageView.setImageBitmap(mBitmap);
    }
}
上面是一段简单的Handler的使用。当使用内部类（包括匿名类）来创建Handler的时候，Handler对象会隐式地持有一个外部类对象（通常是一个Activity的引用）。而Handler通常会伴随着一个耗 时的后台线程（例如从网络拉取图片）一起出现，这个后台线程在任务执行完毕（例如图片下载完毕）之后，通过消息机制通知Handler，然后 Handler把图片更新到界面。然而，如果用户在网络请求过程中关闭了Activity，正常情况下，Activity不再被使用，它就有可能在GC检 查时被回收掉，但由于这时线程尚未执行完，而该线程持有Handler的引用，这个Handler又持有 Activity的引用，就导致该Activity无法被回收（即内存泄露），直到网络请求结束（例如图片下载完毕）。另外，如果 执行了Handler 的postDelayed（）方法，该方法会将Handler装入一个Message，并把这条Message推到MessageQueue中，那么 在设定的delay到达之前，会有一条MessageQueue -> Message -> Handler -> Activity的链，导致Activity被持有引用而无法被回收。

内存泄露的危害
虚拟机占用内存过高，导致OOM（内存溢出），程序出错。对于Android应用来说，就是用户打开一个Activity，使用完之后关闭它，内存泄露；又打开，又关闭，又泄露；几次之后，程序占用内存超过系统限制，FC。

使用Handler导致内存泄露的解决方法
1.通过程序逻辑来进行保护。
（1）在关闭Activity的时候停掉 的后台线程。线程停掉了，就相当于切断了Handler和外部连接的线，Activity自然会在合适的时候被回收。
（2）如果 的Handler是被delay的Message持有了引用，那么使用相应的Handler的removeCallbacks()方法，把消息对象从消息队列移除就行了。
2.将Handler声明为静态类。
静态类不持有外部类的对象，所以 的Activity可以随意被回收。代码如下：
static class MyHandler extends Handler {
    @Override
    public void handleMessage(Message msg) {
        mImageView.setImageBitmap(mBitmap);
    }
}
但是这样还是有问题由于Handler不再持有外部类对象的引用，导致程序不允许 在Handler中操作Activity中的对象了。所以 需要在Handler中增加一个对Activity的弱引用（WeakReference）：
static class MyHandler extends Handler {
    WeakReference<Activity > mActivityReference;

    MyHandler(Activity activity) {
        mActivityReference= new WeakReference<Activity>(activity);
    }

    @Override
    public void handleMessage(Message msg) {
        final Activity activity = mActivityReference.get();
        if (activity != null) {
            mImageView.setImageBitmap(mBitmap);
        }
    }
}

延伸：什么是WeakReference？
WeakReference弱引用，与强引用（即我们常说的引用）相对，它的特点是，GC在回收时会忽略掉弱引用，即就算有弱引用指向某对象，但只 要该对象没有被强引用指向（实际上多数时候还要求没有软引用，但此处软引用的概念可以忽略），该对象就会在被GC检查到时回收掉。对于上面的代码，用户在 关闭Activity之后，就算后台线程还没结束，但由于仅有一条来自Handler的弱引用指向Activity，所以GC仍然会在检查的时候把 Activity回收掉。这样，内存泄露的问题就不会出现了。

那么，Android开发中，有什么有效的方法可以检测内存使用情况以及内存泄漏呢？
这里主要介绍三种方法：
1. 程序的Log信息
程序在进行垃圾回收的时候，会打印一条Log信息（logcat窗口），例如：
D/dalvikvm( 9050): GC_CONCURRENT freed 2049K, 65% free 3571K/9991K, external 4703K/5261K, paused 2ms+2ms
注意这条信息中的 “ 3571K/9991K” 值，这代表着程序使用的heap大小，如果这个值一直在增加，而从来不减小，那么就代表着 的程序存在着内存泄漏。
2. DDMS的Heap信息
Eclipse开发环境还提供了一种更加直观的方法来查看App的Heap信息，操作方式如下：
Android开发实践：检测App的内存占用和泄漏
（1）  连接手机，运行程序，假设是 com.ticktick.test 程序
（2）  点击DDMS按钮，在左侧的Device窗口选中 要检测的程序（com.ticktick.test ）
（3）  点击Device窗口工具栏的第二个图标（Update Heap），
（4）  点击右边的窗口的Cause GC按钮，即可得到当前程序的Heap信息
同样，随着程序的运行，多次点击得到的Heap大小，如果只增不减的话，也昭示着 的程序有内存泄漏。
3.  adb命令查看内存信息
其实，最全面最简单的方式还是用adb命令来查看程序的内存占用和内存泄漏情况，打开命令行窗口，adb命令的格式如下：
adb shell dumpsys meminfo <package_name>
其中，package_name 也可以换成程序的pid，pid可以通过 adb shell top | grep app_name 来查找。

（1） Native/Dalvik 的 Heap 信息
具体在上面的第一行和第二行，它分别给出的是JNI层和Java层的内存分配情况，如果发现这个值一直增长，则代表程序可能出现了内存泄漏。
（2） Total 的 PSS 信息

这个值就是 的应用真正占据的内存大小，通过这个信息， 可以轻松判别手机中哪些程序占内存比较大了。

欢迎关注公众账号