android 工作笔记 内存优化问题


工作中的学习终结,写成博客以供以后学习

Android的虚拟机是基于寄存器的Dalvik,它的最大堆大小一般是16M,有的机器为24M。我们平常看到的OutOfMemory的错误,通常是堆内存溢出。

android常见的内存溢出一般有以下几点问题
1.资源性对象没有关闭(例如cursor,file流等)
2.适配器adapter中没有复用contentview
3.广播调用registerReceiver()后未调用unregisterReceiver().
4.Bitmap使用后未调用recycle()。
5.static关键字等。
1.资源性对象比如(Cursor,File文件等)往往都用了一些缓冲,我们在不使用的时候,应该及时关闭它们,以便它们的缓冲及时回收内存。它们的缓冲不仅存在于java虚拟机内,还存在于java虚拟机外。如果我们仅仅是把它的引用设置为null,而不关闭它们,往往会造成内存泄露。因为有些资源性对象,比如SQLiteCursor(在析构函数finalize(),如果我们没有关闭它,它自己会调close()关闭),如果我们没有关闭它,系统在回收它时也会关闭它,但是这样的效率太低了。因此对于资源性对象在不使用的时候,应该调用它的close()函数,将其关闭掉,然后才置为null.在我们的程序退出时一定要确保我们的资源性对象已经关闭。
  程序中经常会进行查询数据库的操作,但是经常会有使用完毕Cursor后没有关闭的情况。如果我们的查询结果集比较小,对内存的消耗不容易被发现,只有在常时间大量操作的情况下才会复现内存问题,这样就会给以后的测试和问题排查带来困难和风险。

Cursor cursor = null;   
 try {   
   cursor = mContext.getContentResolver().query(uri,null, null,null,null);   
   if(cursor != null) {   
       cursor.moveToFirst();   
       //do something 
   }   
 } catch (Exception e) {   
   e.printStackTrace();     
 } finally {   
   if (cursor != null) {   
      cursor.close();   
   }   
   有一种情况下,我们不能直接将Cursor关闭掉,这就是在CursorAdapter中应用的情况,但是注意,CursorAdapter在Acivity结束时并没有自动的将Cursor关闭掉,因此,你需要在onDestroy函数中,手动关闭。 
@Override  
protected void onDestroy() {         
   if (mAdapter != null && mAdapter.getCurosr() != null) {   
       mAdapter.getCursor().close();   
   }   
   super.onDestroy();    
}   

CursorAdapter中的changeCursor函数,会将原来的Cursor释放掉,并替换为新的Cursor,所以你不用担心原来的Cursor没有被关闭。

Thread(线程)回收:

线程中涉及的任何东西GC都不能回收(Anything reachable by a thread cannot be GC’d ),所以线程很容易造成内存泄露。
如下面代码所示:

[java] view plaincopy 
Thread t = new Thread() {  
    public void run() {  
        while (true) {  
            try {  
                Thread.sleep(1000);  
                System.out.println("thread is running...");  
            } catch (InterruptedException e) {  

            }  
        }  
    }  
};  
t.start();  
t = null;  
System.gc();  

如上在线程t中每间隔一秒输出一段话,然后将线程设置为null并且调用System.gc方法。
最后的结果是线程并不会被回收,它会一直的运行下去。

因为运行中的线程是称之为垃圾回收根(GC Roots)对象的一种,不会被垃圾回收。当垃圾回收器判断一个对象是否可达,总是使用垃圾回收根对象作为参考点。
2.下面是示例代码,减少iew对象的创建会节省很多内存

 public View getView(int position, View convertView, ViewGroup parent) {
ViewHolder holder;
if (convertView == null) {
convertView = mInflater.inflate(R.layout.list_item_icon_text, null);
holder = new ViewHolder();
holder.text = (TextView) convertView.findViewById(R.id.text);
holder.icon = (ImageView) convertView.findViewById(R.id.icon);
convertView.setTag(holder);
} else {
holder = (ViewHolder) convertView.getTag();
}
holder.text.setText(DATA[position]);
holder.icon.setImageBitmap((position & 1) == 1 ? mIcon1 : mIcon2);
return convertView;
}

static class ViewHolder {
TextView text;
ImageView icon;
}

3.广播经常用到,方便了我们进程间通信
可以通过代码的方式注册:
IntentFilter postFilter = new IntentFilter();
postFilter.addAction(getPackageName() + “.background.job”);
this.registerReceiver(receiver, postFilter);

**当我们Activity中使用了registerReceiver()方法注册了BroadcastReceiver,一定要在Activity的生命周期内调用unregisterReceiver()方法取消注册
也就是说registerReceiver()和unregisterReceiver()方法一定要成对出现,通常我们可以重写Activity的onDestory().**
4.接下来就是我们的内存消耗大户bitmap
1.Bitmap类有一个方法recycle(),从方法名可以看出意思是回收。
Bitmap类的构造方法都是私有的,所以开发者不能直接new出一个Bitmap对象,只能通过BitmapFactory类的各种静态方法来实例化一个Bitmap。仔细查看BitmapFactory的源代码可以看到,生成Bitmap对象最终都是通过JNI调用方式实现的。所以,加载Bitmap到内存里以后,是包含两部分内存区域的。简单的说,一部分是Java部分的,一部分是C部分的。这个Bitmap对象是由Java部分分配的,不用的时候系统就会自动回收了,但是那个对应的C可用的内存区域,虚拟机是不能直接回收的,这个只能调用底层的功能释放。所以需要调用recycle()方法来释放C部分的内存。从Bitmap类的源代码也可以看到,recycle()方法里也的确是调用了JNI方法了的。
那如果不调用recycle(),是否就一定存在内存泄露呢?也不是的。Android的每个应用都运行在独立的进程里,有着独立的内存,如果整个进程被应用本身或者系统杀死了,内存也就都被释放掉了,当然也包括C部分的内存。
Android对于进程的管理是非常复杂的。简单的说,Android系统的进程分为几个级别,系统会在内存不足的情况下杀死一些低优先级的进程,以提供给其它进程充足的内存空间。在实际项目开发过程中,有的开发者会在退出程序的时候使用Process.killProcess(Process.myPid())的方式将自己的进程杀死,但是有的应用仅仅会使用调用Activity.finish()方法的方式关闭掉所有的Activity。
2.设置一定的采样率。
如果图片像素过大,使用BitmapFactory类的方法实例化Bitmap的过程中,需要大于8M的内存空间,就必定会发生OutOfMemory异常。这个时候该如何处理呢?如果有这种情况,则可以将图片缩小,以减少载入图片过程中的内存的使用,避免异常发生。
使用BitmapFactory.Options设置inSampleSize就可以缩小图片。属性值inSampleSize表示缩略图大小为原始图片大小的几分之一。即如果这个值为2,则取出的缩略图的宽和高都是原始图片的1/2,图片的大小就为原始大小的1/4。
如果知道图片的像素过大,就可以对其进行缩小。那么如何才知道图片过大呢?
使用BitmapFactory.Options设置inJustDecodeBounds为true后,再使用decodeFile()等方法,并不会真正的分配空间,即解码出来的Bitmap为null,但是可计算出原始图片的宽度和高度,即options.outWidth和options.outHeight。通过这两个值,就可以知道图片是否过大了。

private ImageView preview;   
BitmapFactory.Options options = new BitmapFactory.Options();   
options.inSampleSize = 2;//图片宽高都为原来的二分之一,即图片为原来的四分之一   
Bitmap bitmap = BitmapFactory.decodeStream(cr.openInputStream(uri), null, options);   
preview.setImageBitmap(bitmap);   
第三、巧妙的运用软引用(SoftRefrence) 
有些时候,我们使用Bitmap后没有保留对它的引用,因此就无法调用Recycle函数。这时候巧妙的运用软引用,可以使Bitmap在内存快不足时得到有效的释放。如下例: 

private class MyAdapter extends BaseAdapter {

private ArrayList> mBitmapRefs = new ArrayList>();   
public View getView(int i, View view, ViewGroup viewGroup) {   
    View newView = null;   
    if(view != null) {   
        newView = view;   
    } else {   
        newView =(View)mInflater.inflate(R.layout.image_view, false);   
    }   

    Bitmap bitmap = BitmapFactory.decodeFile(mValues.get(i).fileName);   
    mBitmapRefs.add(new SoftReference(bitmap));     //此处加入ArrayList   
    ((ImageView)newView).setImageBitmap(bitmap);   

    return newView;   
}   

}
5.static int intVal = 42;
static String strVal = “Hello, world!”;

编译器会生成一个叫做clinit的初始化类的方法,当类第一次被使用的时候这个方法会被执行。方法会将42赋给intVal,然后把一个指向类中常量表 的引用赋给strVal。当以后要用到这些值的时候,会在成员变量表中查找到他们。 下面我们做些改进,使用“final”关键字:

static final int intVal = 42;
static final String strVal = “Hello, world!”;

现在,类不再需要clinit方法,因为在成员变量初始化的时候,会将常量直接保存到类文件中。用到intVal的代码被直接替换成42,而使用strVal的会指向一个字符串常量,而不是使用成员变量。
将一个方法或类声明为final不会带来性能的提升,但是会帮助编译器优化代码。举例说,如果编译器知道一个getter方法不会被重载,那么编译器会对其采用内联调用。
你也可以将本地变量声明为final,同样,这也不会带来性能的提升。使用“final”只能使本地变量看起来更清晰些(但是也有些时候这是必须的,比如在使用匿名内部类的时候)。

静态方法代替虚拟方法
如果不需要访问某对象的字段,将方法设置为静态,调用会加速15%到20%。这也是一种好的做法,因为你可以从方法声明中看出调用该方法不需要更新此对象的状态。

减少不必要的全局变量
尽量避免static成员变量引用资源耗费过多的实例,比如Context
因为Context的引用超过它本身的生命周期,会导致Context泄漏。所以尽量使用Application这种Context类型。 你可以通过调用Context.getApplicationContext()或 Activity.getApplication()轻松得到Application对象。

避免创建不必要的对象
最常见的例子就是当你要频繁操作一个字符串时,使用StringBuffer代替String。
对于所有所有基本类型的组合:int数组比Integer数组好,这也概括了一个基本事实,两个平行的int数组比 (int,int)对象数组性能要好很多。
总体来说,就是避免创建短命的临时对象。减少对象的创建就能减少垃圾收集,进而减少对用户体验的影响。

避免内部Getters/Setters
在Android中,虚方法调用的代价比直接字段访问高昂许多。通常根据面向对象语言的实践,在公共接口中使用Getters和Setters是有道理的,但在一个字段经常被访问的类中宜采用直接访问。

避免使用浮点数
通常的经验是,在Android设备中,浮点数会比整型慢两倍。

智能推荐

注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
© 2014-2019 ITdaan.com 粤ICP备14056181号  

赞助商广告