回顧
上一次參加 GMTC 還是 2017 年。那時的我還是剛剛參加工作並在試用期辭職的菜鳥。
2017 年的 GMTC 還是真正的 Global Mobile Tech Conference，2019 年的會議早已經把英文全稱去掉，改稱全球大前端技術大會。
2017 年的 GMTC 還在推廣 PWA、講 Vue、React、Angular2、Weex、RN 的實踐和探索，2019 年的 GMTC 小程序和鋪天蓋地的 Flutter。
2017 年的 GMTC 還在講工程化的問題，2019 年的 GMTC 已經向圍繞 node 的服務形式、客戶端、監控等周邊輻射。
2017 年面試還在問會不會 ES6，2019 年的 GMTC 的 Demo 都成了 TypeScript。
2017 年的我還聽不太懂全部的前端相關的內容，2019 年以爲自身沒有什麼顯著的成長，回顧才發現，舊的東西已經胸有成竹，新的東西也都有所應用。
兩年的時間，一些技術成了基礎設施沒了推廣的必要，一些技術已經被充分驗證了具備大規模使用的能力，一些技術被淘汰或水土不服，還有一些新的東西冒了出來，不知道在不久之後會給大前端帶來翻天覆地的變化還是被迅速淘汰。
結束對歷史的感慨，逐個場談談啓發，因爲我只聽了第二天的場，那麼我就講講第二天的，啓發可能來自各個奇怪的點。
B 站的視頻體驗進化之路
這場是 B 站帶來的分享的是名爲 "video first" 的優化，涉及了產品的改造、資源加載的改造、核心技術（視頻、彈幕）的選型切換。其實從標題也能看出來，很多優化措施是和視頻相關的，我並不是 100% 的受衆。
帶來啓發的點是產品改造部分，一般技術更加關注性能指標，產品更關注用戶行爲。
性能指標方面，其實就是縮短關鍵渲染路徑，一般會從減少首屏加載、優先加載首屏渲染資源方式入手。
但是從用戶行爲方面來講，用戶關注的“首屏”可能並不是真正完整的首屏，如 B 站的視頻播放部分纔是用戶更關注的點，我們可以稱之爲用戶關注的關鍵路徑。
那麼怎麼做更高效的優化呢，需要技術和產品從各自的角度緊密結合。從用戶行爲入手，將用戶關注的關鍵再次從首屏渲染路徑中剝離，做更高優先級的加載，如 B 站優先加載視頻播放這一關鍵路徑上的資源，其他資源主動避讓，在具備視頻播放能力時再加載。同時與產品協作從產品設計方面突出關注點，做產品設計方面的優化，如 B 站新版改造減少頁面元素，將播放器窗口直接顯示在第一屏。
那麼再發散一下，針對複雜、資源較多的頁面，能不能做成幾條功能的關鍵路徑出來，在不同的來源場景下優先加載不同關鍵路徑的資源呢？
0.3秒完成渲染！信息流內容頁“閃開”優化總結和思考
這場是 UC 信息流帶來的消除白屏的優化方式，名爲 NSR（Native Side Render）。
方向是數據預取、預渲染，實現爲在 Native 中做了一套機制，滿足頁面可以提前渲染，丟入內存緩存，在用戶需要時直出。
具體到 UC 信息流的場景，是依靠 Native 做 Render 的工作，Native 緩存固定的模板，在用戶瀏覽時提前加載對應數據，並在 Native 中執行模板和數據的混合，渲染出真實頁面，存入緩存，在用戶點擊時匹配攔截請求直出，完全避免掉瀏覽器渲染頁面前的請求工作。
由於 UC 信息流優化強烈依託於內核，所以他們取捨掉的一些非最優解其實還是用在其他優化場景中的，比如捨棄 HttpCache，使用依賴內核的內存緩存。
思路可以擴展到 Weex 這種寄生在Native 的環境，在瀏覽器端也可以依靠 Service Worker 做些嘗試。
Event Loop、Future與Isolate - 單線程模型下的Dart異步編程模式
講了 Dart 下的異步運行機制，Event Loop 和 JS 的 Event Loop 一樣（插一句，node 11 之前的Event Loop 和瀏覽器端還是不同的，在 node 之後已經趨於相同了），Future 可以類比 Promise，Isolate 可以類比 Worker。
其實對懂 js 的 Event Loop 的前端來說不會有太多收穫，但是看 Dart 中 Future 的示例代碼，確實糾正了我一個關於 promise then 經常忘的點，真是神奇的 then。
Using webpack to make Apps fast at Microsoft
webpack 的維護者 Sean Larkin 帶來的圍繞異步加載的優化。
使用 import() 語法，依託瀏覽器的 Coverage 分析首屏 Unused 代碼，做異步加載處理，從而減少首次有意義渲染（First Meaningful Paint）時間和可交互（Time to Interactive）時間。
我司基於 FMP、TTI 的性能監控也已經運行了一段時間了，也協助業務做過基於 Coverage 的加載優化，所以分享的內容聽起來比較親切。
對我帶來啓發的，第一點是受運行時控制的異步加載 (name) => import(`path/${name})，我感覺實現思路可能對我們自己的微服務架構的服務關聯關係有幫助。第二點是有人問到的加速構建的問題，我司業務中會遇到需要一次構建上百個入口的情況，這時構建會特別的慢，我們一般從提供減少構建入口的能力這一角度做優化，Sean 提到了一個插件 cpuprofile-webpack-plugin 不知道會不會對我們分析構建耗時有幫助。
從一到無窮大：前端工程化中的實踐與臆測
阿里巴巴 Just 工程體系，由前端開發的演變對應到工程化的對應演變，從穩定與高效（版本控制，代碼檢查），標準與定製（研發流程的制定，流程節點的定製），通用與易用（開箱即用、分層增強）角度分享了工程化實踐中對前端開發的賦能、提供良好的前端開發體驗。
沒有特別的啓發，但鏈路很全，在做提供相關服務能力的時候可以做參考。
工作10年，我在前端專業成長路上的探索（一）
講的還是比較積極風趣的，呼籲大家要節約時間高效學習。
快手遊戲直播 Web 站的工程進化之路
如題，從第一階段-開發上線（技術選型與初級架構設計），第二階段-持續交付（提高擴展性、降低業務開發思考成本），第三階段-開發質量（開發、構建、部署流程），第四階段-精細化運營（數據監控，包括錯誤、構建、關鍵業務指標）進行了分享。
主線和《從一到無窮大：前端工程化中的實踐與臆測》比較類似，沒有特別啓發的地方，在做提供相關服務能力的時候可以做參考。
同時不得不感慨一句，快手的技術發展、應用真的很迅猛。
最後
非常榮幸能加入現在的團隊。