關於內存管理
內存管理指的是你的程序在運行過程中進行內存的分配，使用，以及釋放它的過程。一個經過仔細編碼的程序總是盡可能使用更少的內存。在object-c中，內存管理也被看作是你對擁有的有限的內存資源進行數據和代碼的合理分配的過程。如果你仔細通讀瞭本篇文檔，你將能夠合理的管理對象的生命周期以及適時的釋放不再被程序使用的內存。
內存管理看起來似乎是單個對象的操作，但實際上我們總是在管理著對象圖。
LPSTUDY：
1. 1:Class A中通過調用alloc/init方法創建瞭一個對象，此處我命名此對象為aObject，此時由於aObject調用瞭alloc方法，它的引用計數(retain count)是1
2. 在Class B中對aObject進行瞭retain操作，這樣會增加aObject的引用計數，即為2
3. Class C想要使用aObject，於是它調用瞭copy操作，這樣Class C會擁有aObject的拷貝，這個和retain操作不一樣。retain操作僅僅增加瞭aObject指向的實際內存的引用計數，copy操作是又申請瞭一塊內存，此內存引用計數為1，通過copy操作，Class C可以自由處理此塊內存（這個隻有處理是有限制的，受被copy元素的屬性限制），將此塊內存命名為cObject。
4. Class A調用瞭release方法，此時aObject的引用計數減1，變為1
5. Class B又調用瞭一次release方法，引用計數為0，此塊內存被釋放。
6. Class C對自己cObject調用瞭release方法，retain減1，變為0，此塊內存被釋放。
概覽：
object-c提供瞭三種內存管理方法
1. Retain-Release方式：簡稱MRR，這個需要程序員很清楚的跟蹤自己的對象來管理內存，它是通過使用基類NSobject提供的引用計數模型進行管理的。當引用計數為0，此塊內存被釋放。
2. 自動引用字數方式：簡稱ARC，它也是使用瞭同樣的引用計數機制，它在編譯的時候自動幫你添加瞭內存管理方法。如果你使用瞭ARC，很多底層的機制你就無需知道瞭。
see Transitioning to ARC Release Notes
3. 垃圾回收：系統自動跟蹤對象的依存關系，然後自動釋放不再被引用的對象。它使用一個與自動引用計數不同的機制，不過僅僅在Mac Os X中使用，不可以用於IOS。
see GarbageCollection Programming Guide.
如果你想在IOS上編程，你必須使用顯式的內存管理（這篇文檔的主題），如果更進一步，你計劃寫一些庫，或者插件，或者可在垃圾回收和非垃圾回收的程序中使用的共享代碼，你就必須通讀本文檔以使用內存管理技術。（在xcode中，你必須在使用或者禁用垃圾回收都測試一下你的代碼）
良好的習慣可以避免內存方面的問題
主要有兩種問題導致錯誤的內存管理
1. 在數據使用的過程中釋放或者重寫數據。
這可能引起內存崩潰，更典型的如程序崩潰，用戶數據出錯。
數據不再被使用，仍然不釋放內存會導致內存泄露
2. 內存泄露是值你仍然不去釋放已經不會再被使用的內存。內存泄露導致你的程序占用內存過多，從而導致系統性能下降或者在IOS中被強制終止。
不要僅僅從引用計數來看內存管理，那樣你會陷入實現的細節而脫離你真正的目標。你應該更多的從對象所有者和對象圖來考慮內存管理。
Cocoa使用瞭簡單的命名約定來表明你調用的方法返回的對象的內存類型。
See “MemoryManagement Policy.”
雖然比較基本的策略很明確，但同樣有一些很實用的步驟可以幫助你更容易的管理內存，從而是你的程序更健壯，更可靠，同時減少內存的實用
See “Practical Memory Management.”
自動釋放池提供瞭一種向對象延遲發送釋放消息的機制，當你放棄一個對象的所有權而又不想它立刻被釋放（例如你向從一個方法中返回一個對象）時，這種機制是非常有用的。有些場合你需要用到對象自動釋放池
See “Using Autorelease Pools.”
使用代碼分析工具來調試內存問題
為瞭發現你在編譯時候的代碼問題，你可以使用xcode的use the ClangStatic Analyzer
如果內存管理問題確實發生瞭，同樣有一些工具和技術來檢測和查找問題
· 很多的技術工具在Technical Note TN2239,iOSDebugging Magic中被描述，特別是使用NSZombie來幫助你發現over-released 的對象。
· 你也可以使用工具來跟蹤引用計數事件來查找內存泄露的問題。See “CollectingData on Your App”.
作者：lipeng08