一、项目需求
实际项目中，用户在上传图片时，可能会一次性上传大量的图片。上传图片前，我们要进行一系列操作，比如：旋转图片为正确方向，压缩图片等，但是这些操作需要将图片加载到内存中，下面对内存的使用做详细分析.
二、内存分析，没有优化
我在项目中，重复加载了一张图片1000次，首先加载图片到内存，然后进行压缩操作，释放内存
上述的代码看起来没有任何问题，是一种标准的代码写法，每一步骤中都对内存做了小心的处理，但是，实际的内存使用情况：
上图中可以看到，上述的操作在没有任何问题的情况下，加载大量图片时，还是会造成内存的飙升。
可以看到自动释放内存时，图片占用的内存并没有立即释放掉
图片资源没有被立即释放，占用了宝贵的内存资源，最终程序被操作系统杀死。
三、 优化后的内存使用
上面程序被操作系统杀死，是因为程序的内存使用问题，在上面的代码中，我们每一步都对内存做了非常小心的处理，但是在加载大量的图片时，还是会出现问题。其根本原因就是autorelease的问题，autorelease自动释放内存，但是并不会立即把内存释放掉，而是需 要等到下一个事件周期才会释放掉。问题是一些资源我们不得不使用autorelease类型，比如作为函数的返回值，而且系统api及项目是的大部分也都是这么做的，如果全都依靠我们手动释放很容易造成内存泄漏。
优化后的，内存的实际使用情况。
可用内存不再急剧下降。
CGImage及UIImage的数量由原来的220多减少到7个。
可以看到使用了NSAutoreleasePool后，加载大量图片的时候内存也不会出现问题。
四、自动释放池概述
1. 自动释放池被置于一个堆栈中，虽然它们通常被称为被“嵌套”的。创建一个新的自动释放池时，它被添加到堆栈的顶部。当自动释放池被回收时，它从堆栈中被删除。当一个对象收到系统的autorelease消息时，它被添加到当前线程的目前处于栈顶的自动释放池中。程序员不能向自动释放池发送autorelease或retain消息。Application Kit会在一个事件周期（或事件循环迭代）的开端—比如点击屏幕事件—自动创建一个自动释放池，并且在事件周期的结尾释放它，因此代码通常不必关心释放问题。但是以下三种情况需要自己创建的自动释放池：
一个不是基于Application Kit的程序，比如命令行工具，则没有对自动释放池的内置支持；需要自己创建它们。
一个异步线程，一旦该线程开始执行，需要立即创建自动释放池；否则，将会泄漏对象。
一个循环，其中创建了许多临时对象，可以在循环内部创建一个自动释放池，以便在下次迭代之前销毁这些临时对象。自动释放池可以帮助减少应用程序的最大内存占用量。
2. release和drain之间的差异
在引用计数环境下,release和drain一样，会直接自动释放对象。
在GC(垃圾回收)环境下，release是一个no-op(空操作)，drain会触发垃圾回收(如果自上次垃圾回收以来分配的内存大于当前的阈值)。
通常情况下，需要使用drain而不是使用release销毁自动释放池。
-drain方法只适用于Mac OS X10.4(Tiger)及更高版本。
