Effective Objective-C2.0 編寫高質(zhì)量代碼的52個有效方法

閑來無事的時候就把effective OC這本書的52個知識點就謄寫了下,沒事的時候可以看看羔挡。

一腻格、熟悉objective-C

1.了解OC語言的起源

(1)OC為C語言添加了面向?qū)ο筇匦哉锷蓿瞧涑ゲC使用動態(tài)綁定的消息結(jié)構(gòu),也就是說托猩,在運行時才會檢查對象類型印蓖。接收一條消息后,究竟應(yīng)該執(zhí)行何種代碼京腥,由運行環(huán)境而非編譯器決定赦肃。
(2)理解C語言的核心概念有助于寫好OC程序。尤其要掌握內(nèi)存模型與指針公浪。

2.在類的頭文件中盡量少引用其他的頭文件

(1)除非確有必要他宛,否則不要引入頭文件。一般來說欠气,應(yīng)在某個類的頭文件中使用向前聲明提及別的類厅各,并在文件中引入那些類的頭文件。這樣做可以盡量降低類之間的耦合预柒。
(2)有時無法使用向前聲明队塘,比如要聲明某個類遵循一項協(xié)議。這種情況下宜鸯,盡量把"該類遵循某協(xié)議"的這條聲明移至"class-continuation分類"中憔古。如果不行的話,就把協(xié)議單獨放在一個頭文件中淋袖,然后將其引入投放。

3.多用字面量語法,少用與之等價的方法

(1)應(yīng)該使用字面量語法來創(chuàng)建字符串适贸、數(shù)組、數(shù)值涝桅、字典拜姿。與創(chuàng)建此類對象的常規(guī)方法相比,這么做更加簡明扼要冯遂。
(2)應(yīng)該通過取下標操作來訪問數(shù)組下標或字典中的鍵所對應(yīng)的元素蕊肥。
(3)用字面常量無法創(chuàng)建數(shù)組或字典時,若值中有nil蛤肌,則會拋出異常壁却。因此,務(wù)必確保值里不含nil裸准。

4.多用類型常量展东,少用#define預(yù)處理指令

(1)不要用預(yù)處理指令定義常量。這樣定義出來的常量不含類型信息炒俱,編譯器只是會在編譯前據(jù)此執(zhí)行查找與替換操作盐肃。即使有人重新定義了常量值爪膊,編譯器也不會產(chǎn)生警告信息,這將導(dǎo)致應(yīng)用程序中的常量不一致砸王。
(2)在實現(xiàn)文件使用static const來定義"只在編譯單元內(nèi)可見的常量"(translation-unit-specific constant)推盛。由于此類常量不在全局符號表中,所以無須為其添加名稱前綴谦铃。
(3)在頭文件中使用extern來聲明全局常量耘成,并在相關(guān)實現(xiàn)文件中定義其值。這種常量要出現(xiàn)在全局符號表中驹闰,所以其名稱應(yīng)該加以區(qū)隔瘪菌,通常用與之相關(guān)的類名作前綴。

5.用枚舉值表示狀態(tài)疮方、選項控嗜、狀態(tài)碼

(1)應(yīng)該用枚舉值來表示狀態(tài)機的狀態(tài)、傳遞給方法的選項以及狀態(tài)碼等值骡显,給這些值起一個易懂的名字疆栏。
(2)如果把傳遞給某個方法的選項表示為枚舉類型,而多個選項又可同時使用惫谤,那么就將各選項值定義為2的冪壁顶,以便通過按位或操作將其組合起來。
(3)用NS_ENUM與NS_OPTIONS宏來定義枚舉類型溜歪,并指明其底層數(shù)據(jù)類型若专。這樣做可以確保枚舉是用開發(fā)者所選的底層數(shù)據(jù)類型實現(xiàn)出來的,而不會采用編譯器所選的類型蝴猪。
(4)在處理枚舉類型的switch語句中不要實現(xiàn)default分支调衰。這樣的話,加入新枚舉之后自阱,編譯器就會提示開發(fā)者:switch語句未處理所有枚舉嚎莉。

二、對象沛豌、消息趋箩、運行時

6.理解"屬性"這一概念

(1)可以用@property語法來定義對象中所封裝的數(shù)據(jù)。
(2)通過"特質(zhì)"來指定存儲數(shù)據(jù)所需要的正確語義加派。
(3)在設(shè)置屬性所對應(yīng)的實例變量時叫确,一定要遵循該屬性所聲明的語義。
(4)開發(fā)iOS程序時應(yīng)該使用nonatomic屬性芍锦,因為atomic屬性會嚴重影響性能竹勉。

7.在對象內(nèi)部盡量直接訪問實例變量

(1)在對象內(nèi)部讀取數(shù)據(jù)時,應(yīng)該直接通過實例變量來讀取醉旦,而寫入數(shù)據(jù)時饶米,則應(yīng)該通過屬性來寫桨啃。
(2)在初始化方法及dealloc方法中,總是應(yīng)該直接通過實例變量來讀寫數(shù)據(jù)檬输。
(3)有時會使用惰性初始化技術(shù)配置某份數(shù)據(jù)照瘾,這種情況下,需要通過屬性來讀取數(shù)據(jù)丧慈。

8.理解"對象等同性"這一概念

(1)若想檢測對象的等同性析命,請?zhí)峁?is Equal:"與hash方法。
(2)相同的對象必須具有相同的哈希碼逃默,但是兩個哈希碼相同的對象卻未必相同鹃愤。
(3)不要盲目地逐個檢測每條屬性,而是應(yīng)該依照具體需求來指定檢測方案完域。
(4)編寫hash方法時软吐,應(yīng)該使用計算速度快而且哈希碼碰撞幾率低的算法。

9.以"類族模式"隱藏實現(xiàn)細節(jié)

(1)類族模式可以把實現(xiàn)細節(jié)隱藏在一套簡單的公共接口后面吟税。
(2)系統(tǒng)框架中經(jīng)常使用類族凹耙。
(3)從類族的公共抽象基類中繼承子類時要當心,若有開發(fā)文檔肠仪,則應(yīng)首先閱讀肖抱。

10.在既有類中使用關(guān)聯(lián)對象存放自定義數(shù)據(jù)

(1)可以通過"關(guān)聯(lián)對象"機制來把兩個對象連起來。
(2)定義關(guān)聯(lián)對象時可指定內(nèi)存管理語義异旧,用以模仿定義屬性時所采用的"擁有關(guān)系"與"非擁有關(guān)系"意述。
(3)只有在其他做法不可行時才應(yīng)選用關(guān)聯(lián)對象,因為這種做法通常會引入難于查找的bug吮蛹。

11.理解objc_msgSend的作用

(1)消息由接收者荤崇、選擇子及參數(shù)構(gòu)成。給某對象"發(fā)送消息"(invoke amessage)也就相當于在該對象上調(diào)用"調(diào)用方法"( call amethod)潮针。
(2)發(fā)給某對象的全部消息都要由"動態(tài)消息派發(fā)系統(tǒng)"(dynamic message dispatch system)來處理天试,該系統(tǒng)會調(diào)查出對應(yīng)的方法,并執(zhí)行其代碼然低。

12.理解消息轉(zhuǎn)發(fā)機制

(1)若對象無法響應(yīng)某個選擇子,則進入消息轉(zhuǎn)發(fā)流程务唐。
(2)通過運行期的動態(tài)方法解析功能雳攘,我們可以在需要用到某個方法時再將其加入類中。
(3)對象可以把其他無法解讀的某些選擇子交給其他對象進行處理枫笛。
(4)經(jīng)過上述兩步之后吨灭,如果還是沒辦法處理選擇子,那就啟動完整的消息轉(zhuǎn)發(fā)機制刑巧。

13.用"方法調(diào)配技術(shù)"調(diào)試"黑盒方法"

(1)在運行期喧兄,可以向類中新增或替換選擇子所對應(yīng)的方法實現(xiàn)无畔。
(2)使用另一份實現(xiàn)來替換原有的方法實現(xiàn),這道工序叫做"方法調(diào)配"吠冤,開發(fā)者常用此技術(shù)向原有實現(xiàn)中添加新功能浑彰。
(3)一般來說,只有調(diào)試程序的時候才需要在運行期修改方法實現(xiàn)拯辙,這種做法不宜濫用郭变。

14.理解"類對象"的用意

(1)每個實例都有一個指向Class對象的指針,用以表明其類型涯保,而這些Class對象則構(gòu)成了類的繼承體系诉濒。
(2)如果對象類型無法在編譯期確定,那么就應(yīng)該使用類型信息查詢方法來探知夕春。
(3)盡量使用類型信息查詢方法確定對象類型未荒,而不要直接比較類對象,因為某些對象可能實現(xiàn)了消息轉(zhuǎn)發(fā)功能及志。

三片排、接口與API設(shè)計

15.用前綴避免命名空間沖突

(1)選擇與你的公司、應(yīng)用程序或二者皆有關(guān)聯(lián)之名稱作為類名的前綴困肩,并在所有代碼中均適用這一前綴划纽。
(2)若自己所開發(fā)的程序庫中用到了第三方庫,則應(yīng)為其中的名稱加上前綴锌畸。

16.提供"全能初始化方法"

(1)在類中提供一個全能初始化方法勇劣,并于文檔里指明。其他初始化方法均應(yīng)調(diào)用此方法潭枣。
(2)若全能初始化方法與超類不同比默,則需要覆寫超類中對應(yīng)方法。
(3)如果超類的初始化方法不適用于子類盆犁,難么應(yīng)該覆寫這個超類方法命咐,并在其中拋出異常。

17.實現(xiàn)description方法

(1)實現(xiàn)description方法返回一個有意義的字符串谐岁,用以描述該實例醋奠。
(2)若想在調(diào)試時打印出更詳盡的對象描述信息,則應(yīng)該實現(xiàn)debugDescription方法伊佃。

18.盡量使用不可變對象

(1)盡量創(chuàng)建不可變對象窜司。
(2)若某屬性僅可于對象內(nèi)部修改,則在"class-continuation分類"中將其由readonly屬性擴展為readwrite屬性航揉。
(3)不要把可變的collection作為屬性公開塞祈,而應(yīng)提供相關(guān)方法,以此修改對象中的可變collection帅涂。

19.使用清晰而協(xié)調(diào)的命名方式

(1)起名時應(yīng)遵從OC命名規(guī)范议薪,這樣創(chuàng)建出來的接口更容易為開發(fā)者所理解尤蛮。
(2)方法名要言簡意賅,從左至右讀起來要像個日常用語中的句子才好斯议。
(3)方法名里不要使用縮略后的類型名稱产捞。
(4)給方法起名時的第一要務(wù)就是確保其風格與你自己的代碼或所要集成的框架相符。

20.為私有方法名前加前綴

(1)給私有方法的名稱前加上前綴捅位,這樣可以很容易地將其同公共方法區(qū)分開轧葛。
(2)不要單用一個下劃線做私有方法的前綴,因為這種做法是預(yù)留給蘋果公司用的艇搀。

21.理解OC的錯誤模型

(1)只有發(fā)生了可使整個應(yīng)用程序崩潰的嚴重錯誤時尿扯,才應(yīng)使用異常。
(2)在錯誤不那么嚴重的情況下焰雕,可以指派"委托方法"(delegate method)來處理錯誤衷笋,也可以把錯誤信息放在NSError對象里,經(jīng)由"輸出參數(shù)"返回給調(diào)用者矩屁。

22.理解NSCopying協(xié)議

(1)若想令自己所寫的對象具有拷貝功能辟宗,則需要實現(xiàn)NSCopying協(xié)議。
(2)如果自定義的對象分為可變版本與不可變版本吝秕,那么就要同時實現(xiàn)NSCopying與NSMutableCopyig協(xié)議泊脐。
(3)復(fù)制對象時需決定采用淺拷貝還是深拷貝,一般情況下應(yīng)該盡量執(zhí)行淺拷貝烁峭。
(4)如果你所寫的對象需要深拷貝容客,那么考慮新增一個專門執(zhí)行深拷貝的方法。

四约郁、協(xié)議與分類

23.通過委托與數(shù)據(jù)源協(xié)議進行對象間通信

(1)委托模式為對象提供了一套接口缩挑,使其可由此將相關(guān)事件告知其他對象。
(2)將委托對象應(yīng)該支持的接口定義成協(xié)議鬓梅,在協(xié)議中把可能需要處理的事件定義成方法供置。
(3)當某對象需要從另一個對象中獲取數(shù)據(jù)時,可以使用委托模式绽快。這種情況下芥丧,該模式亦稱"數(shù)據(jù)源協(xié)議"(data source protocal)。
(4)若有必要坊罢,可實現(xiàn)含有位段的結(jié)構(gòu)體娄柳,將委托對象是否能響應(yīng)相關(guān)協(xié)議方法這一信息緩存至其中。

24.將類的實現(xiàn)代碼分散到便于管理的數(shù)個分類之中

(1)使用分類機制把類的實現(xiàn)代碼劃分成為易于管理的小塊艘绍。
(2)將應(yīng)該視為"私有"的方法歸入名為Private的分類中,以隱藏實現(xiàn)細節(jié)秫筏。

25.總是為第三方類的分類名稱加前綴

(1)向第三方類中添加分類時诱鞠,總是給其名稱加上專用的前綴挎挖。
(2)向第三方類中添加分類時,總給其中的方法名加上你專用的前綴航夺。

26.勿在分類中聲明屬性

(1)把封裝數(shù)據(jù)所用的全部屬性都定義在主接口里蕉朵。
(2)在"class-continuation分類"之外的其他分類中,可以定義存取方法阳掐,但盡量不要定義屬性始衅。

27.使用"class-continuation分類"隱藏實現(xiàn)細節(jié)

(1)通過"class-continuation分類"向類中新增實例變量。
(2)如果某屬性在主接口中聲明為"只讀"缭保,而類的內(nèi)部又要設(shè)置方法修改此屬性汛闸,那么就在"class-continuation分類"中將其擴展為"可讀寫"。
(3)把私有方法的原型聲明在"class-continuation分類"里面艺骂。
(4)若想使類所遵循的協(xié)議不為人所知诸老,則可于"class-continuation分類"中聲明。

28.通過協(xié)議提供的匿名對象

(1)協(xié)議可在某種程度上提供匿名類型钳恕。具體的對象類型可于淡化成遵從某協(xié)議的id類型别伏,協(xié)議里規(guī)定了對象所應(yīng)該實現(xiàn)的方法。
(2)使用匿名對象來隱藏類型名稱(或類名)忧额。
(3)如果具體類型不重要厘肮,重要的是對象能夠響應(yīng)(定義在協(xié)議里的)特定方法,那么可使用匿名對象來表示睦番。

五类茂、內(nèi)存管理

29.理解引用計數(shù)

(1)引用計數(shù)機制可以遞增遞減的計數(shù)器來管理內(nèi)存。對象創(chuàng)建好之后抡砂,其保留計數(shù)至少為1.若保留計數(shù)為正大咱,則對象繼續(xù)存活。
當保留計數(shù)降為0時注益,對象被銷毀碴巾。
(2)在對象生命周期中,其余對象通過引用來保留或釋放此對象丑搔。保留與釋放操作分別會遞增及遞減保留計數(shù)厦瓢。

30.以ARC簡化引用計數(shù)

(1)有ARC之后,程序員就無須擔心內(nèi)存管理問題了啤月。使用ARC來編程煮仇,可省去類中的許多“樣板代碼”。
(2)ARC管理對象生命期的辦法基本上就是:在合適的地方插入“保留”及“釋放”操作谎仲。在ARC環(huán)境下浙垫,變量的內(nèi)存管理語義可以通過修飾符指明,而原來則需要手工執(zhí)行“保留”及“釋放”操作。
(3)由方法所返回的對象夹姥,其內(nèi)存管理語義總是通過方法名體現(xiàn)杉武。ARC將此確定為開發(fā)者必須遵守的規(guī)則。
(4)ARC只負責管理objective-C對象的內(nèi)存辙售,尤其要注意:CoreFoundation對象不歸ARC管理轻抱,開發(fā)者必須適時調(diào)用CFRetain/CFRelease。

31.在dealloc方法中釋放引用并解除監(jiān)聽

(1)在dealloc方法里旦部,應(yīng)該做的事情就是釋放指向其他對象的引用祈搜,并取消原來訂閱的“鍵值觀察”(KVO)或NSNotificationCenter等通知,不要做其他事情士八。
(2)如果對象持有文件描述等系統(tǒng)資源容燕,那么應(yīng)該專門編寫一個方法來釋放此種資源。這樣的類要和其使用者約定:用完資源后必須調(diào)用close方法曹铃。
(3)執(zhí)行異步任務(wù)的方法不應(yīng)在dealloc里調(diào)用缰趋;只能在正常狀態(tài)下執(zhí)行的那些方法也不應(yīng)在dealloc里調(diào)用,因為此時對象已處于正在回收的狀態(tài)了陕见。

32.編寫“異常安全代碼”時留意內(nèi)存管理問題

(1)捕獲異常時秘血,一定要注意將try塊內(nèi)所創(chuàng)立的對象清理干凈。
(2)在默認情況下评甜,ARC不生成安全處理異常所需的清理代碼灰粮。開啟編譯器標志后,可生成這種代碼忍坷,不過會導(dǎo)致應(yīng)用程序變大粘舟,而且會降低運行效率。

33.以若引用避免保留環(huán)

(1)講某些引用設(shè)為weak佩研,可避免出現(xiàn)“保留環(huán)”柑肴。
(2)weak引用可以自動清空,也可以不自動清空旬薯。自動清空(autoniling)是隨著ARC而引入的新特性晰骑,由運行期系統(tǒng)來實現(xiàn)。在具備清空功能的弱引用上绊序,可以隨意讀取其數(shù)據(jù)硕舆,因為這種引用不會指向已經(jīng)回收過的對象。

34.以“自動釋放池塊”降低內(nèi)存峰值

(1)自動釋放池排布在棧中骤公,對象收到autorelease消息后抚官,系統(tǒng)將其放入最頂端的池里。
(2)合理運用自動釋放池阶捆,可降低應(yīng)用程序的內(nèi)存峰值凌节。
(3)@autoreleasepool這種新式的寫法能創(chuàng)建出更為輕便的自動釋放池钦听。

35.用“僵尸對象”調(diào)試內(nèi)存管理問題

(1)系統(tǒng)在回收對象時,可以將其不真的回收倍奢,而把他轉(zhuǎn)化為僵尸對象彪见。通過環(huán)境變量NSZombieEnabled可開啟此功能。
(2)系統(tǒng)會修改對象的isa指針娱挨,令其指向特殊的僵尸類,從而使該對象變成為僵尸對象捕犬。僵尸類能夠響應(yīng)所有的選擇子跷坝,響應(yīng)方式為:打印一條包含消息內(nèi)容及其接受者的消息,然后終止應(yīng)用程序碉碉。

36.不用使用retainCount

(1)對象的保留計數(shù)看似有用柴钻,實則不然,因為任何時間點給定的“絕對保留計數(shù)”(absolute retain count)都無法反應(yīng)對象生命周期的全貌垢粮。
(2)引入ARC之后贴届,retainCount方法就真是廢止了,在ARC下調(diào)用此方法會導(dǎo)致編譯器報錯蜡吧。

六毫蚓、塊與大中樞派發(fā)

37.理解“塊”這一概念

(1)塊是C、C++昔善、Objective-C中的詞法閉包元潘。
(2)塊可以接受參數(shù),也可返回值君仆。
(3)塊可以分配在楐娓牛或堆上,也可以是全局的返咱。分配在棧上的快可以拷貝到堆上钥庇,這樣的話,就和標準的Objective-C對象一致了咖摹,具備引用計數(shù)了评姨。

38.常用的塊類型創(chuàng)建typedef

(1)以typedef重新定義塊類型,可令塊變量用起來更加簡單楞艾。
(2)定義新類型時應(yīng)遵從現(xiàn)有的命名習慣参咙,勿使其名稱與別的類型相沖突。
(3)不妨為同一個塊簽名定義多個類型的別名硫眯。如果要重構(gòu)的代碼使用了塊類型的某個別名蕴侧,那么只需要修改相應(yīng)的typedef中的塊簽名即可,無須改動其他的typedef两入。

39.用handler塊降低代碼分散程度

(1)在創(chuàng)建對象净宵,可以使用內(nèi)聯(lián)的handler塊將業(yè)務(wù)邏輯一并聲明。
(2)在多個實例需要監(jiān)控時,如果采用委托模式择葡,那么經(jīng)常需要需要根據(jù)傳入的對象來切換紧武,而若改用handler塊來實現(xiàn),則可直接將塊與相關(guān)對象放在一起敏储。
(3)設(shè)計API時如果用到handler塊阻星,那么可以增加一個參數(shù),使調(diào)用者可以通過此參數(shù)來決定應(yīng)該把塊安排在哪個隊列上執(zhí)行已添。

40.用塊引用所屬對象時不要出現(xiàn)保留環(huán)

(1)如果塊所捕獲的對象直接或間接的保留了塊本身妥箕,那么就要當心保留環(huán)問題。
(2)一定要找個適當?shù)臅r機接觸保留環(huán)更舞,而不能把責任推給API的調(diào)用者畦幢。

41.多用派發(fā)隊列,少用同步鎖

(1)派發(fā)隊列可以用來表述同步語義(synchronization semantic)缆蝉,這種做法要比時候用@synchronized塊或NSLock對象更為簡單宇葱。
(2)將同步或異步結(jié)合起來,可實現(xiàn)與普通加鎖機制一樣的同步行為刊头,而這么做卻不會阻塞執(zhí)行異步派發(fā)的線程黍瞧。
(3)使用同步隊列或柵欄快,可以令同步行為更加高效芽偏。

42.多用GCD雷逆,少用performSelector系列方法

(1)performSelector系列方法在內(nèi)存管理方面容易有疏失。它無法確定將要執(zhí)行的選擇子的具體是什么污尉,因而ARC編譯器無法插入適當?shù)膬?nèi)存管理方法膀哲。
(2)performSelector系列方法所能處理的選擇子太多局限了,選擇子的返回值類型及發(fā)送給方法的參數(shù)個數(shù)都受到限制被碗。
(3)如果想把任務(wù)方法哦另一個線程上執(zhí)行某宪,那么最好不要用performSelector系列方法,而是應(yīng)該把任務(wù)封裝到塊里锐朴,然后調(diào)用大中樞派發(fā)機制的相關(guān)方法來實現(xiàn)兴喂。

43.掌握GCD和操作隊列的使用時機

(1)在解決多線程和任務(wù)管理問題時,派發(fā)隊列并非唯一方案焚志。
(2)操作隊列提供了一套高層的Objective-C API衣迷,能實現(xiàn)純GCD的所具備的絕大部分的功能,而且還能完成一些更為復(fù)雜的操作酱酬,那些操作如果改為GCD實現(xiàn)壶谒,則需要另外編寫代碼。

44.通過Dispatch Group機制膳沽,根據(jù)系統(tǒng)資源狀況來執(zhí)行任務(wù)

(1)一系列任務(wù)可歸入一個dispatch group中汗菜。開發(fā)者可以在這組任務(wù)執(zhí)行完畢的時候獲得通知让禀。
(2)通過dispatch group,可以在并發(fā)式派發(fā)隊列中同時執(zhí)行多項任務(wù)陨界。此時GCD會根據(jù)系統(tǒng)資源來調(diào)度這些并發(fā)執(zhí)行的任務(wù)巡揍。開發(fā)者若要實現(xiàn)此功能,則會需要寫大量的代碼菌瘪。

45.使用dispatch_once來執(zhí)行只需要運行一次的線程安全代碼

(1)經(jīng)常需要編寫“只需要執(zhí)行一次的線程安全代碼”(thread-safe single-code excution)腮敌。通過GCD所提供的dispatch_once函數(shù),就很容易實現(xiàn)次功能俏扩。
(2)標記應(yīng)該聲明在static或是global作用域中缀皱,這樣的話,在只需要執(zhí)行一次的塊傳給dispatch_once函數(shù)時动猬,傳進去的標記也是相同的。

46.不要使用dispatch_get_current_queue

(1)dispatch_get_current_queue函數(shù)的行為常常與開發(fā)者所預(yù)期的不同表箭。此函數(shù)已經(jīng)廢棄赁咙,只做調(diào)試的時候使用。
(2)由于派發(fā)隊列是按層級來組織的免钻,所以無法單用某個隊列對象來描述“當前隊列”這一概念彼水。
(3)dispatch_get_current_queue函數(shù)常用于解決由不可重入的代碼引發(fā)的死鎖,然而能用此函數(shù)解決的問題极舔,通常也能用改用"隊列特定數(shù)據(jù)"來解決凤覆。

七、系統(tǒng)框架

47.熟悉系統(tǒng)框架

(1)許多系統(tǒng)框架都可以直接使用拆魏。其中最重要的是Foundation與CoreFoundation盯桦,這兩個框架提供了構(gòu)建應(yīng)用程序所需的許多核心功能。
(2)很多常見功能都能用框架來做渤刃,例如音頻與食視頻處理拥峦、網(wǎng)絡(luò)通信、數(shù)據(jù)管理等卖子。
(3)請記住:用純C寫的框架和與用objective-c寫成的框架是一樣的重要的略号,若想成為優(yōu)秀的oc開發(fā)者,需要掌握C語言的核心洋闽。

48.多用塊枚舉玄柠,少用for循環(huán)

(1)遍歷collection有四種方法。最基本的方式就是for循環(huán)诫舅,其次是NSEnumerator遍歷法以及快速遍歷法羽利,最新、最先進的方式則是"塊枚舉法"骚勘。
(2)"塊枚舉法"本身就是通過GCD來并發(fā)執(zhí)行遍歷操作铐伴,無須另行編寫代碼撮奏。而采用其他的遍歷方式則無法輕易實現(xiàn)這一點。
(3)若提前得知被遍歷的collection是何種對象当宴,則應(yīng)該修改塊簽名畜吊,指出對象的具體類型。

49.對自定義其內(nèi)存管理語義的collection使用無縫橋接

(1)使用無縫橋接技術(shù)户矢,可以在Foundation框架中的objective-c對象與CoreFoundation框架中的C語言數(shù)據(jù)結(jié)構(gòu)之間來回轉(zhuǎn)換玲献。
(2)在CoreFoundation層面創(chuàng)建collection時,可以指定許多回調(diào)函數(shù)梯浪,此函數(shù)表示collection應(yīng)如何處理元素捌年。然后,可運用無縫橋接技術(shù)挂洛,將其轉(zhuǎn)換成具備特殊內(nèi)存管理語義的objective-c的collection礼预。

50.構(gòu)建緩存的時候選用NSCache而非NSDictionary

(1)實現(xiàn)緩時應(yīng)選用NSCache而非NSDictionary對象。因為NSCache可以提供優(yōu)雅的自動刪減功能,而且是"線程安全的",此外肘迎,它與字典不同,并不會拷貝鍵励堡。
(2)可以給NSCache對象設(shè)置上限,用以限制緩存中的對象總個數(shù)以及"總成本"堡掏,而這些尺度則定義了緩存刪除其中對象的時機应结。但絕對不用這些尺度當成可靠的“硬限制”,他們進隊NSCache起一個引導(dǎo)作用泉唁。
(3)將NSPurgeableData與NSCache搭配使用鹅龄,可實現(xiàn)自動清除數(shù)據(jù)的功能,也就是說亭畜,當NSPurgeableData對象所占內(nèi)存為系統(tǒng)所丟棄時砾层,該對象也會從從緩存中移除。
(4)如緩存使用得當贱案,那么應(yīng)用程序的響應(yīng)速度就能提高肛炮。只有那種“重新計算很費勁”的數(shù)據(jù),才能得放入緩存宝踪,比如那些需要從網(wǎng)絡(luò)獲取或磁盤讀取的數(shù)據(jù)侨糟。

51.精簡initialize和load的實現(xiàn)代碼

(1)在加載階段,如果實現(xiàn)了load方法瘩燥,那么系統(tǒng)就會調(diào)用它秕重。分類里也可以定義此方法,類的load方法要比分類中的先調(diào)用厉膀。與其他方法不同溶耘,load方法不會參與覆寫機制二拐。
(2)首次使用某個類之前,系統(tǒng)會向其發(fā)送initialize消息凳兵。由于此方法遵從普通的覆寫規(guī)則百新,所以通常應(yīng)該在里面判斷當前要初始化的是哪個類。
(3)load和initialize方法都應(yīng)該實現(xiàn)得精簡些庐扫,這有助于保持應(yīng)用程序的響應(yīng)能力饭望,也能減少引入"依賴環(huán)"(interdependcy circle)的幾率。
(4)無法再編譯器設(shè)定的全局常量形庭,可以在initialize方法里進行初始化铅辞。

52.別忘了NSTimer會保留其目標對象

(1)NSTimer對象會保留其目標,知道計時器本身失效為止萨醒,調(diào)用invalidate方法可以令計時器失效斟珊,另外,一次性的計時器在觸發(fā)完任務(wù)之后也會失效富纸。
(2)反復(fù)執(zhí)行任務(wù)的計時器(repeating timer)倍宾,很容易引入保留環(huán),如果這種定時器的目標對象又保留了計時器本身胜嗓,那肯定會導(dǎo)致保留環(huán)。這種環(huán)裝保留關(guān)系钩乍,可能是直接發(fā)生的辞州,也有可能是通過對象圖里其他對象間接發(fā)生的。
(3)可以擴充NSTimer的功能寥粹,用"塊"來打破保留環(huán)变过。不過,除非NSTimer將來在公共接口里提供此功能涝涤,否則必須創(chuàng)建分類媚狰,將相關(guān)實現(xiàn)代碼加入其中。

最后編輯于
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末阔拳,一起剝皮案震驚了整個濱河市崭孤,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌糊肠,老刑警劉巖辨宠,帶你破解...
    沈念sama閱讀 216,744評論 6 502
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異货裹,居然都是意外死亡嗤形,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 92,505評論 3 392
  • 文/潘曉璐 我一進店門弧圆,熙熙樓的掌柜王于貴愁眉苦臉地迎上來赋兵,“玉大人笔咽,你說我怎么就攤上這事∨冢” “怎么了叶组?”我有些...
    開封第一講書人閱讀 163,105評論 0 353
  • 文/不壞的土叔 我叫張陵,是天一觀的道長经伙。 經(jīng)常有香客問我扶叉,道長,這世上最難降的妖魔是什么帕膜? 我笑而不...
    開封第一講書人閱讀 58,242評論 1 292
  • 正文 為了忘掉前任枣氧,我火速辦了婚禮,結(jié)果婚禮上垮刹,老公的妹妹穿的比我還像新娘达吞。我一直安慰自己,他們只是感情好荒典,可當我...
    茶點故事閱讀 67,269評論 6 389
  • 文/花漫 我一把揭開白布酪劫。 她就那樣靜靜地躺著,像睡著了一般寺董。 火紅的嫁衣襯著肌膚如雪覆糟。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 51,215評論 1 299
  • 那天遮咖,我揣著相機與錄音滩字,去河邊找鬼。 笑死御吞,一個胖子當著我的面吹牛麦箍,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播陶珠,決...
    沈念sama閱讀 40,096評論 3 418
  • 文/蒼蘭香墨 我猛地睜開眼挟裂,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了揍诽?” 一聲冷哼從身側(cè)響起诀蓉,我...
    開封第一講書人閱讀 38,939評論 0 274
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎暑脆,沒想到半個月后交排,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 45,354評論 1 311
  • 正文 獨居荒郊野嶺守林人離奇死亡饵筑,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 37,573評論 2 333
  • 正文 我和宋清朗相戀三年埃篓,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學(xué)時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片根资。...
    茶點故事閱讀 39,745評論 1 348
  • 序言:一個原本活蹦亂跳的男人離奇死亡架专,死狀恐怖同窘,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情部脚,我是刑警寧澤想邦,帶...
    沈念sama閱讀 35,448評論 5 344
  • 正文 年R本政府宣布,位于F島的核電站委刘,受9級特大地震影響丧没,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜锡移,卻給世界環(huán)境...
    茶點故事閱讀 41,048評論 3 327
  • 文/蒙蒙 一呕童、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧淆珊,春花似錦夺饲、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 31,683評論 0 22
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至戳吝,卻和暖如春浩销,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背听哭。 一陣腳步聲響...
    開封第一講書人閱讀 32,838評論 1 269
  • 我被黑心中介騙來泰國打工慢洋, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人欢唾。 一個月前我還...
    沈念sama閱讀 47,776評論 2 369
  • 正文 我出身青樓,卻偏偏與公主長得像粉捻,于是被迫代替她去往敵國和親礁遣。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 44,652評論 2 354

推薦閱讀更多精彩內(nèi)容