今天发现正在做的项目,时不时的会报错:dalvikvm heap out of memory on a 7458832-byte allocation (堆分配的内存溢出)
为什么会内存溢出呢?我以前从未遇见这种情况。后来在网上查了查资料,还是挺多的。
怎么说呢?因为Android开发基本上是以java语言为基础,那么程序是在java虚拟机上运行的。而虚拟机不允许单个程序中的Bitmap占用超过8M的内存,从报错的日志可以看出:7458832-byte大约就是7M多的样子,基本吻合上述数据。在我的项目中大量的使用到了各种图片,因此是因为图片导致内存溢出的的可能性很高。
那么,下面就提供一下解决方案:
第一种方案:
Android堆内存也可自己定义大小 和 优化Dalvik虚拟机的堆内存分配(LZ没试过,不过网上很多人都说可行)。
强制定义自己软件的对内存大小,我们使用Dalvik提供的 dalvik.system.VMRuntime类来设置最小堆内存为例:
private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);
//设置最小heap内存为6MB大小。当然对于内存吃紧来说还可以通过手动干涉GC去处理
第二种方案:
手动的回收内存。
示例代码如下:bit为Bitmap对象
if (bit != null && !bit.isRecycled()) { bit.recycle(); bit = null; }
System.gc();
bitmap.recycle()方法用于回收该bitmap所占用的内存,用System.gc()调用一下系统的垃圾回收器。
需要注意的是:回收内存要及时,比如说SurfaceView,就应该在onSurfaceDestroyed这个方法中回收。如果Activity使用了bitmap,就可以在onStop或者onDestroy方法中回收等等。
我首先就是用的这种方法,修改后发现bug出现的频率减小了,但仍然存在。
第三种方案:
既然是图的问题,那就从图片下手。就是使图片体积大小变小。
这也分为两个方面:
1、分辨率不变,图片大小减小2、分辨率改变,图片减小。(用PS都很容易的)
需要注意的是:不要减小得太小而影响了人眼看上去的美感。
以上三种方案,后两种较简单且常用。
另外,因为是Android的图片导致的内存问题,那么就总结了一下与图片相关的方法的性能,结果很有收获啊……(不看不知道,一看吓一跳)
测试的环境为:笔记本i3处理器,64位win7系统,测试手机为小米2S,测试图片大小为500KB
比较Drawable与Bitmap占用内存大小
比较BitmapFactory类的decodeResource方法与decodeStream方法的效率
以及优化后的BitmapFactory类的decodeResource方法。
下面贴上代码与运行图:(每次请只运行一个方法,隐藏另外的三种方法)
public class MainActivity extends Activity { int number = 1000; Drawable[] array; Bitmap bitmap[]; @Override protected void onCreate(Bundle savedInstanceState) { super.onCreate(savedInstanceState); setContentView(R.layout.main); testDrawable(); // testBitmap_decodeResource(); // testBitmap_decodeStream(); //testnewBitmap_decodeResource(); } /** * 优化后的BitmapFactory类的decodeResource方法 */ private void testnewBitmap_decodeResource() { bitmap = new Bitmap[number]; for (int i = 0; i < number; i++) { Log.i("", "测试第" + (i + 1) + "张图片"); //压缩,用于节省BITMAP内存空间--解决BUG的关键步骤 BitmapFactory.Options opts = new BitmapFactory.Options(); opts.inSampleSize = 2;//这个的值压缩的倍数(2的整数倍),数值越小,压缩率越小,图片越清晰 //返回原图解码之后的bitmap对象 bitmap[i] = BitmapFactory.decodeResource(getResources(), R.drawable.begin_background, opts); } } /** * BitmapFactory类的decodeStream方法 */ private void testBitmap_decodeStream() { bitmap = new Bitmap[number]; for (int i = 0; i < number; i++) { Log.i("", "测试第" + (i + 1) + "张图片"); bitmap[i] = BitmapFactory.decodeStream(getResources() .openRawResource(R.drawable.begin_background));// 这里换了方法 } } /** * BitmapFactory类的decodeResource方法 */ private void testBitmap_decodeResource() { bitmap = new Bitmap[number]; for (int i = 0; i < number; i++) { Log.d("", "测试第" + (i + 1) + "张图片"); bitmap[i] = BitmapFactory.decodeResource(getResources(), R.drawable.begin_background); } } /** * Drawable的使用 */ private void testDrawable() { array = new BitmapDrawable[number]; for (int i = 0; i < number; i++) { Log.w("", "测试第" + (i + 1) + "张图片"); array[i] = getResources().getDrawable(R.drawable.begin_background); } } }
首先贴出 Drawable的使用 的运行结果:(顺利测试完1000张图片)
BitmapFactory类的decodeResource方法运行结果:(居然只有11张)
运行优化后的BitmapFactory类的decodeResource方法:(优化后可达到46张,且opts.inSampleSize = n;N的参数设置得越大可达到的数量越多,但损失了图片质量)
BitmapFactory类的decodeStream方法:(可达22张图片)
这下,相信大家对Android中与图片相关的这几种方法的性能有直观的认识了吧。其实,在测试时除了看到数量外,还可以看到运行时间上的差距。
Android 内存溢出管理与测试,布布扣,bubuko.com
原文:http://www.cnblogs.com/scetopcsa/p/3866322.html