如果從 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 規范。
專業技能人才不足
這裡的專業技能指的是移動端這個大話題中裡比較垂直的知識領域，大概包含以下幾個方面：
圖像／視頻處理
隨著網絡基礎設施的普及，以及流量費用的大幅度降低，4G 基本上已經全面商用瞭，如果說移動端前五年是文字為主，圖片視頻為輔的話，在接下來的幾年中，用戶對高質量圖片和視頻的要求會日益增長。
由於我對這個領域並不瞭解，所以能夠推薦的並不多，在我印象中，OpenGL 這種跨平臺的引擎，計算機圖形學的知識，視頻編碼與協議都是可以花時間研究的，現在有很多優秀的創業公司也急需這類人才。嚴格來說這些知識都不算移動互聯網方面的知識瞭，所以門檻較高，但門檻這東西是個雙刃劍。它會增加你的學習難度，但一旦你掌握瞭這門知識，門檻又會變成你個人價值的護城河。
我格外想要聲明的是，CoreAnimation 這類的東西如果不是工作中強制要用，一般就別碰瞭，就像沒人會傻到用 SpriteKit/SceneKit 去寫遊戲一樣，這種 API 密集型，又不能跨端的庫是沒有前途的，真正有價值的動畫一定是用一套統一的 DSL（領域特定語言）去實現，然後導出到各個平臺上，所以開發者一定要多在動畫的原理上下功夫，比如瞭解矩陣變換，線性代數這些，而不是把時間浪費在閱讀官方文檔上。
把事情搞定
在任何時候，一個靠譜的，能把事情搞定的工程師一定是受到歡迎的。靠譜是一個很虛的概念，我以最近的觀察簡單的舉兩個例子。
當項目比較大瞭以後，隨著參與開發的人數越來越多，與技術無關的事情也會占據越來越大的比重。比如協調和溝通，測試，後端的人力什麼時候到位，某個 Bug 如何追查復現並定位，新版本的需求哪些可以做，哪些緩一緩，能做的需求什麼時候提測，什麼時候灰度，什麼時候正式發版？這些事情很瑣碎，需要很強的責任心，而且在求職的時候比較難體現出來（除非有知名的 app 背書），但相應的好處是績效一般會比較不錯，而且在領導心目中的印象會比較好。技術不敏感的同學也可以考慮這條路線。
雖然我一向對 UI 開發很不屑，但事實是如果一個 iOS 工程師能把各個系統控件玩得很溜，而且有自己對控件的積累和封裝，再瞭解一些性能優化方面的知識，找到一個相當滿意的 iOS 職位也不會太難。如果你走的是這種傳統的 iOS 開發路線，不妨問問自己，每年的 WWDC 都看完瞭沒，移動開發的各種工具是否都能熟練使用（比如 Reveal，Charles 等），能不能熟練到任何復雜的頁面，都能通過自己積累的組件在短時間內實現？然而根據我的觀察，絕大多數應聘者的簡歷裡博客都很少，更別提 Github 上面有持續迭代的代碼瞭。這條路線的缺點是職業生涯天花板相對比較低，基本上到高級 iOS 工程師就為止瞭。
逆向工程
研究逆向工程的作用不僅僅是破解 app，在我看來更多是學習底層的操作系統。在開發 app 的過程中，我們使用系統提供的庫，調用 API 就可以實現需求，其中的過程完全是黑盒。而逆向工程的目的就是要開盒子，利用一些工具從二進制層面入手，反過來推測應用開發者的代碼和邏輯。這其中會涉及到很多 C 語言，操作系統，編譯原理方面的東西，相對來說門檻很高。逆向工程對企業對價值也很大， 因為大傢都不希望自己被競爭對手一眼看穿，又對競爭對手對秘密頗感興趣。
小結
以上是幾個我目前能想到的，可以花時間研究的專業知識。這些知識大多是自成體系的，沒有較長時間的積累，很難入門。這一點非常重要，因為很多知識看起來非常專業，門檻也很高，比如我下一節就會提到這樣的例子，但這些知識我並不鼓勵學習。區分的標準是，你學習的知識是一個知識點還是一個體系，如果你學習的隻是知識點， 那麼它隻能是整個知識樹上的枝枝丫丫，邊邊角角；如果你學習的是知識體系，就具備瞭衍生知識點的能力，也就是我反復強調的舉一反三的能力。
上面舉的三個例子都是我認為不容易遭到時間的淘汰，比較值得研究的話題。在這些領域上的投入可以理解為線性的，也就是一分耕耘，一分收獲。
全棧人才緊缺
這裡的全棧沒有明確的定義，並非前後端通吃才算是全棧。在我的理解中，隻要是跨知識點的融合，都算是全棧，因為跨知識點的融合往往會產生 1 + 1 > 2 的效果。往小瞭說，全棧可以減少大量浪費在溝通上的時間。往大瞭說，一個人瞭解的領域越多，他就越能把這些領域融合在一起，既能站在更高的角度思考問題，也能作為團隊的領導者和融合劑。這也就意味著，掌握全棧知識對個人價值的影響是指數形勢的，你瞭解的越多，價值就會越快的提高，職業天花板也會越高。
別研究得太深
我經常關註微信的技術博客，比如客戶端通過修改 SQlite 代碼達到瞭更好的性能，以及修復瞭一個非常詭異的內核崩潰問題，這體現瞭微信強大的技術能力，能夠參與其中的工程師也一定收獲頗大。BAT 這種級別的大廠其實有很多非常底層的黑科技，也會在各種大會和文章中對
..... 額 ..... 沒油瞭 收費瞭
摘自 -- 張星宇
百度 iOS 工程師，正向全棧的方向努力。熱愛分享，喜歡研究問題的本質，討厭一切不說人話的描述。
更新 2018-02-06
別研究得太深
我經常關註微信的技術博客，比如客戶端通過修改 SQlite 代碼達到瞭更好的性能，以及修復瞭一個非常詭異的內核崩潰問題，這體現瞭微信強大的技術能力，能夠參與其中的工程師也一定收獲頗大。BAT 這種級別的大廠其實有很多非常底層的黑科技，也會在各種大會和文章中對外介紹，然而我給大多數讀者的建議是，當個新聞看看就可以瞭。人傢研究得這麼深是因為 KPI 指標有壓力，你作為一個外人，如果也研究這麼深隻能說明你傻。
知識是有價值的，不僅價值各不相同，還受到規模的影響，作為微信來說，修復一個發生率極低的 crash，在過億用戶的基數下，很可能會減少幾百萬次崩潰，帶來巨大的收益。然而這個收益，放在你的公司裡，很可能就是 0。因此在選擇自我提高方向時，一定要關註技術本身的價值，有些技術自身並不值錢，但經過公司規模的加成，就產生瞭相當大的價值，但這並不意味著你需要花時間學習它。尤其是某些無法形成體系，僅僅是獨立知識點的技術，公司業務有需要，那為瞭工資得硬著頭皮上，但如果自由時間裡面還要花時間去學，就太浪費瞭。
我拒絕花時間瞭解這類技術的另一個原因在於，很多技術是與業務綁定的，有瞭核心知識，在業務需求的推動下，很容易就會誕生一個框架。比如應用組件化，很多公司都有自己的組件化庫，其實實現原理也就是兩大類，但發表到博客裡面以後，就會有非常多的業務背景幹擾讀者的認知，如果讀者追著這類文章看，是非常難從框架中剝離業務的幹擾，直接挖掘基本原理的。因此大公司搞出來的某些框架，真的沒有那麼神秘，早期都是一個簡陋的基礎框架，當面對業務業務需求時，運用一些合理的編程思想，逐步迭代，最後發佈瞭一個完善的版本，大可不必看得暈頭轉向以後妄自菲薄。
在之前面試的過程中，我也註意到很多應聘者其實對技術很感興趣，經常刷微博上的文章，瞭解的也很多。但大多數情況下隻知其然，不知其所以然。這是因為這些技術偏離瞭你的應用場景。以前我總為微博上的好技術無法在項目中落地感到糾結，後來我突然就明白瞭，這個思路就是錯的，我應該挖掘公司項目的痛點，去微博，Google 等平臺上的文章中尋找解決方案。所以我反對面向微博學習，應該要學一些更通用的技術，把技術與自己的項目結合起來，爭取能在項目中落地，這比看十篇似懂非懂的技術文章還管用。
大公司所謂的基礎知識
上一節解釋瞭為什麼不要研究單獨的幾個底層知識點，除瞭這種知識，以及逆向工程這種自成體系的，求職者隻要具備紮實的基礎，牢牢掌握一些基礎知識就可以瞭。很多人都會覺得大公司對底層的基礎知識考察很嚴格，基礎知識不表示底層，也不一定就很簡單，它們通常是那些被框架做瞭一層封裝，以至於如果不用心思考，很可能就會忽略的知識，但不瞭解這些知識會對你的思考產生較大的影響，也很容易栽進某個坑裡。
除非是變態公司以偏題怪題刁難人為樂，或者無能面試官隻會問自己懂的東西以外，正常的大公司面試都會考察一些比較基礎的問題，如果你還是覺得題目太底層，隻能說明自己看問題的角度還不夠深刻。
大公司著重考察基礎知識，在我看來有兩大原因：首先，在比較大型的項目中，業務邏輯非常復雜，所以很少有人有精力去大量的檢查並提高你的代碼質量，這就要求工程師具備相當紮實的代碼功底，無論是代碼風格還是語言的掌握都不能有太多問題。這樣 Code Review 的時候才能把精力放在業務檢查上，代碼風格一筆帶過，偶爾提醒一下就可以瞭。
另一方面，基礎知識決定一個人思考問題的深度和交流問題的角度。一個不懂計算機背景知識的程序員，看問題的方式經常是錯誤的，錯誤的思考方式也就決定瞭他很難走到正確的道路上，比如我的一個外行朋友曾經接手瞭一個用 C++ 實現的 GUI，他的第一個問題是 " 如何在 C++ 中把字符串加粗 "，讀者大可不必感到荒謬，因為很多人思考問題的方式也不見得高明，在高水平，有經驗的程序員看來，也許同樣是不可理喻的。大公司復雜的業務邏輯同樣也意味著很少有人會耐心的給你講解每一個名詞，比如哈希表，並發，並行，編譯，鏈接等等名詞，如果你聽不懂或者理解不正確，往往意味著交流上會存在一些障礙。
因此我的建議是：數據結構，操作系統，計算機網絡中的基礎知識一定要紮實，怎麼紮實都不為過，因為它決定瞭你看問題時候的高度，深度和思路。
讓腳本取代 GUI
腳本語言非常重要，絕對是提升工作效率的神器，我強烈建議每個客戶端工程師都應該瞭解一些 Shell 腳本並且掌握 Python，Ruby 和 JS 中至少一門語言。
理論上來說沒有什麼是腳本語言做得到，Java 做不到的，但腳本語言最大的特點就是快，快到極點的那種快。對於一些極度簡單的小需求，比如統計一個文件中某一列數字的平均數，我敢保證在我得出結果之前你肯定還來不及打開 Java 編輯器。
腳本語言的另一個特點是高度的自動化，隻要 Unix 和 Linux 系統一天不死，shell 腳本就會永遠存活，你學習的知識就永遠不會過期，比如 awk 和 sed 這樣的神器，年齡比我大得多，至今還非常實用，未來的 20 年也絲毫看不出淘汰的跡象。試問一下，有什麼知識能比一個幾十年不會過期，而且每天都能用上的知識更值得學習呢？由於 Shell 是距離操作系統最近的腳本，瞭解瞭它以後，很多復雜的操作都可以被自動化。比如想找到項目中無用的圖片，也就是一行命令的事。
考慮到腳本語言極高的開發效率，很多對性能不敏感的框架都會選擇用腳本語言來實現，比如 Node，Flask，Rails，mitmproxy 等等。作為一個大前端工程師，不能總是依賴後端工程師，否則沒瞭後端就隻能搞單機模式瞭。因此瞭解腳本語言還有助於我們快速上手後端框架，這絕對是應聘時的加分項。
當然，很多人也會抱怨，我們是 iOS 工程師，平時的工作也接觸不到腳本語言，該如何學習並投入使用呢。我的建議有三個：
整理自己的痛點， 並嘗試著用過腳本去解決，這對學習 Shell 有奇效
整理公司項目開發中的痛點，嘗試著用腳本去解決，適合練習 Python，Ruby 和 JS
拋棄 GUI
GUI 誕生的目的是為瞭更好的顯示信息，而不是成為技術殘疾者的拐杖。舉一個簡單的例子，我發現很多人都裝瞭很多編程效率方面的工具，比如 gitx，sourcetree，tower 之類的 git 工具，還有什麼快速打開模擬器目錄，Derived Data 目錄的小工具，我覺得這實在是太愚蠢瞭。放著大好的學習 Git 和 shell 的機會不要，把時間浪費在瞭解一個軟件的 GUI 上，我覺得是完全不能接受的。尤其是對於 git 來說，我建議多問問自己，學會的是 git 還是 sourcetree 的按鈕，將來換一個 GUI 工具，畢生功力還剩幾成？至於某些小工具，這種絕佳的練手機會，怎麼能拱手相讓給別的軟件呢，尤其是腳本可以自動化，軟件就幾乎不可能瞭。
學點前後端
我並不認為這一波移動互聯網的寒潮是對移動端的否定，短期來看還沒有設備能夠取代手機。在我看來，它其實是 O2O 這種商業模式被證偽後，市場的自然反應。企業都認識到，移動端轉型不是商業模式的救命稻草，所以為瞭節約成本，很多時候都是 Web 先行。這並不意味著移動端的需求沒有瞭，隻是現階段存在著開發成本和收益之間的矛盾。目前移動端對傳統行業的滲透還不夠多，大一些的傳統企業找外包，小一些的幹脆就沒有能力做瞭。
一方面，我認為隨著框架，工具的日益完善，大前端開發的成本會持續下降，逼近業務復雜度本身。如果對前後端都有一定的瞭解，即使是做外包，也能以較低的人力和時間成本完成需求，比如熟悉 React Native 的開發者一個人就抵得上 iOS 和 安卓程序員各一人／畢竟大多數人工作還是為瞭錢，如果有穩定且較高的外包收入，工作也不是不能放棄。
另一方面，在與公司高 T 的聊天中，我瞭解到即使是大公司，對全棧也是有需求的。不是公司裡的每個項目都是淘寶，微信和百度搜索，畢竟多一個人就多一份溝通成本，能夠獨立把前後端打通，負責整個項目的人，無論在哪裡都會被搶著要。
然而這一切的前提都是有紮實的基礎知識，比如對於大前端的開發來說，最重要的就是 HTTP 協議瞭，全棧不是全幹，絕非讀一篇 xxx 實戰指南然後寫幾行 Demo 就算是入門的。因此一定要對框架背後的原理有深刻的瞭解，並且積累一定的實戰經驗才行。程序員應該是框架的主人，因為要節省時間，避免模板代碼才選擇框架，萬萬不能成為框架的奴隸，踩著框架的高跟鞋才能在需求的海洋中蹣跚兩步，離開瞭 API 就不會寫代碼瞭。如果公司有業務需要，提供轉崗的機會，而你又恰好有一定的基礎和興趣，不妨勇敢的嘗試一下。否則就隻能自己創造需求，比如找一個痛點並加以解決瞭。
總結
囉囉嗦嗦說瞭很多，其實總結下來沒幾點：
學習一個技術之前不妨先思考一下它在整個互聯網體系中目前的位置，有什麼樣的未來，會對個人價值有多大的提高
數據結構，操作系統，編譯原理，計算機網絡這些基礎知識不能丟，它決定瞭你看問題時候的高度，深度和思路
未來需要特定技術領域裡的專才，更需要全棧，歸根結底是需要最大化自己的價值。我個人的建議是掌握好腳本語言提高效率，打通前後端，這樣無論在外包，獨角獸創業公司還是大公司，都能獨當一面
學習新技術時要避免好高騖遠或者盲目迷信大廠，轉發或艾特印象筆記提高不瞭自己，要結合實際場景，最重要的是要能落地！
