读取图片 优化android内存
来源:互联网 发布:sql select 创建表 编辑:程序博客网 时间:2024/05/21 15:05
public classMain extendsActivity
{
}
输出结果:
04-07 21:49:25.248: D/szipinf(7828): Initializing inflate state
04-07 21:49:25.398: E/(7828):测试第1张图片
04-07 21:49:25.658: D/dalvikvm(7828): GC_EXTERNAL_ALLOC freed 48K, 50% free 2692K/5379K, external 0K/0K, paused 24ms
04-07 21:49:25.748: E/(7828):测试第2张图片
04-07 21:49:25.748: E/(7828):测试第3张图片
………………
………………
04-07 21:49:26.089: E/(7828): 测试第998张图片
04-07 21:49:26.089: E/(7828): 测试第999张图片
04-07 21:49:26.089: E/(7828): 测试第1000张图片
程序没有报错,正常运行,加载1000个Drawable对象没问题。
下面再来看一下加载1000个Bitmap对象的代码,同样的,代码很简单的,我就不解释了!
public classMain extendsActivity
{
}
输出结果:
04-07 22:06:05.344: D/szipinf(7937): Initializing inflate state
04-07 22:06:05.374: E/(7937):测试第1张图片
04-07 22:06:05.544: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed 51K, 50% free 2692K/5379K, external 0K/0K, paused 40ms
04-07 22:06:05.664: E/(7937):测试第2张图片
04-07 22:06:05.774: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed 1K, 50% free 2691K/5379K, external 6026K/7525K, paused 31ms
04-07 22:06:05.834: E/(7937):测试第3张图片
04-07 22:06:05.934: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 12052K/14100K, paused 24ms
04-07 22:06:06.004: E/(7937):测试第4张图片
04-07 22:06:06.124: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 18078K/20126K, paused 27ms
04-07 22:06:06.204: E/(7937):测试第5张图片
04-07 22:06:06.315: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 24104K/26152K, paused 26ms
04-07 22:06:06.395: E/(7937):测试第6张图片
04-07 22:06:06.495: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 30130K/32178K, paused 22ms
04-07 22:06:06.565: E/(7937):测试第7张图片
04-07 22:06:06.665: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed <1K, 50% free 2691K/5379K, external 36156K/38204K, paused 22ms
04-07 22:06:06.745: E/(7937):测试第8张图片
04-07 22:06:06.845: D/dalvikvm(7937): GC_EXTERNAL_ALLOC freed 2K, 51% free 2689K/5379K, external 42182K/44230K, paused 23ms
04-07 22:06:06.845: E/dalvikvm-heap(7937): 6170724-byte external allocation too large for this process.
04-07 22:06:06.885: I/dalvikvm-heap(7937): Clamp target GC heap from 48.239MB to 48.000MB
04-07 22:06:06.885: E/GraphicsJNI(7937): VM won't let us allocate 6170724 bytes
04-07 22:06:06.885: D/dalvikvm(7937): GC_FOR_MALLOC freed <1K, 51% free 2689K/5379K, external 42182K/44230K, paused 25ms
04-07 22:06:06.885: D/AndroidRuntime(7937): Shutting down VM
04-07 22:06:06.885: W/dalvikvm(7937): threadid=1: thread exiting with uncaught exception (group=0x40015560)
04-07 22:06:06.885: E/AndroidRuntime(7937): FATAL EXCEPTION: main
04-07 22:06:06.885: E/AndroidRuntime(7937): java.lang.OutOfMemoryError: bitmap size exceeds VM budget
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
04-07 22:06:06.885: E/AndroidRuntime(7937):
看看上面的输出,才加载到第8张图片,程序就报错了“java.lang.OutOfMemoryError: bitmap size exceeds VM budget”。
通过上面的例子,可以看清楚地看出来,使用Drawable保存图片对象,占用更小的内存空间。
而使用Biamtp对象,则会占用很大内存空间,很容易就出现OOM了!
下面我们再来看一个例子,这个也是加载Bitmap对象。
只不过,之次不是使用BitmapFactory的decodeResource方法,
而是使用decodeStream方法,看代码。
publicclass Mainextends Activity
{
}
输出结果:
04-07 22:16:12.676: E/(8091):测试第561张图片
04-07 22:16:12.756: E/(8091):测试第562张图片
04-07 22:16:12.826: E/(8091):测试第563张图片
04-07 22:16:12.906: E/(8091):测试第564张图片
04-07 22:16:12.906: D/skia(8091): ---------- mmap failed for imageref_ashmem size=2744320 err=12
04-07 22:16:12.906: E/(8091):测试第565张图片
04-07 22:16:12.906: D/skia(8091): ---------- mmap failed for imageref_ashmem size=2744320 err=12
04-07 22:16:12.906: E/(8091):测试第566张图片
04-07 22:16:12.916: E/filemap(8091): mmap(0,416798) failed: Out of memory
04-07 22:16:12.916: D/filemap(8091): munmap(0x0, 0) failed
04-07 22:16:12.916: W/asset(8091): create map from entry failed
04-07 22:16:12.916: D/AndroidRuntime(8091): Shutting down VM
04-07 22:16:12.916: W/dalvikvm(8091): threadid=1: thread exiting with uncaught exception (group=0x40015560)
04-07 22:16:12.936: E/AndroidRuntime(8091): FATAL EXCEPTION: main
04-07 22:16:12.936: E/AndroidRuntime(8091): java.lang.RuntimeException: Unable to start activity ComponentInfo{bassy.test.drawable/bassy.test.drawable.Main}: android.content.res.Resources$NotFoundException: File res/drawable-mdpi/img.png from drawable resource ID #0x7f020001
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091): Caused by: android.content.res.Resources$NotFoundException: File res/drawable-mdpi/img.png from drawable resource ID #0x7f020001
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091): Caused by: java.io.FileNotFoundException: res/drawable-mdpi/img.png
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
04-07 22:16:12.936: E/AndroidRuntime(8091):
从上面可以看出,程序在加载到第566张的时候,就出现了OOM错误。
不过,跟第2个例子比起来,你会发现,程序可以加载更多的图片。
这说明了使用BitmapFactory的decodeResource方法会占据大量内存,
而使用使用decodeStream方法,则占据更小的内存。
从时间上来说,看看日志输出,大概估算了一下加载一张图片所需要的时间,发现,
decodeResource加载图片需要约0.17秒的时间,
而使用decodeStream方法,只需要约0.08秒的时间!
这说明了,decodeStream无论是时间上还是空间上,都比decodeResource方法更优秀!!
从上面三个例子,可以看出,用第一种方法(即用Drawable加载图片)可以加载更加的图片,加载32张图片的时间约为0.01秒!
我试着把Drawable的数量调至1000000,程序在运行时,停在了153761张图片里,手机提示,“应用程序无响应…”
个人猜测,Drawable应该不属于常驻内存的对象,不然的话,不可能不会出现OOM的~~
网上关于Drawable与Bitmap的资料太少,不能深入学习,真是遗憾~
刚才又做了个测试,把第一个例子中的
array[i] = getResources().getDrawable(R.drawable.img);
方法换成了
array[i] = Drawable.createFromStream(getResources().openRawResource(R.drawable.img), null);
结果和第三个例子一样,在第566张图片中,出现了OOM错误!
而且,加载的时间都是一样~~
这样一来,我就更加迷惑了~~
-----------------------------------------------------
getResources().getDrawable(R.drawable.img),R.drawable.img 在生成apk是已经被编译了,所以array[]数组里的元素都对应同一个R.drawable.img,所以不会报OOM,除非你的 R.drawable.img很大,Drawable.createFromStream是新创建一个对象,如果有100个这样的语句就会创建100对象
- 读取图片 优化android内存
- android图片内存优化
- Android图片内存优化
- android图片内存优化
- Android图片内存优化
- Android图片内存优化
- android优化图片内存
- android图片内存优化
- android图片的内存优化
- Android图片的内存优化
- android图片的内存优化
- android图片的内存优化
- android图片的内存优化
- android图片的内存优化
- android图片的内存优化
- android图片的内存优化
- Android图片与内存优化
- Android图片与内存优化
- HQL语句
- 利用黑窗口发送邮件
- 走进WebKit
- 通过代码切换组织
- hdu 3074 Multiply game(线段树模版)
- 读取图片 优化android内存
- hibernate多表关联配置
- DirectBuffer及内存泄漏
- 数位DP+二分搜索——HDU3943 K-th Nya Number
- vpn 服务器linux 客户端windows
- 归并排序 (不采用哨兵) 算法导论2.3-2答案
- 只有apk时robotium测试程序启动相应时间(一)
- Android 9 patch 图片 (.9.png 格式图片) 的特点和制作
- 关于在for循环的switch语句使用break和continue问题