1-byte array(byte[], boolean[])图片导致的内存过大

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)); 

drawableCache.put(key, new WeakReference(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错误！

而且，加载的时间都是一样～～

这样一来，我就更加迷惑了～～

 

posted @ 2012-08-10 13:55 肆意感受 阅读(292) 评论(0)  编辑

Android 内存溢出解决方案（OOM） 整理总结 （转） 留着以后看

(本文对我帮助很大,在此谢谢原作者)

标签： Android  Android加载大  移动开发

原创作品，允许转载，转载时请务必以超链接形式标明文章  原始出处 、作者信息和本声明。否则将追究法律责任。 http://mzh3344258.blog.51cto.com/1823534/804237

 

在最近做的工程中发现加载的图片太多或图片过大时经常出现OOM问题，找网上资料也提供了很多方法，但自己感觉有点乱，特此，今天在不同型号的三款安卓手机上做了测试，因为有效果也有结果，今天小马就做个详细的总结，以供朋友们共同交流学习，也供自己以后在解决OOM问题上有所提高，提前讲下，片幅有点长，涉及的东西太多，大家耐心看，肯定有收获的，里面的很多东西小马也是学习参考网络资料使用的，先来简单讲下下：

一般我们大家在遇到内存问题的时候常用的方式网上也有相关资料，大体如下几种：

一：在内存引用上做些处理，常用的有软引用、强化引用、弱引用

二：在内存中加载图片时直接在内存中做处理，如：边界压缩

三：动态回收内存

四：优化Dalvik虚拟机的堆内存分配

五：自定义堆内存大小

可是真的有这么简单吗，就用以上方式就能解决OOM了？不是的，继续来看...

下面小马就照着上面的次序来整理下解决的几种方式，数字序号与上面对应：

1：软引用(SoftReference)、虚引用(PhantomRefrence)、弱引用(WeakReference),这三个类是对heap中java对象的应用，通过这个三个类可以和gc做简单的交互，除了这三个以外还有一个是最常用的强引用

1.1：强引用，例如下面代码：

1. Object o=new Object();
2. Object o1=o;

上面代码中第一句是在heap堆中创建新的Object对象通过o引用这个对象，第二句是通过o建立o1到new Object()这个heap堆中的对象的引用，这两个引用都是强引用.只要存在对heap中对象的引用，gc就不会收集该对象.如果通过如下代码：

1. o=null;
2. o1=null

heap中对象有强可及对象、软可及对象、弱可及对象、虚可及对象和不可到达对象。应用的强弱顺序是强、软、弱、和虚。对于对象是属于哪种可及的对象，由他的最强的引用决定。如下:

1. String abc=new String("abc"); //1
2. SoftReference abcSoftRef=new SoftReference(abc); //2
3. WeakReference abcWeakRef = new WeakReference(abc); //3
4. abc=null; //4
5. abcSoftRef.clear();//5

上面的代码中：

第一行在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软引用和弱引用可以有可无，但是虚引用必须有，参见：

1. Reference(T paramT, ReferenceQueue super T>paramReferenceQueue)

被 Soft Reference 指到的对象，即使没有任何 Direct Reference，也不会被清除。一直要到 JVM 内存不足且 没有 Direct Reference 时才会清除，SoftReference 是用来设计 object-cache 之用的。如此一来 SoftReference 不但可以把对象 cache 起来，也不会造成内存不足的错误 （OutOfMemoryError）。我觉得 Soft Reference 也适合拿来实作 pooling 的技巧。

1. A obj = new A();
2. Refenrence sr = new SoftReference(obj);
3. //引用时
4. if(sr!=null){
5. obj = sr.get();
6. }else{
7. obj = new A();
8. sr = new SoftReference(obj);
9. }

1.3:弱引用

当gc碰到弱可及对象，并释放abcWeakRef的引用，收集该对象。但是gc可能需要对此运用才能找到该弱可及对象。通过如下代码可以了明了的看出它的作用：

1. String abc=new String("abc");
2. WeakReference abcWeakRef = new WeakReference(abc);
3. abc=null;
4. System.out.println("before gc: "+abcWeakRef.get());
5. System.gc();
6. System.out.println("after gc: "+abcWeakRef.get());

运行结果:

before gc: abc

after gc: null

gc收集弱可及对象的执行过程和软可及一样，只是gc不会根据内存情况来决定是不是收集该对象。如果你希望能随时取得某对象的信息，但又不想影响此对象的垃圾收集，那么你应该用 Weak Reference 来记住此对象，而不是用一般的 reference。

 

1. A obj = new A();
2. WeakReference wr = new WeakReference(obj);
3. obj = null;
4. //等待一段时间，obj对象就会被垃圾回收
5. 　　...
6. 　　if (wr.get()==null) {
7. 　　System.out.println("obj 已经被清除了 ");
8. 　　} else {
9. 　　System.out.println("obj 尚未被清除，其信息是 "+obj.toString());
10. 　　}
11. 　　...
12. }

 

在此例中，透过 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")对象之前,你就可以做一些其他的事情.通过以下代码可以了解他的作用.

 

1. import java.lang.ref.PhantomReference;
2. import java.lang.ref.Reference;
3. import java.lang.ref.ReferenceQueue;
4. import java.lang.reflect.Field;
5. public class Test {
6. public static boolean isRun = true;
7. public static void main(String[] args) throws Exception {
8. String abc = new String("abc");
9. System.out.println(abc.getClass() + "@" + abc.hashCode());
10. final ReferenceQueue referenceQueue = new ReferenceQueue();
11. new Thread() {
12. public void run() {
13. while (isRun) {
14. Object o = referenceQueue.poll();
15. if (o != null) {
16. try {
17. Field rereferent = Reference.class
18. .getDeclaredField("referent");
19. rereferent.setAccessible(true);
20. Object result = rereferent.get(o);
21. System.out.println("gc will collect:"
22. + result.getClass() + "@"
23. + result.hashCode());
24. } catch (Exception e) {
25. e.printStackTrace();
26. }
27. }
28. }
29. }
30. }.start();
31. PhantomReference abcWeakRef = new PhantomReference(abc,
32. referenceQueue);
33. abc = null;
34. Thread.currentThread().sleep(3000);
35. System.gc();
36. Thread.currentThread().sleep(3000);
37. isRun = false;
38. }
39. }

 

结果为

class java.lang.String@96354

gc will collect:class java.lang.String@96354 好了，关于引用就讲到这，下面看2

2:在内存中压缩小马做了下测试，对于少量不太大的图片这种方式可行，但太多而又大的图片小马用个笨的方式就是，先在内存中压缩，再用软引用避免OOM，两种方式代码如下，大家可参考下：

方式一代码如下：

1. @SuppressWarnings("unused")
2. private Bitmap copressImage(String imgPath){
3. File picture = new File(imgPath);
4. Options bitmapFactoryOptions = new BitmapFactory.Options();
5. //下面这个设置是将图片边界不可调节变为可调节
6. bitmapFactoryOptions.inJustDecodeBounds = true;
7. bitmapFactoryOptions.inSampleSize = 2;
8. int outWidth = bitmapFactoryOptions.outWidth;
9. int outHeight = bitmapFactoryOptions.outHeight;
10. bmap = BitmapFactory.decodeFile(picture.getAbsolutePath(),
11. bitmapFactoryOptions);
12. float imagew = 150;
13. float imageh = 150;
14. int yRatio = (int) Math.ceil(bitmapFactoryOptions.outHeight
15. / imageh);
16. int xRatio = (int) Math
17. .ceil(bitmapFactoryOptions.outWidth / imagew);
18. if (yRatio > 1 || xRatio > 1) {
19. if (yRatio > xRatio) {
20. bitmapFactoryOptions.inSampleSize = yRatio;
21. } else {
22. bitmapFactoryOptions.inSampleSize = xRatio;
23. }
24. }
25. bitmapFactoryOptions.inJustDecodeBounds = false;
26. bmap = BitmapFactory.decodeFile(picture.getAbsolutePath(),
27. bitmapFactoryOptions);
28. if(bmap != null){
29. //ivwCouponImage.setImageBitmap(bmap);
30. return bmap;
31. }
32. return null;
33. }

方式二代码如下:

1. package com.lvguo.scanstreet.activity;
2. import java.io.File;
3. import java.lang.ref.SoftReference;
4. import java.util.ArrayList;
5. import java.util.HashMap;
6. import java.util.List;
7. import android.app.Activity;
8. import android.app.AlertDialog;
9. import android.content.Context;
10. import android.content.DialogInterface;
11. import android.content.Intent;
12. import android.content.res.TypedArray;
13. import android.graphics.Bitmap;
14. import android.graphics.BitmapFactory;
15. import android.graphics.BitmapFactory.Options;
16. import android.os.Bundle;
17. import android.view.View;
18. import android.view.ViewGroup;
19. import android.view.WindowManager;
20. import android.widget.AdapterView;
21. import android.widget.AdapterView.OnItemLongClickListener;
22. import android.widget.BaseAdapter;
23. import android.widget.Gallery;
24. import android.widget.ImageView;
25. import android.widget.Toast;
26. import com.lvguo.scanstreet.R;
27. import com.lvguo.scanstreet.data.ApplicationData;
29. public class PhotoScanActivity extends Activity {
30. private Gallery gallery ;
31. private List ImageList;
32. private List it ;
33. private ImageAdapter adapter ;
34. private String path ;
35. private String shopType;
36. private HashMap> imageCache = null;
37. private Bitmap bitmap = null;
38. private SoftReference srf = null;
39. @Override
40. public void onCreate(Bundle savedInstanceState) {
41. super.onCreate(savedInstanceState);
42. getWindow().setFlags(WindowManager.LayoutParams.FLAG_FULLSCREEN,
43. WindowManager.LayoutParams.FLAG_FULLSCREEN);
44. setContentView(R.layout.photoscan);
45. Intent intent = this.getIntent();
46. if(intent != null){
47. if(intent.getBundleExtra("bundle") != null){
48. Bundle bundle = intent.getBundleExtra("bundle");
49. path = bundle.getString("path");
50. shopType = bundle.getString("shopType");
51. }
52. }
53. init();
54. }
55. private void init(){
56. imageCache = new HashMap>();
57. gallery = (Gallery)findViewById(R.id.gallery);
58. ImageList = getSD();
59. if(ImageList.size() == 0){
60. Toast.makeText(getApplicationContext(), "无照片，请返回拍照后再使用预览", Toast.LENGTH_SHORT).show();
61. return ;
62. }
63. adapter = new ImageAdapter(this, ImageList);
64. gallery.setAdapter(adapter);
65. gallery.setOnItemLongClickListener(longlistener);
66. }
68. private OnItemLongClickListener longlistener = new OnItemLongClickListener() {
69. @Override
70. public boolean onItemLongClick(AdapterView parent, View view,
71. final int position, long id) {
72. //此处添加长按事件删除照片实现
73. AlertDialog.Builder dialog = new AlertDialog.Builder(PhotoScanActivity.this);
74. dialog.setIcon(R.drawable.warn);
75. dialog.setTitle("删除提示");
76. dialog.setMessage("你确定要删除这张照片吗？");
77. dialog.setPositiveButton("确定", new DialogInterface.OnClickListener() {
78. @Override
79. public void onClick(DialogInterface dialog, int which) {
80. File file = new File(it.get(position));
81. boolean isSuccess;
82. if(file.exists()){
83. isSuccess = file.delete();
84. if(isSuccess){
85. ImageList.remove(position);
86. adapter.notifyDataSetChanged();
87. //gallery.setAdapter(adapter);
88. if(ImageList.size() == 0){
89. Toast.makeText(getApplicationContext(), getResources().getString(R.string.phoSizeZero), Toast.LENGTH_SHORT).show();
90. }
91. Toast.makeText(getApplicationContext(), getResources().getString(R.string.phoDelSuccess), Toast.LENGTH_SHORT).show();
92. }
93. }
94. }
95. });
96. dialog.setNegativeButton("取消",new DialogInterface.OnClickListener() {
97. @Override
98. public void onClick(DialogInterface dialog, int which) {
99. dialog.dismiss();
100. }
101. });
102. dialog.create().show();
103. return false;
104. }
105. };
107. private List getSD() {
109. File fileK ;
110. it = new ArrayList();
111. if("newadd".equals(shopType)){
112. //如果是从查看本人新增列表项或商户列表项进来时
113. fileK = new File(ApplicationData.TEMP);
114. }else{
115. //此时为纯粹新增
116. fileK = new File(path);
117. }
118. File[] files = fileK.listFiles();
119. if(files != null && files.length>0){
120. for(File f : files ){
121. if(getImageFile(f.getName())){
122. it.add(f.getPath());
123. Options bitmapFactoryOptions = new BitmapFactory.Options();
124. //下面这个设置是将图片边界不可调节变为可调节
125. bitmapFactoryOptions.inJustDecodeBounds = true;
126. bitmapFactoryOptions.inSampleSize = 5;
127. int outWidth = bitmapFactoryOptions.outWidth;
128. int outHeight = bitmapFactoryOptions.outHeight;
129. float imagew = 150;
130. float imageh = 150;
131. int yRatio = (int) Math.ceil(bitmapFactoryOptions.outHeight
132. / imageh);
133. int xRatio = (int) Math
134. .ceil(bitmapFactoryOptions.outWidth / imagew);
135. if (yRatio > 1 || xRatio > 1) {
136. if (yRatio > xRatio) {
137. bitmapFactoryOptions.inSampleSize = yRatio;
138. } else {
139. bitmapFactoryOptions.inSampleSize = xRatio;
140. }
141. }
142. bitmapFactoryOptions.inJustDecodeBounds = false;
143. bitmap = BitmapFactory.decodeFile(f.getPath(),
144. bitmapFactoryOptions);
145. //bitmap = BitmapFactory.decodeFile(f.getPath());
146. srf = new SoftReference(bitmap);
147. imageCache.put(f.getName(), srf);
148. }
149. }
150. }
151. return it;
152. }
154. private boolean getImageFile(String fName) {
155. boolean re;
157. String end = fName
158. .substring(fName.lastIndexOf(".") + 1, fName.length())
159. .toLowerCase();
161. if (end.equals("jpg") || end.equals("gif") || end.equals("png")
162. || end.equals("jpeg") || end.equals("bmp")) {
163. re = true;
164. } else {
165. re = false;
166. }
167. return re;
168. }
169. public class ImageAdapter extends BaseAdapter{
171. int mGalleryItemBackground;
172. private Context mContext;
173. private List lis;
175. public ImageAdapter(Context c, List li) {
176. mContext = c;
177. lis = li;
178. TypedArray a = obtainStyledAttributes(R.styleable.Gallery);
179. mGalleryItemBackground = a.getResourceId(R.styleable.Gallery_android_galleryItemBackground, 0);
180. a.recycle();
181. }
183. public int getCount() {
184. return lis.size();
185. }
187. public Object getItem(int position) {
188. return lis.get(position);
189. }
191. public long getItemId(int position) {
192. return position;
193. }
195. public View getView(int position, View convertView, ViewGroup parent) {
196. System.out.println("lis:"+lis);
197. File file = new File(it.get(position));
198. SoftReference srf = imageCache.get(file.getName());
199. Bitmap bit = srf.get();
200. ImageView i = new ImageView(mContext);
201. i.setImageBitmap(bit);
202. i.setScaleType(ImageView.ScaleType.FIT_XY);
203. i.setLayoutParams( newGallery.LayoutParams(WindowManager.LayoutParams.WRAP_CONTENT,
204. WindowManager.LayoutParams.WRAP_CONTENT));
205. return i;
206. }
207. }
208. }

上面两种方式第一种直接使用边界压缩，第二种在使用边界压缩的情况下间接的使用了软引用来避免OOM，但大家都知道，这些函数在完成decode后，最终都是通过java层的createBitmap来完成的，需要消耗更多内存,如果图片多且大，这种方式还是会引用OOM异常的，不着急，有的是办法解决，继续看，以下方式也大有妙用的：

1. 1. InputStream is = this.getResources().openRawResource(R.drawable.pic1);
2. BitmapFactory.Options options=new BitmapFactory.Options();
3. options.inJustDecodeBounds = false;
4. options.inSampleSize = 10; //width，hight设为原来的十分一
5. Bitmap btp =BitmapFactory.decodeStream(is,null,options);
6. 2. if(!bmp.isRecycle() ){
7. bmp.recycle() //回收图片所占的内存
8. system.gc() //提醒系统及时回收
9. }

上面代码与下面代码大家可分开使用，也可有效缓解内存问题哦...吼吼...

1. public static Bitmap readBitMap(Context context, int resId){
2. BitmapFactory.Options opt = new BitmapFactory.Options();
3. opt.inPreferredConfig = Bitmap.Config.RGB_565;
4. opt.inPurgeable = true;
5. opt.inInputShareable = true;
6. //获取资源图片
7. InputStream is = context.getResources().openRawResource(resId);
8. return BitmapFactory.decodeStream(is,null,opt);
9. }

3:大家可以选择在合适的地方使用以下代码动态并自行显式调用GC来回收内存：

1. if(bitmapObject.isRecycled()==false) //如果没有回收
2. bitmapObject.recycle();

4:这个就好玩了，优化Dalvik虚拟机的堆内存分配，听着很强大，来看下具体是怎么一回事

对于Android平台来说，其托管层使用的Dalvik JavaVM从目前的表现来看还有很多地方可以优化处理，比如我们在开发一些大型游戏或耗资源的应用中可能考虑手动干涉GC处理，使用 dalvik.system.VMRuntime类提供的setTargetHeapUtilization方法可以增强程序堆内存的处理效率。当然具体原理我们可以参考开源工程，这里我们仅说下使用方法: 代码如下：

1. private final static floatTARGET_HEAP_UTILIZATION = 0.75f;
2. 在程序onCreate时就可以调用
3. VMRuntime.getRuntime().setTargetHeapUtilization(TARGET_HEAP_UTILIZATION);
4. 即可

5：自定义我们的应用需要多大的内存，这个好暴力哇，强行设置最小内存大小，代码如下：

1. private final static int CWJ_HEAP_SIZE = 6* 1024* 1024 ;
2. //设置最小heap内存为6MB大小
3. VMRuntime.getRuntime().setMinimumHeapSize(CWJ_HEAP_SIZE);

好了，文章写完了，片幅有点长，因为涉及到的东西太多了，其它文章小马都会贴源码，这篇文章小马是直接在项目中用三款安卓真机测试的，有效果，项目原码就不在这贴了，不然泄密了都，吼吼，但这里讲下还是会因为手机的不同而不同，大家得根据自己需求选择合适的方式来避免OOM,大家加油呀，每天都有或多或少的收获，这也算是进步，加油加油！