前言：
作爲從事 iOS 開發好幾年的開發者，我見識過 2013-2014 年移動端大熱時的瘋狂，見識過 2016 年一個 iOS 崗位對應千封簡歷的瘋狂。
一個細分的行業從大熱到遇冷，僅僅兩三年的時間。而如今看到現在市場的變化，感覺移動開發進入了一個新的階段：移動端崗位需求正在快速減少，對從業者的要求越來越高。
那種培訓班三個月出來都能找份月薪過萬的工作的事情早就是上古神話了。但是，這只不過意味着志向於從事移動端開發的普通開發者或者普通學校出身的同學需要更努力一點證明自己。
作爲一個開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是一個我的iOS交流羣：638302184，不管你是小白還是大牛歡迎入駐，分享BAT,阿里面試題、面試經驗，討論技術， 大家一起交流學習成長！希望幫助開發者少走彎路。
就像我十年前讀到李開復的博客“二流學校的我該怎麼辦”裏面有一段話：
畢竟復旦、交大、北大、清華是所有HR都知道的，你說你是某個地方某所小學校裏出身的學生。HR可能不是很清楚那所學校的情況，所以對你有些先入爲主的偏見，這很正常。畢竟站在公司的立場，他希望有secure，招人也是件很麻煩的事情。所以他要優先考慮你的背景和資質是否可以勝任或者是完全超越職位所需的。
一旦你能拿出相關的證據（實實在在的）東西，那麼即便你出身二流學校你仍然是很有希望的。如果你拿不出，那麼坐在你旁邊的名校生說我畢業於。。。就讀於某個專業（這個是他的證據）。在雙方都沒有實在證據的前提下，那麼“讀書好”就成了一種支持性的證據，證明他比你優秀。
作爲普通開發者，必須要有實實在在的東西證明自己的能力，才能在行業裏保持競爭力。保持競爭力，不僅要有個人奮鬥，也要注意行業發展的進程。所以，這個事情就簡化成了兩個部分：有深厚的 iOS 開發功底；在大前端時代裏更好地適應。
談談對 iOS 開發的認識
iOS 應用開發是通用軟件開發的一個方向。所以，做好 iOS 開發，需要 iOS 專業知識和通用軟件專業知識。
上面提到“移動開發還真是什麼人都能做”只是說這個行業入門的門檻相對較低而已，如果想在移動端開發有所作爲，還是要努力掌握相關知識的。
UI
很多人可能對移動端開發有一些誤解，甚至覺得做移動端就是畫畫 UI 而已。所以在知乎上會有“爲什麼最難不過二叉樹的算法出現在面試題中都會被應聘者抱怨？”這樣的問題。
額，不懂點算法，有的時候是畫不好 UI 的。比方說，圖片輪播器是一個很常見的 UI 組件，當在 GitHub 上 搜索時，我們會發現排名靠前的方案有些是通過將 original dataSource 重複幾次的方式來生成一個較大的 UICollectionView, 從而以一種取巧的方式實現輪播的效果。這種方式可以只對 dataSource 做簡單的算術運算，而不是使用深拷貝的方式，從而將開銷維持在很低的水平上。不過，當我們懂得基礎的數據結構之後，雙向鏈表封裝一下，可能會是一個更好的解決方案[ 1,2 ]。
Runloop & Runtime
工作過幾年的 iOS 工程師如果出去面試，一定會被問到關於 Runloop 和 Runtime 的問題，這是 iOS 工程師進階必須懂得的知識。可能有些工程師會抱怨，在日常開發中又不會用到這些東西。這個觀點是錯誤的。
Runloop 可以說是iOS 系統的靈魂。內存管理／UI 刷新／觸摸事件這些功能都需要 Runloop 去管理和實現。理解 Runloop 並不是一定要在日常開發中調用 CFRunloopRef 或者 NSRunloop 相關的 API, 而是通過學習 Runloop 來理解 iOS 的運行機制，知道自己寫下去的代碼是怎樣運行的，從而帶給用戶更好的體驗。止步於死記硬背如下筆試題的工程師不是好工程師：
關於 ObjC Runtime, 很多人會冠以“黑魔法”的名稱，聽着就感覺很玄乎。做爲普通開發者，必須糾正諸如“ObjC Runtime 就是 Method Swizzling” 這樣片面的觀點。在 category 裏爲 UIView 添加一個 property 是用到了 Runtime 相關的知識， KVO 也是用到了 Runtime 相關的知識。
如果這些還不夠，今日頭條“iOS 客戶端啓動速度優化”瞭解一下，優化的 tips 包括減少 ObjC 類數量，減少 selector 數量，如果有可能就把 +load() 做的事情延遲到 +initialize 中執行。這些都是和 ObjC Runtime 相關的知識點，理解 Runtime 是能夠解決很多實際問題的。
內存管理
“現在都是 ARC 時代了，還談什麼內存管理，讓系統自己去管理吧。
ARC 減少了開發者花在內存管理上的時間。ARC 減少了 leaked memory, 而 abandoned memory 出現的場景多見於 self -> block -> self 這樣的循環引用，會複製粘貼 weakSelf strongSelf 就能解決。”
在一個大型應用裏，可能出現多個對象形成的循環引用，這種內存泄漏通常比較隱蔽，可能需要使用 Instrument 相關工具來定位問題，或者引入第三方庫在 debug 階段發現內存泄漏。
而我相信這些檢測內存泄漏的第三方庫的作者是在深刻理解 iOS 內存管理方式之後才寫出來的。
所以，對於普通開發者來說，理解 ARC 的原理會提高日常開發的質量，增加對自己的代碼的信心。
文章的最後
與此同時，留下的纔是最美好的，既然你讀到這了，相信你也希望你能改變自己，戰勝自己！大家一起努力，讓我們一起加油，在iOS開發的 這條道上越走越遠！
作爲一個開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是一個我的iOS交流羣：638302184，不管你是小白還是大牛歡迎入駐，分享BAT,阿里面試題、面試經驗，討論技術， 大家一起交流學習成長！希望幫助開發者少走彎路。
文章來源於網絡，如有侵權，請聯繫小編刪除。