GMTC全球大前端技術大會感想

GMTC@2019於06.20在北京舉辦，關注前端，移動，AI應用等多個技術領域，本人（編者注：本文做者爲陳光通）以一個學習者的身份參與了本次會議，在這裏簡單介紹一些本次的見聞以及感想。

會議涉及的技術方向包含前端工程化，性能優化，Node，編程語言等14個主題，因爲時間有限，我在參會前肯定了本身感興趣的場次與時間，並在時間表上作好了標記。

關於NodeJS

NodeJS場包括基礎設施的完善，開發運維體系，Serverless，複雜應用的框架與開發模式等方面的探討。目前，NodeJS在各個大廠中大體存在如下幾種應用方式：

• SSR，提高首屏體驗。
• 做爲服務端與前端之間的中間層，也就是所謂的BFF。這樣的開發模式無疑是更加溫馨的，服務端同窗能夠更加專一本身的領域模型，而無需太過於關心視圖的變化，而前端同窗也能夠自由組裝視圖層的數據，不須要事事都求問服務端。
• 全棧，由前端同窗自行開發一些內部的工具系統，甚至C端服務。

不得不說，NodeJS打破了前端與服務端的邊界，對前端同窗來講，如何維護好本身的NodeJS服務？如何與服務器打交道？如何應對海量的請求以及服務端錯誤排查？成爲了前端同窗不得不面對的一些問題。

海量Node.js雲服務的DevOps實踐

來自騰訊雲開發團隊，主張打破開發，測試與運維的邊界，提出了DevOps，簡單來講就是開發也必須具有運維的能力，其中比較印象比較深入的有以下2點：

1.基礎設施的管理：傳統的雲主機因爲雪花服務器，時間侵蝕，集羣漂移等緣由，存在各類服務不一致的風險，也難以進行自動化管理。針對這些問題，做者提出了基礎設施即代碼的概念，也就是基礎設施的搭建轉換成了配置文件的編寫，經過配置文件來保證高度統一，具體落地能夠分如下幾點：

• Docker：以Linux容器的形式對操做系統上的進程進行隔離，經過一份dockfile配置文件便可快速在系統上生成服務所需容器，而服務的一致性徹底交給了dockfile來決定。
• k8s：基於容器的集羣管理平臺，幫助咱們進行容量的規劃，管理，監控。
• 動態網關：快速完成API的註冊，並提供統一的流量控制，篩選，熔斷等手段。

2.日誌監控：日誌格式必須遵循when,what,how,where等幾個基本準則。針對複雜鏈路的日誌，能夠經過在請求頭部增長traceId的形式進行記錄，方便全鏈路問題的定位。

總體下來感受騰訊雲團隊的基礎設施仍是比較完善的，但分享更可能是基於大方向，流程方面的介紹，沒有太多技術細節透露，不過不得不認可演講者的思路很是清晰，哪怕是以前沒有Node運維的經驗的同窗，應該也能清楚地認識到各個基礎設施，流程存在的必要性以及一些簡單的運維技巧。

基於TypeScript的NodeJS開發實踐

阿里封裝的Midway框架，主要解決的是如何在Node應用愈來愈複雜的狀況下保持代碼良好的可維護性，印象比較深的有以下幾點：

• 引入的Java開發中 Ioc(控制反轉) 的概念，經過裝飾器與xml的定義，在應用啓動時生成實例，從而直接注入到Class裏。
• 經過大範圍使用ts的interface定義來約束項目數據模型的規範，以模塊的形式劃分目錄結構。
• 做者在使用上抽離了核心邏輯與框架適配邏輯，經過針對egg,koa,express開發適配層，保證無縫嵌入各個不一樣的業務場景。

當Node應用變得愈來愈複雜時，咱們不得不向傳統服務端去借鑑一些思路，從而減輕應用的複雜度，以便面對更廣闊的場景。

跨端：Flutter

Flutter：最新進展和將來展望

不得不說，Flutter在本次大會中仍是佔據了至關多的篇幅，來自Google的研究員董韜也向咱們介紹了Flutter將來的一些規劃：Flutter for web的多平臺願景，狀態管理方案的建設，IDE上的改進。

我的感受Flutter在跨端問題上的解決思路仍是很是好的，全新定義的渲染引擎讓一套代碼在不一樣平臺上依然能保持高度一致以及接近原生的體驗，真正作到一次寫，處處跑。代價就是引入了Dart這樣一套全新的語言，然而Dart單線程的運行方式，基於Eventloop實現的異步機制，讓它看上去和JS極爲類似，相信熟悉JS的前端開發直接上手Dart也不會遭遇很大阻礙。

相對而言，Flutter for web彷佛就不是那麼讓人看好了，它的原理是經過Dart2js將Dart語言編譯成JS進行運行，將Flutter的Widget轉換成瀏覽器可理解的Html，Css，canvas，具體流程以下圖所示。考慮到瀏覽器的版本複雜多樣，這個過程不可避免會出現一致性的缺失。官方也建議Flutter for web能夠做爲App在web端的預覽版本，而核心的功能仍是在App中進行開發。

狀態管理方面，社區提供了名爲Provider的狀態管理庫，被官方所採納，這也從側面反映了Dart語言目前在生態上仍是有待完善的，放棄JS意味着就放棄了NPM豐富的第三方庫，這也是咱們想要入坑Flutter所必須考慮的。

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

Flutter在渲染上雖然有獨到之處，但失去了動態下發能力讓App的更新也變得困難，每次的更新都依賴發版，對於頻繁更新的複雜App來講是難以接受的。

美團對此的解決思路利用ios與android動態更新JS腳本的能力，將App中的動態下發模塊分爲邏輯層與渲染層2部分：

邏輯層：經過JScore運行JS腳本，生成相似於Virtual Dom的對象

渲染層：以流的形式將該對象輸入C++引擎，將其轉換成Flutter的Widget，經過Flutter引擎進行渲染。

這套方案既保證了Flutter的渲染性能，又能保證動態下發的能力，因爲不提供PPT下載，我按照本身的理解畫了下大體思路。

相似的方案在微信小程序中的分享中也有提到，可見如何實現Flutter的動態下發仍是你們比較關注的話題，但二者在實現上都對Flutter官方庫進行了必定程度的改造，實現成本比較大，這彷佛是在催促Flutter官方提供更合理的動態下發方案。

體驗優化

0.3秒完成渲染！信息流內容頁「閃開」優化總結和思考

UC團隊針對信息流內容頁秒開的實踐，核心是利用Native的能力進行渲染和資源緩存。流程上在Webview列表初始化的時候進行詳情頁資源的預加載，同時針對視圖內的信息流列表進行內容頁的預渲染，從而在用戶點擊詳情頁的時候能夠直接從內存中讀出HTML，達到閃開的效果。做者將這種渲染方式命名爲NSR(Native Side Render)，用以對比以前的SSR(Server Side Render)與CSR(Client Side Render)。

本人在團隊中也實踐過離線包的思路，但針對HTML的渲染，以前考慮過SSR與構建預渲染，都存在必定的缺陷。

• SSR：強依賴Node服務的穩定性，當頁面流量較大時，前端不得不創建起比較完善的Node運維設施。
• 構建預渲染：構建的時候提早渲染好模版，但只能渲染HTML骨架，由於這個階段即便模擬用戶訪問拿到了數據，也和真實用戶訪問時的數據存在差別。

從這個角度看NSR(Native Side Render)卻是一種全新的思路，它將渲染的損耗分攤到了客戶端，從而保證渲染不會受高流量訪問的影響。但因爲它強依賴客戶端的能力，如何讓這個能力更加通用，讓每一個Webview均可以定製本身預渲染的時機，這多是大範圍實踐這套方案須要解決的問題。

其餘

• B站的視頻體驗進化之路：總體聽下來感受仍是在解決資源加載順序的合理分配，簡單來講就是讓用戶最關注的內容前置加載。另外分享者還提到了經過MPEG-DASH對視頻流播放進行優化，但因爲以前對web端的視頻播放不太熟悉，這場就沒有太多印象深入的點。
• Event Loop、Future與Isolate - 單線程模型下的Dart異步編程模式：Dart語法課的感受，分享者介紹了Dart的單線程模型以及經過Future(相似JS的Promise)來實現異步。

總結

• 首次參與這樣的會議，整體來講，不管是當前的一些趨勢走向，仍是各個大廠的實踐思路，都仍是帶給我很多的收穫與啓發。
• 建議你們在參與會議以前針對本身挑選的議題作一些簡單的調研和預習，避免在演講時陷入一臉懵逼的狀態（好比我此次在聽midway框架的分享時，因爲不太清楚其誕生的背景，全程就有點迷）。
• 最大的遺憾是沒能去跟講師多作溝通，我的感受分享的內容再怎麼精彩，能帶來的收穫終歸仍是有限的，能與技術大牛現場直接溝通技術細節纔是參與大會最大的優點，惋惜此次沒能好好利用。