跨平臺技術實戰!百度文庫跨平臺技術快速落地全過程

語言: CN / TW / HK

圖片

導讀:本文簡述了PC客戶端業務在文庫中快速落地的過程,其中包括了前期的技術選型,方案設計,PC客戶端跨平臺原理,以及Electron框架的應用細節。從應用深入到原理,講解PC客戶端跨平臺技術,如何實現跨平臺渲染,如何實現原生API的呼叫,和如何進行不同目標平臺的應用構建。通過閱讀本文,可以快速上手基於Electron框架進行PC客戶端業務的開發。

全文2545字,預計閱讀時間7分鐘

前言

跨平臺技術在移動客戶端平臺(Android & iOS)上已經發展了多年,從Hybrid App到小程式,再到React Native和Flutter已經得到比較廣泛的應用。無論是前端方案,橋接方案,還是自渲染方案,都需要解決三個問題:

  • 如何進行UI渲染?

  • 如何實現原生API的呼叫?

  • 如何進行客戶端構建?

不同的移動客戶端跨平臺方案都有自己的解決方式,但是在PC客戶端平臺上,大部分傳統應用軟體還是以單平臺開發為主。近期文庫業務開始啟動PC客戶端的專案,同時支援Windows平臺和MacOS平臺,從技術的角度希望通過PC客戶端的跨平臺技術,以更低的成本,更高效的迭代來適應網際網路產品的節奏,同時保證不同平臺下的一致性體驗。本文通過PC客戶端跨平臺框架的分析及跨平臺業務應用進行展開。

一、技術選型

文庫的PC客戶端主要涉及到桌面OS的Windows和MacOS,當前這兩種平臺的應用軟體開發包括了單平臺開發、中間平臺開發、跨平臺開發幾種模式,其中根據目前文庫業務研發人員結構和熟悉程度,Flutter和Electron是重點去考察的PC客戶端跨平臺框架。因為文庫在文件頁面渲染上的技術積累,可以快速複用到業務場景中,所以最終選擇了Electron跨平臺技術方案。

二、Electron框架介紹

接下來,介紹一下Electron框架到底是什麼?如何實現跨平臺的?其實要回到開篇提到的跨平臺需要解決的通用問題,UI渲染、原生API、客戶端構建。Electron是通過整合瀏覽器核心,通過前端的技術來實現不同平臺下的渲染,Electron框架主要解決以下問題:

  • 渲染與服務的融合,即UI和底層服務的融合;

  • 不同平臺下系統API的呼叫及封裝;

  • 不同平臺下應用構建;

圖片

理解Electron框架原理,其難點在於Chromium和Node.js是如何互通的,因為我們知道他們都有自己獨立的事件迴圈,不解決這個問題就無法實現渲染和服務的融合,所以需要先了解Electron的多程序架構。

2.1 Electron多程序架構

Electron多程序架構參考了Chromium的多程序架構,即將渲染程序與主程序隔離,之所以如此設計是因為與OS從單使用者到多工的發展過程類似,為避免一個出錯的頁面或外掛bug引起整個瀏覽器和全部標籤關閉。每個瀏覽器標籤使用獨立的程序,保護整個應用免受渲染程序中Bug和故障影響。在實際業務中,UI都是在渲染程序進行的,當需要使用系統服務時如I/O、DB、Push等等,通過IPC方式在主程序中實現,Electron框架本身已提供了IPC能力,包括ipcMain和ipcRenderer,具體使用可以查詢Electron官方文件,有比較詳細的說明和應用示例。

圖片

2.2 Chromium與Node.js融合

把Chromium和Node.js兩套獨立的體系進行通訊是Electron重點解決的問題之一,根據官方釋出的相關介紹,首先嚐試了用libuv來替換Chromium的message loop,每個平臺都有自己的GUI訊息迴圈,實現過程相對複雜,最終因為資源消耗和延遲的問題無法得到有效解決,所以放棄了。目前Electron框架通過在一個單獨的執行緒中輪詢Node的事件迴圈的方式來實現Chromium與Node.js融合。具體實現可以檢視框架原始碼,本文不進行展開說明。

Node_bindings.cc原始碼

原始碼地址:
https://github.com/electron/electron/blob/master/shell/common/node_bindings.cc

===

三、Electron業務實踐

3.1 多程序方案

文庫同樣採用類似Chromium的多程序方案,其中主程序負責原生服務的呼叫和業務服務的提供,以及Window的管理,可以將每個Window理解為一個渲染程序。渲染程序包括主Window(如圖中綠色1區域所示)和內容Window(如圖中紅色2區域所示),內容Window複用是因為在實際使用過程中建立和釋放Window會有明顯的載入耗時,並且更多的Window會加重記憶體佔用。所以無論是切換導航欄或者標籤都通過內容Window進行載入,並且記錄頁面狀態,實現頁面的狀態恢復,以及離屏渲染。

圖片


3.2 基於線上業務快速迭代

PC客戶端部分頁面與線上頁面是一致的,所以這部分沒必要進行重複開發,儘量通過去複用線上業務,主要的工作就是對線上頁面進行PC客戶端適配,頁面佈局、檢視遮蔽、自適應等等。目前使用注入的方式去實現,另外線上業務也是經常變化的,所以注入的程式碼儘量也是通過雲端控制。具體方式是通過Window、BrowserWindow、WebView中的webContent進行注入,這裡需要檢測頁面生命週期,需要在頁面載入完成後進行注入。

圖片


3.3 Debug & Release

Electron框架會將程式碼進行編譯,再進行打包,開發中每次都需要一定的時間執行客戶端程式,很影響效率。所以可以Debug模式下通過Node服務進行執行,Release模式下才進行編譯打包,來實現開發中的所見即所得。

圖片

===

四、總結和展望

除了Electron框架在PC客戶端上的應用,文庫業務也在移動客戶端上引入Flutter框架,並使用新的框架重構文件相關的能力。隨著Flutter 2.0的釋出,對PC客戶端更友好的支援,以及文庫業務基於Flutter的文件能力建設完善,通過Flutter構建Windows,MacOS,Android,iOS全平臺版本客戶端成為可能,也在持續的探索中。

推薦閱讀

當技術重構遇上DDD,如何實現業務、技術雙贏?

介面文件自動更改?百度程式設計師開發效率MAX的祕訣

技術揭祕!百度搜索中臺低程式碼的探索與實踐

百度智慧雲實戰——靜態檔案CDN加速

化繁為簡--百度智慧小程式主資料架構實戰總結

百度搜索中臺海量資料管理的雲原生和智慧化實踐

百度搜索中“魚龍混雜”的加盟資訊,如何靠AI 解決?

---------- END ----------

百度 Geek 說

百度官方技術公眾號上線啦!

技術乾貨 · 行業資訊 · 線上沙龍 · 行業大會

招聘資訊 · 內推資訊 · 技術書籍 · 百度周邊

歡迎各位同學關注