小前端眼裏的大前端：GMTC 2018 參會小結

剛剛在北京落下帷幕的 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，商業化氣息明顯更濃了。不過無論商業氣息重不重，但願你們都能悶聲發大財，這纔是墜吼的 :-)