通讀「阿里文娛 - 覆蓋前端業務的大前端技術」

前言

看到同事在羣裏分享的一個技術小冊 -- 阿里文娛 - 覆蓋前端業務的大前端技術，抽空讀了下，有些收穫（我的向），算是讀書筆記吧，作個分享。

由於有多個章節，下面就以技術章節做爲本文行文的順序

如何支撐營銷活動？

爲了解決活動頁中重複勞動力開發的問題，大公司們都會有本身的一套「搭建」系統，讓開發者更專一於組件的可複用、可配置。

具體「搭建」系統的架構設計，文章沒有展開講，更多的是講要處理哪些細節：

1. 埋點規範化：作過「搭建」系統的太清楚了，埋點不規範，DA兩行淚
2. scheme跳轉及喚端統一化：活動頁的展示方式可能在多個自家 app,微信，甚至是移動端瀏覽器，因此有必要作跳轉的區分
3. cms數據分發：這個說得有點高大上，不知道與普通的數據展現組件有何區別
4. 組件原生渲染：爲了媲美原生組件的性能，採用集團的 weex 框架，相比純 h5 頁面有更好的體驗
5. 多端搭建：利用 weex 的跨平臺能力，加之樣式響應式處理，實現組件多端複用

前端工程管理實踐

項目之間技術方案各異，複用難，如何解決？

文中提到兩點：

• 縱向：提供開發->發佈一整套解決方案，包括：腳手架、物料平臺、構建服務等，進行工程入口收斂和管控
• 橫向：領域專項，好比：鑑權、埋點、監控、日誌等

感受和各大公司的工程管理實踐差很少。不過文中有個感興趣的點是「經驗複用」這個，提到： 「將平常開發中錯誤進行收集，統一解答歸類存檔，構建錯誤知識庫，下次從知識庫中查找對應結果處理」

不清楚這個收集和歸檔是怎麼處理的，感受可能就是純人力維護+wiki的形式？要是加入自動收集&ai問答，那就完美了。

優酷 Node.js 重構之路

最先：bigpipe+jq 的方案。

bigpipe 可能你沒聽過，其實就是將頁面分爲若干模塊（須要進行標識），在服務端渲染之時異步填充到各個模塊，可以讓瀏覽器和服務器一塊兒併發執行，快速展示核心模塊。缺點可能就是模板編譯帶來的性能損耗較高？（我沒用過）

當前：採用的是 React SSR 方案，並支持 CSR/SSR 一鍵切換。

有兩個處理方式值得借鑑：

1. 當服務端出現渲染壓力時，進行 CSR 服務降級。此時服務端僅負責頁面 SEO 數據獲取

我理解應該是在輸出 CSR 模板的基礎上，把數據也插入 html 頁面，這樣相比原來的 CSR 方案，有更快的展示。

2. 當數據源服務出現問題時，使用 CDN 數據兜底進行頁面容災，避免用戶看到空白頁面這樣。

固然，還有一些細節有待研究，好比如何判斷自動判斷服務端出現渲染壓力，如何自動切換等

將來：Serverless SSR

React SSR 方案是依賴於 Node.js Web 應用的，那必然須要關心服務和運維。

而在 Serverless 時代，基於 FaaS （函數即服務）進行 API 開發是很簡單的，那如何加入 SSR 能力呢？

正如 Umi SSR 等框架讓開發者再也不須要關心 webpack 同樣，當咱們繼續對 node 框架進行定製後，就再也不須要關注 node 服務的細節，僅須要編寫 React 代碼了。

OTT 端登陸態設備穿透：掃碼登陸與反登陸

這部分內容比較有收穫的是第一次據說「掃碼反登陸」這個應用場景。（多是由於我沒用過電視盒子吧。。

什麼是「掃碼反登陸」？就是在 ott 端登陸的狀況下，出現一個二維碼，此時手機掃碼，手機將同步 ott 帳號登陸態，接下來就能夠在手機上進行該帳戶的一些操做了，好比開通會員（由於 ott 端通常不會有支付軟件只能在手機上進行支付）等。

具體的技術方案，和掃碼正登陸有點相似。過程以下

1. 在 ott 端，攜帶 token 發起請求獲取惟一標識值 authCode （隨機生成，由 Redis 維護，關聯 token），並返回「登陸驗證二維碼」url

   這個感受也能夠寫死，由服務端返回多是更加可控，防止服務掛了能夠動態更換，而寫死的話還得用戶更新 ott 版本

2. 將 authCode 拼接在 url （獲得 newUrl）後並生成二維碼
3. 手機端進行掃碼，即請求 newUrl ，此時將去服務端進行驗證 authCode ，驗證經過將返回 token
4. 還能夠再加入重定向的頁面（好比會員購買頁）放入 url 後，手機掃碼登陸成功後重定向到相應頁面
5. 還可讓 authCode 加入「消費」字段，ott 端進行輪詢，在手機登陸成功後自動關閉二維碼頁面

小而美的 egg-react-ssr 開源實現方案

項目地址

文章的內容差很少就是該項目的 README ，能夠直接點擊查看。

印象比較深的是裏面提到該方案相比 Next.js 的代碼非黑盒，有空的話能夠看下實現。

雙 11 貓晚互動前端容器化之路

組件化平臺差別的處理

組件適配平臺仍是平臺適配組件？能夠這樣處理：

1. 組件較多而平臺較少時能夠由平臺進行適配
2. 平臺適配較難或者差別難以抹平則由組件適配
3. 儘可能讓平臺進行適配，減小新組件適配勞動力

容器化

基於 Weex 的原生渲染和拓展能力實現熱更和高性能。具體我沒用過這個框架，就不展開講了。

互動遊戲秒開優化

秒開優化對於 h5 開發的同窗來講應該是老生常談了。

由於沒有玩過雙 11 的互動遊戲，不太理解文章裏面講的「選隊結束」->「遊戲開始」階段，看上去的優化策略應該就是預加載

互動與視頻對齊

首先有個共識，網絡情況不一樣，同一時刻每一個用戶看到的畫面是不一樣的。

而互動信號是，主持人說出「開始」時，界面產生互動。

一般的實現方案是二者分離，直播是直播，互動是互動，互動由另外的接口下發通知。

可是這樣可能會形成，用戶網絡較慢，還沒聽到直播中主持人喊出「開始」口號，界面互動就開始了，這樣會缺乏一點現場感。

解決方案能夠從視頻編解碼入手。

咱們知道，視頻編碼中 SEI (附加增長信息) 能夠帶上自定義數據，那麼只須要再主持人喊開始時，將互動信號經過 SEI 編入視頻流中，這樣用戶看到相應畫面時，正好解到相應的 SEI ，觸發互動展現。

高併發下的服務端穩定性優化

感受文章沒發全？？沒提優化策略就直接講好處了。。

總結

文中提到的幾個方向，不管是工程化、活動頁搭建平臺、近原生開發，都是時下前端的熱點，要學的東西還好多呀。。