本文由論壇會(huì)員keefo分享

首先請(qǐng)諒解我可能使用很多英文,，畢竟英文資料將來(lái)會(huì)是你的主要資料來(lái)源。
在你繼續(xù)深入學(xué)習(xí)之前,，請(qǐng)停下腳步弄清這些問(wèn)題,。如果你是新手，這個(gè)教程不要希望一次能看的非常透徹，學(xué)一定階段反回來(lái)再看看又會(huì)有新的體會(huì)的,。

1. c,c++ background

很多人問(wèn) “沒(méi)有任何語(yǔ)言基礎(chǔ),，我不想學(xué)c直接學(xué)objective-c”
這里簡(jiǎn)單幾句，objc 90%代碼是c,、眾多開(kāi)源代碼是c,c++,。你不學(xué)好c在unix世界里只能是個(gè)二流開(kāi)發(fā)者！也許說(shuō)得過(guò)于嚴(yán)厲,，不過(guò)自己斟酌把,。 

2. Runtime（運(yùn)行時(shí)）

Objective-c是動(dòng)態(tài)語(yǔ)言,  很多新手或者開(kāi)發(fā)人員常常被Runtime這個(gè)東西所迷惑。而恰恰這是一個(gè)非常重要的概念,。 為什么重要呢?。课铱梢赃@么問(wèn)：“如果讓你（設(shè)計(jì),、）實(shí)現(xiàn)一個(gè)計(jì)算機(jī)語(yǔ)言,，你要如何下手？” 很少程序員這么思考過(guò),。但是這么一問(wèn),，就會(huì)強(qiáng)迫你從更高層次思考(1)以前的問(wèn)題了,。 注意我這句話‘設(shè)計(jì)’括起來(lái)了,，稍微次要點(diǎn),，關(guān)鍵是實(shí)現(xiàn),。

我把實(shí)現(xiàn)分成3鐘不同的層次：

    1. 傳統(tǒng)的面向過(guò)程的語(yǔ)言開(kāi)發(fā),，例如c語(yǔ)言,。實(shí)現(xiàn)c語(yǔ)言編譯器很簡(jiǎn)單,，只要按照語(yǔ)法規(guī)則實(shí)現(xiàn)一個(gè)LALR語(yǔ)法分析器就可以了,，編譯器優(yōu)化是非常難的topic,，不在這里討論范圍內(nèi),，忽略。 這里我們實(shí)現(xiàn)了編譯器其中最最基礎(chǔ)和原始的目標(biāo)之一就是把一份代碼里的函數(shù)名稱,，轉(zhuǎn)化成一個(gè)相對(duì)內(nèi)存地址,，把調(diào)用這個(gè)函數(shù)的語(yǔ)句轉(zhuǎn)換成一個(gè)jmp跳轉(zhuǎn)指令。在程序開(kāi)始運(yùn)行時(shí)候,，調(diào)用語(yǔ)句可以正確跳轉(zhuǎn)到對(duì)應(yīng)的函數(shù)地址,。 這樣很好，也很直白,，但是,。。,。太死板了,。everything is per-determined

    2. 我們希望靈活,，于是需要開(kāi)發(fā)面向?qū)ο蟮恼Z(yǔ)言，例如c++,。 c++在c的基礎(chǔ)上增加了類的部分,。但這到底意味著什么呢？我們?cè)賹?xiě)它的編譯器要如何考慮呢,？其實(shí),，就是讓編譯器多繞個(gè)彎，在嚴(yán)格的c編譯器上增加一層類處理的機(jī)制,，把一個(gè)函數(shù)限制在它處在的class環(huán)境里,，每次請(qǐng)求一個(gè)函數(shù)調(diào)用，先找到它的對(duì)象, 其類型,返回值,，參數(shù)等等，確定了這些后再jmp跳轉(zhuǎn)到需要的函數(shù),。這樣很多程序增加了靈活性同樣一個(gè)函數(shù)調(diào)用會(huì)根據(jù)請(qǐng)求參數(shù)和類的環(huán)境返回完全不同的結(jié)果,。增加類機(jī)制后，就模擬了現(xiàn)實(shí)世界的抽象模式,，不同的對(duì)象有不同的屬性和方法,。同樣的方法，不同的類有不同的行為,！ 這里大家就可以看到作為一個(gè)編譯器開(kāi)發(fā)者都做了哪些進(jìn)一步的思考,。但是。,。,。還是死板, 我們?nèi)匀唤衏++是static language。 

    3. 希望更加靈活,！ 于是我們完全把上面哪個(gè)類的實(shí)現(xiàn)部分抽象出來(lái),，做成一套完整運(yùn)行階段的檢測(cè)環(huán)境。這次再寫(xiě)編譯器甚至保留部分代碼里的sytax名稱,，名稱錯(cuò)誤檢測(cè),，runtime環(huán)境注冊(cè)所以全局的類，函數(shù),，變量等等信息等等,，我們可以無(wú)限的為這個(gè)層增加必要的功能。調(diào)用函數(shù)時(shí)候,，會(huì)先從這個(gè)運(yùn)行時(shí)環(huán)境里檢測(cè)所以可能的參數(shù)再做jmp跳轉(zhuǎn),。這，就是runtime,。編譯器開(kāi)發(fā)起來(lái)比上面更加彎彎繞,。但是這個(gè)層極大增加了程序的靈活性,。  例如當(dāng)調(diào)用一個(gè)函數(shù)時(shí)候，前2種語(yǔ)言,，很有可能一個(gè)jmp到了一個(gè)非法地址導(dǎo)致程序crash, 但是在這個(gè)層次里面,，runtime就過(guò)濾掉了這些可能性。 這就是為什么dynamic langauge更加強(qiáng)壯,。 因?yàn)榫幾g器和runtime環(huán)境開(kāi)發(fā)人員已經(jīng)幫你處理了這些問(wèn)題,。

好了上面說(shuō)著這么多，我們?cè)俜祷貋?lái)看objective-c.  現(xiàn)在你是不是能理解這樣的語(yǔ)句了呢,？

看似很簡(jiǎn)單的語(yǔ)句,，但是為了讓語(yǔ)言實(shí)現(xiàn)這個(gè)能力，語(yǔ)言開(kāi)發(fā)者要付出很多努力實(shí)現(xiàn)runtime環(huán)境,。這里運(yùn)行時(shí)環(huán)境處理了弱類型,、函數(shù)存在檢查工作。runtime會(huì)檢測(cè)注冊(cè)列表里是否存在對(duì)應(yīng)的函數(shù),，類型是否正確,，最后確定下來(lái)正確的函數(shù)地址，再進(jìn)行保存寄存器狀態(tài),，壓棧,，函數(shù)調(diào)用等等實(shí)際的操作。

在c,c++年代去完成這個(gè)功能是非常麻煩的,，但是動(dòng)態(tài)語(yǔ)言卻非常簡(jiǎn)單,。

關(guān)于執(zhí)行效率問(wèn)題。 “靜態(tài)語(yǔ)言執(zhí)行效率要比動(dòng)態(tài)語(yǔ)言高”,，這句沒(méi)錯(cuò),。因?yàn)橐徊糠謈pu計(jì)算損耗在了runtime過(guò)程中。而靜態(tài)語(yǔ)言生成的機(jī)器指令更簡(jiǎn)潔,。正因?yàn)橹肋@個(gè)原因,，所以開(kāi)發(fā)語(yǔ)言的人付出很大一部分努力為了保持runtime小巧上。所以objecitve-c是c的超集+一個(gè)小巧的runtime環(huán)境,。  但是,，換句話說(shuō)，從算法角度考慮,，這點(diǎn)復(fù)雜度不算差別的,，Big O notation結(jié)果不會(huì)有差別。( It's not log(n) vs n^2 )

簡(jiǎn)單理解：“Runtime is everything between your each function call.”  

Runtime好比objective-c的靈魂,。很多東西都是在這個(gè)基礎(chǔ)上出現(xiàn)的,。所以它是指的你花功夫去理解的。

3. thread

"thread synchronization another notorious trouble!" 

記不記得上學(xué)時(shí)候?qū)W得操作系統(tǒng)這門(mén)課,，里面都會(huì)有專門(mén)一章介紹任務(wù)調(diào)度和生產(chǎn)者消費(fèi)者的問(wèn)題,。 這就是為了今后使用進(jìn)程,、線程開(kāi)發(fā)打基礎(chǔ)。概念很簡(jiǎn)單,，但是心知肚明的人很少,。難點(diǎn)在synchronization(同步)，因?yàn)?. There is no 100% deadlock detection algorithm. If there is, no deadlock at all. 2. 往往這類錯(cuò)誤很隱晦,，靜態(tài)分析很難找到,。 3. 抽象度較高需要經(jīng)驗(yàn)去把握。  

總體來(lái)說(shuō),，我見(jiàn)到的在這方面的問(wèn)題可以分為一下幾點(diǎn)：

    1. 不知道多線程開(kāi)發(fā)的幾個(gè)基點(diǎn),，看別人代碼越看越糊涂的。一會(huì)NSThread,、一會(huì)*****,、block等等。,。,。Apple封裝了很多線程的api, down to core多線程的結(jié)構(gòu)基本是

 
可以看到在多線程開(kāi)發(fā)中你可以選擇這幾種不同的方式。Mach是最和心的操作系統(tǒng)部分,，你可以用但是沒(méi)必要，太累,。
pthread靈活,、輕巧，但是需要理論基礎(chǔ)還是開(kāi)發(fā)復(fù)雜,，最主要的POSIX開(kāi)的線程不能使用cocoa根據(jù)apple文檔只在pthread下使用cocoa需要先detach at least one NSThread object. 這樣確定[NSThread isMultiThreaded]才可以使用,。
NSThread是Mac OS 10.0后發(fā)布的多線程API較為高層，但是缺乏靈活性,。
Grand Central Dispatch 10.6引入的開(kāi)源多線程庫(kù),， *****介于pthread和NSThread之間。比NSThread更靈活,，小巧但有不需要像pthread一樣考慮很多l(xiāng)ock的問(wèn)題,。而objective-c 2.0發(fā)布的新語(yǔ)法特性之一blocks也正是根據(jù)這種多線程需求推出的。

在你寫(xiě)多線程代碼或者閱讀多線程代碼時(shí)候,，心理先明確了這是那種,。

    2. thread和runloop造成的問(wèn)題
其實(shí)thread和runloop放在以前開(kāi)發(fā)者根本不太當(dāng)成一個(gè)問(wèn)題。因?yàn)闆](méi)有runtime能力,，runloop就是固定的線程執(zhí)行l(wèi)oop,。而現(xiàn)在cocoa開(kāi)發(fā)新手搞不明白的太多了。 NSRunloop和NSThread啥關(guān)系,？由于這個(gè)問(wèn)題比較多,，我單獨(dú)列到第4點(diǎn)里講解把,。

    3. thread和Reference Counting內(nèi)存管理造成的問(wèn)題。
    

引用

線程里面的方法都要放到NSAutoreleasePool里面嗎

這類問(wèn)題很常見(jiàn),，主要原因是 NSAutoreleasePool 到底是干什么用得不明白,。 NSAutoreleasePool跟thread其實(shí)關(guān)系并不顯著，它提供一個(gè)臨時(shí)內(nèi)存管理空間,，好比一個(gè)沙箱,，確保不會(huì)有不當(dāng)?shù)膬?nèi)存分配泄露出來(lái)，在這個(gè)空間內(nèi)新分配的對(duì)象要向這個(gè)pool做一下注冊(cè)告訴：“pool,，我新分配一塊空間了”,。當(dāng)pool drain掉或者release，它里面分配過(guò)的內(nèi)存同樣釋放掉,?？梢?jiàn)和thread沒(méi)有很大關(guān)系。但是,，我們閱讀代碼的時(shí)候經(jīng)常會(huì)看到,，新開(kāi)線程的函數(shù)內(nèi)總是以NSAutoreleasePool開(kāi)始結(jié)束。這又是為什么呢??？ 因?yàn)閠hread內(nèi)恰好是最適合需要它的地方！ 線程函數(shù)應(yīng)該計(jì)算量大,，時(shí)間長(zhǎng)(supposed to be heavy),。在線程里面可能會(huì)有大量對(duì)象生成，這時(shí)使用autoreleasepool管理更簡(jiǎn)潔,。所以這里的答案是,，不一定非要在線程里放NSAutoreleasePool，相對(duì)的在cocoa環(huán)境下任意地方都可以使用NSAutoreleasePool,。如果你在線程內(nèi)不使用NSAutoreleasePool,，要記得在內(nèi)部alloc和relase配對(duì)出現(xiàn)保證沒(méi)有內(nèi)存泄露。 

這里還有一個(gè)值得提出的是autorelease.  NSObject為何會(huì)有autorelease這個(gè)方法? 它是根據(jù)什么auto的,？ 


   4. mainthread和secondary thread疑惑
    

引用

NSThread的detachNewThreadSelector和self的performSelectorOnMainThread方法有什么不同

    
    5. Asynchronous（異步） vs. Synchronous（同步）
    

引用

我在一個(gè)view要顯示多張web圖片,，我想問(wèn)一下，我是應(yīng)該采用異步一個(gè)一個(gè)下載的方式,，還是應(yīng)該采用多線程同時(shí)下載的方式,，還是2個(gè)都用，那種方式好呢,？

    大家可以看一下這個(gè)問(wèn)題,。這句有一點(diǎn)在我看來(lái)是非常奇怪的，因?yàn)槲矣X(jué)得問(wèn)問(wèn)題的人并不理解同步異步是什么意思,。"一個(gè)一個(gè)下載的方式"是同步的行為,，“多線程同時(shí)下載”是異步的行為,。 都搞混了把！
    

4. runloop
現(xiàn)在說(shuō)說(shuō)runloop為何會(huì)成為cocoa開(kāi)發(fā)中迷惑的點(diǎn),。因?yàn)楹芏嘈率譀](méi)有從動(dòng)態(tài)角度看它,。 首先回想一下第2點(diǎn)介紹的runtime的概念。 接著我出一個(gè)題思考一下,。

現(xiàn)在我有一個(gè)程序片段如下：

現(xiàn)在要求,，做某些設(shè)計(jì)，使得當(dāng)這個(gè)線程運(yùn)行的同時(shí),，還可以從其它線程里往它里面隨意增加或去掉不同的計(jì)算任務(wù),。 這，就是NSRunloop的最原始的開(kāi)發(fā)初衷,。讓一個(gè)線程的計(jì)算任務(wù)更加靈活,。 這個(gè)功能在c, c++里也許可以做到但是非常難，最主要的是因?yàn)檎Z(yǔ)言能力的限制,，以前的程序員很少這么去思考,。

好，現(xiàn)在我們對(duì)上面代碼做一個(gè)非常簡(jiǎn)單的進(jìn)化：

注意,，這里沒(méi)有做線程安全處理,，記住Mutable container is not thread safe.
這個(gè)簡(jiǎn)單的擴(kuò)展，讓我們看到了如何利用runtime能力讓線程靈活起來(lái),。當(dāng)我們從另外線程向targetQueue和actionQueue同時(shí)加入對(duì)象和方法時(shí)候,，這個(gè)線程函數(shù)就有了執(zhí)行一個(gè)額外代碼的能力。

但,，有人會(huì)問(wèn)，哪里有runloop? 那個(gè)是 nsrunloop? 看不出來(lái)啊,。

一個(gè)線程內(nèi)這個(gè)結(jié)構(gòu)就叫線程的runloop,   它和NSRunloop這個(gè)類雖然名字很像,，但完全不是一個(gè)東西。以前在使用靜態(tài)語(yǔ)言開(kāi)始時(shí)候,，程序員沒(méi)有什么迷惑,，因?yàn)闆](méi)有NSRunloop這個(gè)東西。 我接著來(lái)說(shuō),，這個(gè)NSRunloop是如何來(lái)得,。

第二段擴(kuò)展代碼里面確實(shí)沒(méi)有NSRunloop這個(gè)玩意兒，我們接著做第3次改進(jìn),。 這次我們的目前是把哪個(gè)動(dòng)態(tài)部分抽象出來(lái),。

5. delegate, protocol
這個(gè)會(huì)列出來(lái)因?yàn)椋腋杏X(jué)問(wèn)它的數(shù)量?jī)H此于內(nèi)存管理部分,，它們用得很頻繁,，并且它們是多鐘設(shè)計(jì)模式的重要組成部分,。

6. responder chain

7. Memory Reference Counting(RC) & Automatic Reference Counting(ARC)
這個(gè)也許是問(wèn)得最多的問(wèn)題了吧。所有這些問(wèn)題往往來(lái)源于3個(gè)地方,，1,、不了解底層機(jī)制；2,、沒(méi)有吃透規(guī)則,； 3、不了解常用container的Reference Counting特性,或著說(shuō)沒(méi)有下功夫去看對(duì)應(yīng)文檔,。

１.　底層機(jī)制
大家是否知道從舊時(shí)代的RC到ARC機(jī)制到底意味著什么呢,？　為什么ARC從開(kāi)發(fā)速度，到執(zhí)行速度和穩(wěn)定性都要優(yōu)于rc,？

開(kāi)發(fā)速度不言而喻,，你少寫(xiě)很多release代碼，甚至很少去操心這部分,。

執(zhí)行速度呢,？這個(gè)還要從runtime說(shuō)起，還記得我在第２點(diǎn)說(shuō)得一句話么：“Runtime is everything between your each function call.”  

RC是一個(gè)古老的內(nèi)存管理哲學(xué),，誰(shuí)分配誰(shuí)釋放,。通過(guò)counting來(lái)計(jì)數(shù)到底該資源有幾個(gè)使用者。道理很簡(jiǎn)單,，但是往往簡(jiǎn)單的東西人卻會(huì)犯錯(cuò),。從來(lái)沒(méi)有一個(gè)程序員可以充滿信心的說(shuō)，我寫(xiě)得代碼從來(lái)沒(méi)有過(guò)內(nèi)存泄露,。這樣來(lái)看,，我們就更需要讓程序可以自己處理這個(gè)管理機(jī)制，這就需要把這個(gè)機(jī)制放到runtime里,。

所以RC->ARC就是把內(nèi)存管理部分從普通開(kāi)發(fā)者的函數(shù)中移到了函數(shù)外的runtime中,。因?yàn)閞untime的開(kāi)發(fā)原型簡(jiǎn)單，邏輯層次更高,，所以做這個(gè)開(kāi)發(fā)和管理出錯(cuò)的概率更小,。實(shí)際上編譯器開(kāi)發(fā)人員對(duì)這部分經(jīng)過(guò)無(wú)數(shù)次測(cè)試，所以可以說(shuō)用arc幾乎不會(huì)出錯(cuò),。另外由于編譯的額外優(yōu)化,，使得這個(gè)部分比程序員自己寫(xiě)得代碼要快速很多。而且對(duì)于一些通用的開(kāi)發(fā)模式,，例如autorelease對(duì)象,，arc有更優(yōu)秀的算法保證autoreleasepool里的對(duì)象更少。

2. RC規(guī)則
首先說(shuō)一下rc是什么，r-Reference參照,，引用 c-counting計(jì)數(shù), rc就是引用計(jì)數(shù),。俗話說(shuō)就是記錄使用者的數(shù)量?！±绗F(xiàn)在我有一個(gè)房間空著,，大家可以進(jìn)去隨意使用，但是你進(jìn)門(mén)前,，需要給門(mén)口的計(jì)數(shù)牌子+1, 出門(mén)時(shí)候-1,。　這時(shí)候這個(gè)門(mén)口的牌子就是該房間里的人數(shù),。一但這個(gè)牌子變?yōu)椋拔揖涂梢园逊块g關(guān)閉,。

這個(gè)規(guī)則可以讓NSObject決定是不是要釋放內(nèi)存。當(dāng)一個(gè)對(duì)象alloc時(shí)候,，系統(tǒng)分配其一塊內(nèi)存并且object自動(dòng)計(jì)數(shù)retainCount=1 這時(shí)候每當(dāng)[object retain]一次retainCount+1（這里雖然簡(jiǎn)寫(xiě)也是rc不過(guò)是巧合或者當(dāng)時(shí)開(kāi)發(fā)人員故意選的retain這個(gè)詞吧）每次[object release]時(shí)候retainCount-1　當(dāng)retainCount==0時(shí)候object就真正把這快內(nèi)存還給系統(tǒng),。

3. 常用container的Reference Counting特性
這個(gè)規(guī)則很簡(jiǎn)單把。但是這塊確實(shí)讓新手最頭疼的地方,?！?/span>問(wèn)題出在，新手總想去驗(yàn)證rc規(guī)則,，又總是發(fā)現(xiàn)和自己的期望不符合,。 　
無(wú)數(shù)次看到有人寫(xiě)下如下句子

當(dāng)然了，我也做過(guò)類似的動(dòng)作,，那種希望一切盡在掌握中的心態(tài),。但是你會(huì)看到其他人告訴這么做完全沒(méi)有意義。rc does not work this way.   也許這樣的暴力釋放會(huì)起作用,，但是retainCount并不是用來(lái)做這個(gè)的,。每個(gè)數(shù)字意味著有其它對(duì)象引用該資源，這樣的暴力釋放很容易導(dǎo)致程序崩潰,。這個(gè)數(shù)字也許并不是你心目中的哪個(gè),。因?yàn)槟愫茈y跟蹤到底哪些對(duì)象引用的該資源。你用代碼建立的資源不光只有你的代碼才會(huì)用到,，你調(diào)用的各種Framework，F(xiàn)ramework調(diào)用的Framework,，都有可能改變這個(gè)資源的retainCount.  所以去驗(yàn)證rc規(guī)則不是明智之舉,。

你能做的就是理解規(guī)則，使用規(guī)則,，讀文檔了解container的引用特性,。或者干脆移到arc上面，讓runtime環(huán)境處理這些問(wèn)題,。

最后說(shuō)一下不用arc的情況,。目前情況來(lái)看，有不少第三方的庫(kù)并未支持arc,，所以如果你的舊項(xiàng)目使用了這些庫(kù),，請(qǐng)檢查是否作者發(fā)布了新版本，或者你需要自己修正支持arc,。

8. class heritage 

9. English

10. Just trying to be smart

其實(shí)剩下這個(gè)有好幾點(diǎn)要說(shuō),，但綜合一下把。思路有些相似
例如剛看到這個(gè)問(wèn)題：

引用

現(xiàn)在有A ＊a,；A＊b
[NSMutableArray addObject : a];
[NSMutableArray replaceObjectAtIndex:0 withObject:b]
執(zhí)行完這兩個(gè)之后,，拿可變數(shù)組里面的0 的位置 就是b元素了，那這個(gè)時(shí)候a到哪里去了,？,？是否還占用著內(nèi)存，如果占用內(nèi)存的話,，又如何去釋放,？？

It's kind of silly.  我并不是想諷刺問(wèn)問(wèn)題的朋友,。其實(shí)如果你真的了解了上面這些知識(shí)點(diǎn),，就不會(huì)再問(wèn)這種問(wèn)題的。 為什么不多思考一層呢,，在問(wèn)這個(gè)問(wèn)題之前想想,，到底為什么會(huì)問(wèn)出這個(gè)問(wèn)題？ ”如果讓你給NSMutableArray實(shí)現(xiàn)一個(gè)replaceObjectAtIndex函數(shù)你會(huì)怎么寫(xiě),？“  難道連個(gè)[obj release]都考慮不到么,？然后根據(jù)ARC，它到底釋放了沒(méi)不言自明了把,。

其實(shí)這種問(wèn)題論壇里很多的,。不妨在迷惑的時(shí)候，先問(wèn)問(wèn)自己為什么會(huì)迷惑,。


(1)這里其實(shí)很有意思,，為何我用“更高層次思考”，而不是“更底層次”,。作為一個(gè)編譯器和語(yǔ)言開(kāi)發(fā)人員,，面對(duì)的問(wèn)題確實(shí)更底層沒(méi)錯(cuò)，但是他們思考的維度更高,，更抽象,，這樣子。一個(gè)不算恰當(dāng)?shù)谋确骄秃孟褚粋€(gè)三維世界的人處理二維世界的一條線的問(wèn)題。