iOS的記憶體管理算是老生常談的問題了，我們寫iOS的時候無時無刻不在涉及到記憶體管理。從開始的MRR(manual retain-release)到後來ARC(Automatic Reference Counting)，包括CoreFoundation的記憶體管理都遵守引用計數的基本原則。
基本的記憶體管理大家肯定都很熟悉，在這裡主要說一點，其餘的就不多說了。官方文件有這樣的一段話
– You own any object you create
You create an object using a method whose name begins with “alloc”, “new”, “copy”, or “mutableCopy” (for example, alloc, newObject, or mutableCopy).
大意就是說，如果你使用alloc/new/copy/mutableCopy這些開頭的方法建立了一個物件，那麼你就會擁有這個物件(retain)。當你不用的時候，你就需要手動的去release一次。
舉一個例子，假設有一個方法，[STObject newObject]
我們應該這麼使用，如果我們最後不release，就會導致Object被洩漏。
|
1 2 3 |
STObject *object = [STObject newObject]; // do something [object release]; |
既然這樣的話，我們也可以想象出如果我們要自己實現new開頭的方法，我們需要如下程式碼
|
1 2 3 4 5 6 7 |
- (instancetype)newObject { return [[[self class] alloc] init]; } + (UIButton *)copyButton { return [[UIButton buttonWithType:UIButtonTypeCustom] retain]; } |
那麼就產生了以下幾個問題：
- MRR下實現了一個newObject方法，該方法遵守約定的原則，返回值會retain+1，然後在ARC下呼叫該方法建立物件
- MRR下實現了一個newObject方法，該方法沒有遵守約定原則，返回autorelease的物件，然後在ARC下呼叫該方法建立物件
- ARC下實現了一個newObject方法，然後在MRR下呼叫newObject方法建立物件，使用完成之後release
- ARC下實現了一個newObject方法，然後在MRR下呼叫newObject方法建立物件，使用完成之後沒有release
我們可以自己編寫以上的實驗程式碼，然後測試。
最終測試結果如下:
- 場景1，3下執行正常
- 場景2下會crash
- 場景4下產生記憶體洩露
為什麼場景2會crash呢？這是由於ARC下我們編譯器如果看到你是以alloc/new/copy/mutableCopy等開頭的方法建立了物件，則會在使用的最後插入一次release操作，由於返回的是autorelease的物件，又被release了一次，所以導致野指標。
場景4產生洩漏的原因也是一樣，ARC下編譯器發現該方法是new等開頭的時候，方法結束的時候不會插入release語句，場景4使用的過程中，沒有對newObject進行release，所以會產生洩漏。
如果我們僅使用MRR或者ARC的話，這種問題一般不會出現。這種問題的出現一般是當ARC/MRR混編的時候，由於一些編寫的不規範導致的，所以在寫程式碼的過程中，遵守規範是很有必要的。
如果我們自己編寫alloc/new/copy/mutableCopy開頭的方法的時候，MRR下一定不要忘了返回retain的物件，同樣當我們使用alloc/new/copy/mutableCopy的方法建立物件的時候，也不能忘了在用完之後release。
如果我們有一段MRR的程式碼，提供了一個new開頭的方法但是沒有遵守規範，我們ARC下該怎麼辦呢？按照上面的結論，我們正常使用肯定會導致野指標的
在這裡呢，如果能改程式碼當然把程式碼都改成遵守規範的最好，如果不能改原始碼的話，我們只能修改使用方。在這裡提供一種方法：
|
1 2 |
SEL selector = NSSelectorFromString(@"copyObject"); STObject *object = (STObject *)[STObject performSelector:selector]; |
大家可以嘗試一下，然後思考一下為什麼。
關於iOS的記憶體管理遠遠不止這些，本文中說的大家實際編碼的過程中也很少遇到，僅僅當作知識的補充吧～