android内存泄露优化总结

 

android手机给应用分配的内存一般是8兆左右，若是处理内存处理不当很容易形成OutOfMemoryError，咱们的产品出现最多的错误也是OutOfMemoryError的异常， 
在解决这个异常时在网上发现不少关于OutOfMemoryError的缘由的介绍。 
OutOfMemoryError主要由如下几种状况形成： 
1.数据库的cursor没有关闭。  
操做Sqlite数据库时，Cursor是数据库表中每一行的集合，Cursor提供了不少方法，能够很方便的读取数据库中的值， 
    能够根据索引，列名等获取数据库中的值，经过游标的方式能够调用moveToNext()移到下一行 
    当咱们操做完数据库后，必定要记得调用Cursor对象的close()来关闭游标，释放资源。 
2.构造adapter没有使用缓存contentview。 
    在继承BaseAdapter时会让咱们重写getView(int position, View   convertView, ViewGroup parent)方法， 
    第二个参数convertView就是咱们要用到的重用的对象 

@Override
public View getView(int position, View convertView, ViewGroup parent) {
    ViewHolder vHolder = null;
               //若是convertView对象为空则建立新对象，不为空则复用
    if (convertView == null) {
        convertView = inflater.inflate(..., null);
        // 建立 ViewHodler 对象
        vHolder = new ViewHolder();
        vHolder.img= (ImageView) convertView.findViewById(...);
        vHolder.tv= (TextView) convertView
                .findViewById(...);
        // 将ViewHodler保存到Tag中
        convertView.setTag(vHolder);
    } else {
                       //当convertView不为空时，经过getTag()获得View
        vHolder = (ViewHolder) convertView.getTag();
    }
    // 给对象赋值，修改显示的值
    vHolder.img.setImageBitmap(...);
    vHolder.tv.setText(...);
    return convertView;
}
       //将显示的View 包装成类
static class ViewHolder {
    TextView tv;
    ImageView img;
}

    这里只讲使用方法，具体性能测试文章请见： 
    ListView中getView的原理＋如何在ListView中放置多个item 
    http://www.cnblogs.com/xiaowenji/archive/2010/12/08/1900579.html 
    Android开发之ListView适配器（Adapter）优化 
    http://shinfocom.iteye.com/blog/1231511 
3.调用registerReceiver()后未调用unregisterReceiver(). 
     广播接收者（BroadcastReceiver）常常在应用中用到，能够在多线程任务完成后发送广播通知UI更新，也能够接收系统广播实现一些功能 
     能够经过代码的方式注册： 
    IntentFilter postFilter = new IntentFilter(); 
    postFilter.addAction(getPackageName() + ".background.job"); 
    this.registerReceiver(receiver, postFilter); 
    当咱们Activity中使用了registerReceiver()方法注册了BroadcastReceiver，必定要在Activity的生命周期内调用unregisterReceiver()方法取消注册 
    也就是说registerReceiver()和unregisterReceiver()方法必定要成对出现，一般咱们能够重写Activity的onDestory()方法： 

@Override
protected void onDestroy() {
      this.unregisterReceiver(receiver);
      super.onDestroy();
}

4.未关闭InputStream/OutputStream。 
    这个就很少说了，咱们操做完输入输出流都要关闭流 
5.Bitmap使用后未调用recycle()。 
    图片处理很差是形成内存溢出的又一个头号缘由，（在咱们的产品中也有体现)， 

    当咱们处理完图片以后能够经过调用recycle()方法来回收图片对象 

if(!bitmap.isRecycled())
{
    bitmap.recycle()
}

    除此以外： 
    直接使用ImageView显示bitmap会占用较多资源，特别是图片较大的时候，可能致使崩溃。 
    使用BitmapFactory.Options设置inSampleSize, 这样作能够减小对系统资源的要求。 
    属性值inSampleSize表示缩略图大小为原始图片大小的几分之一，即若是这个值为2，则取出的缩略图的宽和高都是原始图片的1/2，图片大小就为原始大小的1/4。 
        BitmapFactory.Options bitmapFactoryOptions = new BitmapFactory.Options();  
        bitmapFactoryOptions.inJustDecodeBounds = true;  
        bitmapFactoryOptions.inSampleSize = 2;  
        // 这里必定要将其设置回false，由于以前咱们将其设置成了true  
        // 设置inJustDecodeBounds为true后，decodeFile并不分配空间，即，BitmapFactory解码出来的Bitmap为Null,但可计算出原始图片的长度和宽度  
        options.inJustDecodeBounds = false; 
        Bitmap bmp = BitmapFactory.decodeFile(sourceBitmap, options);  
6.Context泄漏。 
    这是一个很隐晦的OutOfMemoryError的状况。先看一个Android官网提供的例子： 

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);
}

    这段代码效率很快，但同时又是极其错误的； 
    在第一次屏幕方向切换时它泄露了一开始建立的Activity。当一个Drawable附加到一个 View上时， 
    View会将其做为一个callback设定到Drawable上。上述的代码片断，意味着Drawable拥有一个TextView的引用， 
    而TextView又拥有Activity（Context类型）的引用，换句话说，Drawable拥有了更多的对象引用。即便Activity被 销毁，内存仍然不会被释放。 
    另外，对Context的引用超过它自己的生命周期，也会致使Context泄漏。因此尽可能使用Application这种Context类型。 
    这种Context拥有和应用程序同样长的生命周期，而且不依赖Activity的生命周期。若是你打算保存一个长时间的对象， 
    而且其须要一个 Context，记得使用Application对象。你能够经过调用Context.getApplicationContext()或 Activity.getApplication()轻松获得Application对象。 
    最近遇到一种状况引发了Context泄漏，就是在Activity销毁时，里面有其余线程没有停。 
    总结一下避免Context泄漏应该注意的问题： 
    1.使用Application这种Context类型。 
    2.注意对Context的引用不要超过它自己的生命周期。 
    3.慎重的使用“static”关键字。 
    4.Context里若是有线程，必定要在onDestroy()里及时停掉。 
7.static关键字 
    当类的成员变量声明成static后，它是属于类的而不是属于对象的，若是咱们将很大的资源对象（Bitmap，context等）声明成static，那么这些资源不会随着对象的回收而回收， 
    会一直存在，因此在使用static关键字定义成员变量的时候要慎重。