摘要：回顧上一次參加還是年。年的還是真正的，年的會議早已經(jīng)把英文全稱去掉，改稱全球大前端技術(shù)大會。同時(shí)與產(chǎn)品協(xié)作從產(chǎn)品設(shè)計(jì)方面突出關(guān)注點(diǎn)，做產(chǎn)品設(shè)計(jì)方面的優(yōu)化，如站新版改造減少頁面元素，將播放器窗口直接顯示在第一屏。

上一次參加 GMTC 還是 2017 年。那時(shí)的我還是剛剛參加工作并在試用期辭職的菜鳥。

2017 年的 GMTC 還是真正的 Global Mobile Tech Conference，2019 年的會議早已經(jīng)把英文全稱去掉，改稱全球大前端技術(shù)大會。
2017 年的 GMTC 還在推廣 PWA、講 Vue、React、Angular2、Weex、RN 的實(shí)踐和探索，2019 年的 GMTC 小程序和鋪天蓋地的 Flutter。
2017 年的 GMTC 還在講工程化的問題，2019 年的 GMTC 已經(jīng)向圍繞 node 的服務(wù)形式、客戶端、監(jiān)控等周邊輻射。
2017 年面試還在問會不會 ES6，2019 年的 GMTC 的 Demo 都成了 TypeScript。
2017 年的我還聽不太懂全部的前端相關(guān)的內(nèi)容，2019 年以為自身沒有什么顯著的成長，回顧才發(fā)現(xiàn)，舊的東西已經(jīng)胸有成竹，新的東西也都有所應(yīng)用。

兩年的時(shí)間，一些技術(shù)成了基礎(chǔ)設(shè)施沒了推廣的必要，一些技術(shù)已經(jīng)被充分驗(yàn)證了具備大規(guī)模使用的能力，一些技術(shù)被淘汰或水土不服，還有一些新的東西冒了出來，不知道在不久之后會給大前端帶來翻天覆地的變化還是被迅速淘汰。

結(jié)束對歷史的感慨，逐個(gè)場談?wù)剢l(fā)，因?yàn)槲抑宦犃说诙斓膱觯敲次揖椭v講第二天的，啟發(fā)可能來自各個(gè)奇怪的點(diǎn)。

這場是 B 站帶來的分享的是名為 "video first" 的優(yōu)化，涉及了產(chǎn)品的改造、資源加載的改造、核心技術(shù)（視頻、彈幕）的選型切換。其實(shí)從標(biāo)題也能看出來，很多優(yōu)化措施是和視頻相關(guān)的，我并不是 100% 的受眾。

帶來啟發(fā)的點(diǎn)是產(chǎn)品改造部分，一般技術(shù)更加關(guān)注性能指標(biāo)，產(chǎn)品更關(guān)注用戶行為。
性能指標(biāo)方面，其實(shí)就是縮短關(guān)鍵渲染路徑，一般會從減少首屏加載、優(yōu)先加載首屏渲染資源方式入手。
但是從用戶行為方面來講，用戶關(guān)注的“首屏”可能并不是真正完整的首屏，如 B 站的視頻播放部分才是用戶更關(guān)注的點(diǎn)，我們可以稱之為用戶關(guān)注的關(guān)鍵路徑。
那么怎么做更高效的優(yōu)化呢，需要技術(shù)和產(chǎn)品從各自的角度緊密結(jié)合。從用戶行為入手，將用戶關(guān)注的關(guān)鍵再次從首屏渲染路徑中剝離，做更高優(yōu)先級的加載，如 B 站優(yōu)先加載視頻播放這一關(guān)鍵路徑上的資源，其他資源主動避讓，在具備視頻播放能力時(shí)再加載。同時(shí)與產(chǎn)品協(xié)作從產(chǎn)品設(shè)計(jì)方面突出關(guān)注點(diǎn)，做產(chǎn)品設(shè)計(jì)方面的優(yōu)化，如 B 站新版改造減少頁面元素，將播放器窗口直接顯示在第一屏。

那么再發(fā)散一下，針對復(fù)雜、資源較多的頁面，能不能做成幾條功能的關(guān)鍵路徑出來，在不同的來源場景下優(yōu)先加載不同關(guān)鍵路徑的資源呢？

這場是 UC 信息流帶來的消除白屏的優(yōu)化方式，名為 NSR（Native Side Render）。

方向是數(shù)據(jù)預(yù)取、預(yù)渲染，實(shí)現(xiàn)為在 Native 中做了一套機(jī)制，滿足頁面可以提前渲染，丟入內(nèi)存緩存，在用戶需要時(shí)直出。
具體到 UC 信息流的場景，是依靠 Native 做 Render 的工作，Native 緩存固定的模板，在用戶瀏覽時(shí)提前加載對應(yīng)數(shù)據(jù)，并在 Native 中執(zhí)行模板和數(shù)據(jù)的混合，渲染出真實(shí)頁面，存入緩存，在用戶點(diǎn)擊時(shí)匹配攔截請求直出，完全避免掉瀏覽器渲染頁面前的請求工作。
由于 UC 信息流優(yōu)化強(qiáng)烈依托于內(nèi)核，所以他們?nèi)∩岬舻囊恍┓亲顑?yōu)解其實(shí)還是用在其他優(yōu)化場景中的，比如舍棄 HttpCache，使用依賴內(nèi)核的內(nèi)存緩存。

思路可以擴(kuò)展到 Weex 這種寄生在Native 的環(huán)境，在瀏覽器端也可以依靠 Service Worker 做些嘗試。

講了 Dart 下的異步運(yùn)行機(jī)制，Event Loop 和 JS 的 Event Loop 一樣（插一句，node 11 之前的Event Loop 和瀏覽器端還是不同的，在 node 之后已經(jīng)趨于相同了），F(xiàn)uture 可以類比 Promise，Isolate 可以類比 Worker。

其實(shí)對懂 js 的 Event Loop 的前端來說不會有太多收獲，但是看 Dart 中 Future 的示例代碼，確實(shí)糾正了我一個(gè)關(guān)于 promise then 經(jīng)常忘的點(diǎn)，真是神奇的 then。

webpack 的維護(hù)者 Sean Larkin 帶來的圍繞異步加載的優(yōu)化。

使用 import() 語法，依托瀏覽器的 Coverage 分析首屏 Unused 代碼，做異步加載處理，從而減少首次有意義渲染（First Meaningful Paint）時(shí)間和可交互（Time to Interactive）時(shí)間。

我司基于 FMP、TTI 的性能監(jiān)控也已經(jīng)運(yùn)行了一段時(shí)間了，也協(xié)助業(yè)務(wù)做過基于 Coverage 的加載優(yōu)化，所以分享的內(nèi)容聽起來比較親切。

對我?guī)韱l(fā)的，第一點(diǎn)是受運(yùn)行時(shí)控制的異步加載 (name) => import(`path/${name})，我感覺實(shí)現(xiàn)思路可能對我們自己的微服務(wù)架構(gòu)的服務(wù)關(guān)聯(lián)關(guān)系有幫助。第二點(diǎn)是有人問到的加速構(gòu)建的問題，我司業(yè)務(wù)中會遇到需要一次構(gòu)建上百個(gè)入口的情況，這時(shí)構(gòu)建會特別的慢，我們一般從提供減少構(gòu)建入口的能力這一角度做優(yōu)化，Sean 提到了一個(gè)插件 cpuprofile-webpack-plugin 不知道會不會對我們分析構(gòu)建耗時(shí)有幫助。

阿里巴巴 Just 工程體系，由前端開發(fā)的演變對應(yīng)到工程化的對應(yīng)演變，從穩(wěn)定與高效（版本控制，代碼檢查），標(biāo)準(zhǔn)與定制（研發(fā)流程的制定，流程節(jié)點(diǎn)的定制），通用與易用（開箱即用、分層增強(qiáng)）角度分享了工程化實(shí)踐中對前端開發(fā)的賦能、提供良好的前端開發(fā)體驗(yàn)。

沒有特別的啟發(fā)，但鏈路很全，在做提供相關(guān)服務(wù)能力的時(shí)候可以做參考。

講的還是比較積極風(fēng)趣的，呼吁大家要節(jié)約時(shí)間高效學(xué)習(xí)。

如題，從第一階段-開發(fā)上線（技術(shù)選型與初級架構(gòu)設(shè)計(jì)），第二階段-持續(xù)交付（提高擴(kuò)展性、降低業(yè)務(wù)開發(fā)思考成本），第三階段-開發(fā)質(zhì)量（開發(fā)、構(gòu)建、部署流程），第四階段-精細(xì)化運(yùn)營（數(shù)據(jù)監(jiān)控，包括錯(cuò)誤、構(gòu)建、關(guān)鍵業(yè)務(wù)指標(biāo)）進(jìn)行了分享。

主線和《從一到無窮大：前端工程化中的實(shí)踐與臆測》比較類似，沒有特別啟發(fā)的地方，在做提供相關(guān)服務(wù)能力的時(shí)候可以做參考。

同時(shí)不得不感慨一句，快手的技術(shù)發(fā)展、應(yīng)用真的很迅猛。

非常榮幸能加入現(xiàn)在的團(tuán)隊(duì)。