[[140168]]

文/某鳥

前記

不知不覺，從正式?jīng)Q定學(xué)習(xí) iOS 開發(fā)到現(xiàn)在，已經(jīng)差不多一年的時間了。雖然總覺得自己還是個新人，可開發(fā)經(jīng)驗的確是有點，再天天的裝逼說自己是個小白，也是有些不要臉了。所以打算坦然戴上 “iOS 一年開發(fā)經(jīng)驗”的帽子，總結(jié)總結(jié)這一年來零零散散的經(jīng)歷和感悟，也把自己的一些經(jīng)驗和觀點拿來分享，由此做個界定，繼續(xù)走上一條不歸路。

自學(xué)與培訓(xùn)

iOS 開發(fā)學(xué)習(xí)的第一個選擇往往是自學(xué)與培訓(xùn)。自學(xué)的一般不是不信邪就是窮，這是不言自明的。在學(xué)習(xí)初期，遇到的新手朋友們經(jīng)歷各異，有剛畢業(yè)的應(yīng)屆生，有干了幾年其它平臺想轉(zhuǎn)行的老程序員，也有風(fēng)馬牛不相及的興趣轉(zhuǎn)行青年。

相對來說，選擇自學(xué)的人還是比較多，一部分原因是現(xiàn)在的平均學(xué)歷普遍較高，大家的自學(xué)經(jīng)歷比較豐富，估計都是期末趕考的行家。另外一方面，財力有限，而現(xiàn)在的培訓(xùn)費用普遍虛高。雖然各大培訓(xùn)機構(gòu)時不時打出來“先就業(yè)，后付費”的廣告，但實際的投入，又是另一個層次的不言自明了。

筆者自己也是自學(xué)入行，直到最近認識一些正在或剛剛結(jié)束培訓(xùn)的朋友，才對培訓(xùn)有了一個大致的了解，當(dāng)然，

轉(zhuǎn)自他人之口，認識還是很局限，但不妨拿出來一起聊聊之間的區(qū)別。

自學(xué)是伴隨著各種各樣的無知開始的，swift、Objective-C、C，從零開始的時候從哪開始好呢？要不要買 MAC 呢？應(yīng)該買什么樣的書，哪個網(wǎng)站會有不錯的資源，哪個版本的教學(xué)視頻比較靠譜？偶爾也會冒出來“學(xué)3個月能不能找到工作”這樣沒有依據(jù)的問題。如果沒有一些靠譜的引導(dǎo)，自學(xué)的坑總是出奇的多。有些朋友是在職學(xué)習(xí)，時間本來就少，還需要消耗大把的精力用來拓荒。

一般遇到朋友問這樣的問題時，我會先問問之前有沒有什么相關(guān)經(jīng)驗。如果沒絲毫經(jīng)驗，我會推薦他先去學(xué) C語言，一方面是因為 C語言相對比較容易入門，可以比較快的對開發(fā)有一個籠統(tǒng)的認識。

另一方面也可以測試一下自己對于編程的悟性如何，以便對自己未來的學(xué)習(xí)效率有一個估計。最后，因為 Objective-C 本身是 C語言 的超集，把精力分在 C語言 上，總歸不會走彎路。

而對一些有相關(guān)經(jīng)驗的朋友，就要分情況對待了。按照自己的已經(jīng)會的東西找方向去拓展，比如面向?qū)ο蟮木幊谭绞剑热?Objective-C 的語法特性。按照已有的基礎(chǔ)去拓展，會稍微省力一些。一方面比較異同，印象比較深刻；另一方面，學(xué)過第一門語言，寫第二次 Hello world! 總歸會少很多需要拓荒的東西。

自學(xué)是個從無到有的過程，得步步為營，切忌貪多。尤其是方向不明確的時候，一方面不想莫名其妙的走了彎路，另一方面也打擊自己學(xué)習(xí)的信心。在瓶頸期的時候多理理當(dāng)下的學(xué)習(xí)重點，然后對之前會的東西做一些更深入的思考，會比較容易繞出來。尤其是在實踐之后更深入的思考，哪怕是在一個點上理解的更透徹，馬上就會有一種融會貫通的感覺。這種層次上的提升，會開拓自己的視野，讓你用不同的角度來審視開發(fā)，成就感嗖嗖的~

另外一點自學(xué)經(jīng)驗是，開發(fā)入門從來都是高不成低不就的。好不容易用 Objective-C 寫出了自己冠名的第一個類，可還是下不知內(nèi)存管理，上不知如何構(gòu)造界面。明明已經(jīng)下了很大的功夫，卻好像還是什么都不會的樣子。這種經(jīng)歷比較容易惹人心慌，要學(xué)會把握學(xué)習(xí)階段，知道自己已經(jīng)會了什么，距離目標(biāo)之間，還需要學(xué)會哪些知識點，然后逐個擊破。

在自學(xué)過程中，對自己的心性，和對學(xué)習(xí)過程的把握會顯得很重要。而且送一句忠告：因為是自學(xué)，做好在任何情況下發(fā)現(xiàn)自己是個傻逼的心理準(zhǔn)備。筆者前兩天剛在 GitHub 上丟了回人，才知道在類方法中，self 指向的是這個類而非實例，慚愧不已。

而反觀培訓(xùn)過程，一方面有人督促，一方面分段目標(biāo)與進度都比較明確，上面說到的坑基本都是不填自平的。而且一群人坐在一起，很容易知道自己的優(yōu)勢和弱勢，也就容易查漏補缺。再者，有一個相互討論的環(huán)境總是更容易發(fā)現(xiàn)自己一個人下意識回避的盲點，也是一個挺不錯的方法。

不過有一點需要強調(diào)，就是不要對培訓(xùn)報過高的期望。國內(nèi) iOS 開發(fā)的就業(yè)環(huán)境雖然不錯，但總歸不會有宣傳出來的那么夸張。在實際招聘中，對培訓(xùn)出身的童鞋并不會給什么特別的優(yōu)待，偶爾還會有一些輕視，所以記得一定要用實際的開發(fā)能力去打動面試官哦?_?

近來偶爾聽朋友們說自己的培訓(xùn)經(jīng)歷，其實培訓(xùn)的側(cè)重點還是挺不錯的。因為老師也大多是前、現(xiàn)從業(yè)人員，所以學(xué)習(xí)重點與實際的開發(fā)工作關(guān)聯(lián)性也比較強。另外部分培訓(xùn)針對零基礎(chǔ)童鞋會有一些 C語言 和基礎(chǔ)面向?qū)ο箝_發(fā)的預(yù)熱，過渡比較平滑，對于剛接觸開發(fā)的童鞋還是比較友善的。雖然作為一個自學(xué)出生的程序員，總是有意無意的黑培訓(xùn)，但在實際上，不得不承認，工作技能的培訓(xùn)，從來都是務(wù)實的，只不過收費= =

所以總結(jié)下來，建議是如果基礎(chǔ)薄弱、且財力尚可的童鞋不妨考慮考慮靠譜的培訓(xùn)機構(gòu)，僅當(dāng)有一定開發(fā)經(jīng)驗或?qū)ψ约旱淖詫W(xué)能力有自信的同學(xué)可以嘗試自學(xué)。還是那句話，自學(xué)的坑從來都是出奇的多，一定要做足心理準(zhǔn)備。

研究、提問與探討

在找到工作約莫一個月的時候，覺得自己也可以解決一些簡單的問題時，就偶爾去 CocoaChina 的論壇里轉(zhuǎn)轉(zhuǎn)，回回帖。自己也加入了一個開發(fā)新手群，常常會在里面討論一些相關(guān)的問題。

但是回帖這種事情很快就嘗到了疲倦感，簡單的問題往往驚人的相似，止不住的想復(fù)制粘貼。另外一方面則由于提問給出的信息有限，解決的過程一部分靠推斷一部分靠猜，雖然本著自學(xué)坑一個不落踩過來的龐雜經(jīng)驗給了一個靠譜的建議，但有心無力，最后那句話仍然是“你再看看吧……”

在不斷有問題產(chǎn)生的時候，獨立研究的能力會比較重要。在初學(xué)階段，比較困難的地方在于沒有足夠的理論作為依據(jù)來進行合理的假設(shè)，實在不知道為什么就會開腦洞估計是“今天天氣不好，所以才會報錯”的吧？這里除了重申基礎(chǔ)的重要性之外，還得祭出法寶：一點一點試。

很少有語法還寫不好的童鞋就學(xué)會使用斷點和 Debug 工具的，所以笨辦法就是注釋，頻繁的逐句注釋測試。來驗證每一句的正確性，另一方面，強化自己的基礎(chǔ)并開始涉獵 Debug 工具。然后就發(fā)現(xiàn)原來可以增加“異常斷點”，可以在中斷情況下查看范圍內(nèi)的變量值，可以逐句運行。一方面，獨立研究等同于實踐經(jīng)驗，另一方面也會增加自己的 Debug 功底。

如果實在搞不定，那還是得問。但是咱既然問問題，就要本著能拿到答案的方法來。其實挺痛恨截圖的，一口氣截圖一大段代碼，然后沒有上下文，后面跟一句，錯哪了？連粘過來自己復(fù)現(xiàn)都不給機會（ˉ﹃ˉ）。然后就只能一長串的追問，把報錯粘上來，把上下文粘上來，balabala…最后發(fā)現(xiàn)，臥槽，你屬性是個 nil ?。?_?

所以，合理的問問題方式：如果你能夠定位問題，那就定位，如果能夠做合理推理，就把自己的推理也附上去。更重要的是，記得附上報錯，或者 warning 的截圖?？傊芡茢喑鰡栴}的依據(jù)，越多越好，一般當(dāng)你搜集到這么多東西的時候，估計你自己就找出問題所在了。所以，換句話說，多自查，先確保你自己確實找不出原因時（大部分是因為粗心哦我說= =），再提問。如果最終得到的結(jié)論是因為自身的知識點盲區(qū)，理解有限，或者是因為未知的知識點，那么可喜可賀，你問了一個對于自己來說很有價值的問題?？扇绻且驗榇中? =我不怪你，你自己去面壁就好了。

之前遇到的一個比較蛋疼的問題是 NSLog(@"%@ %@",string1),string2;，貼出來一段代碼說檢查變量都沒問題，但就是打印崩潰。然后一群人在上面的代碼里找了好一陣，最后說你把打印的那句貼出來。剛開始大家都以為又是某個“黑魔法”一樣的詭異語法，結(jié)果自己在代碼里一敲，才發(fā)現(xiàn)根本就是少了一個打印變量，被后面的逗號運算符蒙混過去了。然后就在群里吐槽，你真的不看 warning 的么？事后想起，還是一陣菊緊。

另外，盡量不要提用來偷懶的問題。有心氣的時候筆者總是會幫忙百度給個鏈接或者是文檔地址，到后面基本都是甩一句“查文檔”或者“自行百度”了。這個情況倒也不是那么絕對，隨著有了一個固定的討論圈，對大家的開發(fā)經(jīng)歷也有些了解，有時候遇到之前朋友解決的類似問題時，也偶爾會偷偷懶，直接從朋友那里要段代碼走人。建議把握住兩個要點，一個是不會讓對方很費事，另一個是你得確定如果偷不到懶，自己也可以解決這個問題。第二個更重要些。

就自己的經(jīng)驗而言，有一個穩(wěn)定的圈子討論和提問是一個很好的學(xué)習(xí)途徑。每個人都會有盲點，而有價值的話題點能夠很有效的幫助你規(guī)避這個問題。不同的視角，不同的開發(fā)經(jīng)驗，會帶來許多靈感和靠譜的經(jīng)驗，也會很實際的告訴你有哪些你還不會但是必須要會的東西。

補上一條，不建議大家本著與自己無關(guān)的態(tài)度來對待提問，哪怕是在自己懂的東西還很少的時候。提出一個有價值的問題不容易，推斷問題的關(guān)鍵點，涉及的知識點，然后把相關(guān)的知識點系統(tǒng)化，整個一套流程走下來，本身就是對獨立學(xué)習(xí)能力的提升。而且當(dāng)你給別人講述的時候，往往會很容易發(fā)現(xiàn)自己比較含糊的地方，那恰恰就是自己的薄弱環(huán)節(jié)，千萬不要錯過這樣的機會，因為一旦錯過了，下次遇到或許已經(jīng)是上線的 crash 了。

英語

前兩個小節(jié)比較新手向，隨著開發(fā)時間增加，一些剛開始察覺不到的問題就會暴露在眼前。

英語是開發(fā)路上的攔路虎，越是想走遠，就越是不得不正視。

還記得自己第一份工作的第一個月，不完全統(tǒng)計每天至少對著官方文檔3~4個小時，那種崩潰真的是無法言喻。好在 MAC 的三指查詞功能很方便，等價于一手拿著字典一手看文章?？戳四敲匆欢螘r間后，對于看英語的文獻就不再那么排斥了。

專業(yè)英語和普通英語區(qū)別最大的地方在于特定詞匯的使用。像 OOP 是 Object Oriented Programming ，這樣的專業(yè)詞匯甚至縮寫倒不會引起太大的閱讀障礙，哪怕不知道是什么，百度一下也就得到答案了。但某些約定俗成的常見詞就成了閱讀期比較不容易掌握的坑。

比如 declare 和 define ，翻譯過來分別是“聲明”和“定義”。如果是在“先聲明，后調(diào)用”的這個環(huán)境下，你會發(fā)現(xiàn)用“先定義，后調(diào)用”來解釋也是完全說的過去的。但在實際文獻中，兩個詞的不同遠遠不止翻譯區(qū)別這么簡單。

如果你接觸過 python ，他是用 def （define 的縮寫）來定義函數(shù)的，而在 C語言 系中，則是用 declare 來表答函數(shù)和變量的聲明。我們利用兩種語言的報錯來展示這個小細節(jié)。

#python 
print a 

Traceback (most recent call last):

File ““, line 1, in 

NameError: name ‘a’ is not defined

//Objective-C 
NSLog(@"%d",a); 

Use of undeclared identifier ‘a’

當(dāng)然，如果是這樣，是達不到混淆的效果的。只可惜，在 Objective-C 中，你也能看到 define 的出現(xiàn)，在哪呢？宏定義 #define：

//Objective-C 
#define a 1 
#define a 2 

‘a’ macro redefined

如此一來，如果我們對以上兩個單詞不加以區(qū)別，而是簡單的依靠查單詞的話，就很有可能在特定的環(huán)境下出現(xiàn)理解失誤了?？煞从^之，當(dāng)我們確切掌握了這些詞在專業(yè)環(huán)境中的含義，那它們便能成為我們理解文章含義的一把鑰匙，不止不會錯失細節(jié)，反而更容易根據(jù)這些詞來推斷其它不相熟的內(nèi)容。

這里有一個比較典型的例子是 unrecognized selector sent to instance 這句報錯。在新手中往往很容易忽略，看到了也不以為然，然后抓耳撓腮也想不到到底哪里出了錯。可這類錯誤的原因其實往往都來自很低級的錯誤：.h文件中的方法名和.m文件中不一致。比如之前看到的一段代碼：

@interface Man:NSObject 
-(void)setID:(int)id 
         age:(int)age 
         sex:(int)sex; 
@end 
   
@implementation Man 
-(void)setID:(int)id 
         sex:(int)sex 
         age:(int)age{ 
    //... 
} 
@end 

這么寫本身靜態(tài)編譯雖然會給一個 warning 提示沒有實現(xiàn)之前聲明的方法，但是 Build Seuccess 是肯定的。所以只有當(dāng)調(diào)用這個方法的時候，才會報錯。通常的做法都是先從調(diào)用這個方法的上下文找起，然后找不到錯，就在這個方法的實現(xiàn)里找找看。最氣急敗壞的地方在于給實現(xiàn)的第一句打了斷點，結(jié)果還沒進來就報錯了，可之前的所有代碼哪一句都沒問題。郁悶么？是啊，得花多少時間才能發(fā)現(xiàn)是方法名寫錯了，發(fā)現(xiàn)之后是不是很有扇自己耳光的沖動？

可如果你知道了 unrecognized selector sent to instance 這句報錯的意思是實例響應(yīng)了錯誤的方法（你也可以翻譯成“未被承認的選擇器被發(fā)送給了實例”，其實一直挺想吐槽這句報錯來著= =），那么你首先要確認的就應(yīng)該是 selector 是否正確。而什么是 selector 呢，如果寫代碼時有留意的話，在 addTarget: action: 這個方法中，action 的參數(shù)有一個 @selector 標(biāo)記。當(dāng)然了，還有 respondsToSelector 這種“耍流氓”語句的起手勢，它們都在向你透露同一個信息，selector，其實就是方法名。而方法名是以 .h 文件中的方法聲明為基準(zhǔn)的，那還不麻溜的去檢查 .m 文件里的方法名？

#p#

在以前學(xué)英語的時候，老師總是說，同一個意思要學(xué)會用不同的方式去表達。但是在專業(yè)文獻中，詞匯的指代往往準(zhǔn)確而單一，哪怕是 push 這樣口語化的詞，在 iOS 開發(fā)中也是有很確切的含義的。對這些詞的積累會很有助于閱讀，哪怕你不上 Google，不上 StackOverFlow，也不看英文文獻，不看官方文檔，就是只為了看懂 warning 和報錯，也是很有必要的。

在 Objective-C 設(shè)計之初，為了讓整個語言更加易讀，特地設(shè)計了多段式的方法名，來說明每個參數(shù)。而得益于 xcode 強大的自動補全能力，其命名往往長而全，會利用一些關(guān)鍵詞來表達其功能。這使得我們在閱讀代碼的同時，也能夠有效的積累對應(yīng)的表述用詞。所以千萬不要因為自動補全的便利就忽略對類和方法命名的積累，記得多了，一方面看源代碼再也不用頻繁的查詢文檔，另一方面，你會發(fā)現(xiàn)大家在英文文獻中有意無意的使用這些詞匯，在簡要的敘述中其實已經(jīng)給了你代碼級的步驟，這得算意外收獲。

除了閱讀和積累之外，另外一個有效的方法是翻譯。翻譯是一件逼著你去糾結(jié)每一個單詞含義細節(jié)的東西。翻譯一旦不準(zhǔn)確，上下文立馬就會顯得不連貫。而翻譯的過程，會潛移默化的加快你的閱讀能力。

比如筆者第一次翻譯文獻的時候，還處于第一遍翻譯逐個單詞，第二遍拼成整句，第三遍潤色文字的階段。簡單來說，大量的單詞不認識，讓自己無法聚焦于整句的含義。而拼成整句的過程，又無法很好的銜接上下文。于是基本到了第三遍，翻譯的文字才能基本呈現(xiàn)出文章本身的意思。比較遺憾的是，在第一次翻譯 objccn 的文章的時候，我就處于這個階段。

后面的時間里，自己又試著翻譯了一些別的文章，慢慢做到了可以在第一遍的情況下將整句的語序和含義都搞定，而在第二遍的時候借由第一次的通讀全文對上下文做出一些判斷。到了第三遍的時候，文章已經(jīng)有了一定的可讀性。對這樣看似不起眼的進步，自己還是異常欣慰的。記得不知道從什么時候開始，突然發(fā)現(xiàn)一篇英文文章中到處都是看似生僻的專業(yè)詞匯，可自己就是知道它們的含義。相對于成就感，自己更多的是一種難以置信。作為一個學(xué)渣，看到滿屏幕的字母從來都應(yīng)該是撓頭強忍困意，看一遍就能了解其大概意思的情況根本不敢想象。

除此之外，筆者還報名了英語培訓(xùn)班，可以面對面的和外教進行交流從很大程度上彌補了英語使用生澀的硬傷。雖然因為工作，可以去上課的時間總是很有限，但經(jīng)過近半年的積累，自己的聽力和理解力還是有些許進步的。就如當(dāng)初天書一般的代碼現(xiàn)在可以在腦海中復(fù)述，并且下意識的敲出，技能的熟練總是讓人欣喜且知足，也知道了還有很多東西要學(xué)，很多路要走。

當(dāng)然了，即使是這樣，筆者自己的英語水平依舊很差。很現(xiàn)實的例子是，如果在 StackOverFlow 上提問，估計還是花大半天只能憋個屁出來。當(dāng)聽和說開始慢慢的不再成為障礙后，對說和寫的加強就顯得迫在眉睫。如果有朝一日能夠與大神們交流，或者去趟 WWDC，至少不因為英語攔住了路。

代碼是世界的，代碼也是英語的，現(xiàn)實從來都是這么殘酷。

如何提高

瓶頸期從來都是迷茫的，長時間的迷?？赡茉斐晒ぷ鞑环e極、終日碌碌無為，便秘，生活不和諧等種種的惡劣影響。而如何提高，逐漸演變?yōu)橹T位 iOS 新手程序員自入職以來的第二大難題，第一大當(dāng)然是找對象，別問我為什么。

一般而言，網(wǎng)上提供的大多數(shù)攻略都可以歸納為三條：

• 多看網(wǎng)站與博客
• 多寫代碼，多思考
• 學(xué)好英語

由于簡短且步驟性不強，所以實際操作性大多看個人造化。另外這種建議沒有因材施教的特性，太過普遍，真正遇到問題的童鞋還是得自行解決。作為一大段偽干貨，以下是我的一些個人建議，別打算照抄照搬，結(jié)合自己的實際情況，看完你就知道我這是在勸你了。

自己在開發(fā)自學(xué)路上信奉的原則主要有兩條：

• 你現(xiàn)在看到的所有東西都是前人寫出來的，他們能做到你做不到的事，最主要的原因是因為他們會你不會的東西。
• 時間和精力，永遠是進步的不二法門。

數(shù)據(jù)結(jié)構(gòu)里有一個經(jīng)典的術(shù)語叫做“遍歷”，破解技術(shù)里有一個經(jīng)典方法叫做”窮舉“，說白了就一件事，挨個試。不管拓撲模型是否復(fù)雜，也不管數(shù)量級有多恐怖，先試再說。且不說剛接觸 Interface Builder 的時候，把右側(cè)的所有控件先全部拖出來擺弄了一遍這種幼稚的行為。至少在閱讀文章的時候，看到一個新的作者就點進他的博客看看他還寫過什么東西，然后不求逐篇拜讀，起碼看到自己恰巧聽過且不熟悉的內(nèi)容，不要放過。如果能總結(jié)下作者擅長的技術(shù)方向，和主要講述的技術(shù)方向，然后填個收藏且加個 TAG，留待以后遇到相關(guān)問題的時候再來拜讀，也算是下了功夫了。

閱讀習(xí)慣的養(yǎng)成需要循序漸進。剛開始入門的時候，大部分文章其實是看不懂的，這個時候過多的閱讀量除了打擊自信，就是認幾個名字。所以剛開始的時候推薦去找一些介紹 iOS 開發(fā)知識點介紹的文章來看。網(wǎng)上流傳著幾張詳細的知識點劃分，可以當(dāng)做參考。在這個階段，我們只需要大致的理解這些概念屬于 iOS 范疇，粗淺的了解它們是什么就夠了，哪怕對定義的理解有偏差也是允許的。

等到名字認的差不多了，總會有離自己現(xiàn)在學(xué)習(xí)的地方恰巧是踮著腳尖才能夠到的知識點。對，就從它下手，從已有的知識點起步去做拓展和完善，然后反過來校正已有的知識，百試不爽。這個時候可以就可以開始自己的閱讀之旅了，遇到距離近的文章就開始讀，遇到離自己遠的文章別急著跳過，記得收藏和 TAG 哦，可以考慮使用 evernote 的 chrome 剪藏插件和 pocket 作為備份工具。

其實在什么都不會的時候?qū)W東西是最爽的，因為什么都不會，所以也不用挑揀，反正都得學(xué)= =

當(dāng)逐漸的對整體框架都開始有所把握，也就是不再會出現(xiàn)特別大的定義偏差時候，就要開始逐項突破了。選擇困難癥怎么辦？不知道哪個知識點更重要怎么辦？在這里我給出的建議是，從小知識點做起，比如 block 語法 ， 代理/協(xié)議 的代碼實現(xiàn) ，這些開發(fā)初期容易遇到的小坑，它們不涉及特別復(fù)雜的底層原理，也不需要太多額外的知識點作為支撐。選擇小知識點的主要原因是，先把吃透某個知識點的過程走一遍，去體會從定性到定量的過程。

技能的提升無法依靠長時間重復(fù)的工作。就像你用筷子吃飯到現(xiàn)在，也沒辦法夾住一知飛在空中的蒼蠅一樣。提升講究的是短時期、有目標(biāo)、高強度的訓(xùn)練，具體到開發(fā)，就是先舉一反三，再總結(jié)歸納的過程。達到的程度就是你心里已經(jīng)有一桿秤，了解所有的規(guī)則和界限，“這樣寫肯定是對的”。至于怎么學(xué)呢？請學(xué)著暴力點，把所有錯誤的可能性都試出來，知道所有不對的方法，你就知道什么是正確的了。至于為什么只有這些是正確的，請參見你那些年看過的博客。

筆者個人不太相信什么速成與捷徑，縮減意味著取舍，而知識點的縮水就代表了會有盲區(qū)。與其學(xué)個一招鮮吃到老，不如老老實實把所有可能性都踏踏實實過一遍，在實際體會過一遭之后，自然會有個結(jié)論。

另外，隨著不斷的試錯，你會很明顯的感受到最真實的規(guī)則。知道什么是完全不可行，什么是官方不推薦，什么是雖然逗逼但是可行。也知道 “build success” 其實根本不說明問題，知道除了編譯器，其它一切都不具有最終解釋權(quán)。

當(dāng)你有了這樣的試錯經(jīng)驗后，你腦海中的問題就逐步從“什么是什么”轉(zhuǎn)變成了“為什么會是這樣”。這個時候，就是廣泛閱讀的開始了，因為你已經(jīng)掌握了實際的求證能力，而且對文章有了辨別依據(jù)，知道哪些部分是干貨，哪些部分是作者在裝逼和意淫（好吧，暴露文風(fēng)了= =）。

這里沒有對廣大技術(shù)文章作者不敬的意思，無論如何，花費時間和精力去分享知識都是一件值得肯定的事情，但事實是作者本身也有水平高低之分，文章中也偶爾有欠妥之處。我們不能強求每一位作者都寫出來色藝俱佳的文章，所以要懂得在閱讀的同時，別急著輕易相信。

在經(jīng)歷上述過程之后，諸位其實已經(jīng)可以成為一個入門級的 iOS 開發(fā)程序員了。畢竟開發(fā)這件事，是可以照貓畫虎來解決問題的。當(dāng)你學(xué)會了 [] 和 :，就能夠編寫出第一個方法的調(diào)用；學(xué)會了 @interface 和 @implementation ，就可以編寫出第一個屬于自己的類；學(xué)會了 Interface Builder 里的拖拽，就可以構(gòu)造出第一個屬于自己的界面，然后寫一個計算器已經(jīng)不再是問題了。

所以開發(fā)工作隨著熟練一定會變成根據(jù)需求來選擇對應(yīng)解決方案的過程，而提升就是解決方案的積累以及這些方案從開發(fā)到使用的成熟度的進步。

后面的學(xué)習(xí)進度根據(jù)自己的需要和興趣就好，掌握了方法，獲取知識多半是水到渠成的事情。一般來說，ARC/MRC （內(nèi)存管理相關(guān)）、runtime （運行時相關(guān)）、GCD （多線程相關(guān)）是 iOS 面試的三大殺器。由于涉及概念比較底層且復(fù)雜，而且在具體的代碼環(huán)境里細節(jié)比較瑣碎，讓你復(fù)述原理已然算是便宜你了。另外 UIKit 的整體結(jié)構(gòu)并不只有 UIView 與 UIViewController 這兩個基類這么簡單，掌握深層次的觸發(fā)、響應(yīng)、繪制都是必修課。而隨著 SDK 的升級，其實還提供了很多便利的方法，切記在諸多文章中尋找蛛絲馬跡。

更優(yōu)秀的學(xué)習(xí)方法大概就是學(xué)習(xí)與 WWDC 等同等級的視頻與文章了，筆者比較菜，對于這個高度也是可望而不可及，所以還請參考各路大神的分享，要是寫幾篇拓荒文順便給我發(fā)個鏈接那就再感謝不過了。

以上都是我一路走來的一些自學(xué)經(jīng)驗，如果你仔細看，不難看出，其實都是些笨辦法。不斷的試錯，不斷的閱讀去找有用的部分，而且最大的局限可能是自己的毅力和想象力。如果覺得會這些就夠了，或是試錯的時候無法做到痛擊靈魂般較真和深刻，那么得出的效果不止不理想，還很浪費時間，這也是我前文說僅供參考的原因。

不過，如果沒有更好的方法，不妨試試看，學(xué)會了騎自行車，就很難再摔倒。麻煩總好過學(xué)不到東西。

后記

不知不覺，已經(jīng)兩個月沒有更新過博客了，而自己的新工作也進入了第四個月。新工作是一次難得的機遇，幾個月以來的經(jīng)歷也確實是收獲良多。只不過對應(yīng)于收獲，自己在工作上投入的時間和精力與之前也不是一個數(shù)量級，不止博客更新放緩，很多之前有時間做的事情也都斷斷續(xù)續(xù)的停掉了。

雖然把這篇博客作為某個新系列中的一篇，但是什么時候?qū)懴乱黄?，會不會有下一篇，都是個未知數(shù)。而之前博客中的兩個大坑，想要回過頭來填完，偶爾會覺得此生無望。

什么也不敢保證，僅希望本篇文章能夠幫到一些即將或正在入門 iOS 的開發(fā)者童鞋們就好。