剛剛在北京落下帷幕的 GMTC 2018 應該算是近期國內前端圈子裡最高規格（門票最貴）的活動之一了。那麼這兩天的分享有什麼值得一提的地方呢？下面是一份小小的總結。
行程流水賬
我們週三晚上從廈門出發飛抵北京，在鳥巢邊上的會場裡參與了週四和週五為期兩天的密集技術分享。除了第一天早上所有參會者都在同一個會場以外，各個細分主題下的內容都是並行地在不同地分會場內講解的。因此，一個人顯然無法聽完所有的主題的，我們也對想聽的主題做了一些取捨。
我們此行最後選擇的主題還是偏向 Web 前端，覆蓋了混合應用、圖形學應用、Node 和音視訊應用等主題。雖然我們來了兩個同學，最後參與的主題實際上也只覆蓋了全部主題的 70% 左右。下面我們嘗試從這些主題中抽取一些亮點和大家分享 XD
新技術動向
實際上 GMTC 本身的名稱縮寫和「前端」並沒有直接的關係，而是一個面向移動端技術的會議。但在現在「大前端」的浪潮下，這次會議的議題已經在相當大程度上偏向了 Web 前端 / 全棧開發者。我們在現場感受到反響較好的一些分享主題，其內容取向也能印證這一點：
混合應用開發
雖然大會中也有不少 RN / HTML5 混合應用的高質量分享，但要說這個話題裡現場氣氛最熱烈的分享主題，應該非 Flutter 莫屬了。與其它分享中常見的「內部框架定製」和「業務系統演進」主題不同，Google Flutter 團隊的於瀟老師分享了他們所實現的這樣一套能帶來全新開發體驗的開源框架。這個分享顯然是經過精心準備的，有著良好的節奏和精美的互動 Demo，也收穫了現場的一波波掌聲~
Flutter 所對標的應當是 React Native 和 Weex 這樣的混合開發方案，但不同的是，Flutter 不僅採用了 Dart 這樣來自 Google 的程式語言，底層還從 RN 這樣橋接原生 UI 元件的方案換成了基於 OpenGL / Vulkan 這樣的圖形庫，保證了跨平臺的穩定性。現場的演示中帶來的驚豔之處有這麼幾個：
- Dart 語言機制提升了開發體驗。如除錯期 JIT + 執行期 AOT 的效能優化、Tree Shaking 的包體積優化等。並且在 Demo 中，基於 Dart 的 Hot Reload 能夠保留錯誤狀態，而非像 Web 與 RN 那樣在出錯時只能重新整理重置。對難以重入的頁面狀態，這能極大地提升除錯效率。
- Flutter 不依賴原生元件，可以在命令列中方便地執行 Headless 的測試。
- Flutter 使用 Dart 重寫了從底層的繪圖、動畫、手勢到頂層 UI 元件的一整套技術棧，並且實現了充分的元件化。這樣一來許多需要強控制力的效果就能直接在 Dart 生態下實現，而非 RN 那樣動輒需要依賴原生庫。
至於遷移到 Flutter 的成本，主要的顧慮集中在 Dart 的學習曲線和與 Native 專案的整合上。這兩者實際上在當天下午閒魚的 Flutter 實踐分享中都有提到。對於前者，我們得到的回覆是 Dart 實際上很接近 JS 和 Java，它的元件也很接近 React，因此學習曲線並不會十分陡峭。而對於 Native 專案整合，從閒魚團隊的分享上確實看到了還有不少現階段暫時只能 workaround 的坑，但從 Flutter 團隊的支援力度下來看，應當是可以期待持續的改進優化的。
下面這張圖裡你能看到閒魚團隊分享 Flutter 實踐時，在第一排吃瓜慶祝的兩位 Flutter 團隊老闆，自己親手做的東西得到了廣泛的關注，想必很高興吧 XD
中後臺與工程化
既然是「大前端」，那麼 Node 全棧及其對應的 NPM 生態就是個不可或缺的話題。我們也在業務中使用了 Node，因此對這個話題我們還是比較關注的。
不過要評價起這次 GMTC 上 Node 與工程化相關的分享的話，個人理解應該更接近「穩定」吧。這次大會上這方面的多數分享，並非像 Flutter 這樣「從 0 到 1」的新工具釋出，而是主要集中在「從 100 到 1000」這樣基於前端技術保證業務演進的總結上。當然了在純粹的工具方面，這次的議題裡也不是一片空白。比如來自 Apollo 團隊的老闆就詳細介紹了 GraphQL 和 Apollo 全家桶。對於 REST 缺乏可擴充套件性的問題，GraphQL 的按需獲取機制更加易用；對於巢狀的複雜資料，我們無需多次調⽤即可按需獲取，從而減少⽹絡開銷；在快取和預讀取等通用的優化層面，GraphQL 層也可以實現不少對業務透明的優化。
雖然 GraphQL 這樣下一代 API Gateway 的方案呼聲一直很大，但不可否認的是它在國內還沒有達到 Vue 這樣「飛入尋常百姓家」的普及程度。在技術選型時，遷移到 GraphQL 的成本和收益始終是值得仔細權衡的。在這方面 Apollo 平臺下以 apollo-client 為代表的一系列 GraphQL 工具是很值得推薦的：如果我們能夠在不對後端服務做出侵入性改動的前提下，將 Redux / Saga 或 Vuex / MobX 的一系列膠水程式碼用簡潔的宣告式 GraphQL Query 取代，是不是能夠解決一部分資料對接的痛點呢？在其他國內團隊的分享中，也提到了將後端繁多的介面服務統一為「對應用透明的 API 層」的探索，比如阿里的 Node 團隊就提出了 BFF(Backend For Frontend) 的概念，讓微服務架構有了更多的發揮空間。藉助於 BFF 的輕便性，我們甚至可以為每個業務開發一個 API Gateway。期待他們更多的成果呀。
在一些中後臺的系統的積累和工程化上，這次大會上還是看到了不少的實踐分享。幾個大廠對業務的監控、異常排查、報警、問題定位、日誌等系統已經逐一落地，前後端分離與 SSR 的開發模式也已經相當成熟。可能正是因為成熟度已經較高的原因，這個領域的分享較少涉及到具體的程式碼層面，而是一些「道」的高層次總結。當然了，也有些主題是非常接近於商業廣告的，這裡就不細說啦。最後放張 Twitter 的工程化分享現場圖，供各位瞭解一下「道」的氛圍：
效能優化與監控
這個議題下基本上就是大廠同學們秀肌肉的地方了：對於各種國民級應用的核心業務，它們背後的持續打磨優化和大量的支撐系統，是沒有處理過這個量級問題的同學所難以想象的。我們可能常常認為，只要應用了常見在面試題中出現的那幾種「前端效能優化方式」，就已經做到了效能優化。但在這些分享中，我們對於自以為的「已優化過」有了重新的審視，也瞭解了更多考慮效能問題的維度。
以愛奇藝團隊的分享為例，一般對於客戶端而言，除了崩潰率之外開發同學最關心的可能就是流暢度和首屏啟動速度，分享中的實踐在此拋棄了我們慣用的打點記時方式，轉而以錄屏的方式讓測試更準確也更接近實際。再比如電量的消耗一般不是應用開發者所操心的，但真實世界中，流暢度往往直接和電量的消耗負相關。分享中引入的 PowerMonitor 不僅能夠檢測能耗，更能夠據此量化地判斷出優化前後對流暢程度的提升。對於我們熟悉的 WebView，它在應用中幾乎始終是慢的代名詞。這裡我們在分享中看到了通過「離線化 + 非同步化 + 快取化」的一套方案，大大提升了 WebView 初始化的速度，這方面分享團隊所開源的 liteapp 專案值得關注。我們原本以為時下大熱的 AI 潮流和傳統的應用開發沒有特別大的關係，但出乎意料的是分享中我們看到了 AI 技術在自動提升視訊清晰度上的應用，不得不佩服技術團隊跟進落地新技術的實力。最後在安卓機型碎片化的問題上，我們也確認了「沒有捷徑可走」的結論，目前最有效的方式仍然是採購各種機型，在各個機型下進行完備的測試。
圖形學與音視訊
拜 winter 老師的氣場所賜，這次大會中的圖形學話題獲得了不少額外的關注：
雖然是個細到了數學公式和程式碼細節的分享，但分享過程比想象的要有趣得多，不愧是計算機之子啊 XD。事實上我們現在自研的編輯器基礎庫中也已經遇到了一些 DOM 和 Canvas 的表達力瓶頸，而這些瓶頸應當是可以通過更加底層的 Shader 開發來克服的。在一定層面上，我們可以認為這些基礎從來就不會過時。不過 winter 老師前面非常細粒度的分享最後似乎還是為了介紹 GCanvas 和 G3D這兩個輪子（在去年的 D2 上我其實已經聽過了一遍安利啦），要是有什麼新進展的訊息就更好啦。
相比之下，和圖形學同樣處於較為底層的音視訊開發領域，受到的關注就要少那麼一些。印象中音視訊分會場的主持人還有「在座各位想必都身價不菲」這麼一說。這個領域確實有些曲高和寡，如騰訊微視的分享就提到了多 pass 渲染、雙邊濾波等圖形學經典技術。這部分內容已經屬於典型的客戶端開發範疇了，短期內前端同學對音視訊的掌控力可能還是會限制在瀏覽器環境的這一套已有體系上，難以有較大的突破。
好訊息是，大會中已經有了國內的 WASM 分享，基於 WASM 的一些視訊特效應用在 Web 前端也已經有了實驗性的落地。這部分內容由於我們之前也摸過，因此也和主講的老師做了一些交流：現階段 WASM 確實有除錯和構建上的難度和瓶頸，但好在從巨集觀趨勢上來看自去年下半年起社群熱度已經有了顯著增加，也希望它能夠早日落地到我們的業務中去創造價值吧~
總結與展望
最後我們列出一些不分先後的參會小心得與評價吧：
- 從 2015 年的深 JS 大會到今年的 GMTC，能明顯感覺到 JS 端的發力，這在 Node.js 上很有體現：從最開始介紹 koa 這樣的 web 服務框架，到現在阿里的 Pandora.js 這樣的一個可管理、可度量、可追蹤的 Node.js 應用管理器，我們能感受到的是一個生態的進化。在 2015 年 Node.js 剛剛起步，大家都在熱衷於實現一個後端的 "jQuery" 來 hold 住基本的業務需求。而到了現在，大家所追求的是要構建一個生態，畢竟後端服務需要有完善的一套基礎設施才能長久穩定地執行。當然了由於 Node.js 本身的限制，前端同學較難深入到更低的 DB 乃至 OS 等層面去打磨生態，也可以說前端同學在後端領域確實還不夠深入。但這不代表我們沒有在思考，沒有想如何做到更好。
- 國內技術分享者的節奏把控普遍還有不少的優化空間，很多分享還是很容易使得現場氣氛沉悶下來，也確實會有些「新瓶裝舊酒」的內容有些老調重彈的感覺。國外講師普遍明顯要更老司機一些（可能與國內技術崗日常交流偏少有關係）。
- 國內對前端工程的關注點仍然主要放在對業務應用的支撐上。對於比較「低層面」的程式語言、VM、遊戲引擎等的基礎，除了商業產品外，開源出來的東西仍然還不是特別豐富。
- 對於現代規模不斷增長的專案，想要做好已經不是單槍匹馬或是有一技之長就能夠 hold 得住的了。對更長的業務鏈路，我們需要一個能夠統籌全域性且快速組合各類能力的組織，才能控制得住鏈路上各個節點的複雜度。
- 除了基本的工具選型外，Code Review / Case Study 等技術團隊的制度也能很大程度地影響團隊的工程質量甚至氛圍，這方面國內還有很長的路要走。
- 不論客戶端與 Web 前端關係如何發展，它們背後的計算機基礎都是相對穩定的。伴隨著我們對效能的「壓榨」，圖形學一類的基礎可能會更加重要。
- GMTC 相比 D2，商業化氣息明顯更濃了。不過不管商業氣息重不重，希望大家都能悶聲發大財，這才是墜吼的 :-)