在实际项目中，用户在上传图片时，有时会一次性上传大量的图片。在上传图片前，我们要进行一系列操作，比如：旋转图片为正确方向，压缩图片等，这些操作需要将图片加载到内存中，这时候会遇到的一个问题是内存剧增，导致内存不够用，从而出现闪退的问题，下面对内存的使用做详细分析.
一、内存分析，非优化
我在测试项目中，重复加载了一张图片1000次，首先加载图片到内存，然后进行压缩操作，释放内存
for (int i = 0; i <= 1000; i ++) {
//1.首先我们获取到需要处理的图片资源的路径
NSString *filePath = [[NSBundle mainBundle] pathForResource:@"upload" ofType:@"PNG"];
//2.将图片加载到内存中，我们使用了alloc关键字，在使用完后，可以手动快速释放掉内存
UIImage *image = [[UIImage alloc] initWithContentsOfFile:filePath];
//3.这一步我们将图片进行了压缩，并得到一个autorelease类型实例
UIImage *image2 = [image imageByScalingAndCroppingForSize:CGSizeMake(480, 320)];
//4.释放掉2步骤的内存
[image release];
}
上面的代码看起来没有任何问题，可以说是一种标准的代码写法，在每一步骤中都对内存做了小心的处理，我们来看一下，实际的内存使用情况：
在上图中可以看到，我们的操作在没有任何问题的情况下，在加载大量图片时，还是会造成内存的剧增
可以看到自动释放内存时，图片占用的内存并没有立即释放掉
[图片上传失败...(image-98bb33-1513839329366)]
在上图中可以看到，我们的操作在没有任何问题的情况下，在加载大量图片时，还是会造成内存的剧增
[图片上传失败...(image-701454-1513839329365)]
可以看到自动释放内存时，图片占用的内存并没有立即释放掉
[图片上传失败...(image-9f26ae-1513839329364)]
这些资源没有立即释放的资源，占用了宝贵的内存资源，最终使程序被kill
三优化后的内存使用
上面程序被kill，是因为程序的内存使用问题，在上面的代码中，我们每一步都对内存做了非常小心的处理，但是在加载大量的图片时，还是会出现问题。其根本原因就是autorelease惹的祸，autorelease自动释放内存，并不会立即把内存释放掉，而是要等到下一个事件周期才会释放掉。问题是一些资源我们不得不使用autorelease类型，比如作为函数的返回值，而且系统api及项目是的大部分也都是这么做的，如果全都依靠我们手动释放很容易造成内存泄漏。
记住：NSAutoreleasePool里面的维护了一个NSMutableArray数组，所有标记为autorelease的对象都会被添加都该数组中。只有当pool对象被drain的时候，才会去遍历该数组，若retainCount为0则释放内存，不为零就发生内存泄露！OC已经为我们建立一个pool对象，但是该pool对象需要比较久的时间才能drain掉，因此在一些遍历处理的场景中，需要我们手动去建立pool对象，并手动drain掉。
for (int i = 0; i <= 1000; i ++) {
//创建一个自动释放池
NSAutoreleasePool *pool = [NSAutoreleasePool new];
NSString *filePath = [[NSBundle mainBundle] pathForResource:@"test" ofType:@"PNG"];
UIImage *image = [[UIImage alloc] initWithContentsOfFile:filePath];
UIImage *image2 = [image imageByScalingAndCroppingForSize:CGSizeMake(480, 320)];
[image release];
//将自动释放池内存释放，它会同时释放掉上面代码中产生的临时变量image2
[pool drain];
}
优化后的，内存使用情况
[图片上传失败...(image-35425-1513839372453)]
可用内存不再剧减
CGImage及UIImage的数据由原来的220多减少到6-7个
可以看到使用了 NSAutoreleasePool后，加载大量图片的时候内存也不会出现问题
四、自动释放池概述
（1）自动释放池被置于一个堆栈中，虽然它们通常被称为被“嵌套”的。当您创建一个新的自动释放池时，它被添加到堆栈的顶部。当自动释放池被回收时，它们从堆栈中被删除。当一个对象收到送autorelease消息时，它被添加到当前线程的目前处于栈顶的自动释放池中。你不能向自动释放池发送autorelease或retain消息。Application Kit会在一个事件周期（或事件循环迭代）的开端—比如鼠标按下事件—自动创建一个自动释放池，并且在事件周期的结尾释放它，因此您的代码通常不必关心。 有三种情况您应该使用您自己的自动释放池：
如果您正在编写一个不是基于Application Kit的程序，比如命令行工具，则没有对自动释放池的内置支持；您必须自己创建它们。
如果您生成了一个从属线程，则一旦该线程开始执行，您必须立即创建您自己的自动释放池；否则，您将会泄漏对象。
如果您编写了一个循环，其中创建了许多临时对象，您可以在循环内部创建一个自动释放池，以便在下次迭代之前销毁这些
对象。这可以帮助减少应用程序的最大内存占用量。
（2） release和drain之间的差异
在引用计数环境下,release和drain一样，会直接自动释放池l对象。
在GC(垃圾回收)环境下，release是一个no-op(空操作)，drain会触发垃圾回收(如果自上次垃圾回收以来分配的内存大于当前的阈值)。
通常情况下，您都应该使用drain而不是使用release来销毁自动释放池。
-drain方法只适用于Mac OS X10.4(Tiger)及更高版本。
PS:如果项目使用的是ARC机制的，则在相同的位置使用@autoreleasepool {},
即，
for (int i = 0; i <= 1000; i ++) {
//创建一个自动释放池
@autoreleasepool {
NSString *filePath = [[NSBundle mainBundle] pathForResource:@"test" ofType:@"PNG"];
UIImage *image = [[UIImage alloc] initWithContentsOfFile:filePath];
UIImage *image2 = [image imageByScalingAndCroppingForSize:CGSizeMake(480, 320)];
}
}
在实际项目中，用户在上传图片时，有时会一次性上传大量的图片。在上传图片前，我们要进行一系列操作，比如：旋转图片为正确方向，压缩图片等，这些操作需要将图片加载到内存中，这时候会遇到的一个问题是内存剧增，导致内存不够用，从而出现闪退的问题，下面对内存的使用做详细分析.
一、内存分析，非优化
我在测试项目中，重复加载了一张图片1000次，首先加载图片到内存，然后进行压缩操作，释放内存
for (int i = 0; i <= 1000; i ++) {
//1.
首先我们获取到需要处理的图片资源的路径
NSString *filePath = [[NSBundle mainBundle]pathForResource:@"upload"ofType:@"PNG"];
//2.
将图片加载到内存中，我们使用了
alloc
关键字，在使用完后，可以手动快速释放掉内存
UIImage *image = [[UIImage alloc]initWithContentsOfFile:filePath];
//3.
这一步我们将图片进行了压缩，并得到一个
autorelease
类型实例
UIImage *image2 = [image imageByScalingAndCroppingForSize:CGSizeMake(480, 320)];
//4.
释放掉
2步骤的内存
[image release];
}
上面的代码看起来没有任何问题，可以说是一种标准的代码写法，在每一步骤中都对内存做了小心的处理，我们来看一下，实际的内存使用情况：
[图片上传失败...(image-87484c-1513838509643)]
在上图中可以看到，我们的操作在没有任何问题的情况下，在加载大量图片时，还是会造成内存的剧增
[图片上传失败...(image-837e1a-1513838509638)]
可以看到自动释放内存时，图片占用的内存并没有立即释放掉
[图片上传失败...(image-9d2b2b-1513838509636)]
这些资源没有立即释放的资源，占用了宝贵的内存资源，最终使程序被kill
三优化后的内存使用
上面程序被kill，是因为程序的内存使用问题，在上面的代码中，我们每一步都对内存做了非常小心的处理，但是在加载大量的图片时，还是会出现问题。其根本原因就是
autorelease
惹的祸，
autorelease自动释放内存，并不会立即把内存释放掉，
而是要等到下一个事件周期才会释放掉
。问题是一些资源我们不得不使用autorelease类型，比如作为函数的返回值，而且系统api及项目是的大部分也都是这么做的，如果全都依靠我们手动释放很容易造成内存泄漏。
记住：NSAutoreleasePool里面的维护了一个NSMutableArray数组，所有标记为autorelease的对象都会被添加都该数组中。
只有当pool对象被drain的时候，
才会去遍历该数组，若retainCount为0则释放内存，不为零就发生内存泄露！OC已经为我们建立一个pool对象，但是该pool对象需要比较久的时间才能drain掉，因此在一些遍历处理的场景中，需要我们手动去建立pool对象，并手动drain掉。
for (int i = 0; i <= 1000; i ++) {
//
创建一个自动释放池
NSAutoreleasePool *pool = [NSAutoreleasePool new];
NSString*filePath = [[NSBundle mainBundle]pathForResource:@"test"ofType:@"PNG"];
UIImage*image = [[UIImage alloc] initWithContentsOfFile:filePath];
UIImage *image2 = [image imageByScalingAndCroppingForSize:CGSizeMake(480, 320)];
[image release];
//
将自动释放池内存释放，它会同时释放掉上面代码中产生的临时变量
image2 [pool drain];
}
优化后的，内存使用情况
[图片上传失败...(image-169621-1513838509642)]
可用内存不再剧减
CGImage及UIImage的数据由原来的220多减少到6-7个
可以看到使用了
NSAutoreleasePool
后，加载大量图片的时候内存也不会出现问题
四、自动释放池概述
（1）
自动释放池被置于一个堆栈中，虽然它们通常被称为被“嵌套”的。当您创建一个新的自动释放池时，它被添加到堆栈的顶部。当自动释放池被回收时，它们从堆栈中被删除。当一个对象收到送autorelease消息时，它被添加到当前线程的目前处于栈顶的自动释放池中。
你不能向
自动释放池发送autorelease或retain消息
。
Application Kit会在一个事件周期（或事件循环迭代）的开端—比如鼠标按下事件—自动创建一个自动释放池，并且在事件周期的结尾释放它，因此您的代码通常不必关心。
有三种情况您应该使用您自己的自动释放池：
-
如果您正在编写一个不是基于Application Kit的程序，比如命令行工具，则没有对自动释放池的内置支持；您必须自己创建它们。
-
如果您生成了一个从属线程，则一旦该线程开始执行，您必须立即创建您自己的自动释放池；否则，您将会泄漏对象。
-
如果您编写了一个循环，其中创建了许多临时对象，您可以在循环内部创建一个自动释放池，以便在下次迭代之前销毁这些
对象。这可以帮助减少应用程序的最大内存占用量。
（2）
release和drain之间的差异
在引用计数环境下,release和drain一样，会直接自动释放池l对象。
在GC(垃圾回收)环境下，release是一个no-op(空操作)，drain会触发垃圾回收(如果自上次垃圾回收以来分配的内存大于当前的阈值)。
通常情况下，您都应该使用drain而不是使用release来销毁自动释放池。
-drain方法只适用于Mac OS X10.4(Tiger)及更高版本。
PS:如果项目使用的是ARC机制的，则在相同的位置使用
@autoreleasepool{},
即，
//
创建一个自动释放池
@autoreleasepool
{
NSString*filePath = [[NSBundle mainBundle]pathForResource:@"test"ofType:@"PNG"];
UIImage *image = [[UIImage alloc]initWithContentsOfFile:filePath];
UIImage*image2 = [image imageByScalingAndCroppingForSize:CGSizeMake(480, 320)];
}
}
网友评论