大部分android开发者只知道bitmap再使用之后,需要显式的调用一次bitmap.recycle,回收bitmap内存;

这个观点,在android3.0之后其实已经过时了,android3.0将bitmap所引用的位图资源从native heap移到虚拟机的heap空间,bitmap的生命周期由虚拟机管理,开发者只需要保证在应用中不在持有对bitmap的引用,即可保证不发生内存泄漏;位图资源的内存由GC进行回收;
将bitmap的位图内存转移到虚拟机heap后,由于位图资源本身较大,造成gc的概率的增加

bitmap proxy

在一般的应用场景中,bitmap的引用一般是和imageview关联;当大量imageview持有对bitmap的引用时,虚拟机无法释放bitmap的内存,导致oom;

针对这种场景,开发者可以实现一个bitmap的代理类,作为bitmap和imageview的中间层,在imageview不可见时(例如imageview是一个listview的子控件,listview发生滚动/activiy切换到后台),即释放掉对bitamp的引用;当imageview重新可见时,通过代理类重新去加载bitmap,以解耦bitmap和iamgeview的引用关系;

inBitmap

android在3.0之后新增了一个BitmapFactory.Options.inBitmap开关,加了这个开关之后,bitmapfactory在加载位图时候,会尝试使用inbitmap指向的已分配在heap中位图空间;而不是重新申请一块内存;从而减少了虚拟机最讨厌的短生命周期大内存对象; 不过这个开关有严格的使用场景,即两个bitamp的位图大小必须一致

Comments