2018 年過去了一半，iOS 工程師如何自我提升。上篇

若是從 13 年移動客戶端大火開始算起，至今已經有五個年頭了。如今移動端的形勢也不須要太多的廢話來描述，一句話總結就是：「浪潮退去，誰在裸泳一看就清楚。」我但願藉助這篇文章來聊聊在我心目中，移動互聯網下一個五年的趨勢和機會，以及咱們 iOS 工程師能作哪些準備，實現自我提升。本文主觀性的見解比較多，文筆也比較激進，僅供參考。

咱們都知道價格會受到供需的影響，若是某項技能在市場上緊缺，那麼掌握這門技能的工做者工資就會相對高一些，好比 14 年前先後能寫好 UITableView 就能找到一個相對不錯的工做了。在我看來，將來幾年的移動互聯網，會出現「一個過剩，兩個不足」，我會逐個分析並試着給出一些建議。

UI 工程師過剩

這一點是我老生常談的了，首先要注意的是避免成爲 API 調用工程師，由於這些 UI 方面的知識對我的價值的增加不是線性的，若是你還記得高中數學，請回憶一下 y = ln(x) 這個函數的曲線。從零到寫好 UITableView 給一個工程師帶來的收益，遠遠不是從寫好 UITableView 到寫好 UIStackView 能比得上的。

就以 UIStackView 爲例吧，先不說它從 iOS 9 纔開始支持，而要想應用不支持 iOS 9，怕是要等到猴年馬月了。就說它提供的功能，雖然簡化了已有場景，但這個功能徹底能夠經過封裝已有的組件來實現，相信不少大型項目都有，爲何還要費力氣去兼容版本，以及再學習一個新的 API 呢？人的精力是有限的，若是你老是追着蘋果的腳步，每一年補 WWDC 上那些新坑和老債，那麼視野就永遠只能停留在 iOS 中了。

我拒絕追隨 WWDC 的另外一個緣由是把本身的職業生涯押注在一個平臺或者公司上，是極度不明智，也是極度危險的，即便這是蘋果。上半年的時候咱們小組招聘，我負責篩選了一批簡歷，其中有一位已經三十多歲，十年經驗的程序員，他的簡歷讓我感觸良多。他本科畢業後就在諾基亞負責塞班系統的研發，大概至關於今天的蘋果公司負責寫 iOS 系統，看起來光環很是明顯了，後來前後去過兩家生產安卓手機的大廠，如今又申請 iOS 的程序員職位。在他的簡歷裏，我看不到一個十年程序員該有的技術和思惟深度，只有一個又一個古老名詞的堆砌。所以，我衷心的建議各位讀者，在你學習一個新技術之前，不妨先花十秒鐘猜想一下，這個技術三年後，五年後，十年後會是什麼樣？猜不許沒問題，若是有了明確的答案，還往坑裏踩，就只能怪本身了。

固然，我並非全盤否認 UI 的技術，畢竟程序員拿工資是由於你能爲公司創造效益，因此該作的需求仍是要 100% 高質量的完成，也就是說該學的仍是要學。但若是是業餘時間的自我提升就另說了，個人建議是找一個 UI 組件認真學習下，把官方文檔讀一遍，本身寫個 Demo 理清楚知識脈絡。我並不期望這個組件能真的幫上什麼忙，但一個合格的程序員，也歷來不該該只作本身會作的事。合格的程序員應該要有觸類旁通，快速學習的能力，因此只要找一個組件熟悉一下整個學習流程就能夠了。瞭解一個 UIStackView 的來龍去脈以及如何兼容低版本是一個程序員好學的體現，但若是一個程序員只是每一年學習新的控件，又不能在項目中取得較大的收益，就只能說是學習方法有問題了。

從技術角度來講，蘋果的 UI 佈局是我見過最落後的方式，不管是前端的 HTML 仍是安卓的 XML 都要比 iOS 先進。這主要是由於把佈局信息耦合進二進制代碼很是不合理，並且必定程度上損失了動態化和解耦的能力。若是 iOS 的佈局方案未來有較大幅度的優化，我能夠斷言絕對不是 Autolayout 這樣的雞肋工具，或者 Storyboard 這種傻瓜工具。相比之下我更看好一種統一的，可以跨端佈局技術，好比 flexbox 規範。

其實作爲一個開發者，有一個學習的氛圍跟一個交流圈子特別重要這是一個個人iOS交流羣：681503716（驗證碼：寂靜），無論你是小白仍是大牛歡迎入駐，你們一塊兒交流學習
專業技能人才不足

這裏的專業技能指的是移動端這個大話題中裏比較垂直的知識領域，大概包含如下幾個方面：

圖像／視頻處理

隨着網絡基礎設施的普及，以及流量費用的大幅度下降，4G 基本上已經全面商用了，若是說移動端前五年是文字爲主，圖片視頻爲輔的話，在接下來的幾年中，用戶對高質量圖片和視頻的要求會日益增加。

因爲我對這個領域並不瞭解，因此可以推薦的並很少，在我印象中，OpenGL 這種跨平臺的引擎，計算機圖形學的知識，視頻編碼與協議都是能夠花時間研究的，如今有不少優秀的創業公司也急需這類人才。嚴格來講這些知識都不算移動互聯網方面的知識了，因此門檻較高，但門檻這東西是個雙刃劍。它會增長你的學習難度，但一旦你掌握了這門知識，門檻又會變成你我的價值的護城河。

我格外想要聲明的是，CoreAnimation 這類的東西若是不是工做中強制要用，通常就別碰了，就像沒人會傻到用 SpriteKit/SceneKit 去寫遊戲同樣，這種 API 密集型，又不能跨端的庫是沒有前途的，真正有價值的動畫必定是用一套統一的 DSL（領域特定語言）去實現，而後導出到各個平臺上，因此開發者必定要多在動畫的原理上下功夫，好比了解矩陣變換，線性代數這些，而不是把時間浪費在閱讀官方文檔上。

把事情搞定

在任什麼時候候，一個靠譜的，能把事情搞定的工程師必定是受到歡迎的。靠譜是一個很虛的概念，我以最近的觀察簡單的舉兩個例子。

當項目比較大了之後，隨着參與開發的人數愈來愈多，與技術無關的事情也會佔據愈來愈大的比重。好比協調和溝通，測試，後端的人力何時到位，某個 Bug 如何追查復現並定位，新版本的需求哪些能夠作，哪些緩一緩，能作的需求何時提測，何時灰度，何時正式發版？這些事情很瑣碎，須要很強的責任心，並且在求職的時候比較難體現出來（除非有知名的 app 背書），但相應的好處是績效通常會比較不錯，並且在領導心目中的印象會比較好。技術不敏感的同窗也能夠考慮這條路線。

雖然我一貫對 UI 開發很不屑，但事實是若是一個 iOS 工程師能把各個系統控件玩得很溜，並且有本身對控件的積累和封裝，再瞭解一些性能優化方面的知識，找到一個至關滿意的 iOS 職位也不會太難。若是你走的是這種傳統的 iOS 開發路線，不妨問問本身，每一年的 WWDC 都看完了沒，移動開發的各類工具是否都能熟練使用（好比 Reveal，Charles 等），能不能熟練到任何複雜的頁面，都能經過本身積累的組件在短期內實現？然而根據個人觀察，絕大多數應聘者的簡歷裏博客都不多，更別提 Github 上面有持續迭代的代碼了。這條路線的缺點是職業生涯天花板相對比較低，基本上到高級 iOS 工程師就爲止了。

逆向工程

研究逆向工程的做用不只僅是破解 app，在我看來更可能是學習底層的操做系統。在開發 app 的過程當中，咱們使用系統提供的庫，調用 API 就能夠實現需求，其中的過程徹底是黑盒。而逆向工程的目的就是要開盒子，利用一些工具從二進制層面入手，反過來推測應用開發者的代碼和邏輯。這其中會涉及到不少 C 語言，操做系統，編譯原理方面的東西，相對來講門檻很高。逆向工程對企業對價值也很大， 由於你們都不但願本身被競爭對手一眼看穿，又對競爭對手對祕密頗感興趣。

小結

以上是幾個我目前能想到的，能夠花時間研究的專業知識。這些知識大可能是自成體系的，沒有較長時間的積累，很難入門。這一點很是重要，由於不少知識看起來很是專業，門檻也很高，好比我下一節就會提到這樣的例子，但這些知識我並不鼓勵學習。區分的標準是，你學習的知識是一個知識點仍是一個體系，若是你學習的只是知識點， 那麼它只能是整個知識樹上的枝枝丫丫，邊邊角角；若是你學習的是知識體系，就具有了衍生知識點的能力，也就是我反覆強調的觸類旁通的能力。

上面舉的三個例子都是我認爲不容易遭到時間的淘汰，比較值得研究的話題。在這些領域上的投入能夠理解爲線性的，也就是一分耕耘，一分收穫。