ARC 即為 “automatic reference counting”，相比 MRR，主要區(qū)別在于是人為還是編譯器插入與內(nèi)存管理相關(guān)的語句。此文只會記錄 ARC 的內(nèi)存管理規(guī)則，以及一些如弱引用、自動釋放的快速返回等特性。所以這個標(biāo)題起大了（目的是為了和之前的文章標(biāo)題對齊??），要真探究自動引用技術(shù)的實現(xiàn)，大多是編譯器的工作了吧？
所有權(quán)修飾符
ARC 的出現(xiàn)引起了對引用計數(shù)模型的理解的變化：在 ARC 的環(huán)境下，開發(fā)者們不用苦思冥想加一、減一去操作對象的引用計數(shù)（這部分交給編譯器去完成），只需要知道被強引用的對象會存在，不再被強引用的對象會被釋放。
聲明 id 類型和對象類型時都必須加上所有權(quán)（ownership）修飾符，有四個選項：__strong, __weak, __unsafe_unretained, __autoreleasing。
__strong
__strong 是默認的修飾符。將對象賦給 __strong 修飾的變量后，該變量對對象有強引用，當(dāng)超出變量的作用域的時候，該變量銷毀，對象的強引用不復(fù)存在：
// ARC 下的
{
id __strong obj = [[NSObject alloc] init];
id __strong arr = [NSMutableArray array];
}
// 等同于
// MRR 下的
{
id obj = [[NSObject alloc] init];
id arr = [NSMutableArray array];
[obj release];
}
編譯器對于符合命名規(guī)則的實例化方法，能正確地判斷怎么釋放對象，比如上面的 arr 變量就不會被發(fā)送 -release 消息。所以光 __strong 修飾符是能完成內(nèi)存管理法則中的前兩條的工作，至于后面如何釋放，由編譯器推斷好了。
__weak
前面提到被強用的對象不會被銷毀，那么兩個對象相互強引用那就不得了了，除非打破這個循環(huán)引用，否則它們永遠都不會被釋放，這個時候弱引用就派上用場了。除此之外，__weak 修飾的變量，在其所指向的強引用的對象被釋放時，會自動設(shè)置為 nil；
__unsafe_unretained
__unsafe_unretained 貌似是為了兼容 iOS 4 及以前的運行環(huán)境而出現(xiàn)的。作用與 __weak 類似，不同之處在于它所修飾的變量，不會在所指對象銷毀時被置 nil：
id __weak weakObj;
id __unsafe_unretained unsafeObj;
@autoreleasepool {
id obj = [[NSObject alloc] init];
weakObj = obj;
unsafeObj = obj;
}
NSLog(@"%@", weakObj); // 打印 (null)
NSLog(@"%@", unsafeObj); // 爆炸??????
__autoreleasing
對象賦給由 __autoreleasing 修飾的變量時，會被注冊到自動釋放池中。當(dāng)然像下面這樣不用顯式使用 __autoreleasing 修飾，作為返回值的對象，也會被編譯器注冊到自動釋放池中（也不一定，后面會提到另一種情況）：
+(id)array {
return [NSMutableArray new];
}
關(guān)于 __autoreleasing 還有個很有意思的是，我們在寫一些向上返回 NSError 對象的方法時，編譯器會將 NSError ** 解釋為 NSError *__autoreleasing * 像這樣：
-(void)foo {
NSError *error = nil;
if ([self barWithError:<#(NSError *__autoreleasing *)#>]) {
// handle error
}
}
-(BOOL)barWithError:(NSError **)error {
BOOL inevitableError = YES;
if (error && *error) {
*error = [[NSError alloc] init];
}
return inevitableError;
}
這個也是服從內(nèi)存管理規(guī)則的，畢竟這個 NSError 對象不是外部調(diào)用者使用 allow/new/copy/mutableCopy 開頭的方法生成并持的。
弱引用
__weak 修飾的變量是如何“自動”地被置為 nil 的？
要回答這個問題必須了解弱引用的實現(xiàn)，先看一個例子探究其如何存儲（ MRR 下也是可以開啟弱引用的）：
id obj = [NSObject new];
id __weak weakObj = obj;
[obj release];
NSLog(@"%@", weakObj);
結(jié)合 NSObject.mm 和 object-weak.mm 這兩個文件，通過查看匯編和符號斷點調(diào)試，可以推測上面例子的實際調(diào)用過程：
extern id objc_initWeak(id *location, id newObj);
extern void objc_destroyWeak(id *location);
id obj = [NSObject new];
id weakObj;
objc_initWeak(&weakObj, obj);
[obj release];
NSLog(@"%@", objc_loadWeak(&weakObj));
objc_destroyWeak(&weakObj);
介紹上面函數(shù)之前，先看一下與弱引用表等數(shù)據(jù)結(jié)構(gòu)，如下圖：
還記得那 64 個 SideTable 小格子嗎？每個 SideTable 都有這么個結(jié)構(gòu)體 weak_table 作為成員。而 weak_table_t 包含 weak_entries 這個指針，指向一塊包含多個條目的內(nèi)存區(qū)域，每一次給弱變量賦予不同的對象，都會產(chǎn)生一個新的條目，而當(dāng)一個對象不再存在弱引用變量時，這個條目也會被移除，這塊內(nèi)存是大小是不斷變化的。weak_entry_t 中的 referent 正是被弱引用指向的對象，下面有個聯(lián)合體，其中上下兩個結(jié)構(gòu)體占用的內(nèi)存是相同的，它們的使用是一種“或”的關(guān)系，其作用是存放弱變量的地址，當(dāng)數(shù)目不超過 WEAK_INLINE_COUNT 時，把這些地址存放到 inline_referrers 這個數(shù)組中去，否則存到 referrers 指向的內(nèi)存區(qū)域中，其大小也是動態(tài)變化的。
回到函數(shù)的實現(xiàn)，這里不貼代碼，只記錄其大概的工作流程：
-
objc_init()通過簡單的賦值讓weakObj和obj指向相同的對象，然后對obj散列，映射到一個 SideTable 的weak_table后，創(chuàng)建一個weak_entry_t把對象地址和weakObj變量的地址存起來； -
objc_loadWeak()任何取得__weak變量的值的地方都會用到這個函數(shù)，它對&weakObj解引用，如果解引用的結(jié)果是nil或者weakObj指向的對象在沒有相應(yīng)的weak_entry_t，返回nil；否則返回該對象并向?qū)ο蟀l(fā)送-retain和-autorelease消息； -
objc_destroyWeak()則是移除已注冊的弱引用變量。如果移除后，某個對象不再有弱引用，那么釋放存在于weak_table中條目。
那么問題來了，哪個函數(shù)將 weakObj 置為 nil 了？
答案就在 [obj release] 這一行中，當(dāng) obj 要被釋放，其調(diào)用的函授大概是這樣的：
objc_object::rootDealloc()
object_dispose(id obj)
objc_object::clearDeallocating()
weak_clear_no_lock(weak_table_t *weak_table, id referent_id)
由于先前在 objc_init() 的時候存下了弱引用的地址，在 weak_clear_no_lock() 函數(shù)中很容易通過 *referrer = nil 將其置為 nil。
自動釋放的快速返回
好吧這個名字是我自己起的 = =，通過 objc_autoreleaseReturnValue() 和 objc_retainAutoreleasedReturnValue() 等函數(shù)，優(yōu)化內(nèi)存管理，減少注冊到自動釋放池的對象數(shù)量。比如說下面這一段 MRR 下的代碼：
+(instancetype)randomPerson {
Person * p = [[Person alloc] init];
return [p autorelease];
}
+(void)test {
Person *p = [[Person randomPerson] retain];
[p doSomething];
[p release];
}
在獲得 +randomPerson 后，由于我并不持有它，生怕它在某個時刻被釋放掉而 do 不了 something，所以要 retain 一下。
而這份代碼在 ARC 下經(jīng)過編譯器改寫后據(jù)說是醬紫的：
+(instancetype)randomPerson {
Person * p = [[Person alloc] init];
return objc_autoreleaseReturnValue(p);
}
+(void)test {
Person *p = objc_retainAutoreleasedReturnValue([Person randomPerson]);
[p doSomething];
objc_storeStrong(&p, nil); // 相當(dāng)于 [p release]
}
但是如果編譯器知道代碼會 retain 一下 +randomPerson 返回的對象，那么就不會把這個對象放到自動釋放池中以減少額外的開銷。
不管是什么書還是博客都這么說，但是我在測驗的時候，寫下這樣的代碼：
__strong Person *p = [Person randomPerson];
__strong Person *k = [Person randomPerson];
[p doSomething];
[k doSomething];
_objc_autoreleasePoolPrint();
還是能看到有一個 Person 對象被注冊到自動釋放池中。
把 __strong 改成 __weak 的話就合乎情理——兩個對象都被注冊到自動釋放池中。
關(guān)于這點想了好久都沒搞清楚，所以我打算得到新的 objc-runtime 的源碼之后再回到這個問題上。??
