作者：京東零售 馬銀濤

基于 Taro 打造的京東鴻蒙 APP 已跟隨鴻蒙 Next 系統(tǒng)公測(cè)，本系列文章將深入解析 Taro 如何實(shí)現(xiàn)使用 React 開(kāi)發(fā)高性能鴻蒙應(yīng)用的技術(shù)內(nèi)幕

背景

HarmonyOS 采用自研的 ArkUI 框架作為原生 UI 開(kāi)發(fā)方案，這套方案有完善的布局系統(tǒng)和樣式控制，但是他的標(biāo)準(zhǔn)與 W3C 的 CSS 標(biāo)準(zhǔn)存在不一致性。這意味著，如果 Taro 直接使用 HarmonyOS 提供的樣式系統(tǒng)，開(kāi)發(fā)者在使用 Taro 開(kāi)發(fā)時(shí)會(huì)遇到非常多的樣式兼容性問(wèn)題，寫(xiě)出來(lái)的代碼也會(huì)失去跨平臺(tái)兼容的能力，與 Taro 多端統(tǒng)一開(kāi)發(fā)的定位不符。如何抹平 ArkUI 標(biāo)準(zhǔn)和 W3C 的 CSS 標(biāo)準(zhǔn)之間的差異成了一個(gè)重中之重的任務(wù)。

本文將介紹 Taro 處理 CSS 的全流程，剖析將不同的 CSS 樣式轉(zhuǎn)換為 ArkUI 樣式遇到的問(wèn)題和對(duì)應(yīng)的解決方案。

CSS 樣式和 ArkUI CAPI 樣式的差異和抹平

1、樣式書(shū)寫(xiě)方式不一致

以幾個(gè)我們?nèi)粘?huì)使用到的屬性為例，下面的分別是 CSS 的寫(xiě)法和 ArkUI CAPI 的寫(xiě)法。

對(duì)比可以看出，CSS 樣式和鴻蒙樣式在單位系統(tǒng)和數(shù)據(jù)表示方式上存在顯著差異。CSS 提供多樣化的尺寸和顏色單位，而 ArkUI 的 CAPI 接口采用更統(tǒng)一的表示方式。

ArkUI 的 CAPI 接口將所有尺寸統(tǒng)一為 vp 單位，顏色采用 0xAARRGGBB 格式的 uint32 類(lèi)型，對(duì)于漸變和 transform 等復(fù)雜樣式屬性，更是需要轉(zhuǎn)換為顏色停止點(diǎn)和角度值列表和矩陣運(yùn)算，這樣的接口簡(jiǎn)潔但需要調(diào)用者根據(jù)具體場(chǎng)景完成必要的單位轉(zhuǎn)換。

一個(gè)頁(yè)面通常會(huì)包含非常多的樣式規(guī)則，如果所有的單位轉(zhuǎn)換都放在運(yùn)行時(shí)候完成，必定會(huì)造成明顯的性能問(wèn)題。因此，我們選擇提前完成部分轉(zhuǎn)換。HTML 節(jié)點(diǎn)的樣式主要來(lái)源于 CSS 和 Style 屬性。CSS 樣式通常是靜態(tài)的，可以在編譯階段進(jìn)行轉(zhuǎn)換。為此，我們基于 lightningCSS 開(kāi)發(fā)了一個(gè) Rust 插件。該插件通過(guò)遍歷項(xiàng)目 CSS 的抽象語(yǔ)法樹(shù)（AST），將其轉(zhuǎn)換為 ArkUI 的 CAPI 接口可直接使用的數(shù)據(jù)結(jié)構(gòu)。

而對(duì)于 Style 屬性，其內(nèi)容在運(yùn)行時(shí)才能確定，因此必須在運(yùn)行時(shí)進(jìn)行轉(zhuǎn)換。在 React 的語(yǔ)法中，Style 可能以字符串形式呈現(xiàn)，也可能是 CSS 屬性名和屬性值的鍵值對(duì)。為了有效解析 Style，我們針對(duì)各種類(lèi)型的 CSS 語(yǔ)法寫(xiě)了一系列小型的 CSS 語(yǔ)法解析邏輯。這些邏輯能夠從各種不同格式的字符串中準(zhǔn)確匹配出屬性值并進(jìn)行轉(zhuǎn)換。

雖然這種方法需要在運(yùn)行時(shí)進(jìn)行語(yǔ)法分析，但考慮到 Style 屬性通常只包含有限的樣式，加上 C++語(yǔ)言的高效執(zhí)行特性，這種實(shí)時(shí)轉(zhuǎn)換對(duì)性能的影響可以忽略不計(jì)。更為重要的是，這些運(yùn)行時(shí)的 CSS 語(yǔ)法解析邏輯可以為后面 Taro 支持 CSS 變量提供能力支持。

2、布局存在差異

除了書(shū)寫(xiě)方式的差異，ArkUI 有很多布局屬性的行為在細(xì)節(jié)上也和 W3C 的布局屬性存在著不小的差異，比如鴻蒙的絕對(duì)定位相對(duì)父級(jí)定位，Web 的絕對(duì)定位相對(duì)最近的已定位祖先元素定位，并且鴻蒙的定位不支持 right 和 bottom（早期）。

web可以通過(guò)margin的auto實(shí)現(xiàn)居中，鴻蒙能通過(guò)flex實(shí)現(xiàn)居中。

同時(shí)， ArkUI 的 CAPI 接口缺少一些 Web 常用功能，如 calc() 計(jì)算和百分比設(shè)置支持。為消除這些差異，我們選擇采用 Yoga 作為布局引擎，而非使用鴻蒙原生提供的布局。Yoga 是 Facebook 開(kāi)發(fā)的開(kāi)源跨平臺(tái)布局引擎，實(shí)現(xiàn)了基于 Web 標(biāo)準(zhǔn)的 FlexBox 布局算法。使用 Yoga 可以很容易地實(shí)現(xiàn)對(duì)大部分 CSS 布局屬性的支持，讓兩端的差異縮小 。

在具體實(shí)現(xiàn)中，我們需要在構(gòu)建 Taro 節(jié)點(diǎn)樹(shù)的同時(shí)，構(gòu)建結(jié)構(gòu)一致的 Yoga 節(jié)點(diǎn)樹(shù)。

然后把原本直接設(shè)置到鴻蒙節(jié)點(diǎn)上的樣式屬性（如寬高、margin、padding、display 和 position）設(shè)置到 Yoga 節(jié)點(diǎn)上。經(jīng) Yoga 計(jì)算后，我們?cè)購(gòu)?Yoga 節(jié)點(diǎn)上讀取計(jì)算后的 width、height、x 和 y 值設(shè)置到鴻蒙節(jié)點(diǎn)上，從而實(shí)現(xiàn)鴻蒙端和 web 端的布局一致性。

通過(guò)使用 Yoga 作為布局引擎，我們不僅解決了鴻蒙系統(tǒng)與 Web 布局之間的差異，還提高了跨平臺(tái)一致性。這種方法使開(kāi)發(fā)者可以使用熟悉的 Web 布局概念，同時(shí)確保在鴻蒙平臺(tái)上獲得預(yù)期的布局效果。

樣式的工作流程

介紹完 Taro 適配 ArkUI 的 CAPI 樣式過(guò)程中遇到的問(wèn)題和對(duì)應(yīng)的解決策略之后，我們就可以來(lái)看看基于這些策略，鴻蒙樣式的整個(gè)工作流程是怎么樣的。

樣式初始化

首先，項(xiàng)目啟動(dòng)后，編譯器處理后的樣式文件將第一個(gè)被加載到運(yùn)行時(shí)環(huán)境。樣式處理邏輯會(huì)根據(jù)各個(gè)選擇器（selector）生成相應(yīng)的樣式規(guī)則（StyleRule），即 CSS 屬性的鍵值對(duì)集合。

根據(jù) ClassName 匹配 StyleRule

React 在構(gòu)建每個(gè)節(jié)點(diǎn)的同時(shí)，會(huì)通過(guò) Reconciler 把 React 節(jié)點(diǎn)的 ClassName 和 Style 設(shè)置到相應(yīng)的 Taro 節(jié)點(diǎn)上，這個(gè)時(shí)候我們就開(kāi)始進(jìn)入節(jié)點(diǎn)的樣式匹配環(huán)節(jié)。樣式處理會(huì)執(zhí)行以下步驟：首先，從 CSSStylesheet 這個(gè)樣式集合里識(shí)別出與 className 相關(guān)的所有 StyleRule；然后，根據(jù)選擇器的優(yōu)先級(jí)合并這些 StyleRule；最后，將合并結(jié)果與由 Style 生成的 StyleRule 合并，從而得出最終的樣式配置。

這里順帶提一下，CSS 除了可以書(shū)寫(xiě)樣式之外，還可以書(shū)寫(xiě)偽元素和關(guān)鍵幀動(dòng)畫(huà)，這兩者在都沒(méi)辦法直接設(shè)置到鴻蒙的樣式里，在處理某個(gè)節(jié)點(diǎn)時(shí)，如果匹配到這個(gè)節(jié)點(diǎn)的樣式里包含偽元素，就會(huì)把這個(gè)偽元素轉(zhuǎn)換成 一次 insertBefore api 的調(diào)用，用這個(gè)新 insert 進(jìn)去的子元素來(lái)承載偽元素的 StyleRule，舉一個(gè)例子，下面的 F 節(jié)點(diǎn)的 CSS 樣式里帶有一個(gè) ::after 的偽類(lèi)，那么當(dāng) F 節(jié)點(diǎn)匹配到這個(gè)樣式的時(shí)候，就會(huì)被插入一個(gè)子節(jié)點(diǎn)用來(lái)承載 ::after 對(duì)應(yīng)的樣式。

而對(duì)于匹配到關(guān)鍵幀的動(dòng)畫(huà)，會(huì)把動(dòng)畫(huà)對(duì)應(yīng)的元素，動(dòng)畫(huà)播放的次數(shù)、播放的方向、播放的緩動(dòng)函數(shù)收集起來(lái)放到另外的線程，由這個(gè)線程算出元素每一幀對(duì)應(yīng)的屬性值，并在元素當(dāng)前幀的 StyleRule 設(shè)置完之后，設(shè)置到節(jié)點(diǎn)上，保證動(dòng)畫(huà)的優(yōu)先級(jí)一定是最高的。

樣式的應(yīng)用

確定了節(jié)點(diǎn)對(duì)應(yīng)的樣式表后，我們就到了把樣式應(yīng)用到節(jié)點(diǎn)上這個(gè)環(huán)節(jié)了。這個(gè)環(huán)節(jié)我們會(huì)調(diào)用節(jié)點(diǎn)的 SetStyle 方法，遍歷 StyleRule 中的所有樣式。對(duì)于布局相關(guān)的屬性（如 display、position、float、flex、width、height、margin、padding），如需更新，會(huì)被設(shè)置到節(jié)點(diǎn)對(duì)應(yīng)的 Yoga 節(jié)點(diǎn)上，同時(shí)為節(jié)點(diǎn)本身添加 layout_dirty 標(biāo)記。接著，判斷是否有繪制相關(guān)的屬性需要更新，如果有，則設(shè)置到節(jié)點(diǎn)對(duì)象的臨時(shí)屬性上，并為節(jié)點(diǎn)添加 draw_dirty 標(biāo)記。這些被標(biāo)記的節(jié)點(diǎn)并不會(huì)立刻被處理，而是會(huì)被納入下一幀的樣式處理隊(duì)列中，這樣能避免同一幀多次設(shè)置同一個(gè)結(jié)點(diǎn)的相同屬性，確保樣式更新的高效性，同時(shí)也能保證布局屬性和繪制屬性設(shè)置到鴻蒙節(jié)點(diǎn)時(shí)的前后時(shí)序。

在標(biāo)記完所有需要更新的節(jié)點(diǎn)后，下一幀的樣式處理流程就會(huì)對(duì)這些節(jié)點(diǎn)進(jìn)行處理。首先，系統(tǒng)會(huì)調(diào)用 Yoga 的 calcYGLayout 函數(shù)，讓 Yoga 從根節(jié)點(diǎn)開(kāi)始對(duì)所有的 Yoga 節(jié)點(diǎn)進(jìn)行測(cè)算。在此過(guò)程中，布局信息發(fā)生改變的 Yoga 節(jié)點(diǎn)會(huì)被打上 has_new_layout 的標(biāo)記，節(jié)點(diǎn)上的信息也會(huì)被更新。

我們用一個(gè)例子來(lái)說(shuō)明Yoga如何判斷布局變化的影響范圍：假設(shè)節(jié)點(diǎn)E的寬度改變，這可能影響到依賴(lài)父元素寬度的子元素以及由子元素?fù)伍_(kāi)寬度的父元素。計(jì)算后，系統(tǒng)可能會(huì)更新A、B、C、E、F、H等節(jié)點(diǎn)。

測(cè)算完成后，我們遍歷Yoga節(jié)點(diǎn)樹(shù)，找出標(biāo)記為has_new_layout的節(jié)點(diǎn)，并將其width、height、x、y值更新到對(duì)應(yīng)的鴻蒙節(jié)點(diǎn)上。這樣，所有節(jié)點(diǎn)的布局信息就更新完畢了。

布局更新完成后，我們?cè)侔亚耙粠刑砑拥綐邮教幚黻?duì)列的節(jié)點(diǎn)拿出來(lái)。將存儲(chǔ)在節(jié)點(diǎn)臨時(shí)對(duì)象中的繪制屬性轉(zhuǎn)移到鴻蒙節(jié)點(diǎn)上。在這個(gè)環(huán)節(jié)里大多數(shù)繪制屬性可以直接設(shè)置，少量依賴(lài)節(jié)點(diǎn)布局信息的屬性（如百分比形式的 background-size）也可以利用新計(jì)算出的布局信息來(lái)準(zhǔn)確確定這些屬性的值。

樣式的更新

了解了初始化狀態(tài)的樣式工作流程后，我們?cè)倩剡^(guò)頭來(lái)看一下樣式更新部分的邏輯，在這一塊邏輯里，樣式的匹配和應(yīng)用與前面的流程沒(méi)有任何區(qū)別，所以只是簡(jiǎn)單介紹一下一個(gè)節(jié)點(diǎn)的樣式是怎么被更新的。

?Style更新

Style 的更新是相對(duì)比較好處理的一部分，因?yàn)?Style 的影響范圍只在節(jié)點(diǎn)的本身。當(dāng)元素的 Style 更新時(shí)，我們只需要重新生成對(duì)應(yīng)的 inline_style_，然后將其與通過(guò) className 生成的樣式進(jìn)行合并應(yīng)用即可。這個(gè)過(guò)程相對(duì)簡(jiǎn)單直接，因?yàn)椴恍枰紤]對(duì)其他元素的影響。通過(guò)這種方式，我們可以確保元素的樣式得到準(zhǔn)確更新，同時(shí)保持整體樣式系統(tǒng)的一致性和效率。

?ClassName更新

當(dāng)元素的 ClassName 更新時(shí)，我們需要執(zhí)行以下步驟來(lái)確保樣式正確應(yīng)用：

1.識(shí)別包含新 ClassName 的所有選擇器規(guī)則。

2.根據(jù) ClassName 在規(guī)則中的位置，確定需要重新進(jìn)行樣式匹配的元素：

?目標(biāo)元素選擇器：更新當(dāng)前節(jié)點(diǎn)

?直接后代選擇器：更新直接子節(jié)點(diǎn)

?后代選擇器：更新所有子孫節(jié)點(diǎn)

這些規(guī)則適用于 className 的增加、刪除、修改和查詢(xún)操作。對(duì)于 className 的修改，我們將其視為先刪除舊 className 再添加新 className，并執(zhí)行兩次規(guī)則匹配。

舉一個(gè)例子，當(dāng)樣式規(guī)則和元素結(jié)構(gòu)如下時(shí)：

.E .G {} .E .H {} .I > .J {} .I {}

為藍(lán)色的節(jié)點(diǎn)添加className I，為紅色的節(jié)點(diǎn)添加className E，那么需要要被更新的節(jié)點(diǎn)就有 F G H I J

在實(shí)際應(yīng)用中，我們還需考慮性能問(wèn)題。對(duì)于大型應(yīng)用或復(fù)雜的元素結(jié)構(gòu)，頻繁的樣式重計(jì)算可能會(huì)影響性能。因此，我們采取了一種優(yōu)化策略：找出需要更新的節(jié)點(diǎn)后，不會(huì)立即進(jìn)行樣式重匹配，而是將這些節(jié)點(diǎn)標(biāo)記為"臟"并放入更新隊(duì)列中。然后，我們?cè)谙乱粠y(tǒng)一完成所有樣式重匹配的工作。這種方法可以有效減少重復(fù)計(jì)算，提高整體性能。

總結(jié)

通過(guò)本文，我們?cè)敿?xì)闡述了Taro在處理CSS樣式與鴻蒙系統(tǒng)ArkUI框架之間差異的全流程。我們探討了樣式書(shū)寫(xiě)方式的不一致性、樣式匹配和應(yīng)用的復(fù)雜過(guò)程，以及樣式更新時(shí)的處理策略。這些功能和特性使得Taro能夠在保持跨平臺(tái)兼容性的同時(shí)，實(shí)現(xiàn)CSS樣式到鴻蒙系統(tǒng)的有效轉(zhuǎn)換。

作為開(kāi)發(fā)者，我們深知這個(gè)過(guò)程中面臨的挑戰(zhàn)，但也為最終取得的成果感到自豪。通過(guò)這種方法，我們?yōu)殚_(kāi)發(fā)者提供了一個(gè)統(tǒng)一且強(qiáng)大的多端開(kāi)發(fā)解決方案，使他們能夠更加高效地開(kāi)發(fā)跨平臺(tái)應(yīng)用。

我們相信，隨著技術(shù)的不斷進(jìn)步，未來(lái)還會(huì)出現(xiàn)更多的優(yōu)化空間。我們將繼續(xù)致力于改進(jìn)Taro的性能和兼容性，為開(kāi)發(fā)者提供更好的開(kāi)發(fā)體驗(yàn)。同時(shí)，我們也歡迎社區(qū)的反饋和貢獻(xiàn)，共同推動(dòng)Taro在多端開(kāi)發(fā)領(lǐng)域的發(fā)展。

系列往期精選：

《京東鴻蒙上線前瞻——使用 Taro 打造高性能原生應(yīng)用》

《Taro 鴻蒙技術(shù)內(nèi)幕系列（一）：如何將 React 代碼跑在 ArkUI 上》

審核編輯 黃宇