当你的应用由于加载大量图片出现OOM异常时，肯定会上网搜索关于OOM的文章，并导求相应的解决方案，比如压缩图片大小，或手动回收资源什么的。在这里我们不讨论图片压缩或缓冲这些方法，而是讨论一下手动回收BITMAP时可能出现的问题，亦即 Canvas: trying to use a recycled bitmap。
很容易可以预料到，你必然会遇到并使用如下代码：
- if(bitmap != null && !bitmap.isRecycled()){
- bitmap.recycle(); //此句造成的以上异常
- bitmap = null;
- }
- System.gc();
然后你将其添加到应用中，用着用着应用崩溃了，查一下LogCat日志，即出现了Canvas: trying to use a recycled bitmap类似的错误。
在进一步探讨之前，我们首先要提醒一下：Android本身就有资源回收机制，它的效果并不似他人所说的“不堪入目”，当你的程序运行时出现GC_CONCURRENT_XX时，说明系统正在回收资源。当然，前提是确实存在垃圾（亦即不再会被引用到的资源）。很多时候，你的应用程序出现OOM异常，是因为应用程序可能对大量的BITMAP资源都有引用，ANDROID自然不会去回收你可能会用到的资源，所以这个时候出现OOM是你的应用程序本身有些不完善，不能怪ANDROID。
一般来说，如果代码已经不再需要使用Bitmap对象了，就可以释放了。释放内存以后，就不能再使用该Bitmap对象了，如果再次使用，就会抛出异常。所以一定要保证不再使用的时候释放。比如，如果是在某个Activity中使用Bitmap，就可以在Activity的onStop()或者onDestroy()方法中进行回收。
那什么才是“不再需要使用的Bitmap对象”呢？废话，不就是后面用不到的图片资源呀，但实际使用的时候，你可能还是会遇到这个异常。其实只要注意BITMAP对象的引用后续是否可能会用到即可，即对象引用的特性！
比如，有同仁在做Android的开发的时候，在ListView 或是 GridView中需要加载大量的图片，为了避免加载过多的图片引起OutOfMemory错误，设置了一个图片缓存列表 Map<String, SoftReference<Bitmap>> imageCache ， 并对其进行维护，在图片加载到一定数量的时候，就手动回收掉之前加载图片的bitmap，如果这个bitmap对象引用还会使用到，就会引起了这个错误。
如下所示：
public class TextBm{
private Bitmap bm;
public void setBitmap(Bitmap bm) {this.bm = bm;}
public Bitmap getBitmap(){return this.bm;}
}
TestBm test_bm = new TestBm();
test_bm.setBitmap(BitmapFactory.decodeFile(path1));
//其它更多代码
test_bm.setBitmap(BitmapFactory.decodeFile(path2));
当程序对TestBm的某个实例进行第二次赋值时，由于第一个Bitmap没有引用到，所以就成为垃圾，这个时候就可以在第二次赋值前用开头的回收代码进行回收。这个垃圾也会被ANROID系统自动回收，但不要小看这种垃圾，有些代码用定时刷新线程来做这样的赋值，产生很多垃圾，虽然系统能回收掉，但也会消耗很多时间，看看上图中的pause多少ms就知道了，那就是回收占用的时间。
再如下所示：
test_bm.setBitmap(imageCache.get(str1));//从图片缓存列表中取出1
//其它更多代码
test_bm.setBitmap(imageCache.get(str2));//从图片缓存列表中取出2
注意：这里第二次赋值时，第一个是有引用的（或者在更多其它地方使用过的），就是存在imageCache的Map中，如果你也像上面那样回收，就不是回收test_bm中bm成员的Bitmap1，而是将imageCache中的Bitmap1也给回收了，因为两个对象是同一个Bitmap1，这样一旦还有其它地方要使用，就会发生:
Canvas: trying to use a recycled bitmap