GMTC 2019 參會感想

寫在前面

得知 GMTC 2019 在北京舉行仍是今年 3 月份 EE 協做文檔 的前端同窗，推薦咱們團隊去 GMTC 作個分享，因此也順便組織團隊成員一塊兒去向業界大佬學習。咱們團隊也有幸在 GMTC 的跨平臺專場分享了《基於 Electron 的跨平臺桌面客戶端開發實踐》，感興趣的同窗能夠關注咱們，會在後期作相關的分享。

分享主題

限於篇幅，咱們挑選了一些前端熱門的主題內容，介紹了演講的內容和與會者的感想。其中 WebAssembly 一節是咱們團隊一個美國小哥哥寫的英文，咱們就不作翻譯了，你們見諒，哈哈。

極致前端性能優化探索（陳辰）

1. 優化的四個階段

2. 方案

• 現狀：評估出是否須要優化，以及優化數據的具體緣由
• 目標：主要是性能優化的數據理想狀態，以及優化方案制定的主要因素
• 成果：優化後實際達到的效果，大多數效果不如目標

3. 面對的困難

• 硬實力：技術知識，實現所需功能的編碼能力
• 軟實力：需求梳理 && 推廣 && 數據支撐（平臺），實現優化的價值

4. 實踐案例

• 文本壓縮（gzip原理）
• 圖片壓縮（視覺欺騙，針對人眼的色感度）
• 百度巴西官網

筆者感想

優化的範圍不僅侷限於技術，能夠擴展到產品乃至運營的手段，不設邊界。

1. 在前端領域，咱們面對的最終用戶仍是屏幕前的人，因此能夠從人類的能力範圍內尋找優化空間，例如圖片壓縮方案中針對人眼的視覺欺騙，計算機會忠實的呈現全部像素，但人眼沒有這個識別能力，在必定程度內的圖片質量損失不會被人發現，同時也達到了縮小體積的目的
2. 百度巴西官網的案例：百度巴西官網的feature，是須要在當地打開一個介紹頁面，介紹頁面中包含一張126k左右，而且不容許壓縮的偉人圖片，他們的小組從技術方面作的幾個優化方案效果都達不到預期，除了基本的無損壓縮少許收益外，最後的採用的方案是在當地大量投放帶該圖片的廣告，令當地運營商和儘量多的設備緩存圖片，以達到秒開的效果，是個須要國家機器推進的解決方案

對於優化工做，數據支撐是很是重要的，纔有可能爭取更多的資源，沒有數據就創造數據，成果纔有意義。 演講中提到的數據監控平臺我在上家公司也作過，一方面欠缺推廣能力，另外本身的投入可能也不太夠，只作了個初步階段便停滯了。

Debug的時光機能力，提供了徹底的交互重演能力（超出預期的點在於request和response的攔截）。

1. 全部action和payload的重演
2. 網絡請求reqeust和response的重演

工做10年，我在前端專業成長路上的探索（張鑫旭）

筆者屢次遇到的 CSS 問題，總能在張鑫旭的博客上找到滿意的答案，在此先感謝鑫旭大大無私的分享。張鑫旭的專場有不少的同窗參與，現場的同窗應該有感覺，門口擠滿了人（忘記拍照了，逃）。他現場的分享氣氛跟他的博客風格同樣，風趣幽默，以致於讓聽衆懷疑可能進入相聲專場了。

張鑫旭分享了本身過去與如今的生活對比，相比過去，本身的物質生活有很大的提高，但更多的是精神層面上的知足，從事本身喜歡的工做，自由能夠安心作技術。又由於本身的分享，給行業內的同窗創造了價值，可以被你們所感謝，被你們尊重。接着分享了本身必然成功的路徑，他跟阮一峯是一類人，堅持不懈的作分享，一堅持就是 10 多年，正如他本身所說的，回過頭看，專一於專業技術反而成爲趕超他人的一條捷徑。

接着分享了本身的學習方法，就是學習、實踐、概括和總結（分享），可是堅持作下來的同窗並很少。他鼓勵你們作的事情是堅持，有些同窗由於貪玩而有負罪感（三天打魚兩天曬網），他說玩就痛快玩，學習就痛快學，不要有負罪感。即便你玩3天，只學習半個小時，但只要你一直這麼堅持下去，也能超過不少的人。

最後分享了他本身對於財富獲取的見解，你得到的財富是與你創造的價值正相關。首先，你須要創造價值（分爲行業價值和企業價值），其次要讓別人知道你創造了價值。鑫旭分享了本身的例子：經過本身堅持不懈的博客分享，既創造了行業價值（幫助他人成長，幫助行業成長），又提高了本身的技術水平，還給本身帶來了財富；在公司內部，經過本身的技術解決了小說做者沒法制做優美精良的小說封面問題，給公司和小說的做者都帶來了極大的價值。

整場的分享雖然雞湯滿滿，而我看到的是一個普通人如何經過本身的努力和堅持獲取成功的，沒有任何奇技淫巧，惟有堅持不懈的投入。

基於跨平臺框架 Flutter 的動態化平臺建設

做爲跨平臺方案，2018年開始推出的 Flutter 可謂是跨平臺的優異解決方案。隨着 Release 1.0 的發佈，美團積極跟進了 Flutter 技術。發現了 Flutter 在優異的跨平臺方案上最大的不足在於其缺少必定的動態性。因此美團技術團隊基於 Flutter 開發了動態化的能力，使之造成了一個支持動態的 Flutter 開發平臺。

• 邏輯層動態化： 經過修改Flutter Engine，增長調用 JSCore 運行js的能力
• 渲染層動態化：選用xml+css，爲 Flutter Framework 層增長解析 xml+css 到 widget tree的能力，借用Flutter的渲染引擎來渲染。

可能因爲保密緣由，細節介紹很少，大體講了一下總體架構和方案，例如動態化的UI層如何調用Flutter接口或者js接口能力。從技術方案上來看，與以前閒魚團隊選擇的jsonSchema相比，選擇了一個比較複雜和技術難度較大的方案，多是出於平臺化建設須要提供更豐富的動態化能力的選擇。

基於Flutter引擎的TypeScript UI框架在樹莓派上的應用

針對 IOT 時代嵌入式設備UI開發面臨設備碎片化、動態性欠缺、開發效率低等問題，淘寶渲染技術團隊在 Flutter 的 Native 引擎基礎上，創建了一套基於 TypeScript 的，擁有 2D/WebGL/WebGPU 能力的可編程自定義的UI渲染管線。

1. 技術特色：Flutter 引擎 + TypeScript + GCanvas
2. 將總體的渲染分爲兩部分：TypeScript 的部分是自定義渲染管線，其他部分歸爲引擎

樹的構建: Widget Tree -> Element Tree -> Render Object Tree 佈局與繪製：基於構建樹，藉助構建出的 RenderPadding、renderConstrained Box等進行一系列定位與繪製; 合成：Offesetlayer or PictureLayer 引擎部分使用了光柵化緩存，上層可指定組件是否爲複雜組件、將來是否會變化等。

筆者感覺：flutter -> dart / dart -> flutter 沒有必要強綁定。該團隊圍繞平臺自身的特色，僅採用 flutter 引擎，廢棄了 dart，利用 TypeScript 構建了一套 UI 框架。在 flutter 等技術比較流行的趨勢下，各個開發者能夠結合結合當前業務和開發平臺的特色，選擇其中適合本身的部分，構建更合理的開發方式。

基於DOM 的可協做幻燈片編輯器架構模式

幻燈片編輯器的技術選型

圖形技術選型

• svg: 優勢是支持 Event Handler，移動端正常展現，實現簡單；缺點是存在性能問題
• canvas: 優勢是性能好，渲染效率高；缺點是實現較複雜，需適配移動端

文本技術選型

• svg/canvas: 實現較複雜，目前只有少數廠商使用
• HTML DOM contenteditable: 實現簡單，能最大化利用瀏覽器功能，但 execCommand 功能不完善，生成的 HTML 結構不可控，徹底依賴瀏覽器的實現
• 各種第三方編輯器: 基於 contenteditable，數據與 UI 分離，保證數據與 DOM 的一致性，可擴展定製

可協做幻燈片的算法實現

可協做幻燈片的算法實現分爲兩大部分，一部分是實時協做OT算法，另外一部分是幻燈片中圖形的變換計算。

OT算法：用insert、 remove和retain來表示文檔內容及其修改

OT算法的基本概念是根據前一次操做來變換後面的操做，用以保證最終計算結果的一致性。

例如如今有一個字符串 abc，兩個用戶正在實時編輯這個字符串，小明在 a 前面插入了 x，能夠這樣描述這個操做：O1 = Insert[0, 'x']。小紅刪掉了 c，也就是 O2 = Delete[2, 'c']。

爲了體現實時協做的效果，在小明的頁面上，咱們先對他的字符串進行 O1 操做，而後要把小紅的 O2 操做運用到頁面上，此時咱們須要先對 O2 操做進行變換，變成 O2' = Delete[3, 'c']，而後再進行計算。同理，在小紅的頁面上，咱們須要把 O1 轉換爲 O1' = Insert[0, 'x']。

圖形變換： 矩陣運算

當圖形通過一系列平移、旋轉、縮放等操做後，再去計算圖形的最終位置是一件有些複雜的事，好在圖形學中對這些基本圖形變換已經有較爲成熟的算法。例如縮放，就能夠用下面的矩陣來表示：

值得一提的是，CSS 中的 transform 等變換屬性，本質上也是經過矩陣運算實現的, CSS 中提供了 matrix 方法用來進行復雜的圖形變換操做。

筆者感覺

• 技術選型須要考慮到穩定性、兼容性、可擴展性、實現成本等多方面
• 目前編輯器的實現依賴第三方庫，最終但願能由瀏覽器在標準層面實現

前端路上的思考

本次阿里巴巴資深總監鄭葉飛（圓心）分享了阿里經濟體前端委員會四大技術方向：

• 搭建服務：框架標準化、模塊標準化、服務標準化（我的理解是統一開發流程，減小技術選型帶來的不一樣產品不一樣技術，能夠更好的維護代碼）
• Serverless：雲+端，給了前端下沉的機會
• 智能化：AI * Front-End，極大的加快前端完成靜態頁面開發速度，有效釋放人力
• IDE：銜接源碼開發+可視化研發+FaaS開發+小程序裝修，打通開發生態

我的感受最重要的方向是 Serverless，這給了前端更多接觸業務的能力，雖然 Node 的誕生給了前端接觸後端的機會，但總體上因爲缺少監控、sql 理解、運維能力等其它相關技術，致使大部分前端並不能成爲一名合格的後端開發。可是 Serverless 的出現，自然把這些東西都隔離出來了，這樣前端在寫後端代碼的時候僅僅只是須要關心業務邏輯便可，並且能夠本身定製接口，作以前後端不肯意乾的髒活累活。這樣有了 Serverless 以後前端就能夠擁有本身完成整個技術開發的能力，進一步能夠增強本身對業務完備邏輯的思考，從而更好的把控業務。

基於 Serverless 的淘寶前端研發模式升級

簡潔來講，Serverless = FaaS + BaaS

做爲近段時間前端領域中最火的幾個概念之一，Serverless 的架構實現了輕量級的業務服務端研發，可使業務開發更多的去關注業務的實現，而沒必要去考慮資源利用，運維成本等等其餘的事情（固然這些依賴於一個強大的平臺）。這種架構在提高了業務的開發效率的同時給前端帶來了更多的機遇，前端能夠更多的參與到業務的交付中，不僅是侷限於瀏覽器

Using webpack to make Apps fast at Microsoft

隨着 web 日益發展，移動端所佔份額愈來愈大。目前移動端網頁平都可交互時間須要 14s，其中 Javascript 和 CSS 是加載的最昂貴的資源。越少的代碼，意味着更短加載時間和更快的可交互時間。

經過微軟內部網站優化的一個具體例子，分析網頁加載時間，定位性能問題，而後使用 webpack 的 code split 功能來實現代碼的按需加載，提高首屏的加載時間。甚至咱們還能夠經過 service worker 等技術進一步加強 code split 的功能，提高用戶體驗。

網頁加載性能不只是一個技術問題，更重要的是會提高咱們用戶的留存率，甚至是付費率，值得咱們重點關注和持續優化。

總結：經過一個微軟本身網站優化的一個例子，不只僅向咱們展現瞭如何利用 webpack 的 code split 來提高咱們網站的加載性能，更重要的是向咱們展現了一次性能優化完整的流程，發現問題 -> 肯定關鍵指標（數據化）-> 分析問題 -> 定位問題 -> 概括總結 (本質緣由） -> 修復問題 -> 驗證效果（數據提高）。

WebAssembly — 技術變革，將來已來

The WebAssembly talk did a great job of summarizing the history and motivation of WebAssembly, the progress made so far, and what lies ahead for WebAssembly project. The conclusion seems that WASM is ready for production, but that doesn't mean everything should be rewritten to WASM immediately. Rather, focus on performances bottlenecks and maintain code usability.

The beginning of the talk covered where the bottlenecks in JS come from, not just parsing and optimizing JS code, but also the JS language specification itself. This slide captures all the work involved adding two numbers in JS.

All four major browsers have already shipped support for the MVP of WebAsm. In the PPT, you can see a basic example of how to get WebAssembly code running in your browser. The slides give you a brief overview of the binary WASM format, and a quick example of how to compile C++ code to WebAssembly. With the first MVP of WebAssembly, people have already created photo editing libraries, porting C libraries like MozJPEG (C++) and webp (C) to WebAsm. Ebay has shipped a mobile barcode scanner to the browser using WebAsm. The two focuses of the WASM MVP were to enable high-performance compute, and to allow for code reusability.

As for WASM goals post-MVP, significant progress is already being made in threading, SIMD vector instructions, and system call integrations. Chrome 74 was shipped WASM threads providing atomic load instructions, mutex locks, and shared memory via SharedArrayBuffer. 128-bit SIMD instructions are planned for the next version of WASM along with many more optimizations.

Another big development in WASM came with the system interface for Wasm. WASI provides a secure and low-overhead sandbox for invoking system calls directly to the OS. Fastly CDN has already developed a runtime written in Rust to run Wasm on your system outside of a web browser called Lucet.

Overall, the talk was a great overview of the current progress of WebAssembly. The speaker made a compelling case for the benefits of WASM. The PPT includes plenty of instructive code samples for how to get started with WASM by yourself. The conclusion seems that WASM is ready for production, but that doesn't mean everything should be rewritten to Wasm immediately. Rather, focus on performances bottlenecks and maintain code usability.

Wasm 總結建議： 找到性能瓶頸，選擇性使⽤。作好降級⽅案，保證可⽤性。

寫在後面

此次大會給團隊的同窗帶來的很多收穫，也擴大了你們的視野。還見到了一些混跡知乎等各社區的大佬們（winter、hax、狼叔、張鑫旭等），沒好意思去要合照，溜了溜了。

文章做者：飛書團隊。

邀請優秀的人一塊兒作有挑戰的事兒！字節跳動效率工程團隊研發職位招聘，想成爲技術大牛的夥伴快點進來看！職位介紹