再来一道面试题，在使用ARC的前提下，还有自己在代码中使用autoreleasepool的必要么？
由 tinyfool 发布于 2017年02月16日无人欣赏。
模版代码里面的不算，我们还有自己手工调用autoreleasepool的必要么？为什么？在什么场景调用？
目前想到以下这些，纯靠记忆，可能有误：
- 这个疑难杂症或者说选择困难还是要看回 LLVM 3.0 发布的时候，看似只是简单的去掉了 NS 这个恼人的前缀，但实际上那之后的 autoreleasepool 比之前的快了不少。
- autoreleasepool 虽然叫这个名字，但其实是个标题党，其实它什么也不会 autorelease……这个在 Apple 的 “ Advanced Memory Management Programming Guide ”说的很明白，那 ARC 是不是更好的 garbage collection 方式呢？我觉得是，ARC 明显在 compile time 上优秀的多。
ARC 和 autoreleasepool 的关系是什么？在我看来并不是谁替代谁的关系，而需要看特定的场景：
如一楼 @Evic 所说，在较大的 loop 里临时变量确实会有这个需求。
同时因为一些历史包袱，在创建一些大型本地库的时候，还是非常需要 autoreleasepool 的。在 ARC 不够 auto 或是 release time 明显过慢的时候？另外 Swift 里已经把 autoreleasepool {} 从表面上去掉了......如果你不主动去找的话。
总之我觉得这是个历史遗留问题，但到目前这个转型期，还是 OC 和 Swift 混编的阶段，还是要对症下药， Swift 很可可以解决这个问题。比如数字计算特别多的 app 项目里，ARC 的出问题的几率就会明显比较多。
我在实际开发时遇到过不得不加的情况。当时的情景是要把一个词典的数据导入 Realm 的数据库，由于词典条目非常多，跑了一段时间后，Mac 的内存就耗尽了。使用 autoreleasepool 把单个词汇的导入代码包起来之后，内存占用就不会一直增长了。
场景1：当你有一个循环,创造了很多临时对象-在每个迭代的循环内使用autoreleasePool 块来释放内存。虽然最终迭代前后使用的内存可能是相同的，但是对于你的App而言要求的最大内存或许会通过一个巨大的因素而递减。 场景2：当你创建线程的时候。每个线程有它自己的autorelease块栈，主线程以它自己的autoreleasepool开头因为它来自于生成的代码，而对于自定义的线程而言，你必须创建你自己的autorelease pool。 对于Tiny老师的那个场景就不得而知了，autorelease pool block是一个工具，用来放弃一个对象的关系-消除它被立刻地dealloc。为什么会提前释放？提早释放是不正确的内存管理方式导致的一种问题而已，@tinyfool老师 求解释。。。。