作为一名iOS开发者，相信大家对使用autoreleasepool来降低峰值内存或多或少都有所了解吧。简单来讲，如果需要在for循环中创建局部实例对象，而循环次数又非常大，此时就会导致App瞬时内存很高。
for (int i = 0; i < 10000*1000; i++) {
NSObject *obj = [[NSObject alloc] init];
}
此时，我们可以通过注册autoreleasepool提前释放不再使用的对象，以达到降低峰值内的目的。
for (int i = 0; i < 10000*1000; i++) {
@autoreleasepool {
NSObject *obj = [[NSObject alloc] init];
}
}
然而，这样使用真的有效吗？实践是检验真理的唯一标准，我们还是把代码跑起来，用事实说话。我目前能想到的验证方式有两种，一种是通过instruments工具，优点是操作简单，结果直观，缺点是不能细粒度的跟踪对象的生命周期；第二种方式是通过runtime源码调试，它的优缺点跟方式一正好相反，能够细粒度的跟踪函数调用，但是配置繁琐，好在GitHub上有配置好的工程，可以clone下来直接使用。
我们采用方式二进行验证，在NSObject *obj = [[NSObject alloc] init];和runtime源码中的dealloc方法分别下一个断点，观察obj对象的销毁时机，具体调试步骤我不再赘述，直接上结论：
在ARC环境下，通过alloc方式分配的局部对象，即使没有autoreleasepool包裹，在其作用域结束的时候也会立即释放
也就是说，我们上面的第二段代码完全是画蛇添足，没起到任何作用。
难道我们一直以来的理解是完全错误的吗？还是说我们使用的姿势不对？我记得第一次看到这种用法是在经典的《effective objective-c 2.0》中，出现这种错误的可能性几乎为零。我们先来还是捋一捋完整流程，之所以会造成峰值内存高，是因为对象没有被及时释放，是什么导致对象不能及时释放呢？是因为对象需要在当前runloop结束时才有机会释放，我们知道系统在runloop entry时会自动push一个自动释放池，在runloop即将休眠时pop旧的释放池，并push一个新的释放池，此时会对这期间创建的对象调用release，而我们自己创建释放池的目的只是创建一个嵌套的释放池，使得对象不再被使用时提前释放，而不用非等到当前runloop结束的时候。问题逐渐明朗了，其实我们要搞清楚的是哪种方式创建的对象在pop释放池的时候会被release。回顾一下遥远的MRC时代我们是怎么管理对象的生命周期的，通过new、alloc、copy、mutableCopy创建的对象需要手动release，其他方式创建的对象不需要手动release，原因是其他方式创建的对象在方法返回前已经调用了autorelease，很明显，自动释放池只对调用了autorelease的对象起作用。
接下来验证我们的猜想，NSArray是我们开发中经常用到的OC容器类，它有多个版本的构造方式，既可以通过alloc、new创建，也可以通过arrayWithObject:等工厂方法构建，二者区别上文已经说过了，前者不会调用autorelease，后者在方法返回前会调用autorelease。如果我们的猜想成立，那么
1.通过alloc、new创建的array对象会在作用域结束时dealloc；
2.通过arrayWithObject:等工厂方法构建的array对象不会在作用域结束时dealloc，而是要延迟到当前runloop结束的时候，如果循环次数很大就会造成峰值内存过高；
3.如果给通过arrayWithObject:等工厂方法构建的array手动加上autoreleasepool，可以在当前释放池pop的时候提前释放array对象，降低峰值内存。
代码很简单，我就不贴了，直接把上文中的NSObject换成NSArray就行了。验证结果表明，我们的猜想正确。另外需要注意一点，在ARC环境下，通过autoreleasepool降低峰值内存只对系统类的工厂方法有效，对于自定义类的自定义工厂方法（注：此处及下文描述的自定义类的自定义工厂方法，均不包含通过调用系统基类的工厂方法来实现的构造方法）是无效的，原因留给大家自己思考。
文章结论全部来自于笔者个人的猜想验证，如有错误欢迎大家批评指正！最后，我们还是简单总结一下
在ARC环境下，通过new、alloc、copy、mutableCopy创建的类对象、以及自定义类的自定义工厂方法创建的类对象，autoreleasepool都起不到降低峰值内存的作用；这种方式只对系统类非new、alloc、copy、mutableCopy构造方法有效
