1.iOS記憶體管理有三種方法:ARC、MRC、記憶體池。
2.MRC：遵循誰申請、誰添加、誰釋放的原則。需要手動處理記憶體技術的增加和修改。從12年iOS開始開始，逐步被ARC(自動記憶體計數)模式取代。
3.ARC就是取代了MRC，在App編譯階段，由Xcode添加了記憶體管理的程式碼。
4.記憶體釋放池Release Pool：把需要釋放的記憶體統一放在一個池子中，當池子被抽乾後(drain)，池子中所有的記憶體空間也被自動釋放掉。 記憶體池的釋放操作分為自動和手動。自動釋放受runloop機制影響。
5.內存池是屬於MRC的技術嗎？ ARC模式下有自動記憶體計數了，MRC下有手動記憶體處理了。那麼記憶體池是MRC下的相對於release 方法的另一種記憶體計數處理方法嗎？
6.我是搞不清ARC、MRC、內存池 三者的關係。
7.ARC的語意就是在實際開發中，根本不用操心記憶體管理問題。 （是嗎？）
ARC和MRC其实都是原始的内存管理方式，申请：alloc；释放：release，这种方式下内存的申请和释放都需要精确计算，对于比较复杂的程序，计算申请对象应该何时被释放是有些头昏脑热的事情。于是就出现了引用计数Reference Counting这种方式，用来统计对象的使用情况以得到对象应不应该被释放。MRC就是Mannul Reference Counting，它需要手动进行对象使用的计算，也就是每次使用对象时，要手动的retain一下给引用计数加一，而不再使用时还要release一下给引用计数减一。这样写久了，会感觉特别麻烦，要费老大劲去写retain和release，于是乎就有了ARC自动引用计数，原理也很简单，就是通过程序去推断retain和release应该出现的位置，代替我们去写retain和release。而
AutoRelease则又是完全不同的一套思路，有点儿像Java中的GC垃圾清理机制，它不会像ARC或者MRC那样在对象不再会被使用时马上被释放，而是等到一个时机去释放它。在ARC比较成熟的今天，用到的机会已经不多了，不过再一些特殊的场景下，AutoRelease还是能达到ARC所不能達到的效果的。你自己解釋的很清楚了，ARC不能說完全不用考慮記憶體管理，但是做的確實很完善。記憶體池就是你存放你申請記憶體的地方，這個很好理解。我記得ARC的情況下，好像是把以前需要手動釋放的記憶體直接放到release pool裡就可以了，系統會自動釋放掉release pool裡的記憶體。 MRC就是你說的那樣，誰申請誰釋放的原則。說起來還是喜歡MRC,有種大權在握的感覺。
如果要談歷史的話oc從面世時就是MRC的，而AutoRelease是2.0的特性。但是我不知道autorelease還關係到runloop，我知道main函數中有用到runloop，能否解決？
MRC 最早，程式設計師手動管理記憶體。
ARC 的前身是“Clang static analyzer” 項目，該項目用於分析Objective-C 代碼，找出內存洩漏、過早釋放之類的錯誤,效果非常好以至於蘋果考慮乾脆用這個分析器來自動插入所有的retain、release 算了，最後促成了ARC 的產生。
自動釋放池（Autorelease Pool）應該是和 MRC 同期的東西，和 ARC 沒什麼關係。常見使用場景是：某方法需要回傳一個新建立的對象，但不想retain 它，又擔心提前釋放問題，就發送autorelease 訊息，讓自動釋放池成為它的臨時擁有者，不至於被提前釋放，drain 時這個臨時的計數也減掉了。
所以自動釋放池的名字可能有點誤導，自動釋放池並不會「自動」 release 任何東西，它 release 的都是你此前告訴它要 release 的。
總結一下：MRC 是程式設計師自己寫 retain 、 release 來管理內存，自動釋放池機制用於解決一些棘手的對象歸屬權問題， ARC 拯救萬民於水火。
ARC 的執行結果就是自動加入了 retain 、 release 後的程式碼，和你 MRC 寫的沒什麼兩樣，只是不容易出錯。也就是說 ARC 的機制和 Java 的垃圾回收之類的完全不同， ARC 是編譯時的機制，而不是執行階段。
使用 ARC 依然需要關注記憶體問題，例如使用 block 時很容易出現的循環強引用，這類問題 ARC 是幫不了你的，比較基本，找本 Objective-C 的書應該都會講。