关于android 使用bitmap的OOM心得和解决方式

最新推荐文章于 2023-07-20 08:15:00 发布
最新推荐文章于 2023-07-20 08:15:00 发布
阅读量220 收藏
点赞数
文章标签： 移动开发 java

android开发，从2010年開始学习到如今的独立完毕一个app，这漫长的四年，已经经历了非常多次bug的折磨。无数次的加班训练。然而，自以为自己已经比較了解android了，却近期在一个项目上。由于oom而折腾了一个周，回到原地。认识了自己的不足，感觉自己是如此的菜鸟呀。

好了，不废话，大家在使用开发android的时候，非常少会注意或者意识到释放内存的重要性。由于大家在使用过程中，涉及的图片资源不多，或者比較稳定，来回切换界面，图片也就那么几张或者使用的都是非常小的图片，根本不会感觉到图片占用内存可能引发的潜在危机。

假设你的程序中，使用了一下功能，你作为一个合格的android开发project师，你有必要。注意oom的潜在危机
1.界面比較多，而且非常多界面的背景图片不一样；

2.涉及到换肤功能。定义多种皮肤，皮肤的资源不是使用color 而是图片资源；


以上两种情况，假设你不注意合理的释放内存，你将会为自己程序莫名其妙的崩溃付出代价的。

我们在android程序中，不管是使用layout布局设置了背景还是使用了setBackgroundResource 设置背景。你都以为不须要释放内存？这绝对是一个错误的观念，绝对的错误。或许这一点的错误的认识，将会在大屏幕手机上。暴露出来你的oom的现象。特别是在三星的大屏幕手机。爆oom的几率更大。

或许。大家在使用开发中。会注意这一点，使用了一下方式去解决释放内存（网上非常多样例都是使用该方式去释放内存），比方：

		View view = findViewById(R.id.page_bg);
		BitmapDrawable bitmapDrawable = (BitmapDrawable) view.getBackground();
		view.setBackgroundResource(0);
		bitmapDrawable.setCallback(null);
		Bitmap bitmap = bitmapDrawable.getBitmap();
		if(bitmap != null && !bitmap.isRecycled()){
			bitmap.recycle();
			bitmap = null;
		}
		System.gc();

从我们的測试效果来看看logcat 打印出来的结果

05-07 06:55:39.330: D/dalvikvm(6988): GC_FOR_ALLOC freed 4091K, 31% free 9715K/13936K, paused 44ms, total 45ms
05-07 06:55:39.340: I/dalvikvm-heap(6988): Grow heap (frag case) to 13.126MB for 3686416-byte allocation
05-07 06:55:39.421: D/dalvikvm(6988): GC_CONCURRENT freed <1K, 5% free 13314K/13936K, paused 6ms+5ms, total 83ms
05-07 06:55:39.600: D/dalvikvm(6988): GC_FOR_ALLOC freed <1K, 5% free 13314K/13936K, paused 44ms, total 44ms
05-07 06:55:39.670: I/dalvikvm-heap(6988): Grow heap (frag case) to 19.377MB for 6554896-byte allocation
05-07 06:55:39.790: D/dalvikvm(6988): GC_CONCURRENT freed 0K, 4% free 19715K/20340K, paused 7ms+20ms, total 114ms
05-07 06:55:40.011: I/System.out(6988): onCreate
05-07 06:55:41.760: D/dalvikvm(6988): GC_EXPLICIT freed 10759K, 56% free 9063K/20340K, paused 4ms+7ms, total 111ms
05-07 06:55:41.821: D/dalvikvm(6988): GC_EXPLICIT freed <1K, 56% free 9062K/20340K, paused 4ms+7ms, total 62ms
05-07 06:55:41.821: I/System.out(6988): onDestroy

从以上logcat中。我们看到了GC_EXPLTCIT 为我们释放了10759k的内存，这个是非常可观的，或许这一刻你会沾沾自喜。会觉得你已经攻克了程序中oom的潜在危机。


然而，实际上，你却引发了另外一个潜在的问题，假设有A和B界面，同一时候使用了一个背景，你在A中释放了，在B中去使用。就会导致了一下error的logcat

05-07 07:00:37.250: D/dalvikvm(6988): GC_EXPLICIT freed 6411K, 81% free 2692K/13936K, paused 4ms+6ms, total 105ms
05-07 07:00:37.310: D/dalvikvm(6988): GC_EXPLICIT freed 88K, 82% free 2604K/13936K, paused 3ms+8ms, total 59ms
05-07 07:00:37.310: I/System.out(6988): onDestroy
05-07 07:00:37.891: D/AndroidRuntime(6988): Shutting down VM
05-07 07:00:37.891: W/dalvikvm(6988): threadid=1: thread exiting with uncaught exception (group=0x40a71930)
05-07 07:00:37.991: E/AndroidRuntime(6988): FATAL EXCEPTION: main
05-07 07:00:37.991: E/AndroidRuntime(6988): java.lang.RuntimeException: Canvas: trying to use a recycled bitmap android.graphics.Bitmap@417fc280
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.graphics.Canvas.throwIfRecycled(Canvas.java:1026)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.graphics.Canvas.drawBitmap(Canvas.java:1127)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.graphics.drawable.BitmapDrawable.draw(BitmapDrawable.java:393)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.View.draw(View.java:13697)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.View.draw(View.java:13596)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewGroup.drawChild(ViewGroup.java:2928)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:2797)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.View.draw(View.java:13594)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewGroup.drawChild(ViewGroup.java:2928)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:2797)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.View.draw(View.java:13594)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewGroup.drawChild(ViewGroup.java:2928)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewGroup.dispatchDraw(ViewGroup.java:2797)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.View.draw(View.java:13715)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.widget.FrameLayout.draw(FrameLayout.java:467)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at com.android.internal.policy.impl.PhoneWindow$DecorView.draw(PhoneWindow.java:2211)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewRootImpl.drawSoftware(ViewRootImpl.java:2281)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewRootImpl.draw(ViewRootImpl.java:2177)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewRootImpl.performDraw(ViewRootImpl.java:2045)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewRootImpl.performTraversals(ViewRootImpl.java:1854)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewRootImpl.doTraversal(ViewRootImpl.java:989)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.ViewRootImpl$TraversalRunnable.run(ViewRootImpl.java:4351)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.Choreographer$CallbackRecord.run(Choreographer.java:749)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.Choreographer.doCallbacks(Choreographer.java:562)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.Choreographer.doFrame(Choreographer.java:532)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.view.Choreographer$FrameDisplayEventReceiver.run(Choreographer.java:735)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.os.Handler.handleCallback(Handler.java:725)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.os.Handler.dispatchMessage(Handler.java:92)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.os.Looper.loop(Looper.java:137)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at android.app.ActivityThread.main(ActivityThread.java:5041)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at java.lang.reflect.Method.invokeNative(Native Method)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at java.lang.reflect.Method.invoke(Method.java:511)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:793)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:560)
05-07 07:00:37.991: E/AndroidRuntime(6988): 	at dalvik.system.NativeStart.main(Native Method)


感觉非常奇怪把。由于你在这句logcat中，根本找不到错误的地方和为什么发生这种错误，可是这个错误却是致命的。

从英文的字面意思理解：你使用了一个已经释放的Bitmap来绘制你的界面。

遇到这种情况，或许40%的android程序猿都不知所错，由于我们依据无法把握出错的地方，或许你觉得你是依照Activity的生命周期来做填充背景和释放背景，却出现这种错误。

网上的资料解释。你能理解，却还是无法找到详细的问题所在。

我经历过这个问题的痛苦，看了网上的解释和解决的方法，根本就找不到靠谱的。我对待这个问题。始终不放弃，经过了多次的測试和验证，该问题出现的地点是有一下两种可能性：
情况1、 你A界面中使用了a.png图片，然后做了跳转。finish了A界面，finish的时候，你使用了一下的代码释放了内存：

		View view = findViewById(R.id.page_bg);
		BitmapDrawable bitmapDrawable = (BitmapDrawable) view.getBackground();
		view.setBackgroundResource(0);
		bitmapDrawable.setCallback(null);
		Bitmap bitmap = bitmapDrawable.getBitmap();
		if(bitmap != null && !bitmap.isRecycled()){
			bitmap.recycle();
			bitmap = null;
		}
		System.gc();

然后再次进入A界面。极有可能出现该问题。



情况2、 你在A界面使用了a.png图片。然后在B界面也使用了a.png， A界面没有finish。B界面使用了finsh，而且使用上面相同的方式释放了内存。然后我们正常情况下。A界面会经历onResume的方式来显示，但是这个时候。我们的a.png在内存中已经释放了，所以就会引发上面的

05-07 07:00:37.991: E/AndroidRuntime(6988): java.lang.RuntimeException: Canvas: trying to use a recycled bitmap android.graphics.Bitmap@417fc280

看着字面非常简单。非常easy理解，实际中找到问题的所在却不是easy的一件事。


或许，你在这一刻是否已经抓狂了。难道就没办法来释放内存来解决潜在的oom问题？
答案是否。像google这种大公司。他们提供的api。考虑的潜在问题比我们正常程序猿考虑的还要深入N倍。

个人从新阅读了相关的api，得出了一下解决的方法来释放内存。解除我们潜在的oom情况

不管你是在xml中布局使用了：

android:background  。

还是在java代码中调用了：

setBackground(background);

setBackgroundDrawable(background)

setBackgroundResource(resid)

 的方式去设置了背景图片.

使用的时候。请调用一下相应的方法：
setBackgroundResource和android:background →setBackgroundResource(0);

setBackgroundDrawable(background)→ setBackgroundDrawable(null)

setBackground(background) → setBackground(null)  


然后再onDestory中调用System.gc();
以上的代码，我们改动为：

		
		View view = findViewById(R.id.page_bg);
		view.setBackgroundResource(0);
		System.gc();


我们在看看我们的logcat的结果： 

05-07 07:29:18.941: D/dalvikvm(7598): GC_FOR_ALLOC freed 27K, 65% free 9791K/27452K, paused 43ms, total 58ms
05-07 07:29:18.970: I/dalvikvm-heap(7598): Grow heap (frag case) to 13.203MB for 3686416-byte allocation
05-07 07:29:19.041: D/dalvikvm(7598): GC_FOR_ALLOC freed 83K, 52% free 13308K/27452K, paused 72ms, total 72ms
05-07 07:29:19.140: D/dalvikvm(7598): GC_CONCURRENT freed <1K, 52% free 13308K/27452K, paused 4ms+29ms, total 105ms
05-07 07:29:19.240: D/dalvikvm(7598): GC_FOR_ALLOC freed <1K, 52% free 13307K/27452K, paused 40ms, total 40ms
05-07 07:29:19.310: I/dalvikvm-heap(7598): Grow heap (frag case) to 19.373MB for 6554896-byte allocation
05-07 07:29:19.420: D/dalvikvm(7598): GC_CONCURRENT freed 0K, 29% free 19709K/27452K, paused 4ms+31ms, total 106ms
05-07 07:29:19.590: I/System.out(7598): onCreate
05-07 07:29:21.290: D/dalvikvm(7598): GC_EXPLICIT freed 10749K, 56% free 9064K/20340K, paused 3ms+8ms, total 125ms
05-07 07:29:21.290: I/System.out(7598): onDestroy
以上的界面和我们调用了手动释放的方式是不是一样？ 呵呵。重复測试多次，看看还会不会导致java.lang.RuntimeException: Canvas: trying to use a recycled bitmap

实际上，我们的程序不会再出现上面的问题了。而且攻克了oom得潜在危机。

如此的简单，如此的便捷。


同理：假设我们在程序中。使用了ImageView的话， 我们也能够使用
imageView.setImageResource(0);  这样的方式，来释放我们设置的android:src或者bitmap等等。


那么，关于图片的oom可能潜在的问题，我们告一段落，从这次的经历。让我更加的深入的了解java语言的内存回收机制，总结一句话：尽可能的让系统去释放内存。我们仅仅负责标示须要释放的内存。通俗点：我们仅仅是标记须要杀的人，谁来杀，就让杀手看着办。


作者：SpringSky 
出处：http://blog.csdn.net/springsky_/article/details/25212419
blog：http://blog.csdn.net/springsky_
本文版权归作者和CSDN共同拥有，欢迎转载，但未经作者允许必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。



Github TOP100 Android开源，android开发环境搭建实验报心得
m0_64603929的博客
12-05 505
作者同类文章X 排名完全是根据 GitHub 搜索 Java 语言选择 (Best Match) 得到的结果, 然后过滤了跟 Android 不相关的项目, 所以排名并不具备任何官方效力, 仅供参考学习, 方便初学者快速了解当前一些流行的 Android 开源库。 | 项目名称 | 项目简介 | | — | — | | 1. react-native | 这个是 Facebook 在 React.js Conf 2015 大会上推出的基于 JavaScript 的开源框架 React Native
android图片存储优化的心得
平
05-13 398
在android开发过程中图片的存储优化是非常常见，处理不好，时常会造成图片OOM。接下来分享一下我在开发过程中做的相应的处理，仅供各位参考，如有不足还请多多指教。 首先我们知道图片在app存在形式无非就是：file、stream流、bitmap！ 一、接下来列出几个图片OOM的出现情况 1、在一个页面中一次性加载过多的图片 2、加载的图片过大 ...
处理android bitmap oom
05-05
安卓在加载大图的时候经常会出现oom的错误,给大家分享我的一些处理经验。 这个是优化后的版本。
关于android 使用bitmap的OOM心得和解决方案
spring sky
05-07 1万+
android开发，从2010年开始学习到现在的独立完成一个app，这漫长的四年，已经经历了很多次bug的折磨，无数次的加班训练。然而，自以为自己已经比较了解android了，却最近在一个项目上，因为oom而折腾了一个周，回到原地，认识了自己的不足，感觉自己是如此的菜鸟呀。 好了，不废话，大家在使用开发android的时候，很少会注意或者意识到释放内存的重要性，因为大家在使用过程中，涉及的图片资
Android加载大图Bitmap发生OOM（Out Of Memmory Error）解决方案
Zhang Phil
08-31 3374
Android加载大图Bitmap发生OOM（Out Of Memmory Error）解决方案 Android的内存管理机制对Bitmap比较敏感，并且Android对Bitmap的操作是基于native方法，当在应用中加载过大的Bitmap时候，很容易造成Android OOM(Out Of Memmory) Error，进而导致整个APP崩溃，调试还十分困难。 A
android Bitmap和OOM
jyygn163的专栏
01-03 281
Bitmap OOM Sample: Bitmap mB=null,mB2,mB3; @Override public void onBackPressed() { for (int i = 0; i &lt;20 ; i++) { mB=BitmapFactory.decodeResource(getResources(), R.drawable.cloud...
android 解决bitmap造成的OOM问题
hahahacff的专栏
11-18 1838
前一段时间由于项目中图片过多经常造成内存溢出的问题，现在已经解决。 1通过强引用和弱引用以及LRU算法。 private static final int HARD_CACHE_CAPACITY = 20;//强引用的bitmap的数量 //为了提高图片的利用率，通过单链表实现先进先出，将老的图片移到软引用里面保存 private static LinkedHashMap sHardBit
深入Android开发全方位指南.docx
最新发布
03-04
- **缓存机制**：合理设置 Bitmap 缓存策略，避免 OOM 错误。 #### 三、实际项目经验解析 ##### 3.1 项目背景与需求分析 在实际项目中，首先要对项目的背景有一个清晰的认识，这包括但不限于： - **市场定位**：...
2020Android面试心得，已拿到offer，腾讯T4架构师
m0_69438973的博客
04-11 224
写在前面 1月初失业，找了近2个多月的工作了，还没找到心仪的工作，感觉心好慌，不知道该怎么办了？找不到工作的时候压力很大，有人说自信会很受打击，还有人说会很绝望，是人生的低谷……尽管很多时候我们自己知道，我不是找不到工作，只是找不到理想中的好工作。但这也不能改变你的空白期正在一天一天变长，不妥协的那份坚定正在一天一天动摇的事实。 朋友推荐给我这份文档，狂刷五遍之后，最近刚刚获得字节跳动等多家公司的offer，今天将这份文档分享给大家，希望正在找工作或准备找工作的朋友都可以获得自己心仪公司的offer。 七、
加载Bitmap对象时出现OutOfMemory
zkw12358的专栏
06-18 1503
最近简单做了一个自定义相机，拍拍照后将
android bitmap oom 最新处理办法,[Android] Bitmap OOM解决办法一
weixin_31907307的博客
05-25 584
尽量不要使用setImageBitmap或setImageResource或BitmapFactory.decodeResource来设置一张大图，因为这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存。因此，改用先通过BitmapFactory.decodeStream方法，创建出一个bitmap，再将其设为ImageView的 source...
Android 之 Bitmap 引起的 OOM 问题
leyang0910的博客
07-20 236
(内存溢出)，我们都知道Android系统会为每个APP分配一个独立的工作空间， 或者说分配一个单独的Dalvik虚拟机，这样每个APP都可以独立运行而不相互影响！而Android对于每个 Dalvik虚拟机都会有一个最大内存限制，如果当前占用的内存加上我们申请的内存资源超过了这个限制 ，系统就会抛出OOM错误！另外，这里别和RAM混淆了，即时当前RAM中剩余的内存有1G多，但是OOM还是会发生！别把RAM(物理内存)和OOM扯到一起！另外RAM不足的话，就是杀应用了，而不是仅仅是OOM了！
[Android] Bitmap OOM解决办法
weixin_30381793的博客
04-06 162
在最近做的工程中发现加载的图片太多或图片过大时经常出现OOM问题，找网上资料也提供了很多方法，但自己感觉有点乱，特此，今天在不同型号的三款安卓手机上做了测试，因为有效果也有结果，今天小马就做个详细的总结，以供朋友们共同交流学习，也供自己以后在解决OOM问题上有所提高，提前讲下，片幅有点长，涉及的东西太多，大家耐心看，肯定有收获的，里面的很多东西小马也是学习参考网络资料使用的，先来简单讲下下： ...
android使用bitmap的OOM心得
wdly16526853的专栏
05-07 362
android使用bitmap的OOM心得 　　android开发，从2010年开始学习到现在的独立完成一个app，这漫长的四年，已经经历了很多次bug的折磨，无数次的加班训练。然而，自以为自己已经比较了解android了，却最近在一个项目上，因为oom而折腾了一个周，回到原地，认识了自己的不足，感觉自己是如此的菜鸟呀。 　　好了，不废话，大家在使用开发android的时候，很少会注意
android bitmap oom 最新处理办法,【移动开发】Android中图片过大造成内存溢出，OOM（OutOfMemory）异常解决方法...
weixin_30068505的博客
05-25 460
当我们在做项目过程中，一遇到显示图片时，就要考虑图片的大小，所占内存的大小，原因就是Android分配给Bitmap的大小只有8M,试想想我们用手机拍照，普通的一张照片不也得1M以上，所以android处理图片时不得不考虑图片过大造成的内存异常。那时候只是简单地缓存图片到本地 然后将图片进行压缩，但是感觉这个问题没有很好的解决办法，只是减小了发生的几率这里，我将前辈们解决的方法重新整理一番,方便自...
关于android中bitmap使用时的oom的一些解决方法
zzh1026的博客
08-12 651
背景:这些天弄一个关于relativelayout中设置高斯模糊图片的事情,需求是从网络上获取到该背景图片.图片过大做完后感觉还行,但是测试的时候发现背景多加载几次就会oom,通过as上的memory可以看到每次加载内存都会增加,但是却不会减少,通过查了一些资料发现以下一些结论:在Android应用里，最耗费内存的就是图片资源。而且在Android系统中，读取位图Bitmap时，分给虚拟机中的图片的
Android问题—Bitmap引起的OOM问题的解决办法
此博客已停用，博文会逐渐转移到新地址，http://blog.csdn.net/liupeifeng3514
04-12 7273
1.什么是OOM？为什么会引起OOM？ 答：Out Of Memory(内存溢出)，我们都知道Android系统会为每个APP分配一个独立的工作空间， 或者说分配一个单独的Dalvik虚拟机，这样每个APP都可以独立运行而不相互影响！而Android对于每个 Dalvik虚拟机都会有一个最大内存限制，如果当前占用的内存加上我们申请的内存资源超过了这个限制 ，系统就会抛出OOM错误！另外，这里
Android开发中解析、创建Bitmap对象时OOM的有效解决方法并附上一些干货
热门推荐
活在当下！输出快乐！
06-01 1万+
先来点鸡汤： Stay hungry，stay foolish 这句话的的解读：我们必须了解自己的渺小。如果我们不学习，科技发展的速度会让我们五年后被清空。所以，我们必须用初学者谦虚的自觉，饥饿者渴望的求知态度，来拥抱未来的知识。 这几天做的项目中需要从图库选择图片或者拍照生成图片，然后展现在IamgeView控件上。当然，从图库选择图片和拍照选择图片的功能实现起来很简单。直接写上代码： Cha
Android优化：避免Bitmap内存泄漏与OOM解决策略
"Android应用程序开发过程中，Bitmap对象的不当使用可能导致严重的内存问题，尤其是当处理大量或高分辨率图片时，可能会触发OutofMemory (OOM)异常。本文关注于Bitmap使用后未调用`recycle()`这一常见问题及其解决...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值