weak的生命周期

我們都知道weak表示的是一個(gè)弱引用，這個(gè)引用不會(huì)增加對(duì)象的引用計(jì)數(shù)，并且在所指向的對(duì)象被釋放之后，weak指針會(huì)被設(shè)置的為nil。weak引用通常是用于處理循環(huán)引用的問(wèn)題，如代理及block的使用中，相對(duì)會(huì)較多的使用到weak。

之前對(duì)weak的實(shí)現(xiàn)略有了解，知道它的一個(gè)基本的生命周期，但具體是怎么實(shí)現(xiàn)的，了解得不是太清晰。今天又翻了翻《Objective-C高級(jí)編程》關(guān)于__weak的講解，在此做個(gè)筆記。

我們以下面這行代碼為例：

代碼清單1：示例代碼

{ 
id __weak obj1 = obj; 
} 

當(dāng)我們初始化一個(gè)weak變量時(shí)，runtime會(huì)調(diào)用objc_initWeak函數(shù)。這個(gè)函數(shù)在Clang中的聲明如下：

id objc_initWeak(id *object, id value); 

其具體實(shí)現(xiàn)如下：

id objc_initWeak(id *object, id value) 
{ 
*object = 0; 
return objc_storeWeak(object, value); 
} 

示例代碼輪換成編譯器的模擬代碼如下：

id obj1; 
objc_initWeak(&obj1, obj); 

因此，這里所做的事是先將obj1初始化為0(nil)，然后將obj1的地址及obj作為參數(shù)傳遞給objc_storeWeak函數(shù)。

objc_initWeak函數(shù)有一個(gè)前提條件：就是object必須是一個(gè)沒(méi)有被注冊(cè)為_(kāi)_weak對(duì)象的有效指針。而value則可以是null，或者指向一個(gè)有效的對(duì)象。

如果value是一個(gè)空指針或者其指向的對(duì)象已經(jīng)被釋放了，則object是zero-initialized的。否則，object將被注冊(cè)為一個(gè)指向value的__weak對(duì)象。而這事應(yīng)該是objc_storeWeak函數(shù)干的。objc_storeWeak的函數(shù)聲明如下：

id objc_storeWeak(id *location, id value); 

其具體實(shí)現(xiàn)如下：

id objc_storeWeak(id *location, id newObj) 
{ 
id oldObj; 
SideTable *oldTable; 
SideTable *newTable; 
 
...... 
 
// Acquire locks for old and new values. 
// Order by lock address to prevent lock ordering problems. 
// Retry if the old value changes underneath us. 
retry: 
oldObj = *location; 
 
oldTable = SideTable::tableForPointer(oldObj); 
newTable = SideTable::tableForPointer(newObj); 
 
...... 
 
if (*location != oldObj) { 
OSSpinLockUnlock(lock1); 
#if SIDE_TABLE_STRIPE > 1 
if (lock1 != lock2) OSSpinLockUnlock(lock2); 
#endif 
goto retry; 
} 
 
if (oldObj) { 
weak_unregister_no_lock(&oldTable->weak_table, oldObj, location); 
} 
if (newObj) { 
newObj = weak_register_no_lock(&newTable->weak_table, newObj,location); 
// weak_register_no_lock returns NULL if weak store should be rejected 
} 
// Do not set *location anywhere else. That would introduce a race. 
*location = newObj; 
 
...... 
 
return newObj; 
} 

我們撇開(kāi)源碼中各種鎖操作，來(lái)看看這段代碼都做了些什么。在此之前，我們先來(lái)了解下weak表和SideTable。

weak表是一個(gè)弱引用表，實(shí)現(xiàn)為一個(gè)weak_table_t結(jié)構(gòu)體，存儲(chǔ)了某個(gè)對(duì)象相關(guān)的的所有的弱引用信息。其定義如下(具體定義在objc-weak.h中)：

struct weak_table_t { 
weak_entry_t *weak_entries; 
size_t num_entries; 
...... 
}; 

其中weak_entry_t是存儲(chǔ)在弱引用表中的一個(gè)內(nèi)部結(jié)構(gòu)體，它負(fù)責(zé)維護(hù)和存儲(chǔ)指向一個(gè)對(duì)象的所有弱引用hash表。其定義如下：

struct weak_entry_t { 
DisguisedPtr<objc_object> referent; 
union { 
struct { 
weak_referrer_t *referrers; 
uintptr_t out_of_line : 1; 
...... 
}; 
struct { 
// out_of_line=0 is LSB of one of these (don't care which) 
weak_referrer_t inline_referrers[WEAK_INLINE_COUNT]; 
}; 
}; 
}; 

其中referent是被引用的對(duì)象，即示例代碼中的obj對(duì)象。下面的union即存儲(chǔ)了所有指向該對(duì)象的弱引用。由注釋可以看到，當(dāng)out_of_line等于0時(shí)，hash表被一個(gè)數(shù)組所代替。另外，所有的弱引用對(duì)象的地址都是存儲(chǔ)在weak_referrer_t指針的地址中。其定義如下：

typedef objc_object ** weak_referrer_t;

SideTable是一個(gè)用C++實(shí)現(xiàn)的類，它的具體定義在NSObject.mm中，我們來(lái)看看它的一些成員變量的定義：

class SideTable { 
private: 
static uint8_t table_buf[SIDE_TABLE_STRIPE * SIDE_TABLE_SIZE]; 
 
public: 
 
RefcountMap refcnts; 
weak_table_t weak_table; 
 
...... 
 
} 

RefcountMap refcnts，大家應(yīng)該能猜到這個(gè)做什么用的吧？看著像是引用計(jì)數(shù)什么的。哈哈，貌似就是啊，這東東存儲(chǔ)了一個(gè)對(duì)象的引用計(jì)數(shù)的信息。當(dāng)然，我們?cè)谶@里不去探究它，我們關(guān)注的是weak_table。這個(gè)成員變量指向的就是一個(gè)對(duì)象的weak表。

了解了weak表和SideTable，讓我們?cè)倩剡^(guò)頭來(lái)看看objc_storeWeak。首先是根據(jù)weak指針找到其指向的老的對(duì)象：

oldObj = *location; 

然后獲取到與新舊對(duì)象相關(guān)的SideTable對(duì)象：

oldTable = SideTable::tableForPointer(oldObj); 
newTable = SideTable::tableForPointer(newObj); 
 
下面要做的就是在老對(duì)象的weak表中移除指向信息，而在新對(duì)象的weak表中建立關(guān)聯(lián)信息： 
 
if (oldObj) { 
weak_unregister_no_lock(&oldTable->weak_table, oldObj, location); 
} 
if (newObj) { 
newObj = weak_register_no_lock(&newTable->weak_table, newObj,location); 
// weak_register_no_lock returns NULL if weak store should be rejected 
} 

接下來(lái)讓弱引用指針指向新的對(duì)象：

*location = newObj; 

***會(huì)返回這個(gè)新對(duì)象：

return newObj; 

objc_storeWeak的基本實(shí)現(xiàn)就是這樣。當(dāng)然，在objc_initWeak中調(diào)用objc_storeWeak時(shí)，老對(duì)象是空的，所有不會(huì)執(zhí)行weak_unregister_no_lock操作。

而當(dāng)weak引用指向的對(duì)象被釋放時(shí)，又是如何去處理weak指針的呢？當(dāng)釋放對(duì)象時(shí)，其基本流程如下：

調(diào)用objc_release

因?yàn)閷?duì)象的引用計(jì)數(shù)為0，所以執(zhí)行dealloc

在dealloc中，調(diào)用了_objc_rootDealloc函數(shù)

在_objc_rootDealloc中，調(diào)用了object_dispose函數(shù)

調(diào)用objc_destructInstance

***調(diào)用objc_clear_deallocating

我們重點(diǎn)關(guān)注一下***一步，objc_clear_deallocating的具體實(shí)現(xiàn)如下：

void objc_clear_deallocating(id obj) 
{ 
...... 
 
SideTable *table = SideTable::tableForPointer(obj); 
 
// clear any weak table items 
// clear extra retain count and deallocating bit 
// (fixme warn or abort if extra retain count == 0 ?) 
OSSpinLockLock(&table->slock); 
if (seen_weak_refs) { 
arr_clear_deallocating(&table->weak_table, obj); 
} 
...... 
} 

我們可以看到，在這個(gè)函數(shù)中，首先取出對(duì)象對(duì)應(yīng)的SideTable實(shí)例，如果這個(gè)對(duì)象有關(guān)聯(lián)的弱引用，則調(diào)用arr_clear_deallocating來(lái)清除對(duì)象的弱引用信息。我們來(lái)看看arr_clear_deallocating具體實(shí)現(xiàn)：

PRIVATE_EXTERN void arr_clear_deallocating(weak_table_t *weak_table, id referent) { 
{ 
weak_entry_t *entry = weak_entry_for_referent(weak_table, referent); 
if (entry == NULL) { 
...... 
return; 
} 
// zero out references 
for (int i = 0; i < entry->referrers.num_allocated; ++i) { 
id *referrer = entry->referrers.refs[i].referrer; 
if (referrer) { 
if (*referrer == referent) { 
*referrer = nil; 
} 
else if (*referrer) { 
_objc_inform("__weak variable @ %p holds %p instead of %p\n", referrer, *referrer, referent); 
} 
} 
} 
 
weak_entry_remove_no_lock(weak_table, entry); 
weak_table->num_weak_refs--; 
} 
} 

這個(gè)函數(shù)首先是找出對(duì)象對(duì)應(yīng)的weak_entry_t鏈表，然后挨個(gè)將弱引用置為nil。***清理對(duì)象的記錄。

通過(guò)上面的描述，我們基本能了解一個(gè)weak引用從生到死的過(guò)程。從這個(gè)流程可以看出，一個(gè)weak引用的處理涉及各種查表、添加與刪除操作，還是有一定消耗的。所以如果大量使用__weak變量的話，會(huì)對(duì)性能造成一定的影響。那么，我們應(yīng)該在什么時(shí)候去使用weak呢？《Objective-C高級(jí)編程》給我們的建議是只在避免循環(huán)引用的時(shí)候使用__weak修飾符。

另外，在clang中，還提供了不少關(guān)于weak引用的處理函數(shù)。如objc_loadWeak, objc_destroyWeak, objc_moveWeak等，我們可以在蘋(píng)果的開(kāi)源代碼中找到相關(guān)的實(shí)現(xiàn)。等有時(shí)間，我再好好研究研究。

參考

《Objective-C高級(jí)編程》1.4: __weak修飾符

Clang 3.7 documentation – Objective-C Automatic Reference Counting (ARC)

apple opensource – NSObject.mm

零碎

CAGradientLayer

CAGradientLayer類是用于在其背景色上繪制一個(gè)顏色漸變，以填充層的整個(gè)形狀，包括圓角。這個(gè)類繼承自CALayer類，使用起來(lái)還是很方便的。

與Quartz 2D中的漸變處理類似，一個(gè)漸變有一個(gè)起始位置(startPoint)和一個(gè)結(jié)束位置(endPoint)，在這兩個(gè)位置之間，我們可以指定一組顏色值(colors，元素是CGColorRef對(duì)象)，可以是兩個(gè)，也可以是多個(gè)，每個(gè)顏色值會(huì)對(duì)應(yīng)一個(gè)位置(locations)。另外，漸變還分為軸向漸變和徑向漸變。

我們寫(xiě)個(gè)實(shí)例來(lái)看看CAGradientLayer的具體使用：

CAGradientLayer *layer = [CAGradientLayer layer]; 
layer.startPoint = (CGPoint){0.5f, 0.0f}; 
layer.endPoint = (CGPoint){0.5f, 1.0f}; 
layer.colors = [NSArray arrayWithObjects:(id)[UIColor blueColor].CGColor, (id)[UIColor redColor].CGColor, (id)[UIColor greenColor].CGColor, nil]; 
layer.locations = @[@0.0f, @0.6f, @1.0f]; 
layer.frame = self.view.layer.bounds; 
 
[self.view.layer insertSublayer:layer atIndex:0]; 

參考

CAGradientLayer Class Reference

Xcode中Ineligible Devices的處理

換了臺(tái)新電腦，裝了個(gè)Xcode 6.3，整了個(gè)新證書(shū)和profile，然后打開(kāi)Xcode，連上手機(jī)。額，然后發(fā)現(xiàn)設(shè)備居然被標(biāo)識(shí)為Ineligible Devices，沒(méi)認(rèn)出來(lái)。情況類似于下圖：

電腦是受信任的，證書(shū)和profile也都是OK的。試了幾次重啟Xcode和重新連接手機(jī)，無(wú)效。設(shè)備就是選不了。***是在Product->Destination里面才選中這個(gè)設(shè)備的。不過(guò)在工具欄還是不能選擇，郁悶，求解。

iOS 7后隱藏UITextField的光標(biāo)

新項(xiàng)目只支持iOS 7后，很多事情變得簡(jiǎn)單多了，就像隱藏UITextField的光標(biāo)一樣，就簡(jiǎn)單的一句話：

textFiled.tintColor = [UIColor clearColor];

通常我們用UIPickerView作為我們的UITextField的inputView時(shí)，我們是需要隱藏光標(biāo)的。當(dāng)然，如果想換個(gè)光標(biāo)顏色，也是這么處理。

這么處理的有個(gè)遺留問(wèn)題是：通常我們使用UIPickerView作為UITextField的inputView時(shí)， 并不希望去執(zhí)行各種菜單操作(全選、復(fù)制、粘帖)，但只是去設(shè)置UITextField的tintColor時(shí)，我們?nèi)匀豢梢詧?zhí)行這邊操作，所以需要加額外的處理。這個(gè)問(wèn)題，我們可以這樣處理：在textFieldShouldBeginEditing:中，我們把UITextField的userInteractionEnabled設(shè)置為NO，然后在textFieldShouldEndEditing:，將將這個(gè)值設(shè)置回來(lái)。如下：

- (BOOL)textFieldShouldBeginEditing:(UITextField *)textField { 
 
textField.userInteractionEnabled = NO; 
 
return YES; 
} 
 
- (BOOL)textFieldShouldEndEditing:(UITextField *)textField { 
 
textField.userInteractionEnabled = YES; 
 
return YES; 
} 

這樣就OK了。當(dāng)然這只是我們當(dāng)前使用的一種處理方式，還有其它的方法，直接google或者stackoverflow吧。

iOS 7后UIAlertView中文字左對(duì)齊問(wèn)題

在iOS 7之前，如果我們想要讓UIAlertView中的文字居左顯示的話，可以使用以下這段代碼來(lái)處理：

for (UIView *view in alert.subviews) { 
if([[view class] isSubclassOfClass:[UILabel class]]) { 
((UILabel*)view).textAlignment = NSTextAlignmentLeft; 
} 
} 

但很遺憾的是，在iOS 7之后，蘋(píng)果不讓我們這么干了。我們?nèi)トIAlertView的subviews時(shí)，獲得的只是一個(gè)空數(shù)組，我們沒(méi)有辦法獲取到我們想要的label。怎么辦？三條路：告訴產(chǎn)品經(jīng)理和UED說(shuō)這個(gè)實(shí)現(xiàn)不了(當(dāng)然，這個(gè)是會(huì)被鄙視的，人家會(huì)說(shuō)你能力差)；自己寫(xiě)；找第三方開(kāi)源代碼。嘿嘿，不過(guò)由于最近時(shí)間緊，所以我決定跟他們說(shuō)實(shí)現(xiàn)不了，哈哈。不過(guò)在github上找了一個(gè)開(kāi)源的，Custom iOS AlertView，star的數(shù)量也不少，看來(lái)不錯(cuò)，回頭好好研究研究。