鑽石舞台

公司直播課業務快速迭代，PC 學生端日漸顯現出技術棧老舊，模塊依賴複雜等問題，導致穩定性問題不斷，維護成本高，不能滿足於業務需求迭代速度。在這種情況下，就需要重新設計和改造來提高應用的穩定性、擴展性、可維護性，高質高效地滿足業務需求。

首先，簡單介紹下 Electron：可使用端與 FE 技術棧構建跨平台桌面應用程序的開源框架，社區活躍。基於該框架開發的應用有 VSCode，Notion，Postman 等。

學生端集成了從課前設備檢測、選課、課中環節的簽到、媒體直播 / 回放、Cocos 題目、手勢、語音、選項卡等多類互動，到課後環節的學習測驗。複雜場景流程讓⼀些問題更為凸顯，基於這些問題及現狀分析，我們確定了本次重構的主要方式和目標：

前期實現簡單，穩定性擴展性不足，維護多套直播間成本高，且無法保證線上質量，因此我們計劃通過⼀套配置化的功能組件來滿足多套直播間的需求，從而降低成本，並且其他業務線也可以低成本接入。

可以通過進程隔離、架構分層、封裝底層細節等手段來解決無規範、無封裝調用引起穩定性的問題。降低業務迭代風險，提高線上穩定性，也是防迭代劣化手段之⼀。

通過降低應用 CPU，內存資源消耗來解決部分低端機上卡頓體驗不佳的問題。

目前日誌混亂缺失，定位問題成本高，無機制監控應用狀態。可以建立應用日誌及數據體系來解決，確保應用狀態及線上問題有數據可查，並有數據指標來指導應用優化。

以目標拆分，PC 學生端新架構如下：

存在平滑過渡需求，所以需要從運行流程方面做好規劃，按模塊優先級分批迭代替換。

PC 學生端生命周期及運行流程如下：

按架構圖拆解，列舉⼀些核心功能模塊，簡述功能與設計思路：

作用：信令主要用於主講端、服務端、學生端之間數據交互。

設計：之前信令操作沒有封裝與業務邏輯耦合，維護成本高。

對信令數據交互邏輯做了封裝。業務研發只需註冊相關事件即可收發信令，降低研發成本及風險。

信令通道：使用 Node 實現長鏈接替換了之前 PPAPI 實現的信令數據交互邏輯，功能及穩定性更可控。

作用：日誌在開發調試，線上問題追溯，應用監控都是必不可少的數據源。收集必要數據上報後多維分析來滿足業務 / 技術指標，報警需求。

設計

數據收集：客戶端區分日誌種類級別採用不同的刷盤和上報策略進行持久化，供數據消費環節使用。上報失敗有補發機制避免關鍵日誌丟失。

數據鏈路：目前有指標監控報警、問題定位、業務數據分析多種結合了 OLAP， OLTP 的場景的需求，以公司單套數據基建無法滿足。我們推動打通了公司的 Rlog 和 Nlog 數據通路，使得日誌在⼀處上報即有 Rlog 的時效性及報警相關功能，又可以享受 Nlog 強大的數據處理基建的福利。

數據消費：對於指標監控報警類需求則使用Rlog 通路上的 promethus+grafana 滿足，對於時效性 T+1 的業務 / 技術指標數據則使用 Nlog 通路上的報表平台滿足。其他直播課定製化的數據需求，我們開發了哈勃平台，解決了直播課大前端團隊線上 Case 定位難的問題。

下面是數據鏈路圖，數據鏈路建設過程複雜可另起篇幅詳述。

作用：BV（BrowserView）是 Electron 提供的一種 Web 容器。BVManager 模塊主要是對 BV 容器生命周期的創建、更新、銷毀和 JS/CSS 注入、層級切換、BV 池操作等的封裝。

設計：

在 BrowserWindow、iframe、BrowserView中選擇 Web 容器時，需要從性能、易用性、可維護性方面綜合考慮。有多業務線接入需求，所以要在隔離性方面做到渲染進程間相互隔離，資源銷毀可控，性能優異並有完備 API 滿足業務場景，基於這些原因，最終選擇了 BV。

為性能與安全起見，在不同類型的 BV 中做了精細化的環境初始化，只注入必要的方法。

業務使用 BV 時需要及時響應，做了 BV 池封裝處理來提高用戶體驗。

各 Web 容器對比細節：

BrowserWindow

BrowserView

iframe

<webview>

作用：集成流媒體 SDK，負責推拉流操作及視頻幀渲染。

設計：

早期是 PPAPI 封裝數據處理邏輯，線上問題不少。新版將流媒體 C++ 部分封裝為 Node 模塊去做分流、轉碼、裁切、渲染等數據操作，性能及穩定性可控。

渲染更改為視頻數據消費側主動拉取幀數據，避免 SDK 推視頻幀數據在低端設備中消費不及時渲染數據堆積導致的卡頓及內存溢出。

流媒體數據相關鏈路如下：

還有⼀些 AI 模塊、數據存儲模塊、IPC 通信模塊、熱更 / 熱修復模塊、打包簽名模塊等，這裡就不一一列舉了。

新架構的迭代中也遇到了⼀些問題，這裡記錄⼀下：

架構升級帶來的新的兼容問題：

a. 殺毒軟件對進程創建和文件讀寫權限的干涉導致的各類問題。

b. Win7 系統上 Electron 新版本的兼容性引起的 Crash 問題。

PC 學生端在部分低端設備中有卡頓現象。通過數據分析，4G 內存以下和 Win7 用戶占比較大，PC 客戶端需要對老舊系統設備做兼容。

以上為穩定性相關問題，按工單定量來看低端設備導致卡頓的工單占問題工單總量 70% 以上，殺軟及安全設置問題占工單總量 20%。針對於低端設備兼容與殺軟兼容性問題我們做了專項優化，主要三方面着手解決：

通過火焰圖分析定位到性能瓶頸，根據場景進行針對性的性能優化：

a. 對日誌讀寫模塊進行專項優化。

b. 對部分 Electron 第三方模塊進行自研，增強擴展性及性能。

c. 部分低端機型下流媒體，Cocos 互動效果降級。

安全相關優化：了解安全軟件策略，儘量避免 CLI 運行可執行文件，非用戶目錄的文件讀寫，註冊表的操作等系統敏感操作。

規範 & 流程：

a. 建立 PC 端設備分級規範（設備分為不支持、不推薦、推薦），對於不支持、不推薦設備進行提示與引導，有助於快速解決用戶問題。

b. 部分殺軟問題可以從業務 SOP，應用相關提示引導來解決。

通過專項優化後，基本解決了上述問題。還有⼀些如特定 Win7小版本系統上極小概率Crash 等長尾問題需要持續跟進。

綜合來看優化效果明顯，着重說以下幾點：

對於業務：

a. 產品配置化，技術模塊化可以低成本的滿足多種直播間需求，其他業務線也可以輕鬆的接入直播間功能。

b. 提高了線上穩定性，提供更好的用戶體驗。

性能方面：在 CPU 及內存方面新架構消耗整體優於老架構。以教學內容及交互類似的課程對比新老架構：

老架構下：

新架構下：

APP CPU占用

15.1%

11.1%

下降 26.4%

APP 內存占用

1278M

980M

下降 23.3%

穩定性

a. Crash 率遠低於老架構：經過灰度數據來看，整體應用 Crash 率均值為萬分之 8，低於之前 0.6%。

b. 系統資源可控：通過下圖可以看出在直播過程中有內存回收痕跡，新架構內存回收及時。

老架構：

新架構：

迭代提效：PC 學生端分為 Electron 層、業務容器層、前端應用層。各層邊界分工清晰明確，維護性與迭代效率的增加，也在⼀定程度上防劣化。

該項目涉及到的業務流程和技術棧複雜，細節繁多，歡迎有感興趣的小夥伴來一起探討。感謝。

作者介紹：

劉泉有

作業幫直播 PC 端負責人，目前主要聚焦於直播、Electron、大數據應用基建方向，在該領域有一定的架構設計，優化與實踐經驗。