一個普通的 5 年iOS開發者的自我總結，以及5年開發經歷和感想！

前言：

做爲從事 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,阿里面試題、面試經驗，討論技術， 你們一塊兒交流學習成長！但願幫助開發者少走彎路。

文章來源於網絡，若有侵權，請聯繫小編刪除。