Android下常见的内存泄露

转自 http://www.linuxidc.com/Linux/2011-10/44785.htm

因为Android使用Java作为开发语言，很多人在使用会不注意内存的问题。

于是有时遇到程序运行时不断消耗内存，最终导致OutOfMemery，程序异常退出，这就是内存泄露导致的。

我们现在就来总结一下可能导致内存泄露的情况：

1. 查询数据库而没有关闭Cursor

   在Android中，Cursor是很常用的一个对象，但在写代码是，经常会有人忘记调用close, 或者因为代码逻辑问题状况导致close未被调用。

   
   通常，在Activity中，我们可以调用startManagingCursor或直接使用managedQuery让Activity自动管理Cursor对象。
   但需要注意的是，当Activity介绍后，Cursor将不再可用！
   若操作Cursor的代码和UI不同步（如后台线程），那没需要先判断Activity是否已经结束，或者在调用OnDestroy前，先等待后台线程结束。
   
   除此之外，以下也是比较常见的Cursor不会被关闭的情况：

   try {
       Cursor c = queryCursor();
       int a = c.getInt(1);
       ......
       c.close();
   } catch (Exception e) {
   }

   虽然表面看起来，Cursor.close()已经被调用，但若出现异常，将会跳过close()，从而导致内存泄露。

   所以，我们的代码应该以如下的方式编写：

    Cursor c = queryCursor();
    try {
        int a = c.getInt(1);
        ......
    } catch (Exception e) {
    } finally {
        c.close(); //在finally中调用close(), 保证其一定会被调用
    }

2. 调用registerReceiver后未调用unregisterReceiver().

   在调用registerReceiver后，若未调用unregisterReceiver，其所占的内存是相当大的。
   而我们经常可以看到类似于如下的代码：

    registerReceiver(new BroadcastReceiver() {
        ...
    }, filter); ...

   这是个很严重的错误，因为它会导致BroadcastReceiver不会被unregister而导致内存泄露。
   

   
   

3. 未关闭InputStream/OutputStream

   在使用文件或者访问网络资源时，使用了InputStream/OutputStream也会导致内存泄露

   
   

4. Bitmap使用后未调用recycle()

   根据SDK的描述，调用recycle并不是必须的。但在实际使用时，Bitmap占用的内存是很大的，所以当我们不再使用时，尽量调用recycle()以释放资源。

   
   

5. Context泄露

   这是一个很隐晦的内存泄露的情况。
   先让我们看一下以下代码：

    private static Drawable sBackground;
   
    @Override
    protected void onCreate(Bundle state) {
      super.onCreate(state);
   
      TextView label = new TextView(this);
      label.setText("Leaks are bad");
   
      if (sBackground == null) {
        sBackground = getDrawable(R.drawable.large_bitmap);
      }
      label.setBackgroundDrawable(sBackground);
   
      setContentView(label);
    }

   在这段代码中，我们使用了一个static的Drawable对象。
   这通常发生在我们需要经常调用一个Drawable，而其加载又比较耗时，不希望每次加载Activity都去创建这个Drawable的情况。
   此时，使用static无疑是最快的代码编写方式，但是其也非常的糟糕。
   当一个Drawable被附加到View时，这个View会被设置为这个Drawable的callback (通过调用Drawable.setCallback()实现)。
   这就意味着，这个Drawable拥有一个TextView的引用，而TextView又拥有一个Activity的引用。
   这就会导致Activity在销毁后，内存不会被释放。

   
   

   6.构造Adapter时，没有使用缓存的 convertView

   描述：

       以构造ListView的BaseAdapter为例，在BaseAdapter中提高了方法：

   public View getView(int position, View convertView, 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 --> void addScrapView(View scrap) 方法。

    

   示例代码：

   public View getView(int position, View convertView, ViewGroup parent) {

       View view = new Xxx(...);

       ... ...

       return view;

   }

    

   修正示例代码：

   public View getView(int position, View convertView, ViewGroup parent) {

       View view = null;

       if (convertView != null) {

           view = convertView;

           populate(view, getItem(position));

           ...

       } else {

           view = new Xxx(...);

           ...

       }

       return view;

   }