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

標籤：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 語言，作業系統，編譯原理方面的東西，相對來說門檻很高。逆向工程對企業對價值也很大， 因為大家都不希望自己被競爭者一眼看穿，又對競爭者對秘密頗感興趣。

小結

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

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

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