我們都知道價格會受到供需的影響，如果某項技能在市場上緊缺，那麽掌握這門技能的工作者工資就會相對高一些，比如 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 語言，操作系統，編譯原理方面的東西，相對來說門檻很高。逆向工程對企業對價值也很大， 因為大家都不希望自己被競爭對手一眼看穿，又對競爭對手對秘密頗感興趣。

小結

以上是幾個我目前能想到的，可以花時間研究的專業知識。這些知識大多是自成體系的，沒有較長時間的積累，很難入門。這一點非常重要，因為很多知識看起來非常專業，門檻也很高，比如我下一節就會提到這樣的例子，但這些知識我並不鼓勵學習。區分的標準是，你學習的知識是一個知識點還是一個體系，如果你學習的只是知識點， 那麽它只能是整個知識樹上的枝枝丫丫，邊邊角角；如果你學習的是知識體系，就具備了衍生知識點的能力，也就是我反復強調的舉一反三的能力。

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

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