关于android使用bitmap的OOM心得和解决方案.docxVIP

关于android使用bitmap的OOM心得和解决方案android开发，从2010年开始学习到现在的独立完成一个app，这漫长的四年，已经经历了很多次bug的折磨，无数次的加班训练。然而，自以为自己已经比较了解android了，却最近在一个项目上，因为oom而折腾了一个周，回到原地，认识了自己的不足，感觉自己是如此的菜鸟呀。好了，不废话，大家在使用开发android的时候，很少会注意或者意识到释放内存的重要性，因为大家在使用过程中，涉及的图片资源不多，或者比较稳定，来回切换界面，图片也就那么几张或者使用的都是很小的图片，根本不会感觉到图片占用内存可能引发的潜在危机。如果你的程序中，使用了一下功能，你作为一个合格的android开发工程师，你有必要，注意oom的潜在危机1.界面比较多，并且很多界面的背景图片不一样；2.涉及到换肤功能，定义多种皮肤，皮肤的资源不是使用color 而是图片资源；以上两种情况，如果你不注意合理的释放内存，你将会为自己程序莫名其妙的崩溃付出代价的。我们在android程序中，无论是使用layout布局设置了背景还是使用了setBackgroundResource 设置背景，你都以为不需要释放内存？这绝对是一个错误的观念，绝对的错误。也许这一点的错误的认识，将会在大屏幕手机上，暴露出来你的oom的现象，特别是在三星的大屏幕手机，爆oom的几率更大。也许，大家在使用开发中，会注意这一点，使用了一下方式去解决释放内存（网上很多例子都是使用该方式去释放内存），比如：view sourceprint?01.View view = findViewById(R.id.page_bg);02.BitmapDrawable bitmapDrawable = (BitmapDrawable) view.getBackground();03.view.setBackgroundResource(0);04.bitmapDrawable.setCallback(null);05.Bitmap bitmap = bitmapDrawable.getBitmap();06.if(bitmap !=?null? !bitmap.isRecycled()){07.bitmap.recycle();08.bitmap =?null;09.}10.System.gc();从我们的测试效果来看看logcat 打印出来的结果view sourceprint?01.05-07?06:55:39.330: D/dalvikvm(6988): GC_FOR_ALLOC freed 4091K,?31% free 9715K/13936K, paused 44ms, total 45ms02.05-07?06:55:39.340: I/dalvikvm-heap(6988): Grow heap (frag?case) to?13.126MB?for?3686416-byte?allocation03.05-07?06:55:39.421: D/dalvikvm(6988): GC_CONCURRENT freed 1K,?5% free 13314K/13936K, paused 6ms+5ms, total 83ms04.05-07?06:55:39.600: D/dalvikvm(6988): GC_FOR_ALLOC freed 1K,?5% free 13314K/13936K, paused 44ms, total 44ms05.05-07?06:55:39.670: I/dalvikvm-heap(6988): Grow heap (frag?case) to?19.377MB?for?6554896-byte?allocation06.05-07?06:55:39.790: D/dalvikvm(6988): GC_CONCURRENT freed 0K,?4% free 19715K/20340K, paused 7ms+20ms, total 114ms07.05-07?06:55:40.011: I/System.out(6988): onCreate08.05-07?06:55:41.760: D/dalvikvm(6988): GC_EXPLICIT freed 10759K,?56% free 9063K/20340K, paused 4ms+7ms, total 111ms09.05-07?06:55:41.821: D/dalvikvm(6988): GC_EXPLICIT freed 1K,?56% free 9062K/20340K, paused 4ms+7ms, total 62ms10.05-07?06