摘要

文章围绕 Taro 处理 CSS 样式与鸿蒙 ArkUI 框架差异展开，阐述了样式书写、布局差异，介绍工作流程包括初始化、匹配、应用、更新等，强调其成果与跨平台兼容性并展望未来。

一、背景

HarmonyOS 采用 ArkUI 框架，其标准与 W3C 的 CSS 标准不一致。若 Taro 直接使用 HarmonyOS 样式系统，会出现样式兼容性问题，影响跨平台兼容性，与 Taro 定位不符。所以抹平两者差异很重要。本文将介绍 Taro 处理 CSS 全流程，包括转换不同 CSS 样式为 ArkUI 样式的问题与解决方案。

二、CSS 样式和 ArkUI CAPI 样式的差异和抹平

（一）样式书写方式不一致

1. 单位与数据表示差异
   • CSS 和 ArkUI CAPI 写法不同，如单位系统和数据表示方式。CSS 尺寸和颜色单位多样，ArkUI 的 CAPI 接口更统一，尺寸统一为 vp 单位，颜色采用0xAARRGGBB格式的uint32类型，复杂样式属性转换方式也不同。
2. 转换方式
   • 页面样式多，运行时完成所有单位转换会有性能问题。HTML 节点样式源于 CSS 和 Style 属性。CSS 样式静态，可在编译阶段转换，基于lightningCSS开发Rust插件，遍历 CSS 抽象语法树（AST）转换为 ArkUI 的 CAPI 接口可用数据结构。
   • 对于Style属性，运行时确定内容，需在运行时转换。在React语法中，Style有多种形式，针对各种 CSS 语法写小型解析逻辑，从不同格式字符串中匹配属性值转换。虽然运行时解析，但Style属性样式有限且C ++执行高效，对性能影响可忽略，还能为支持 CSS 变量提供能力。

（二）布局存在差异

1. 定位与功能差异
   • ArkUI 布局属性行为和 W3C 布局属性有差异，如绝对定位参考对象、居中方式不同，ArkUI 的 CAPI 接口缺少 Web 常用功能。
2. 解决方案
   • 采用Yoga作为布局引擎（Facebook开发的开源跨平台布局引擎），构建 Taro 节点树时构建结构一致的Yoga节点树，把部分样式属性设置到Yoga节点上，经Yoga计算后将结果设置到鸿蒙节点上，解决布局差异并提高跨平台一致性。

三、样式的工作流程

（一）样式初始化

项目启动后，编译器处理后的样式文件首先加载到运行时环境，样式处理逻辑根据选择器生成样式规则（StyleRule）。

（二）根据 ClassName 匹配 StyleRule

1. 匹配步骤
   • React构建节点时设置ClassName和Style到 Taro 节点，样式处理会识别与className相关的StyleRule，根据优先级合并，再与Style生成的StyleRule合并得出最终样式配置。
2. 特殊样式处理
   • CSS 中的伪元素和关键帧动画不能直接设置到鸿蒙样式。匹配到伪元素时，转换为insertBefore API 调用，插入子元素承载样式；匹配到关键帧动画，收集相关信息到另一线程计算每一帧属性值，在元素当前帧StyleRule设置完后设置到节点上保证动画优先级最高。

（三）样式的应用

1. 设置样式属性
   • 确定节点样式表后，调用节点SetStyle方法遍历StyleRule。布局相关属性更新时设置到Yoga节点并标记layout_dirty，绘制相关属性更新时设置到节点临时属性并标记draw_dirty，这些节点纳入下一帧样式处理队列。
2. 更新节点布局和绘制属性
   • 下一帧样式处理时，调用Yoga的calcYGLayout函数测算Yoga节点，布局信息改变的节点标记has_new_layout并更新信息，遍历Yoga节点树找出标记节点更新鸿蒙节点布局信息，再处理前一帧样式处理队列中的节点，将绘制属性转移到鸿蒙节点上。

（四）样式的更新

1. Style 更新
   • Style更新时，重新生成inline_style_并与className生成的样式合并应用，因为Style只影响节点本身，过程相对简单。
2. ClassName 更新
   • ClassName更新时，识别包含新ClassName的选择器规则，根据ClassName在规则中的位置确定需重新样式匹配的元素，如目标元素、直接后代、所有子孙节点等，对于className修改视为先删旧再添新并执行两次规则匹配。还考虑性能问题，找出需更新节点后标记为“脏”放入更新队列，下一帧统一完成样式重匹配。

四、总结

详细阐述 Taro 处理 CSS 样式与鸿蒙系统 ArkUI 框架差异全流程，包括样式书写、匹配应用、更新策略等，实现跨平台兼容性和 CSS 样式到鸿蒙系统的有效转换，还展望了 Taro 未来发展方向。