[[140168]]

文/某鳥

前記

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

自學與培訓

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

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

筆者自己也是自學入行，直到最近認識一些正在或剛剛結束培訓的朋友，才對培訓有了一個大致的了解，當然，

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

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

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

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

而對一些有相關經驗的朋友，就要分情況對待了。按照自己的已經會的東西找方向去拓展，比如面向對象的編程方式，比如 Objective-C 的語法特性。按照已有的基礎去拓展，會稍微省力一些。一方面比較異同，印象比較深刻；另一方面，學過第一門語言，寫第二次 Hello world! 總歸會少很多需要拓荒的東西。

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

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

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

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

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

近來偶爾聽朋友們說自己的培訓經歷，其實培訓的側重點還是挺不錯的。因為老師也大多是前、現從業人員，所以學習重點與實際的開發工作關聯性也比較強。另外部分培訓針對零基礎童鞋會有一些 C語言 和基礎面向對象開發的預熱，過渡比較平滑，對于剛接觸開發的童鞋還是比較友善的。雖然作為一個自學出生的程序員，總是有意無意的黑培訓，但在實際上，不得不承認，工作技能的培訓，從來都是務實的，只不過收費= =

所以總結下來，建議是如果基礎薄弱、且財力尚可的童鞋不妨考慮考慮靠譜的培訓機構，僅當有一定開發經驗或對自己的自學能力有自信的同學可以嘗試自學。還是那句話，自學的坑從來都是出奇的多，一定要做足心理準備。

研究、提問與探討

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

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

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

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

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

所以，合理的問問題方式：如果你能夠定位問題，那就定位，如果能夠做合理推理，就把自己的推理也附上去。更重要的是，記得附上報錯，或者 warning 的截圖。總之，能推斷出問題的依據，越多越好，一般當你搜集到這么多東西的時候，估計你自己就找出問題所在了。所以，換句話說，多自查，先確保你自己確實找不出原因時（大部分是因為粗心哦我說= =），再提問。如果最終得到的結論是因為自身的知識點盲區，理解有限，或者是因為未知的知識點，那么可喜可賀，你問了一個對于自己來說很有價值的問題。可如果是因為粗心= =我不怪你，你自己去面壁就好了。

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

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

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

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

英語

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

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

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

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

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

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

#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’

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

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

‘a’ macro redefined

如此一來，如果我們對以上兩個單詞不加以區別，而是簡單的依靠查單詞的話，就很有可能在特定的環境下出現理解失誤了。可反觀之，當我們確切掌握了這些詞在專業環境中的含義，那它們便能成為我們理解文章含義的一把鑰匙，不止不會錯失細節，反而更容易根據這些詞來推斷其它不相熟的內容。

這里有一個比較典型的例子是 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 

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

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

#p#

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

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

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

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

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

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

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

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

如何提高

瓶頸期從來都是迷茫的，長時間的迷茫可能造成工作不積極、終日碌碌無為，便秘，生活不和諧等種種的惡劣影響。而如何提高，逐漸演變為諸位 iOS 新手程序員自入職以來的第二大難題，第一大當然是找對象，別問我為什么。

一般而言，網上提供的大多數攻略都可以歸納為三條：

• 多看網站與博客
• 多寫代碼，多思考
• 學好英語

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

自己在開發自學路上信奉的原則主要有兩條：

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

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

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

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

其實在什么都不會的時候學東西是最爽的，因為什么都不會，所以也不用挑揀，反正都得學= =

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

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

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

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

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

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

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

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

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

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

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

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

后記

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

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

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