Cocoa 編碼指南 框架開發(fā)者使用技巧和技術(shù)是本文要介紹的內(nèi)容，相對于其他的開發(fā)者而言，框架開發(fā)者要更加注意編寫代碼的方式。因為許多客戶應(yīng)用程序可能鏈接到框架，而這樣寬泛地暴露接口，就導(dǎo)致框架的任何缺點都可能通過系統(tǒng)放大。下面的條款討論一些框架編程技術(shù)，框架開發(fā)者可以利用它們來確保框架的高效性和完整性。

請注意：此處所討論的一些技術(shù)并不局限于框架開發(fā)。將之用于應(yīng)用程序開發(fā)同樣卓有成效。

初始化

下述意見和建議涵蓋框架初始化方面的內(nèi)容。

類的初始化

initialize類方法中的代碼只執(zhí)行一次，它是類里面***個被調(diào)用的方法。我們通常利用該方法來設(shè)置類的版本號（請參考“版本化和兼容性”一節(jié)）。

對于繼承鏈中的每一個類，不論其是否實現(xiàn)initialize方法，運行時都會向它發(fā)送initialize消息。這可能導(dǎo)致一個類的initialize方法被多次調(diào)用（舉個例子,如果子類沒有實現(xiàn)initialize方法,則其父類的方法將被調(diào)用兩次）。但通常您希望始化代碼僅執(zhí)行一次，為確保如此，您可以執(zhí)行如下檢查：

if (self == [NSFoo class]) {   
    // the initializing code   
}  

您不應(yīng)該顯式地調(diào)用initialize方法。如果需要觸發(fā)初始化行為，則請調(diào)用一些無害的方法，例如：

[NSImage self];  

指定初始化函數(shù)

指定初始化函數(shù)是類的一個init方法，它調(diào)用超類的某個init方法（其他的初始化函數(shù)調(diào)用類自己定義的init方法）。每個公共類都應(yīng)包含一個或多個指定初始化函數(shù)。舉些例子，NSView的initWithFrame:方法以及NSResponder的init方法都是指定初始化函數(shù)。在某些情況下，類的init方法并不想被重載，比如NSString和其他面向類簇的抽象類，因而其子類應(yīng)該實現(xiàn)自己的初始化方法。

您應(yīng)該明確標示出指定初始化函數(shù)，因為該信息對于想根據(jù)您的類來派生子類的開發(fā)者有重要的意義。一個子類可以只重載指定初始化函數(shù)，這對其他所有初始化函數(shù)沒有影響，它們?nèi)詫雌湓仍O(shè)計的行為工作。

在實現(xiàn)一個框架類時，您經(jīng)常需要為其實現(xiàn)諸如initWithCoder:以及encodeWithCoder:這樣的歸檔方法。請注意，對象解檔時未發(fā)生的事情不要放在初始化代碼路徑里執(zhí)行。對于實現(xiàn)歸檔功能的類，我們有一個比較好的方法可以做到這一點，那就是在類的指定初始化方法以及initWithCoder: 方法（該方法也是個指定初始化函數(shù)）中調(diào)用一個公共的例程。

初始化過程中的錯誤檢測

為確保能夠恰當?shù)貦z測并傳播錯誤，一個設(shè)計良好的初始化方法應(yīng)完成如下步驟：

調(diào)用super的init方法對self重新賦值。

檢測指定初始化方法的返回值是否為nil。返回值為nil表明超類的初始化過程出現(xiàn)錯誤。

如果當前類在初始化的過程中出現(xiàn)錯誤，則請釋放對象并且返回nil值。

列表1 描述的方法可以完成上述步驟。

列表1  初始化過程中的錯誤檢測

(id)init {   
    if ((self = [super init]) != nil) {   // call a designated initializer here   
        // initialize object  ...   
        if (someError) {   
            [self release]; // [self dealloc] or [super dealloc] might be   
            self = nil;     // better if object is malformed   
        }   
    }   
    return self;   
}  

版本化和兼容性

在向框架添加新類或新方法時，您通常沒必要為每個新功能群指定新的版本號。因為一般情況下，開發(fā)者會執(zhí)行（或者說，應(yīng)該執(zhí)行）諸如respondsToSelector:這種Objective-C的運行時檢測來判斷給定的系統(tǒng)是否存在某種功能。開發(fā)者比較喜歡使用這種方式來檢測新功能，同時它也是最動態(tài)的方式。

不論如何，您可以使用數(shù)種技術(shù)以確保新版本的框架能被正確標志并盡可能地兼容早期版本。

框架的版本

如果已存在的新功能或者錯誤改正不容易通過運行時進行檢測，則您應(yīng)該為開發(fā)者提供檢測這些變更的辦法。有一種辦法是把確切的框架版本號保存起來，然后讓該號碼對開發(fā)者可見：

把變更歸檔在一個版本號下面（例如，歸檔在發(fā)布記錄中）。

設(shè)置框架的當前版本號并且提供某種方法使之全局可見。您可以把版本號保存在框架的信息屬性列表（Info.plist），這樣就可以從該列表獲取版本號。

基于鍵的歸檔

如果框架對象需要被寫入到nib文件，則它們必須能夠自我歸擋 。另外，如果文檔使用歸擋機制來保存文檔數(shù)據(jù)，則您也要對它們做歸擋。在歸擋時，您可以使用“老風格”（利用initWithCoder:和encodeWithCoder:這樣的方法）。但是，為了更好地兼容過去、現(xiàn)在、以及未來的框架版本，您應(yīng)該基于健進行歸檔。

基于鍵進行歸檔，對象就可以使用鍵來讀取或?qū)懭氡粴w擋值。相對以往的歸擋機制，該方法可以在前向和后向兼容性上提供更多的靈活性。因為老歸檔機制要求代碼和讀取或?qū)懭氲闹稻S持相同的順序，而且它也沒有什么好辦法來改變已寫到檔案的數(shù)據(jù)。如果您需要了解更多基于鍵的歸檔機制，請參考 Cocoa歸檔和序列化編程指南 （Archives and Serializations Programming Guide for Cocoa）一文。

對于正在編寫的新的類，請為其使用基于鍵的歸檔機制。如果之前已發(fā)布的類使用了老歸檔機制，您也無需再采取任何措施。如果對象實現(xiàn)了Mac OS X 10.2版本之前的歸檔機制，則它必須能從檔案中讀取內(nèi)容并能其內(nèi)容寫入到檔案。但如果您在Mac OS X v10.2及之后的平臺上為該對象添加新屬性，則您不必，實際上是不應(yīng)該，將這些屬性保存到老檔案中（這樣做可能會使老檔案在更早的系統(tǒng)中變得不可讀?。@種情況下，新屬性應(yīng)使用鍵值歸檔機制。

請注意下列和基于鍵歸檔相關(guān)的事實：

如果檔案中的某個鍵丟失，則在獲取這個鍵對應(yīng)值的時候，依據(jù)所要求的類型，其返回值可能是nil、 NULL、NO、0、或者0。通過對該返回值進行測試，您可以減少寫到檔案中的數(shù)據(jù)。同時，還可以檢測某個鍵是否已被寫入到檔案中。

如果使用舊式歸檔，則initWithCoder:的實現(xiàn)需要獨自挑起兼容性的重擔。但如果使用鍵值歸檔，則歸檔方法和解檔方法都可以采取一些措施以保證兼容性。舉個例子，一個新版本的類的歸檔方法可能使用鍵來寫入一個新值，而依舊把早期的字段寫入到檔案中，這樣類的舊版本仍然可以理解該對象。與此同時，我們還可以在解檔方法中使用某種合理的方式以處理數(shù)值缺失的情況，從而為將來的版本保留一些靈活性。

在命名框架類的檔案鍵時，我們提倡使用和框架其他API元素一樣的前綴，前綴后面再使用實例變量名稱。您只要確保它的名稱不會和任意的子類或者超類名稱發(fā)生沖突即可。

如果您使用一個工具函數(shù)向檔案中寫入一個基本數(shù)據(jù)類型（換句話說，就是一個非對象的值），則請務(wù)必為該數(shù)值使用一個唯一鍵。舉個例子，如果您有一個對矩形歸檔的“archiveRect” 例程，則您應(yīng)該為該函數(shù)傳入一個鍵作為參數(shù)。您可以直接把它作為檔案鍵；或者，如果這個例程向檔案寫入多個值（例如，寫入四個浮點數(shù)值），則它應(yīng)該把每個數(shù)值自身獨有的位添加到所提供的鍵上面。

位字段對于編譯器和比特序有依賴關(guān)系，按照位字段現(xiàn)有的格式進行歸檔可能會有危險。只有當有多個位元需要被寫入檔案多次時，我們才會對位字段進行歸檔，這主要是為了提高性能。請參看 “位字段”一節(jié) 以獲取相關(guān)的建議。

對象的尺寸和保留字段

每個Objective-C的對象都有一個尺寸，它由對象自身實例變量加上對象所有超類具有的實例變量得到的總尺寸決定。如果改變了一個類的尺寸，則其擁有實例變量的子類必須重新編譯。為了保持二進制兼容性，通常情況下，我們不能通過向類添加新的實例變量或者去除類里面不必要的實例變量來改變對象的尺寸。

因此，對于新的類，為其留下幾個額外的”保留“字段以便于將來擴展是個不錯的想法。如果一個類只會有少數(shù)的幾個實例，這個想法顯然不成問題。但如果這個類會被實例化數(shù)千次，則您可能需要讓保留的單個變量的尺寸小一些（也就是說，任意對象都占用四個字節(jié)）。

對于較早的類的對象，如果它們的空間已經(jīng)用完（并且假定實例變量沒有被導(dǎo)出成為公共變量），則您可以移動實例變量，或者把它們捆綁在一起,使之成為一個更小的字段。通過對實例變量進行重新排布，您就有可能添加新的數(shù)據(jù)而不會導(dǎo)致對象的總尺寸發(fā)生改變?；蛘吣梢园岩粋€剩余的保留槽作為指針，使它可以指向一塊額外的內(nèi)存，然后您在對象初始化的時候分配這塊內(nèi)存（并且在對象釋放的時候銷毀它）。又或者您可以把額外的數(shù)據(jù)放入到一張外部的哈希表（例如放入NSDictionary）；這種方法對于那些很少創(chuàng)建使用的實例變量具有很好的效果。

異常和錯誤

大多數(shù)Cocoa框架的方法不會強制要求開發(fā)者捕捉處理異常，因為程序正常執(zhí)行時不會產(chǎn)生異常，而且我們通常也不使用異常來表示可預(yù)期的運行時錯誤或用戶錯誤。下面這些例子屬于可預(yù)期的運行時錯誤或者用戶錯誤：

文件找不到

用戶不存在

試圖打開應(yīng)用程序中一個錯誤類型的文檔

把字符串轉(zhuǎn)化為特定編碼時出現(xiàn)錯誤

但是不管怎么樣， Cocoa確實會引發(fā)異常以指示下面這些編程錯誤或者邏輯錯誤：

數(shù)組索引越界

試圖改變一個不可改變的對象

錯誤參數(shù)類型

我們認為應(yīng)用程序推向市場之前，開發(fā)者會對其進行測試，發(fā)現(xiàn)并解決這些類型的錯誤。因此，應(yīng)用程序不需要在運行時處理上述異常。如果出現(xiàn)一個異常發(fā)生但應(yīng)用程序沒有捕捉，則最頂層的缺省處理器通常會捕捉并且報告該異常，然后程序?qū)⒗^續(xù)執(zhí)行。開發(fā)者可以選擇替換掉這個缺省的異常處理器，新的處理器可以更詳細地描述什么地方發(fā)生了錯誤，并且還能夠讓用戶選擇是否保存數(shù)據(jù)并且推出應(yīng)用程序。

錯誤是Cocoa框架不同于其他軟件庫的又一個地方。Cocoa的方法通常不返回錯誤碼。某些情況下，一個錯誤具有一個合理或者可能的原因，方法通過對一個布爾值或者對象返回值（nil/non-nil）進行簡單測試以判斷該情況；但是返回NO或者nil值的原因則被記錄在文檔中。另外，您不應(yīng)該使用錯誤碼來指示需要在運行時處理的編程錯誤，相反您應(yīng)該引發(fā)一個異常，或者在某些情況下，您也可以只記錄下該錯誤而不引發(fā)異常。

舉個例子，NSDictionary的objectForKey:方法會返回所找到的對象，如果對象找不到，則它會返回nil值。NSArray的objectAtIndex:法不可能返回nil值（除非我們把通用的編程語言約定重載成向nil對象發(fā)送消息都會返回nil值），因為NSArray對象不能保存nil值，并且所有的越界訪問都被定義成編程錯誤，這種錯誤引發(fā)異常而并不返回nil對象。如果對象不能使用用戶提供的參數(shù)進行初始化，許多init方法都會返回nil值

在少數(shù)情況下，一個方法需要多個不同的錯誤碼是合理的。這時，該方法需要將錯誤碼指定到一個傳引用參數(shù)，然后您可以利用該參數(shù)返回一個錯誤碼，也可以返回一個本地化的錯誤字符串，或者一些其他的可以描述錯誤的信息。舉個例子，您可以把錯誤轉(zhuǎn)換成NSError對象返回（請參看Foundation框架的NSError.h頭文件以獲取更多的細節(jié)）。而除了這個NSError對象，方法還能直接返回相對簡單的BOOL值或者nil值。另外要注意，這種方法的所有傳引用參數(shù)都是可選的。因此，如果發(fā)送者不想了解錯誤原因，它們可以傳一個NULL 值給錯誤碼參數(shù)。

重要： NSError類在Mac OS X v10.3之后的版本對外公開。

框架數(shù)據(jù)

框架數(shù)據(jù)的處理方式可能會對性能、跨平臺兼容性、以及其他某些方面產(chǎn)生影響。本節(jié)討論一些和框架數(shù)據(jù)相關(guān)的技術(shù)。

常量數(shù)據(jù)

出于性能的原因，您應(yīng)盡可能多地把框架數(shù)據(jù)標志為常量，因為這樣可以減小Mach-O二進制文件的__DATA 段的尺寸。沒有const標記的全局或靜態(tài)的數(shù)據(jù)最終會存放在__DATA段的__DATA節(jié)。對于每一個使用該框架的應(yīng)用程序?qū)嵗?，這種類型的數(shù)據(jù)都會占用內(nèi)存。盡管多出500字節(jié)（舉個例子）好像沒那么糟糕，但是這有可能導(dǎo)致應(yīng)用程序所需的內(nèi)存頁面的數(shù)量增多—即每個應(yīng)用程序都需要額外的四千字節(jié)的內(nèi)存。

您應(yīng)該為所有不變的數(shù)據(jù)添加const標記。具有const標記的數(shù)據(jù)塊，如果其中沒有char *類型的指針，則該數(shù)據(jù)會被存放在__TEXT段中（這會使數(shù)據(jù)成為真正的常量）；否則數(shù)據(jù)就會被存放在__DATA段中，但是這些數(shù)據(jù)不可以被寫入（除非預(yù)綁定未完成，如果預(yù)邦定已經(jīng)完成，則只能在加載的時候，通過移動二進制文件的方式來寫入）。

您應(yīng)該初始化靜態(tài)變量，這樣可以確保該變量被合并到__DATA段的__data節(jié)中而非__bss節(jié)。如果沒有明顯的值用于初始化靜態(tài)變量，則請使用0、NULL、0.0、或者任何恰當?shù)闹怠?/p>

位字段

如果使用有符號的值來表示位字段，而代碼又假定這個位字段是布爾值，則可能會導(dǎo)致未定義的行為。只有一個位的位字段尤為如此。因為在這種情況下，這個位字段只能存儲0和 -1（取決于編譯器的實現(xiàn)），把它和1做比較，其結(jié)果總是不相等。因此，只有一個位的位字段應(yīng)該是無符號的。舉個例子，如果您在代碼中遇到如下情況：

BOOL isAttachment:1;   
int startTracking:1;  

您應(yīng)該把上述代碼中的類型改為unsigned int

和位字段相關(guān)的另一個問題是歸檔。通常情況下，您不應(yīng)該按照當前格式將其寫入到磁盤或者檔案中，因為當我們在另外的架構(gòu)或者編譯器中讀取這些字段時，它們的格式可能發(fā)生變化。

內(nèi)存分配

在框架代碼中，如果可以的話，***是完全避免分配內(nèi)存。如果出于某種原因，您需要一塊臨時的緩沖區(qū)，則通常情況下，使用棧比分配緩沖區(qū)更好。但是，棧的大小有限（棧總的大小通常為512千字節(jié)）， 因此是否使用棧取決于函數(shù)和您所需要的緩沖區(qū)的大小。通常情況下，如果您需要的緩沖區(qū)的大小不超過1000（或者是MAXPATHLE定義的值）字節(jié)，使用棧是合適的。

一個比較精細的方法是在開始的時候使用棧，但是如果所需要的內(nèi)存的大小超過了棧緩沖區(qū)的大小，則切換到malloc內(nèi)存分配方式。列表 2展示的代碼片段就是這么做的。

列表 2  使用棧內(nèi)存和通過malloc分配的緩沖區(qū)

#define STACKBUFSIZE (1000 / sizeof(YourElementType))   
 YourElementType stackBuffer[STACKBUFSIZE];   
 YourElementType *buf = stackBuffer;   
 int capacity = STACKBUFSIZE;  // In terms of YourElementType   
 int numElements = 0;  // In terms of YourElementType   
    
while (1) {   
    if (numElements > capacity) {  // Need more room   
        int newCapacity = capacity * 2;  // Or whatever your growth algorithm is   
        if (buf == stackBuffer) {  // Previously using stack; switch to allocated memory   
            buf = malloc(newCapacity * sizeof(YourElementType));   
            memmove(buf, stackBuffer, capacity * sizeof(YourElementType));   
        } else {  // Was already using malloc; simply realloc   
            buf = realloc(buf, newCapacity * sizeof(YourElementType));   
        }   
        capacity = newCapacity;   
    }   
    // ... use buf; increment numElements ...   
  }   
  // ...   
  if (buf != stackBuffer) free(buf);  

語言問題

下面的條款討論和Objective-C語言相關(guān)的問題，包括協(xié)議、對象比較、以及向?qū)ο蟀l(fā)送autorelease消息的時機。

向nil對象發(fā)送消息

在Objective-C中，只要消息的返回值是對象、任意的指針類型、或是其尺寸小于等于sizeof(void*)的整數(shù)型標量，我們就可以將其發(fā)送給nil對象，該消息將返回nil值。這個特性一種很有價值的編程資產(chǎn)，但是有一個問題需要注意。如果發(fā)送給nil對象的消息的返回值非上述類型（例如，消息返回任意的struct類型，或者浮點類型，或者任意的向量類型），則消息的返回值未定義。通常情況下，如果消息的返回值不是一個對象，則不要依賴這種行為，因為那是很糟糕的做法。在Power PC系統(tǒng)中，向nil對象發(fā)送上述類型的消息不會有問題，但對于其他架構(gòu)來說，這種行為行不通。

對象比較

通用的對象比較方法isEqual:和與對象類型關(guān)聯(lián)在一起的比較方法（諸如isEqualToString:）有一個重要的不同。isEqual:方法允許任何對象作為參數(shù)，如果用于比較的對象屬于不同的類，則該方法將返回NO值。而諸如isEqualToString:以及isEqualToArray:這樣的方法通常都假定參數(shù)是某種特定的類型（和接收者一樣的類型）。因此，這種函數(shù)不會執(zhí)行類型檢查，這使得它們運行速度比普通的對象比較方法快，但是安全性則不如之。對于那些從外部源獲取的值，例如從應(yīng)用程序的的信息屬性表（Info.plist）或者應(yīng)用程序的偏好設(shè)置獲取的值，在對其進行比較時，我們傾向于使用isEqual:方法，因為這種方法更安全；但如果我們已知道要進行比較的值的類型，則應(yīng)使用isEqualToString:方法。

關(guān)于isEqual:方法，還有一點就是它和hash方法的聯(lián)系。存放在基于散列的Cocoa集合類里的對象（例如存放在NSDictionary或者NSSet中的對象）有一個基本的不變式，即如果[A isEqual:B] == YES，則[A hash] == [B hash]也成立。因此，如果您重寫了類的isEqual:方法，則您也應(yīng)重寫hash方法以保持不變式成立。缺省情況下，isEqual:方法判斷對象地址指針是否相等，而hash方法則返回一個基于對象地址產(chǎn)生的hash數(shù)值，因此，這個不變式就可以保持成立。

協(xié)議

協(xié)議是Objective-C中一個有趣的概念，但是它們在Cocoa API中用得有限。之所以這樣做，有一個原因是協(xié)議有嚴格的設(shè)計要求。以某個含有十個方法的NSDataSource協(xié)議為例。如果某個開發(fā)人員遵循該協(xié)議并且實現(xiàn)其所有方法，而之后您又向該協(xié)議添加了一個新的方法，這就會破壞開發(fā)者和原有協(xié)議的一致性。因此，協(xié)議往往僅能包含它們***公開時所含有的方法集（除非您不期望其他開發(fā)者實現(xiàn)該協(xié)議）。因此，只有方法集不可能再增長時，才應(yīng)使用協(xié)議。如果您必須擴展某個協(xié)議，則您應(yīng)該添加一個新的協(xié)議，利用新協(xié)議來對原來的協(xié)議進行擴展，或者您可以把新方法添加在協(xié)議外部，并且在使用前檢查它是否存在。

基本上，上述的原因也可以解釋為何您不能使用常規(guī)協(xié)議來聲明委托方法。而把委托方法聲明為NSObjec上的范疇類— 即非正式的協(xié)議— 的另一個原因是我們可以選擇是否實現(xiàn)某個方法。

自動釋放的對象

返回對象值的方法或者函數(shù)，如果它們不是用于創(chuàng)建對象或者復(fù)制對象(new,alloc,copy 以及這些方法的變體)，則請務(wù)必讓其返回的對象可以autoreleased 。在此處，“自動釋放”并不一定表示對象應(yīng)該顯式自動釋放-即在返回對象之前，向?qū)ο蟀l(fā)送autorelease 消息。一般情況下，它僅表示返回值不是由調(diào)用者釋放。

出于性能方面的原因，請盡可能不要在方法實現(xiàn)中使用自動釋放的對象，特別是那些可能會在短時間內(nèi)頻繁執(zhí)行的代碼（例如在循環(huán)結(jié)構(gòu)中，循環(huán)次數(shù)未知并且可能是很多的情況）使用。舉個例子，對于下面的情況，您不應(yīng)該發(fā)送如下的消息：

[NSString stringWithCharacters:]  

而是應(yīng)該發(fā)送下面的消息：

[[NSString alloc] initWithCharacters:]  

當您不再需要該字符串對象時，請顯示地釋放它。但是，請記住有些時候方法或者函數(shù)會返回自動釋放的對象，這時您需要向?qū)ο蟀l(fā)送autorelease消息。

存取方法

在存取方法中作什么事情才是正確呢，這是個重要的問題。舉個例子，假設(shè)您在一個獲取方法中直接返回一個實例變量，而后立刻調(diào)用設(shè)置方法，則在釋放先前實例變量的時候就可能會有危險，因為它有可能把您之前返回的值給釋放掉。

Cocoa框架的原則是讓設(shè)置方法自動釋放實例變量先前的值,但某些情況下,所涉及的某個設(shè)置方法會被頻繁的調(diào)用（例如在一個很密集的循環(huán)中），這時候Cocoa的原則就不適用了。但在實踐中，這種情況非常罕見，除非是一些底層的對象才會如此。另外，諸如NSAttributedString、NSArray、以及NSDictionary這樣的通用集合不會自動釋放對象，這主要是為了維護對象的存在時間。它們只是簡單地留存或者釋放其含有的對象。另外，它們也應(yīng)該對這一事實進行歸檔，這樣客戶程序就可以了解這些對象的行為。

對于現(xiàn)在正在編寫的框架代碼， 我們建議在get方法中使用自動釋放的對象，因為這是最安全的方法：

(NSString *)title {   
    return [[instanceVar retain] autorelease];   
}   
    
- (void)setTitle:(NSString *)newTitle {   
    if (instanceVar != newTitle) {   
        [instanceVar release];   
        instanceVar = [newTitle copy];   
        // or retain, depending on object & usage   
    }   
}  

另外，我們還需要考慮設(shè)置方法是使用copy方式還是使用retain方式。如果您所感興趣的是對象的值而非實際對象本身，則請使用copy方式。一個一般性的經(jīng)驗法則是對實現(xiàn)NSCopying協(xié)議的對象使用copy方式（您不應(yīng)該在運行時檢測對象是否實現(xiàn)NSCopying協(xié)議，而應(yīng)該直接查找參考文檔）。通常情況下,諸如字符串、顏色、URL這樣的對象應(yīng)該能被復(fù)制；而像視圖、窗口這樣的對象則應(yīng)該可以被保持。而至于其他的對象（例如數(shù)組），是使用copy還是使用retain，則要根據(jù)具體情況決定。

小結(jié)：Cocoa 編碼指南 框架開發(fā)者使用技巧和技術(shù)的內(nèi)容介紹完了，希望本文對你有所幫助！關(guān)于Cocoa 編碼指南的更多內(nèi)容請參與編輯推薦。