Android系统中Bitmap是否有调用bitmap recycle时机方法的必要性

只需一步,快速开始
只需一步, 快速开始
后使用快捷导航没有帐号?
查看: 194145|回复: 12
积分威望金钱
Bit调用recycle? WhenBitmap有一个recycle方法,意思很简单,回收Bitmap的空间。
Q 1: Bitmap是否有调用recycle方法的必要性?A: 嵌入式系统总是格外注重空间的问题,不小心的话就会有OOM。但是应用层使用的平台有其天然的优势【java语言有自己的垃圾回收,android平台上各个application有自己的process自己的空间】。无需调用bitmap的理由有:a. 垃圾回收会处理的;b. 当application关闭,process被杀掉,所有这个process占用的空间自然回归系统;
但是,如果你有点洁癖,或者有点理想主义,或者很有控制欲,或者很闲。。。bitmap的recycle函数的调用还是可以是有必要的,理由有:a. 垃圾回收虽然好使,但是有可能的话,我们还是让它少干点活吧。垃圾回收有很大的未来不确定性,会加重未来未知时间点的loading,若有大量bitmap需要垃圾回收处理,那必然垃圾回收需要做的次数就更多也发生地更频繁,小心会造成ANR。但是,若是自己recycle,就可以可控制地分散处理了这些回收任务了。b. 若是launcher那样一直运行的application,它的process一直存在,memory问题还是多多注意下比较好。
Q2: When?A: Timing的问题在这里很重要。早了就大事不好了,会有这样的Exception:java.lang.RuntimeException,Canvas: trying to use a recycled bitmapandroid.graphics.Bitmap@44ebeee0,Canvas.java,955So, 怎样才可以保证不会早了呢?关于图片显示,重要的时间点:step1: 设置进去的时间点;Step2: 画面画出来的时间点;最保险最笨的做法,在新的图片设置进去以后再recycle掉老的图片,这样做的坏处在于,在某个时间段,你需要的空间是double的【新旧两套都在】;如果你不偏向于那么做,又有时间,可以考虑后面一个时间点,除了setImage以及其它代码中显示调用那个bitmap的时候我们会检查bitmap,在acticvity变为visible的时候系统还是会去找之前设置进去的bitmap【即使你的onResume方法里面并没有提到去refresh UI,这件事情它也是会去做的,大概不然它就不知道这次该显示些什么了】。所以,在UI线程里面,在一个不可能被打断的方法里面,是先设置新的bitmap还是先recycle旧的图片是没有影响的。譬如说& &&&mBitmap.recycle();mBitmap = …..& &//设置mImageView.setImage(mBitmap);这样的代码是完全可以的。
后面这样的做法,最重要的就是确保:在UI线程【因为设置UI显示只能在UI主线程里】里面一个不可能被打断的方法里面。这个是为了确保在两者之间UI主线程不可能被打断,不可能刚好从invisible变成visible。所以,特别小心两种东西:1. 多线程【个人觉得最好不要在其他线程里面调用UI用过的bitmap的recycle方法,多线程之间是很难保证时间顺序的,暂时没有想出一种在background thread里面recycle的合理的方式】;2. 非及时发生的方法:譬如,发intent啊,发notify啊去通知UI主线程去做UI重新刷新并不能替代mImageView.setImage(mBitmap);这样的句子。完全有可能,你确实发了intent出去了,但是目标activity之一还没有做UI重新设置【Q: maybe没收到 or 收到但还是等待处理,不确定这两种可能是不是都有可能】,这个时候这个acitivity变成visible了,系统仍然试图找旧的图片,找不到了就会报exception了。
PS: java.lang.RuntimeException,Canvas: trying to use a recycled bitmap android.graphics.Bitmap@44ebeee0,Canvas.java,955 这样的exception可能也许你并不能够看到,默认的log里面好像只能看到uncaught exception,第一次看到是在monkey的events.log里面,若你知道怎么打开相应手机这方面的log trace应该也是可以看到的。
今天,我又来了
积分威望金钱
我也是坐沙发的
积分威望金钱
介是神马?!!
积分威望金钱
高级会员, 积分 1641, 距离下一级还需 1359 积分
高级会员, 积分 1641, 距离下一级还需 1359 积分
积分威望金钱
高级会员, 积分 2217, 距离下一级还需 783 积分
高级会员, 积分 2217, 距离下一级还需 783 积分
支持你哈...................................
积分威望金钱
高级会员, 积分 1809, 距离下一级还需 1191 积分
高级会员, 积分 1809, 距离下一级还需 1191 积分
我是个凑数的。。。
积分威望金钱
高级会员, 积分 1759, 距离下一级还需 1241 积分
高级会员, 积分 1759, 距离下一级还需 1241 积分
积分威望金钱
高级会员, 积分 1428, 距离下一级还需 1572 积分
高级会员, 积分 1428, 距离下一级还需 1572 积分
高手云集 果断围观
积分威望金钱
支持,赞一个
积分威望金钱
高级会员, 积分 2847, 距离下一级还需 153 积分
高级会员, 积分 2847, 距离下一级还需 153 积分
我也是坐沙发的
社区QQ达人
使用QQ帐号登录论坛的用户
经常参与各类话题的讨论,发帖内容较有主见
长期对论坛的繁荣而不断努力,或多次提出建设性意见
活跃且尽责职守的版主
曾经为论坛做出突出贡献目前已离职的版主
为论坛做出突出贡献的会员
经常帮助其他会员答疑
积极宣传本站,为本站带来更多注册会员
积极宣传本站,为本站带来更多的用户访问量
Powered byBitmap调用recycle? When?
Bitmap有一个recycle方法,意思非常easy,回收Bitmap的空间。
Q 1: Bitmap是否有调用recycle方法的必要性?
A: 嵌入式系统总是格外注重空间的问题,不小心的话就会有OOM。可是应用层使用java的android平台有其天然的优势【java语言有自己的垃圾回收,android平台上各个application有自己的process自己的空间】。
&&& 无需调用bitmap的理由有:
&&& a. 垃圾回收会处理的;
&&& b. 当application关闭,process被杀掉,全部这个process占用的空间自然回归系统;
&&& 可是,假设你有点洁癖,或者有点理想主义,或者非常有控制欲,或者非常闲。。。bitmap的recycle函数的调用还是能够是有必要的,理由有:
&&& a. 垃圾回收尽管好使,可是有可能的话,我们还是让它少干点活吧。垃圾回收有非常大的未来不确定性,会加重未来未知时间点的loading,若有大量bitmap须要垃圾回收处理,那必定垃圾回收须要做的次数就很多其它也发生地更频繁,小心会造成ANR。可是,若是自己recycle,就能够可控制地分散处理了这些回收任务了。
&&& b. 若是launcher那样一直执行的application,它的process一直存在,memory问题还是多多注意下比較好。
A: Timing的问题在这里非常重要。早了就大事不好了,会有这种Exception:
&&& java.lang.RuntimeException,Canvas: trying to use a recycled bitmap
android.graphics.Bitmap@44ebeee0,Canvas.java,955
&&& So, 如何才干够保证不会早了呢?
&&& 关于图片显示,重要的时间点:
&&& step1: 设置进去的时间点;
&&& Step2: 画面画出来的时间点;
&&& 最保险最笨的做法,在新的图片设置进去以后再recycle掉老的图片,这样做的坏处在于,在某个时间段,你须要的空间是double的【新旧两套都在】;
&&& 假设你不偏向于那么做,又有时间,能够考虑后面一个时间点,除了setImage以及其他代码中显示调用那个bitmap的时候我们会检查bitmap,在acticvity变为visible的时候系统还是会去找之前设置进去的bitmap【即使你的onResume方法里面并没有提到去refresh UI,这件事情它也是会去做的,大概不然它就不知道这次该显示些什么了】。所以,在UI线程里面,在一个不可能被打断的方法里面,是先设置新的bitmap还是先recycle旧的图片是没有影响的。
&&& 譬如说&&&& mBitmap.recycle();
&&&&&&&&&&&&&&&&&
mBitmap = .....&& //设置
&&&&&&&&&&&&&&&&& mImageView.setImage(mBitmap);
&&& 这种代码是全然能够的。
&&& 后面这种做法,最重要的就是确保:在UI线程【由于设置UI显示仅仅能在UI主线程里】里面一个不可能被打断的方法里面。这个是为了确保在两者之间UI主线程不可能被打断,不可能刚好从invisible变成visible。
&&& 所以,特别小心两种东西:
&&& 1. 多线程【个人认为最好不要在其它线程里面调用UI用过的bitmap的recycle方法,多线程之间是非常难保证时间顺序的,临时没有想出一种在background thread里面recycle的合理的方式】;
&&& 2. 非及时发生的方法:譬如,发intent啊,发notify啊去通知UI主线程去做UI又一次刷新并不能替代mImageView.setImage(mBitmap);这种句子。全然有可能,你确实发了intent出去了,可是目标activity之中的一个还没有做UI又一次设置【Q: maybe没收到 or 收到但还是等待处理,不确定这两种可能是不是都有可能】,这个时候这个acitivity变成visible了,系统仍然试图找旧的图片,找不到了就会报exception了。
java.lang.RuntimeException,Canvas: trying to use a recycled bitmap android.graphics.Bitmap@44ebeee0,Canvas.java,955 这种exception可能或许你并不可以看到,默认的log里面好像仅仅能看到uncaught exception,第一次看到是在monkey的events.log里面,若你知道怎么打开对应手机这方面的log trace应该也是可以看到的。
阅读(...) 评论()}

我要回帖

更多关于 bitmap recycle 无效 的文章

更多推荐

版权声明:文章内容来源于网络,版权归原作者所有,如有侵权请点击这里与我们联系,我们将及时删除。

点击添加站长微信