2019 TWeb 騰訊前端技術大會精彩回顧

週六的時候去了 TWeb 騰訊前端技術大會, 總結一下. 爲了更清晰地闡述一些技術點，我會加上本身的理解介紹大會中的重點內容和相關技術落地的成果或進度.

分享主題: 是時候瞭解一下 Web IDL

講師: 吳小倩 - W3C 中國總經理

什麼是 Web IDL

Web IDL 的關鍵在於定義瞭如何把 DOM 和相關的 Web API 映射到語言裏，尤爲是 ECMAScript。以前的標準都使用 OMG IDL，沒有正式的對這些映射關係作出定義，實現者須要從字裏行間猜想。 -- Maciej Stachowiak (Webkit), 2009-9-28

2015年8月4日，W3C的Web應用工做組（Web Applications Working Group）發佈了Web接口定義語言（Web IDL Level 1）的標準工做草案。該文檔定義了接口定義語言（interface definition language）即Web IDL，它可用於描述要在Web瀏覽器中實現的接口。Web IDL是一種IDL的變體，它所具備的大量特性使之可以更容易地對Web平臺裏的經常使用腳本對象的行爲進行指定和說明。

除了描述 ECMAScript 接口以外, Web IDL 能夠轉換成瀏覽器代碼和 Web API 測試用例. 若是發現了瀏覽器對標準實現有問題, 能夠嘗試對照 Web IDL 進行捉蟲.

若是你想讀懂 DOM 和 Web API 的定義, 更好地書寫你對 Web 的提案, 更好地認識瀏覽器和 Web, 你須要瞭解 Web IDL.

關於 Web IDL 的相關語法和工具, 由於介紹篇幅較長, 能夠看下講師的 ppt 瞭解

參考:

W3C發佈了Web接口定義語言（Web IDL Level 1）的標準工做草案

分享主題: Headless CMS——小微項目的業務中臺解決方案

講師: 張雲龍 - 巧子科技創始人

目前講師在作的事情

將下圖中講到的全部流程, 都封裝起來, 作了一套系統

分享中, 講師着重介紹了 strapi, 這是一個開源的 Node.js Headless CMS 框架. 該框架經過簡單的幾行 npm 命令, 便可生成一個 CMS 系統, 該系統經過界面操做, 能夠生成數據庫表, node 增刪改查的代碼和相關路由. 掘金這裏不知道怎麼放視頻，你們能夠到strapi官網瞭解，或者聯繫我，我給你發視頻～

分享主題: Flutter在騰訊企鵝輔導上的實踐之路

講師: 塗金林 - 騰訊教育 Flutter 負責人

講師先是介紹了 flutter, 接着講了騰訊企鵝輔導上的實踐, 包括了安卓, iOS 和 Pad 上的原生應用如何嵌入 flutter 以及原生頁面與 flutter 頁面混合切換的實踐, 另外還講了 flutter 的性能優化與 flutter for web 在生產環境的實踐. 這裏邊的技術細節限於篇幅就再也不展開, 感興趣的能夠看下講師的 ppt 瞭解

爲了更好的瞭解 flutter 在騰訊的落地狀況, 你們能夠看這個視頻

分享主題: 大型Web項目可用性提高優化方案

講師: 郭林爍 - 騰訊 AlloyTeam 高級前端工程師

講師所在的項目是騰訊文檔, 是一個大型的團隊, 一個頁面就有不少人開發, 在遇到問題時, 得先指定人排查, 排查出問題, 再交接給相應的人解決, 比較低效, 此次分享講了如何解決這個問題，主要分如下三個方面

腳本錯誤監控、優化、持續跟進

講師所在的團隊, 經過腳本錯誤監控, 結合代碼自動 sourceMap, 定位到出錯文件的具體位置, 經過自動化腳本與 git blame 命令, 找出當前報錯行的歷史提交者, 經過內部工單系統, 自動提 bug 單給歷史提交者, 由於工單有內部流程保證會被處理.

在開發階段, 若是有腳本報錯, 也會自動彈窗, 阻斷開發.

對報錯量級進行了監控, 若是忽然上漲, 也會有相應告警.

通過以上幾個措施, 線上的報錯量愈來愈少了.

前端日誌系統搭建、優化與打通

通過上面的錯誤監控, 優化與持續跟進, 已經解決了腳本錯誤的問題, 但若是有些邏輯問題, 在大型項目裏也是很難定位. 這個時候就要依靠日誌了.

由於是個大型的項目, 前端也會產生不少日誌, 經過前端上報不靠譜, 容易在上傳時丟失. 咱們來看看騰訊文檔作了哪些內容解決日誌問題

1. 利用了客戶端(微信, QQ)的接口, 經過客戶端上報到內部的日誌系統
2. 爲了避免阻塞用戶的交互, 利用 worker 線程進行上報.
3. 將全部的異步請求作了攔截監控, 至關因而前端的一個遠程抓包, 經過一個 id 便可查找到
4. 接入了 "吐個槽" 服務, 能夠方便地收到真實用戶的反饋
5. 將全部遇到的問題落地爲測試用例, 防止以後再犯

騰訊文檔「白屏」監控體系與優化

1. 增長 loading, 減緩用戶的焦慮
2. 對加載失敗的靜態文件進行加載重試, 並結合 wait-external-webpack-plugin 插件確保重試後, 代碼的依賴順序依然正確
3. 在重試加載後, 若是還沒加載成功, 就彈框提示用戶網絡可能存在問題, 讓用戶刷新或反饋
4. 爲了檢測加載到的資源與發佈的資源是一致的, 還在 script 標籤的 integrity 屬相加了 js 文件的 sha1 值作一致性檢測
5. 爲了防止運營商劫持, 採用了內容安全策略(CSP)進行預防

分享主題: 《騰訊 OMI +》 - OMI 框架前端生態賦能與創新實踐

講師: 張磊 - 知名開源框架 OMI 做者

該分享的 PPT 就有 80 多頁, 現場分享更是一度超時, 這裏就長話短說, 講一些核心的內容

Cross-Frameworks Framework

OMI 是一個跨框架的框架, 也就是 OMI 能夠結合 react, vue, Web Component, Kbone, Preact, Three.js 等框架使用. 用 OMI 編寫的組件, 也能夠被 react, vue, preact 等框架直接使用, 反過來, react, vue, preact 等框架也可使用 OMI 編寫的組件.

OMI-THREE

另外比較有趣的是 OMI-THREE, 若是純基於 three.js 編寫遊戲或 3D 場景, 咱們須要建立不少實例, 好比 new 一個場景, new 一個立方體, 這裏放一個光效, 這裏加一個旋轉, 這些都須要咱們編寫一些命令式的代碼來處理. 但 OMI-THREE 可讓咱們聲明式的寫法完成以上內容, 來看個 demo:

實現以上效果的代碼是聲明式的, 很清晰:

關於 OMI 還有其餘內容, 如 OMI + React, OMI + Vue, OMI + Kbone, OMIX, OMIM 以及 OMI 設計哲學, 感興趣的能夠看下講師的 ppt 瞭解

分享主題: 極致SSR：高效率構建高性能Web同構頁面

講師: 段隆賢 - Vue 語法編譯引擎 aga 做者

爲何須要 SSR

1. 更好的搜索引擎優化(SEO: Search Engine Optimization)
2. 更快的首次有效繪製(FMP: First Meaningful Paint)

SSR 的現狀

1. 通常SSR, 首屏(FMP)依賴頁面全部接口， 首屏不必定快，同時分塊傳輸有額外的工做量
2. 開發效率低: 傳統的SSR, 須要操做DOM, 開發效率低， 難維護， 同構頁面可響應時間（TTI）長
3. SSR頁面切換沒法漸進式加載， 頁面切換時不能定義過渡動畫

什麼是分塊傳輸

不須要等待頁面全部的接口返回， 頁面頭部接口響應便可響應頁面， FP(首字渲染 first paint)和FCP(首次內容渲染: first contentful paint)更快

例如一個 v.qq.com 的請求, 利用分塊傳輸, 能夠先返回首屏內容, 後面的內容等數據拉取好後再返回, 注意這裏是一個請求

講師團隊的實踐

在 Vue 編譯時, 將 Vue 語法編譯爲字符串拼接, 並經過自動化分塊傳輸, 並作到了同構開發.

分塊傳輸自動化

1. 程序分析模板的異步數據， 自動拆分模板
2. 根據模板上下的依賴關係 , 自動收集數據依賴
3. 自動把局部模板和數據關聯

分享主題: Serverless SSR 實踐

講師: 水瀾 - 阿里巴巴前端技術專家

要作 SSR 並不容易, 首先咱們要保障 Node 服務的穩定性, 期間咱們可能會遇到以下問題:

1. 磁盤佔用過多
2. 內存負載變高
3. 內存溢出
4. Node 服務發生錯誤
5. Node 宕機
6. 擴縮容, 機器裁撤

另外還要考慮如何讓一套代碼兩端共用:

7. 渲染機制的差別
8. 端上環境的限制
9. 如何處理數據請求
10. 如何避免狀態污染
11. 開發調試環境的打通

第一部分, 講師的實踐是將 node 服務落地到 serverless 中, 有以下好處

1. 函數即服務 (Faas, Function as a service), 開發者能夠更關注業務邏輯自己
2. 自然的隔離性, 動態修復，函數間相互獨立
3. 無需運維, 全託管服務、按需執行、彈性伸縮

第二部分, 講師使用阿里開源的 Rax 來解決一套代碼兩端共用的問題

Rax 是一套遵循 React 標準的跨端解決方案, 而且經過 Rax 的腳手架, 執行一條命令即可以部署到阿里的 fc 或國外的 now serverless 提供商中

這裏比較值得關注的是, 在 Rax 中, 請求的發起與路由的映射, 是能夠作到先後端同構的, 限於篇幅, 感興趣的同窗能夠查看 ppt 或 google: Rax

分享主題: 騰訊教育 Serverless 實踐及探索

講師: 蔣林源 - 騰訊IMWeb前端工程師

Serverless 邏輯架構

Serverless = Faas + Baas

初探 serverless

如上圖所示, 用戶在騰訊雲的 serverless 平臺上, 上傳雲函數的代碼(或直接用在線編輯器編寫)

保存後, 咱們能夠設置觸發器,

也就是上面的 Event Source, 能夠是 api 網關觸發器, 也就是經過請求來觸發, 其它觸發器還有: 定時觸發, COS 觸發(COS 收到上傳時觸發, 好比上傳了一張圖片, 觸發某個雲函數進行壓縮), 消息隊列觸發等等.

然後邊在提供支持的 BaaS, 則提供了不少後端服務, 像 AI, 咱們就能夠調用語音圖像的識別接口, 還能夠輕易地調用雲 DB, 而云 DB 也不須要咱們人工維護, 還有對象存儲, 諸如圖片, 視頻上傳, 回源到 CDN等, 簡直太方便了.

冷啓動

目前我體驗到騰訊雲的冷啓動作得比較不錯, 只要在必定時間閾值內有訪問, 就不存在冷啓動慢的問題, 但若是雲函數長期都沒人訪問, 此後的第一次訪問, 就會慢一些. 還能夠接受.

騰訊教育相關業務的落地

講師提到了兩個徹底使用騰訊雲 serverless 的業務, 以下

企鵝背單詞

騰訊課堂 - 新人專屬禮包

騰訊雲 serverless devOps

騰訊教育在內部的實踐中, devOps 也很完善了, 整個流程以下:

開發完 push 代碼到 git, 自動觸發代碼的構建 (yarn && yarn build 等), 自動觸發雲函數的測試環境部署, 此外, 預發佈和發佈環境也能經過內部的交付系統流暢地部署

分享主題: 阿里控制檯系統提效之路

講師: 潕量 - 阿里前端技術專家

以上即爲控制檯系統

一句話歸納該分享: 經過內部物料系統(能夠理解爲 npm 的公共 UI 組件庫積累), 阿里自研了一套 Fusion 系統, 能夠方便設計師配置設計稿, 該系統的配置粒度幾乎知足設計師的全部需求, 配置的每個參數都會記錄下來, 設計師在提交設計稿時, 會根據配置內容, 生成一個 npm 包, 前端開發更新 npm 包, 便可拿到設計師的成果, 該成果是基於物料系統的, 也就是代碼生成後, 基於 react 可讀(阿里統一使用 react), 此後即可在這個基礎上增長前端邏輯, 與設計師溝通扯皮的問題被解決得很完全.

工做流

來個主題配置的例子(其它例子的圖片 ppt 上丟失了動態效果):

大會所有ppt獲取

• 歡迎關注「前端Q」，回覆 tweb 或 ebook 便可

最後

• 歡迎加我微信(winty230)，拉你進技術羣，長期交流學習...
• 歡迎關注「前端Q」,認真學前端，作個有專業的技術人...