Android-视图显示大量图片时的内存问题
昨天优化一个项目(基本上每个ACTIVITY都会有大量图片),查了很多资料,借鉴了一些做法,网上的说法有对有错,这里总结一下。
android3.0默认heap size为48m,进入ddms,在ddms中“update heap”-“cause gc”,查看应用的内存使用情况,发现每进入一个activity,
1-byte array(byte[], boolean[])的值总是会相应的增加,到最后一个activity的时候啥都不干,heap size已经快30m了。
通过分析,1-byte array就是bitmap的占用空间,这就说明不断有新的bitmap在内存中。由于ui使用了很多图片,比如大背景图,
按钮图片等等,看来是这些图片 都会存在内存中,即使当前activity已经销毁进入下一个activity,前一个activity的图片资源也没有销毁。
其中一个做法是: 用Bitmap bm = BitmapFactory.decodeResource(this.getResources(), R.drawable.splash); BitmapDrawable bd = new BitmapDrawable(this.getResources(), bm); mBtn.setBackgroundDrawable(bd); 来代替mBtn.setBackgroundResource(R.drawable.splash)。
销毁的时候使用: BitmapDrawable bd = (BitmapDrawable)mBtn.getBackground(); mBtn.setBackgroundResource(0);
//别忘了把背景设为null,避免onDraw刷新背景时候出现used a recycled bitmap错误 bd.setCallback(null); bd.getBitmap().recycle();
因为setBackgroundResource时,会缓存图片的CHCHE,以便重绘时加快速度。如果说,每次都使用recycle的话,就达不到这个目的了。
而且根据以往的经验,对于一般应用,根本就没有这个必要,内存过大,势必还有原因造成。 在“update heap”-“cause gc”,
点击1-byte array(byte[], boolean[])行后,在Heap表里,查看图片内存的占用比例直方图,发现一些图片的占用内存居然高达10M(特别是在三星galaxy note运行时),
但项目里最大的原始图片也才1M多,很明显程序的写法有问题。最后,发现,在资源文件里,设置android:background为某些图片时,导致内存大增。
但如果把设置背景的步骤写在JAVA代码里,问题便解决了。 JAVA代码: testview.setBackgroundResource(R.drawable.testview_bg);
//内存还是会增大两三倍 结合上面的另一种作法,改用setBackgroundDrawable,
如: Bitmap bitmap = null;
try { bitmap = BitmapFactory.decodeResource(context.getResources(), res, bfOptions);
} catch (OutOfMemoryError oom) {
android.util.Log.e("getSDCardImageBitmapByUrl", "OutOfMemoryError");
System.gc(); System.runFinalization(); }
finally { }
if (bitmap != null && !bitmap.isRecycled()) {
BitmapDrawable bd = new BitmapDrawable(context.getResources(), bitmap);
v.setBackgroundDrawable(bd); // bitmapCache.put(key, new WeakReference<Bitmap>(bitmap));
drawableCache.put(key, new WeakReference<Drawable>(bd));
} 内存问题解决。
但是,setBackgroundResource和setBackgroundDrawable的差别为什么这么大,待研究。。。
==================================另一篇文章===================================
关于android中使用很多大图片的一些做法
最近在xoom上开发应用,碰到ui设计都是使用图片,而且是多个activity。开始没觉得怎么样,就开始做呗。等做完了,开始在前三个activity运行没问题,一切ok。但在最后一个activity里,会经常出现oom(out of memory),由于在最后一个activity,需要打开一个pdf,然后render,随着multi-touch,reander的pdf页缩放,由于reander的图片本身就比较大(比如,如果pdf放大到当前屏幕的两倍,pdf图片占用的内存为1280*800*4*2/(1024*1024),约等于8m),而且由于为了视觉上感受好,会在其中缓存图片(为了不让用户在使用过程中感受操作有停滞感),所以总是导致oom异常。
oh,my god!最怕碰到这种情况,android对于内存heap size限制让人比较崩溃,ios虽然也号称一个应用有内存限制,但是在实际使用中一个应用使用的内存往往可以超过100m,所以还是挺容易做一个性能满意的应用程序。
我的应用到底哪些地方使用了这么多内存,因为android3.0默认heap size为48m,按道理来说还是可以接受的,怎么应用没跑几下就oom呢?没办法,只能通过ddms来分析,在ddms中“update heap”-》“cause gc”,来查看应用的内存使用情况,发现每进入一个activity,1-byte array(byte[], boolean[])的值总是会相应的增加,到最后一个activity的时候啥都不干,heap size已经快30m了,oh。。。怎么会这样。。。冷静冷静。。。通过分析,1-byte array就是bitmap的占用空间,这就说明不断有新的bitmap在内存中。由于ui使用了很多图片,比如大背景图,按钮图片等等,看来是这些图片都会存在内存中,即使当前activity已经销毁进入下一个activity,前一个activity的图片资源也没有销毁。
原因找到了,但不是太想得通。因为在onCreate中我用mBtn.setBackgroundResource(R.drawable.splash)为控件设置背景图,然后在onDestroy中会用((BitmapDrawable)mBtn.getBackground()).setCallback(null)清理背景图。按道理来说图片资源应该已经清理掉了的。百思不得其解,仔细看Bitmap的源代码,它其实起的作用是销毁java对象BitmapDrawable,而android为了提高效率,Bitmap真正的位图数据是在ndk中用c写的,所以用setCallback是不能销毁位图数据的,应该调用Bitmap的recycle()来清理内存。
所以想当然的在onDestroy加上((BitmapDrawable)mBtn.getBackground()).getBitmap().recycle(),这样跑下来,内存情况很理想,不管在哪个activity中,使用的资源仅仅是当前activity用到的,就不会象之前到最后一个activity的时候,所有之前使用的资源都累积在内存中。在每个activity资源和class等使用的内存都在10m左右,已经很理想了(当然如果是在android低版本比如1.5,16时还是不行的,这得重新构架应用),可以为显示pdf预留了比较多内存了。
但新的问题又出现了,当返回之前的activity时,会出现“try to use a recycled bitmap"的异常。这真是按了葫芦起了瓢啊,内心那个沮丧。。。没办法,继续分析。看来是后加上recycle引起的, 位图肯定在内存中有引用,在返回之前的activity时,因为位图数据其实已经被销毁了,所以才造成目前的情况。在看了setBackgroundResource的源码以后,恍然大悟,android对于直接通过资源id载入的资源其实是做了cache的了,这样下次再需要此资源的时候直接从cache中得到,这也是为效率考虑。但这样做也造成了用过的资源都会在内存中,这样的设计不是很适合使用了很多大图片资源的应用,这样累积下来应用的内存峰值是很高的。看了sdk后,我用:
Bitmap bm = BitmapFactory.decodeResource(this.getResources(), R.drawable.splash);
BitmapDrawable bd = new BitmapDrawable(this.getResources(), bm);
mBtn.setBackgroundDrawable(bd);
来代替mBtn.setBackgroundResource(R.drawable.splash)。
销毁的时候使用:
BitmapDrawable bd = (BitmapDrawable)mBtn.getBackground();
mBtn.setBackgroundResource(0);//别忘了把背景设为null,避免onDraw刷新背景时候出现used a recycled bitmap错误
bd.setCallback(null);
bd.getBitmap().recycle();
这样调整后,避免了在应用里缓存所有的资源,节省了宝贵的内存,而其实这样也不会造成太大效率问题,毕竟重新载入资源是非常快速,不会对性能造成很严重的影响,在xoom里我没有感受到和之前有什么区别。
总之,在android上使用大量位图是个比较痛苦的事,内存限制的存在对应用是个很大的瓶颈。但不用因噎费食,其实弄明白了它里面的机制,应用可以突破这些限制的。这只是其中的一种处理方法,还可以考虑BitmapFactory.Options的inSampleSize来减少内存占用。
==================================另一篇文章===================================
今天做了个内存优化的小测试,包括两点
1, 比较Drawable与Bitmap占用内存大小
2, 比较BitmapFactory类的decodeResource方法与decodeStream方法的效率
好吧,先来看第1个测试!
以下这个是测试加载1000个Drawable对象的代码,很简单的,我就不解释了!
public class Main extends Activity
{
int number = 1000;
Drawable[] array;
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
array = new BitmapDrawable[number];
for(int i = 0; i < number; i++)
{
Log.e("", "测试第" + (i+1) + "张图片");
array[i] = getResources().getDrawable(R.drawable.img);
}
}
}
输出结果:
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 class Main extends Activity
{
int number = 1000;
Bitmap bitmap[];
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
bitmap = new Bitmap[number];
for (int i = 0; i < number; i++)
{
Log.e("", "测试第" + (i+1) + "张图片");
bitmap[i] = BitmapFactory.decodeResource(getResources(), R.drawable.img);
}
}
}
输出结果:
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): at android.graphics.Bitmap.nativeCreate(Native Method)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.graphics.Bitmap.createBitmap(Bitmap.java:477)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.graphics.Bitmap.createBitmap(Bitmap.java:444)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.graphics.Bitmap.createScaledBitmap(Bitmap.java:349)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.graphics.BitmapFactory.finishDecode(BitmapFactory.java:498)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.graphics.BitmapFactory.decodeStream(BitmapFactory.java:473)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.graphics.BitmapFactory.decodeResourceStream(BitmapFactory.java:336)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.graphics.BitmapFactory.decodeResource(BitmapFactory.java:359)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.graphics.BitmapFactory.decodeResource(BitmapFactory.java:385)
04-07 22:06:06.885: E/AndroidRuntime(7937): at bassy.test.drawable.Main.onCreate(Main.java:37)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1722)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1784)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.app.ActivityThread.access$1500(ActivityThread.java:123)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:939)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.os.Handler.dispatchMessage(Handler.java:99)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.os.Looper.loop(Looper.java:130)
04-07 22:06:06.885: E/AndroidRuntime(7937): at android.app.ActivityThread.main(ActivityThread.java:3835)
04-07 22:06:06.885: E/AndroidRuntime(7937): at java.lang.reflect.Method.invokeNative(Native Method)
04-07 22:06:06.885: E/AndroidRuntime(7937): at java.lang.reflect.Method.invoke(Method.java:507)
04-07 22:06:06.885: E/AndroidRuntime(7937): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:847)
04-07 22:06:06.885: E/AndroidRuntime(7937): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:605)
04-07 22:06:06.885: E/AndroidRuntime(7937): at dalvik.system.NativeStart.main(Native Method)
看看上面的输出,才加载到第8张图片,程序就报错了“java.lang.OutOfMemoryError: bitmap size exceeds VM budget”。
通过上面的例子,可以看清楚地看出来,使用Drawable保存图片对象,占用更小的内存空间。
而使用Biamtp对象,则会占用很大内存空间,很容易就出现OOM了!
下面我们再来看一个例子,这个也是加载Bitmap对象。
只不过,之次不是使用BitmapFactory的decodeResource方法,
而是使用decodeStream方法,看代码。
public class Main extends Activity
{
int number = 1000;
Bitmap bitmap[];
@Override
public void onCreate(Bundle savedInstanceState)
{
super.onCreate(savedInstanceState);
setContentView(R.layout.main);
bitmap = new Bitmap[number];
for (int i = 0; i < number; i++)
{
Log.e("", "测试第" + (i+1) + "张图片");
bitmap[i] =BitmapFactory.decodeStream(getResources().openRawResource(R.drawable.img));//这里换了方法
}
}
}
输出结果:
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): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1768)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.app.ActivityThread.handleLaunchActivity(ActivityThread.java:1784)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.app.ActivityThread.access$1500(ActivityThread.java:123)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.app.ActivityThread$H.handleMessage(ActivityThread.java:939)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.os.Handler.dispatchMessage(Handler.java:99)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.os.Looper.loop(Looper.java:130)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.app.ActivityThread.main(ActivityThread.java:3835)
04-07 22:16:12.936: E/AndroidRuntime(8091): at java.lang.reflect.Method.invokeNative(Native Method)
04-07 22:16:12.936: E/AndroidRuntime(8091): at java.lang.reflect.Method.invoke(Method.java:507)
04-07 22:16:12.936: E/AndroidRuntime(8091): at com.android.internal.os.ZygoteInit$MethodAndArgsCaller.run(ZygoteInit.java:847)
04-07 22:16:12.936: E/AndroidRuntime(8091): at com.android.internal.os.ZygoteInit.main(ZygoteInit.java:605)
04-07 22:16:12.936: E/AndroidRuntime(8091): at dalvik.system.NativeStart.main(Native Method)
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): at android.content.res.Resources.openRawResource(Resources.java:860)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.content.res.Resources.openRawResource(Resources.java:836)
04-07 22:16:12.936: E/AndroidRuntime(8091): at bassy.test.drawable.Main.onCreate(Main.java:43)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.app.Instrumentation.callActivityOnCreate(Instrumentation.java:1047)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.app.ActivityThread.performLaunchActivity(ActivityThread.java:1722)
04-07 22:16:12.936: E/AndroidRuntime(8091): ... 11 more
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): at android.content.res.AssetManager.openNonAssetNative(Native Method)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.content.res.AssetManager.openNonAsset(AssetManager.java:429)
04-07 22:16:12.936: E/AndroidRuntime(8091): at android.content.res.Resources.openRawResource(Resources.java:857)
04-07 22:16:12.936: E/AndroidRuntime(8091): ... 15 more
从上面可以看出,程序在加载到第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错误!
而且,加载的时间都是一样~~
这样一来,我就更加迷惑了~~
(本文对我帮助很大,在此谢谢原作者)
在最近做的工程中发现加载的图片太多或图片过大时经常出现OOM问题,找网上资料也提供了很多方法,但自己感觉有点乱,特此,今天在不同型号的三款安卓手机上做了测试,因为有效果也有结果,今天小马就做个详细的总结,以供朋友们共同交流学习,也供自己以后在解决OOM问题上有所提高,提前讲下,片幅有点长,涉及的东西太多,大家耐心看,肯定有收获的,里面的很多东西小马也是学习参考网络资料使用的,先来简单讲下下:
一般我们大家在遇到内存问题的时候常用的方式网上也有相关资料,大体如下几种:
一:在内存引用上做些处理,常用的有软引用、强化引用、弱引用
二:在内存中加载图片时直接在内存中做处理,如:边界压缩
三:动态回收内存
四:优化Dalvik虚拟机的堆内存分配
五:自定义堆内存大小
可是真的有这么简单吗,就用以上方式就能解决OOM了?不是的,继续来看...
下面小马就照着上面的次序来整理下解决的几种方式,数字序号与上面对应:
1:软引用(SoftReference)、虚引用(PhantomRefrence)、弱引用(WeakReference),这三个类是对heap中java对象的应用,通过这个三个类可以和gc做简单的交互,除了这三个以外还有一个是最常用的强引用
1.1:强引用,例如下面代码:
上面代码中第一句是在heap堆中创建新的Object对象通过o引用这个对象,第二句是通过o建立o1到new Object()这个heap堆中的对象的引用,这两个引用都是强引用.只要存在对heap中对象的引用,gc就不会收集该对象.如果通过如下代码:
heap中对象有强可及对象、软可及对象、弱可及对象、虚可及对象和不可到达对象。应用的强弱顺序是强、软、弱、和虚。对于对象是属于哪种可及的对象,由他的最强的引用决定。如下:
上面的代码中:
第一行在heap对中创建内容为“abc”的对象,并建立abc到该对象的强引用,该对象是强可及的。第二行和第三行分别建立对heap中对象的软引用和弱引用,此时heap中的对象仍是强可及的。第四行之后heap中对象不再是强可及的,变成软可及的。同样第五行执行之后变成弱可及的。
1.2:软引用
软引用是主要用于内存敏感的高速缓存。在jvm报告内存不足之前会清除所有的软引用,这样以来gc就有可能收集软可及的对象,可能解决内存吃紧问题,避免内存溢出。什么时候会被收集取决于gc的算法和gc运行时可用内存的大小。当gc决定要收集软引用是执行以下过程,以上面的abcSoftRef为例:
1 首先将abcSoftRef的referent设置为null,不再引用heap中的new String("abc")对象。
2 将heap中的new String("abc")对象设置为可结束的(finalizable)。
3 当heap中的new String("abc")对象的finalize()方法被运行而且该对象占用的内存被释放, abcSoftRef被添加到它的ReferenceQueue中。
注:对ReferenceQueue软引用和弱引用可以有可无,但是虚引用必须有,参见:
被 Soft Reference 指到的对象,即使没有任何 Direct Reference,也不会被清除。一直要到 JVM 内存不足且 没有 Direct Reference 时才会清除,SoftReference 是用来设计 object-cache 之用的。如此一来 SoftReference 不但可以把对象 cache 起来,也不会造成内存不足的错误 (OutOfMemoryError)。我觉得 Soft Reference 也适合拿来实作 pooling 的技巧。
1.3:弱引用
当gc碰到弱可及对象,并释放abcWeakRef的引用,收集该对象。但是gc可能需要对此运用才能找到该弱可及对象。通过如下代码可以了明了的看出它的作用:
运行结果:
before gc: abc
after gc: null
gc收集弱可及对象的执行过程和软可及一样,只是gc不会根据内存情况来决定是不是收集该对象。如果你希望能随时取得某对象的信息,但又不想影响此对象的垃圾收集,那么你应该用 Weak Reference 来记住此对象,而不是用一般的 reference。
在此例中,透过 get() 可以取得此 Reference 的所指到的对象,如果返回值为 null 的话,代表此对象已经被清除。这类的技巧,在设计 Optimizer 或 Debugger 这类的程序时常会用到,因为这类程序需要取得某对象的信息,但是不可以 影响此对象的垃圾收集。
1.4:虚引用
就是没有的意思,建立虚引用之后通过get方法返回结果始终为null,通过源代码你会发现,虚引用通向会把引用的对象写进referent,只是get方法返回结果为null.先看一下和gc交互的过程在说一下他的作用.
1.4.1 不把referent设置为null, 直接把heap中的new String("abc")对象设置为可结束的(finalizable).
1.4.2 与软引用和弱引用不同, 先把PhantomRefrence对象添加到它的ReferenceQueue中.然后在释放虚可及的对象.
你会发现在收集heap中的new String("abc")对象之前,你就可以做一些其他的事情.通过以下代码可以了解他的作用.
结果为
class java.lang.String@96354
gc will collect:class java.lang.String@96354 好了,关于引用就讲到这,下面看2
2:在内存中压缩小马做了下测试,对于少量不太大的图片这种方式可行,但太多而又大的图片小马用个笨的方式就是,先在内存中压缩,再用软引用避免OOM,两种方式代码如下,大家可参考下:
方式一代码如下:
方式二代码如下:
上面两种方式第一种直接使用边界压缩,第二种在使用边界压缩的情况下间接的使用了软引用来避免OOM,但大家都知道,这些函数在完成decode后,最终都是通过java层的createBitmap来完成的,需要消耗更多内存,如果图片多且大,这种方式还是会引用OOM异常的,不着急,有的是办法解决,继续看,以下方式也大有妙用的:
上面代码与下面代码大家可分开使用,也可有效缓解内存问题哦...吼吼...
3:大家可以选择在合适的地方使用以下代码动态并自行显式调用GC来回收内存:
4:这个就好玩了,优化Dalvik虚拟机的堆内存分配,听着很强大,来看下具体是怎么一回事
对于Android平台来说,其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理,比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理,使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程,这里我们仅说下使用方法: 代码如下:
5:自定义我们的应用需要多大的内存,这个好暴力哇,强行设置最小内存大小,代码如下:
好了,文章写完了,片幅有点长,因为涉及到的东西太多了,其它文章小马都会贴源码,这篇文章小马是直接在项目中用三款安卓真机测试的,有效果,项目原码就不在这贴了,不然泄密了都,吼吼,但这里讲下还是会因为手机的不同而不同,大家得根据自己需求选择合适的方式来避免OOM,大家加油呀,每天都有或多或少的收获,这也算是进步,加油加油!