登錄 注冊
購物車0
TOP
Imgs 行業(yè)資訊

0

HarmonyOS學習之JS GUI技術(shù)棧

2021-03-26 17:57:01

眾所周知,剛剛開源的「鴻蒙 2.0」以 JavaScript 作為 IoT 應(yīng)用開發(fā)的框架語言。這標志著繼 SpaceX 上天之后,JavaScript 再一次蹭到了新聞聯(lián)播級的熱點。這么好的機會,只拿來陰陽怪氣實在太可惜了。作為科普,這篇文章不會拿著放大鏡找出代碼中的槽點來吹毛求疵,而是希望通俗地講清楚它所支持的 GUI 到底是怎么一回事。只要對計算機基礎(chǔ)有個大概的了解,應(yīng)該就不會對本文有閱讀上的障礙。
我們已經(jīng)知道在「鴻蒙 2.0」上,開發(fā)者只需編寫形如 Vue 組件式的 JavaScript 業(yè)務(wù)邏輯,即可將其渲染為智能手表等嵌入式硬件上的 UI 界面。這個過程中需要涉及哪些核心的模塊呢?這些模塊中又有哪些屬于自研,哪些使用了現(xiàn)成的開源項目呢?這里將其分為自上而下的三個抽象層來介紹:
JS 框架層,可理解為一個大幅簡化的 Vue 式 JavaScript 框架
JS 引擎與運行時層,可理解為一個大幅簡化的 WebKit 式運行時
圖形渲染層,可理解為一個大幅簡化的 Skia 式圖形繪制庫
這三個抽象層,整體構(gòu)成了一套面向嵌入式硬件的 GUI 技術(shù)棧。不同于許多高呼「不明覺厲 / 深不可測」的輿論,個人認為至少對于 GUI 部分,國內(nèi)凡是接觸過目前主流 Hybrid 式跨端方案或 JS 運行時研發(fā)的一線開發(fā)者,都很容易從源碼出發(fā)來理解它。下面逐層對其做一些解讀和分析。
JS 框架層
從最頂層的視角出發(fā),要想用「鴻蒙 2.0」渲染出一段動態(tài)的文本,你只需要編寫如下的 HML(類 XML)格式代碼:
{{hello}}
然后在同級目錄編寫這樣的 JavaScript:
// hello.js
export default {
data: {
hello: 'PPT'
},
boil() {
this.hello = '核武器';
這樣只要點擊文本,就會調(diào)用boil方法,讓PPT變成核武器。
這背后發(fā)生了什么呢?熟悉 Vue 2.0 的同學應(yīng)該會立刻聯(lián)想到下面這幾件事:
需要對 XML 的預(yù)處理機制,將其轉(zhuǎn)換為 JS 中的嵌套函數(shù)結(jié)構(gòu)。這樣只需在運行時做一次簡單 eval ,即可用 JS 生成符合 XML 結(jié)構(gòu)的 UI。
需要事件機制,使得觸發(fā)onclick事件時能執(zhí)行相應(yīng)回調(diào)。
需要數(shù)據(jù)劫持機制,使得對this.hello賦值時能執(zhí)行相應(yīng)回調(diào)。
需要能在回調(diào)中更新 UI 對象控件。
這幾件事分別是怎么實現(xiàn)的呢?簡單說來是這樣的:
XML 預(yù)處理依賴現(xiàn)成的 NPM 開源包,從而把 XML 中的onclick屬性轉(zhuǎn)換為 JS 對象的屬性字段。
事件的注冊和觸發(fā)都直接由 C++++ 實現(xiàn)。如上一步所獲得的 JS 對象onclick屬性會在 C++ 中被檢查和注冊,相當于全部組件均為原生。
數(shù)據(jù)劫持機制用 JS 實現(xiàn),是個基于Object.defineProperty的(幾百行量級的)ViewModel。
UI 控件的更新,會在 ViewModel 自動執(zhí)行的 JS 回調(diào)中,調(diào)用 C++ 的原生方法實現(xiàn)。這部分完全隱式完成,并未開放document.createElement式的標準化 API。
由于大量常見 JS 框架中的能力都直接做進了 C++,所以整套 GUI 技術(shù)棧里用純 JavaScript 所實現(xiàn)的東西(主要見ace_lite_jsfwk倉庫下的core/index.js、observer.js和subject.js),相當于有且只有這么一個功能:
一個可以 watch 的 ViewModel。
至于純 JS 框架部分的實現(xiàn)復(fù)雜度和質(zhì)量,客觀地說如果是個人業(yè)余作品,可以當作校招面試中不錯的加分項。
JS 引擎與運行時層
理解了 JS 框架層之后,我們既可以認為「鴻蒙 2.0」選擇把高度簡化后的 Vue 深度定制進了 C++ 里,也可以認為它緊密圍繞著高度簡化(且私有)的 DOM 實現(xiàn)了配套的前端框架。因此要想繼續(xù)探索這套 GUI 的原理,我們就必須進入其 C++ 部分,了解其 JS 引擎與運行時層的實現(xiàn)。
JS 引擎和運行時之間,有什么區(qū)別與聯(lián)系呢?JS 引擎一般只需符合 ECMA-262 規(guī)范,其中沒有對任何帶「副作用」的平臺 API 的定義。從setTimeout到document.getElementById到console.log再到fs.readFile,這些能執(zhí)行實際 IO 操作的功能,都需要由「將引擎 API 和平臺 API 膠合到一起」的運行時提供。運行時本身的原理并不復(fù)雜,譬如在個人的文章《從 JS 引擎到 JS 運行時》中,你就可以看到如何借助現(xiàn)成的 QuickJS 引擎,自己搭建一個運行時。
那么在「鴻蒙 2.0」中,JS 運行時是如何搭建出來的呢?有這么幾條重點:
JS 引擎選擇了 JerryScript,這是一款由三星開發(fā)的嵌入式 JS 引擎。
每種形如和
除 UI 原生對象外,還有一系列在 JS 中以@system為前綴的 built-in 模塊,它們提供了 JS 中可用的 Router / Audio / File 等平臺能力(參見ohos_module_config.h)。
這里特別值得一提的是 Router。它和 vue-router 等常見 Web 平臺路由的實現(xiàn)原理有很大區(qū)別,是專門在運行時內(nèi)深度定制的(參見router_module.cpp、js_router.cpp和js_page_state_machine.cpp)。簡單說來這個「路由」是這樣實現(xiàn)的:
在 JS 中調(diào)用切換頁面的router.replace原生方法,走進 C++。
在新狀態(tài)機的 Init 過程中,調(diào)用 JS 引擎去 eval 新頁面的 JS 代碼,獲得新頁面的 ViewModel。
將路由參數(shù)附加到 ViewModel 上,銷毀舊狀態(tài)機及其上的 JS 對象。
所以我們可以發(fā)現(xiàn),這里所謂的「切換路由」,其實更接近 Web 瀏覽器的「刷新頁面」。那么我們可以認為這個 JS 運行時的能力,已經(jīng)可以對標 WebKit 級的瀏覽器內(nèi)核了嗎?
當然還差得很遠。與 WebKit 相比,它并未支持對 HTML 和 CSS 的解析(二者都會在開發(fā)階段被解析轉(zhuǎn)換成同等執(zhí)行效果的 JS),也沒有瀏覽器中持續(xù)動態(tài)加載、解析與執(zhí)行資源的挑戰(zhàn)(小程序不外乎是幾個本地的靜態(tài) JS 文件)。至于排版布局和渲染方面自然也有很大差距,這點會在最后一節(jié)提及。
另外,相信很多同學都會對 JerryScript 引擎感到好奇。本部分最后分享一些個人對此所掌握的消息。
JerryScript 引擎是一款專為嵌入式硬件實現(xiàn)的 JS 解釋器,只支持到 ES5.1 標準。在 QuickJS Benchmark 中,可以查看到它們的性能對比結(jié)果:

可以看到論性能,JerryScript 在無 JIT 的引擎中大幅弱于 QuickJS 和 Hermes。如果和開啟了 JIT 的 V8 相比,甚至會慢出兩個數(shù)量級。因此這是非常特定于低端設(shè)備的引擎,如果需要支持React 和 Vue 這類中大型前端項目中標配的基礎(chǔ)庫(甚至其相應(yīng)全家桶),仍然可能需要使用更強大的引擎。
對于 JerryScript 的使用,有同場景重度應(yīng)用經(jīng)驗的當屬RT-Thread創(chuàng)始人
@午夜熊
,他們和某國內(nèi)一線廠商合作研發(fā)的智能手表就用 JerryScript 實現(xiàn)了 UI,目前產(chǎn)品馬上就要上市了。他們團隊對 JerryScript 的一些使用反饋也吻合上述評價,概括說來是這樣的:
JerryScript 在體積和內(nèi)存占用上,相比 QuickJS 有更好的表現(xiàn)。
JerryScript 的穩(wěn)定性弱于 QuickJS,有一些難以繞過的問題。
JerryScript 面對稍大(1M 以上)的 JS 代碼庫,就有些力不從心了。
那么師出名門的 QuickJS 和 Facebook 的 Hermes,是否就是無 JIT 式 JS 引擎的下一代標桿了嗎?倒也未必如此。這方面可以參考個人的知乎回答:隨著 TypeScript 繼續(xù)普及,會不會出現(xiàn)直接跑 TypeScript 的運行時?這里提到的微軟為教育項目 MakeCode 研發(fā)的 Static TypeScript,就相當有潛力成為下一代的高性能 JS 系語言環(huán)境。通過限定 TypeScript 的靜態(tài)強類型子集并為其搭建工具鏈,STS 可以做到無需 JIT 也能接近 V8 的性能水平,同時內(nèi)存占用比 V8 少兩個數(shù)量級。這使得 STS 不光能用于開發(fā)普通 app 這類 IO 密集的應(yīng)用,還能順利在嵌入式硬件上開發(fā)小游戲這類更偏計算密集(需逐幀更新渲染)的應(yīng)用,在工程能力上是一項很大的突破。
所以說,當「鴻蒙 2.0」還需要熟練開發(fā)者勉強搭建出環(huán)境跑通 Hello World 時,微軟已經(jīng)讓上百萬小朋友都能用 TypeScript 在網(wǎng)頁里給教學用的掌上游戲機寫小游戲入門編程了。這里沒什么唱反調(diào)的意思,只希望提醒一下我們在為國產(chǎn)「里程碑」歡呼時,也要清醒地看到業(yè)界前沿的動向,僅此而已。
圖形繪制層
理解 JS 運行時之后,還剩最后一個問題,即 JS 運行時中的各種 Component 對象,是如何被繪制為手表等設(shè)備上的像素的呢?
這就涉及「鴻蒙 2.0」中的另一個graphic_lite倉庫了??梢哉J為,這里才是真正執(zhí)行實際繪制的 GUI。像之前的TextComponent等原生組件,都會對應(yīng)到這里的某種圖形庫 View。它以一種相當經(jīng)典的方式,在 C++ 層實現(xiàn)并提供了「Canvas 風格的立即模式 GUI」和「DOM 風格的保留模式 GUI」兩套 API 體系(對于立即模式和保留模式 GUI 的區(qū)別與聯(lián)系,可參見個人這篇 IMGUI 科普回答)。概括說來,這個圖形子系統(tǒng)的要點大致如下:
圖形庫提供了UIView這個 C++ 控件基類,其中有一系列形如OnClick/OnLongPress/OnDrag的虛函數(shù)?;久糠N JS 中可用的原生 Component 類,都對應(yīng)于一種 UIView 的子類。
除了各種定制化 View 之外,它還開放了一系列形如DrawLine/DrawCurve/DrawText等命令式的繪制方法。
這個圖形庫具備名為 GFX 的 GPU 加速模塊,但它目前似乎只有象征性的FillArea矩形單色填充能力。
在基礎(chǔ) UI 控件方面,不難找到一些值得一提的自研模塊特性:
支持了簡易的 RecycleView 長列表。
支持了簡易的 Flex 布局。
支持了內(nèi)部的 Invalidate 臟標記更新機制。
至于 2D UI 渲染中的幾項關(guān)鍵能力,則基本可分為路徑、位圖和文字三類。這個圖形庫在這幾個方面都有涉及,最后簡單介紹一下。
首先對于位圖,這個圖形庫依賴了libpng和libjpeg做圖像解碼,然后即可使用內(nèi)存中的 bitmap 圖像做繪制。
然后對于路徑,這個圖形庫自己實現(xiàn)了各種 CPU 中的像素繪制方法,典型的例子就是這個貝塞爾曲線的繪制源碼:
void DrawCurve::DrawCubicBezier(const Point& start, const Point& control1, const Point& control2, const Point& end,
const Rect& mask, int16_t width, const ColorType& color, OpacityType opacity)
if (width == 0 || opacity == OPA_TRANSPARENT) {
return;
Point prePoint = start;
for (int16_t t = 1; t <= INTERPOLATION_RANGE; t++) {
Point point;
point.x = Interpolation::GetBezierInterpolation(t, start.x, control1.x, control2.x, end.x);
point.y = Interpolation::GetBezierInterpolation(t, start.y, control1.y, control2.y, end.y);
if (prePoint.x == point.x && prePoint.y == point.y) {
continue;
DrawLine::Draw(prePoint, point, mask, width, color, opacity);
prePoint = point;
基于高中的數(shù)學知識,我們不難明白這種曲線是如何繪制出來的:取足夠多的點(也就是那個默認 1000 的INTERPOLATION_RANGE)作為插值輸入,逐點計算出曲線表達式的 XY 坐標,然后直接修改像素位置所在的 framebuffer 內(nèi)存即可。這種教科書式的實現(xiàn)是最經(jīng)典的,不過如果要拿它對標 Skia 里的黑魔法,還是不要勉為其難了吧。
最后對于文字的繪制,會涉及一些字體解析、定位、RTL和折行等方面的處理。這部分實際上也是組合使用了一些業(yè)界通用的開源基礎(chǔ)庫來實現(xiàn)的。比如對于「牢」這個字,就可以找到圖形庫的這么幾個開源依賴,它們各自扮演不同的角色:
harfbuzz- 用來告訴調(diào)用者,應(yīng)該把「牢」的 glyph 字形放在哪里。
freetype- 從宋體、黑體等字體文件中解碼出「牢」的 glyph 字形,將其光柵化為像素。
icu- 處理 Unicode 中許多奇葩的特殊情況,這塊個人不了解,略過。
到這里,我們就可以理出一個非常概括性的渲染流程了:
JS 中執(zhí)行this.hello = 'PPT'之類的代碼,觸發(fā)依賴追蹤。
JS 依賴追蹤回調(diào)觸發(fā)原生函數(shù),更新 C++ 的 Component 組件狀態(tài)。
Component 更新其綁定的 UIView 子類狀態(tài),觸發(fā)圖形庫更新。
圖形庫更新內(nèi)存中的像素狀態(tài),完成繪制。
這就是個人對「鴻蒙 2.0」這套 GUI 技術(shù)棧的解讀了。時間有限并未進一步深挖,歡迎(文明的)批評指正。
總結(jié)
特別聲明:本部分主觀評論僅針對「鴻蒙 2.0」當前的 GUI 框架部分,請勿隨意曲解。
對于「鴻蒙 2.0」在 GUI 部分的亮點,個人能想到這些:
確實有務(wù)實(但和當年 PPT 介紹完全兩碼事)的代碼。
不是 WebView 套殼,布局和繪制是自己做的。
無需超過大學本科水平的計算機知識,也能順利閱讀理解。
而至于明顯(不只是某幾行代碼寫得丑)的缺失或問題,目前看來則有這么一些:
JS 框架層
沒有基本的組件間通信(如 props / emit 等)能力
沒有基本的自定義組件能力
沒有除基礎(chǔ)依賴追蹤以外的狀態(tài)管理能力
JS 引擎與運行時層
標準支持過低,無法運行 Vue 3.0 這類需 Proxy 的下一代前端框架
性能水平弱,難以支持中大型 JS 應(yīng)用
沒有開放 DOM 式的對象模型 API,不利于上層抹平差異
圖形渲染層
沒有實質(zhì)可用的 GPU 加速
沒有 SVG 和富文本等高級渲染能力
Canvas 完成度低,缺狀態(tài)棧和很多 API
看起來槽點很多,但是你會指責汽車沒有噴氣式發(fā)動機嗎?對于不同復(fù)雜度的場景,自然存在著不同的最優(yōu)架構(gòu)設(shè)計。目前看來,這套設(shè)計確實很適合嵌入式硬件和簡易「小程序」的場景。但如果按照所謂「分布式全場景跨平臺」的要求來審視,那么不管比起現(xiàn)代的 Web 瀏覽器還是 iOS 和安卓的 GUI,這套架構(gòu)的復(fù)雜度都是完全無法相提并論的。如果想在手機上實裝,幾乎必定還需要追加大量復(fù)雜模塊,進行大幅的架構(gòu)演化與重新設(shè)計。

高都電子,為客戶創(chuàng)造價值!

雙面板免費加費,四層板加急打樣,厚銅電路板打樣

Xcm