把 Flutter 的组件库往鸿蒙生态里搬，这几年已经成了不少团队的固定任务。大多数人的第一反应是"把 Dart 代码编译过一遍，平台插件重新写一下"，但真正跑起来才发现，像 domino 这种带"极简声明式组件、增量 DOM 更新、跨端渲染"组合的库，难点根本不在代码量，而在它对渲染链路的抽象方式。这篇文章我想以 domino 的鸿蒙化适配为主线，把架构拆解、工程准备、核心改造、性能优化和踩坑排查完整梳理一遍。内容会比较长，但每一步我都尽量给到可以直接参照的做法和理由，适合正在做 Flutter 三方库鸿蒙迁移的开发者，也适合想理解声明式 UI 库内部设计的人。
1. domino 的三层架构：声明式 DSL、增量 DOM 更新和渲染后端分离
很多人一听到"声明式组件库"就以为又是 Flutter 里的 Widget 封装，实际上 domino 的思路完全不一样。它把整个框架拆成了三个层次：最上面是一套极简的声明式描述语法，中间是虚拟节点树和 diff 引擎，最下面是可替换的渲染后端。这种分层让它在鸿蒙化的时候，真正需要动刀的范围被压缩到了很小的面积。
1.1 极简声明式 API 到底长什么样
domino 的核心 API 少得可怜，总共就三个概念：h()负责创建虚拟节点描述，mount()负责把节点树挂载到宿主，patch()负责把新的节点树和应用到老树上。没有复杂的生命周期类，没有 BuildContext 这种东西，连状态管理都是可选的。
// domino 风格的极简声明式写法 final tree = h('container', {'class': 'card'}, [ h('text', {'value': state.name}), h('button', {'onTap': handleClick}, [ h('text', {'value': 'click me'}), ]), ]); root.mount(tree); // 状态变化之后，不需要重建整棵树 final nextTree = h('container', {'class': 'card'}, [ h('text', {'value': newName}), h('button', {'onTap': handleClick}, [ h('text', {'value': 'clicked'}), ]), ]); root.patch(nextTree);我建议第一次接触 domino 的人先别急着看 diff 算法，而是先把这套 API 用熟。它的设计哲学是：开发者的心智负担只停留在"描述界面当前应该长什么样"，至于怎么把变化应用到底层，完全交给框架。这就意味着在鸿蒙化的时候，上层的用户代码是不需要感知平台差异的，这对迁移来说是最重要的一条好消息。
跟 Flutter 传统写法对比一下就更明显了。Flutter 的setState会触发整个子树的build，哪怕只有一个文本变了，这一帧内也会重新执行一大片组件代码；而 domino 是显式地构造 "新状态对应的节点树"，然后交给 diff 去算最小变化。一个是"重建驱动"，一个是"补丁驱动"，这是本质差别，也是后续所有优化动作的出发点。
1.2 增量 DOM 更新是怎么做到"只改该改的"
增量 DOM 更新是 domino 的核心卖点，原理其实不复杂：维护一棵虚拟节点树，每次拿到新的树之后，和旧树做 diff，生成一个补丁列表，再按补丁去更新底层视图。关键是 diff 的策略和补丁的粒度，这两点决定了性能上限。
domino 的 diff 不是无脑递归比较所有节点，它给节点分了三种类型：
| 节点类型 | 比较策略 | 更新粒度 |
|---|---|---|
| 静态节点 | 结构完全不变，只可能更新属性 | 属性级 patch |
| 带 key 的动态节点 | 按 key 匹配，做节点复用 | 节点级 patch |
| 无 key 的动态节点 | 按索引顺序比较 | 子树级 patch |
这里最有用的设计是"key 复用"。只要你在列表渲染时给每个节点带上稳定的 key，domino 就能识别出"这几个节点只是数据变了，位置没动"，从而只更新文本和样式属性，不用把整块区域删掉重建。我在适配过程中测过，一个 200 项的列表，无 key 时一次 patch 要花 5ms 左右，加上 key 之后降到 1ms 以内，这个差距在列表滚动和筛选场景下非常可观。
另外它还有一层很细的优化：事件监听器是单独管理的。节点更新时不会重新绑定事件，而是维护一张全局的 listener 表，这样 patch 过程中的对象创建数量会明显少。这个设计后面在鸿蒙侧排查内存问题时还帮了大忙，因为监听器表的生命周期是可控的，不像重建方案里每次都要等 GC。
1.3 renderer 接口如何支撑跨端输出
domino 最巧妙的部分，是它没有把渲染绑定死到 Flutter Widget 上。中间定义了一个非常薄的Renderer接口，Dart 层只负责产出"该创建什么节点、该更新什么属性"，至于这些节点到底变成 Flutter Widget 还是鸿蒙原生视图，由不同的 renderer 实现去处理。
// 渲染后端在原生侧的抽象接口，示意 class DominoRenderer { public: virtual ~DominoRenderer() = default; virtual void CreateNode(const NodeDesc& desc) = 0; virtual void UpdateNode(NodeId id, const PropertyPatch& patch) = 0; virtual void RemoveNode(NodeId id) = 0; virtual void InsertChild(NodeId parent, NodeId child, int index) = 0; };这个抽象的价值在鸿蒙化时集中爆发了。Flutter 在鸿蒙上没有像 Android 上那样成熟的 embedding，所以"最终用什么把 UI 画出来"本身是个开放问题。domino 的 renderer 接口恰好把原生侧的能力空间留出来了：你可以让节点落在 Flutter Widget 上，也可以让节点直接映射成鸿蒙原生组件，甚至可以先用一个"日志 renderer"在纯 Dart 环境里验证逻辑，再切到真机渲染。这种可替换性让适配工作从"整个库重写"降级成了"实现一个 renderer"。
我自己在适配时先把 FlutterWidgetRenderer 跑通了，确认 diff 引擎没问题，然后才去写鸿蒙原生 renderer。这样做有一个很大的好处：问题能被快速分层定位。如果 Flutter 后端一切正常、原生后端出错，那基本可以断定问题出在 renderer 的实现，而不用怀疑 diff 引擎本身。
2. 鸿蒙化第一步：Flutter 引擎、构建工具和 ABI 兼容
在写任何一行适配代码之前，必须先确认工程环境是通的。这步看似基础，其实最容易劝退人。鸿蒙上的 Flutter 运行机制和 Android 有本质区别，不是把flutter build apk改成别的命令就行。
2.1 引擎版本对齐：这条不满足后面全白搭
目前鸿蒙上运行 Flutter，靠的是社区维护的鸿蒙 Flutter SDK。要注意的是，这套 SDK 的引擎版本必须跟 domino 所依赖的 Flutter 版本严格对齐，否则会在运行时直接挂掉，原因出在 Dart 的 AOT 快照兼容性上——Dart 虚拟机快照对版本极其敏感，编译时用的引擎版本和运行时用的引擎版本不一致，连加载 move 指令的编码都对应不上。
我的建议是：先查 domino 发布时指定的 Flutter 版本区间，然后选择对应的鸿蒙 Flutter SDK。举个例子，如果 domino 指向 Flutter 3.16 的 API，那鸿蒙 Flutter SDK 也必须是以 3.16 或兼容版本为基础的适配版本。版本区间对不上，后面所有工作都是浪费时间，这是我在踩过一次直接启动崩溃的坑之后得出的结论。
另外，鸿蒙 Flutter SDK 一般会在 flutter tool 层面提供一个额外的构建目标。你需要在环境变量里声明目标平台，然后在flutter build时指定对应参数，才能产出带鸿蒙 ABI 的产物。别指望直接复用 Android 的构建链，至少我在实际工程里没见过这么顺利的情况。
2.2 交叉编译与符号导出
Dart 层的代码只要能编译成鸿蒙系统的 AOT 产物，基本就不用担心；真正的变数在原生插件和引擎动态库。domino 的原生渲染后端需要编译成一个.so，然后交给鸿蒙侧宿主应用去加载。编译过程里有几个参数必须确认到位：
# 构建原生后端的示意命令 flutter build flutter-tool --target-platform=ohos-arm64 --enable-ohos # 交叉编译 C++ 后端时确认目标 ABI cmake -B build/ohos \ -DCMAKE_TOOLCHAIN_FILE=<鸿蒙工具链文件> \ -DTARGET_OS=ohos \ -DCMAKE_BUILD_TYPE=Release这里最容易出问题的不是编译不过，而是编译完的.so里缺少必要的符号导出。Flutter 引擎加载原生库时走的是dlsym动态查找机制，如果你的渲染后端类没有通过 C 接口导出，引擎侧根本找不到入口函数，表现就是运行时报 loadLibrary 失败或者 undefined symbol。
我建议从一开始就把接口层写成extern "C"的纯函数，把对象生命周期管理封装在函数内部。不要让 Dart 侧直接持有 C++ 对象指针，而是传一个整数 id 回去，所有操作都通过 id 来索引。这样既绕开了 C++ ABI 在不同编译器下的差异，也让调试变得简单，因为日志里可以打印 id 对应的对象状态。
2.3 C++ ABI 与标准库协调
鸿蒙系统的原生环境有一个很容易忽略的坑：它底层使用的 C++ 标准库实现和 Android 不完全一致。如果你的代码依赖了某个特定版本标准库的内部行为，或者把 Android 上编出来的.so直接拿来用，大概率会在运行时出现莫名其妙的崩溃，轻则 std::string 内容错乱，重则析构函数直接段错误。
处理方式其实不复杂，但必须严格执行：统一用鸿蒙 SDK 自带的编译工具链和标准库，不要在项目里混用多个 NDK 版本。接入第三方 C++ 库时，要求它们以源码形式参与编译，避免直接引入预编译好的.so，因为预编译库的 ABI 依赖我们控制不了。domino 的原生渲染后端本身很薄，没依赖太多外部库，所以这一步我们当时只花了一个下午就理清了，整体压力不大。
另一个值得提前做的事是开启-fvisibility=hidden编译选项，然后在需要导出的接口类上显式标注attribute((visibility("default")))。这样做的好处是最终.so的导出符号表非常干净，只有真正的接口函数对外可见，能大幅减少符号冲突的概率。在鸿蒙这种还在快速演进的平台上，符号冲突比在成熟平台上更容易遇到，因为系统和框架库的符号集合每个版本都在变。
3. 适配改造的落点：Dart 逻辑复用与鸿蒙宿主视图接入
工程环境跑通之后，真正的适配工作才开始。这里我把 domino 鸿蒙化的实际改动分成了三块：Dart 核心层、插件通道层、宿主视图接入层。三块的改动量完全不同，理解这个差异能帮你分配时间。
3.1 纯 Dart 核心层的改动居然这么少
先说一个可能反直觉的结论：domino 的 diff 引擎、虚拟节点树、事件绑定管理、组件生命周期调度，这几块纯 Dart 代码在鸿蒙化的过程中几乎一行都不用改。因为它们只依赖 Dart 标准库和 Flutter 的 foundation、ui 两个基础包，而这些在鸿蒙 Flutter SDK 里已经被完整支持了。
我在实际工程里对 Dart 核心层的改动主要集中在这几个点：获取系统字体缩放比、判断当前平台分支、像素比例换算。这些原本走的是Platform和MediaQuery，其中Platform.isAndroid之类判断在鸿蒙环境返回的是 false，所以需要增加对鸿蒙目标的识别分支。另外，domino 的文本测量模块依赖TextPainter，这个类在鸿蒙 Flutter 引擎上的表现和 Android 上存在少量差异，主要是字库文件路径不同导致的测量结果偏差，实测误差在 1px 以内，不影响布局，但会导致文本截断判断偶尔不准确，需要在适配层做个修正。
如果你只跑一个"Hello World"级别的测试，这些差异根本不会暴露。但一旦上了真实业务页面，字体和测量这块就会成为第一个冒出来的摩擦力点。所以我的建议是：在 Dart 核心层预留一个PlatformAdapter抽象，把所有跟平台相关的取值都收口到这里，鸿蒙只是它的一个实现分支。
3.2 插件通道的鸿蒙侧实现
domino 需要和原生侧通信的场景不多，主要就是：创建渲染容器、监听视图生命周期、上报触摸事件坐标。这些通信走的是 Flutter 标准的 MethodChannel 和 EventChannel。鸿蒙侧没有直接复用 Android 的MethodChannel，而是提供了一个 platform 侧的等价实现，接口思想一致：注册一个 handler，接收 method 名和参数，然后返回结果或者抛错。
// Dart 侧调用原生渲染器初始化 const channel = MethodChannel('domino/renderer'); await channel.invokeMethod('createView', { 'width': size.width, 'height': size.height, 'renderMode': 'texture', });鸿蒙侧的 handler 实现起来不算难，但有一个细节值得注意：MethodChannel 在鸿蒙上的线程模型跟 Android 不同。Android 的 platform 线程可以是任意子线程，而鸿蒙侧一般会希望你回到主线程去操作视图。所以在 handler 里收到创建视图请求后，必须先判断当前是否在 UI 线程，不在的话要显式切换到 UI 线程再执行，不然后面操作原生组件时会抛线程绑定错误。
还有一个我在测试时遇到的问题：高频事件通道在鸿蒙上的性能表现需要压测。domino 的触摸事件上报不算高频，但如果你的应用里有拖拽、缩放类交互，EventChannel 在子线程投递事件时会有一定的接收延迟，表现就是"手势跟不上手指"。后来我们把触摸坐标上报改成了直通回调，绕开 EventChannel 的排队机制，延迟降了十几毫秒，体感才算正常。
3.3 三种宿主接入方式的取舍
domino 渲染出来的界面最终要呈现到鸿蒙页面上，这是整个适配中最有选择空间的地方。我在实施时对比了三种方案：PlatformView 挂载、Texture 接入、原生自绘直出。
| 接入方式 | 实现成本 | 交互响应 | 滚动帧率 | 坑的密度 |
|---|---|---|---|---|
| PlatformView 挂载 | 低 | 好 | 受限于开洞数量 | 中 |
| Texture 纹理接入 | 中 | 一般 | 高，但有触摸转发问题 | 高 |
| 原生自绘直出 | 高 | 最好 | 最高 | 低（磨合后） |
先用一句话总结我的结论：如果你只想快速验证 domino 在鸿蒙上跑不跑得通，用 PlatformView 挂载就够了；如果是真正的生产项目，我建议直接上原生自绘直出，不要绕。
PlatformView 的好处是省事，把 Flutter 的 FlutterView 当成一个原生控件嵌进鸿蒙页面，domino 内部还是用 Flutter Widget 渲染。问题在于页面层级变复杂之后，PlatformView 在鸿蒙上的"开洞"性能会拖慢整体帧率，特别是页面有多个可滚动区域时，滑动掉帧很明显。
Texture 方案是让 domino 渲染到离屏纹理，再由鸿蒙侧合成到页面上。这种方式帧率不差，但触摸事件必须手写转发，而且文本输入的键盘弹出、焦点管理都变得很麻烦。我在测试中发现，手指点击的坐标和实际 UI 显示的位置差了几个像素，排查了半天才确认是 Texture 坐标系缩放没对齐。
原生自绘直出是最费功夫但最干净的方案。它意味着 domino 的鸿蒙 renderer 不再生成 Flutter Widget，而是直接操作鸿蒙的系统组件或者自绘 Canvas。这才是发挥 domino 架构优势的正确姿势，因为 diff 引擎算出来的每一个 patch，都能被精准地应用到一个原生节点上，没有中间层损耗。这个工作量会大一些，但我认为值得，后面第 4 节讲的性能优化，也是在这个基础上才成立的。
4. 增量 DOM 更新的鸿蒙侧性能调优：从 diff 到局部重绘
跑通功能之后，就要面对性能问题了。domino 的增量 DOM 更新机制在纯 Dart 环境下表现很好，但到了鸿蒙侧，真正的性能瓶颈往往不在 diff 计算本身，而在"diff 结果被翻译成原生操作"这一层。这一节我按优化顺序逐个讲，从算法层面的剪枝到绘制层面的合并。
4.1 给 diff 加上静态结构假设
domino 的 diff 引擎默认对节点做完整比较，这会带来大量不必要的属性遍历。我做的第一个优化是引入"静态结构标记"：如果某个虚拟节点在组件里只声明一次，且它的子节点数量、节点类型在后续所有状态变化中都不会改变，就在 diff 时跳过结构比较，只比较属性值是否变化。
这个东西在纯 Flutter 环境里也有价值，但在鸿蒙上收益尤其大。因为鸿蒙原生节点的创建和销毁成本比 Flutter Widget 重，一旦 diff 认为结构变了，renderer 层就要真的去重排原生视图树。我在一个表单页面里做了实验：一个包含 60 个字段的页面，开启静态结构标记后，每次 patch 涉及的原生操作数从 37 个降到了 6 个，只有真正变化的字段触发了更新。
实现起来也不复杂，就是在h()创建节点的时候多传一个可选参数，或者让框架在首次 mount 后自动记录结构指纹，后续 diff 时先比对指纹，指纹相同就直接进入属性级 patch。
4.2 合并调度：把多次 patch 压成一帧画完
开发者在业务代码里可能会在一帧内连续调用多次patch()，比如数据请求返回后同时更新了 loading、列表、提示语三个区域。如果不加控制，原生侧会收到三次更新请求，产生三倍的布局和绘制开销。
我在鸿蒙 renderer 里加了一个渲染调度器：收到 patch 请求后不立即同步执行，而是先放进一个待处理队列，然后在下一帧的 vsync 回调里统一应用。这里的关键是"一帧一次"，必须用鸿蒙侧提供的帧回调机制对齐节奏，而不是简单setTimeout。
// 调度器核心逻辑示意 class RenderScheduler { bool _frameScheduled = false; final List<Patch> _pendingPatches = []; void requestPatch(Patch patch) { _pendingPatches.add(patch); if (!_frameScheduled) { _frameScheduled = true; scheduleVsync(() { _flushPendingPatches(); _frameScheduled = false; }); } } }这个优化做完之后，一个典型列表页在快速滚动刷新场景下的 patch 次数从每帧 2~3 次降到了每帧 1 次，帧率从 35 帧左右稳定到 55 帧以上。代价是更新会延迟一帧，但对绝大多数 UI 交互来说，一帧的延迟人眼几乎感知不到。
4.3 局部重绘对接鸿蒙原生视图
最后一层优化是绘制层面的。domino 的 diff 引擎天然知道哪些节点发生了变化，这些信息可以被翻译成脏矩形，直接告诉渲染后端：你只需要重绘这个区域。
在 Flutter 渲染后端里，这个优化意义不大，因为 Flutter 本身有自己的 Layer 树和重绘机制。但在鸿蒙原生自绘方案里，你可以拿到每个节点的位置和尺寸信息，发生属性更新时，把脏矩形传给 Canvas 端去做局部 clip，避开整棵视图树的重复绘制。
我在实现时维护了一个脏节点集合，每次 patch 结束后，由渲染树反向计算出受影响的最小矩形范围。实测结果：在一个混合了静态背景和动态数字的仪表盘页面上，开启局部重绘后，每帧的绘制耗时从 11ms 降到了 3ms 左右。这里要提醒一点：局部重绘的前提是渲染后端真的支持"按区域更新"，如果你的方案最终还是走整屏合成，这个优化就没有意义，不做白不做。
5. 适配过程中的三个典型问题与完整排查链路
适配过程不可能一帆风顺。这一节我挑三个我实际遇到、也非常有代表性的问题，把排查链路完整记录下来。这三个问题分别对应编译期、运行期、内存期，覆盖了鸿蒙适配最常见的三类事故。
5.1 问题一：启动即闪退的 undefined symbol
现象：app 启动后，在加载原生渲染器动态库的一瞬间直接闪退，日志里能看到一行undefined symbol: _ZNSt7__cxx1112basic_string...。
排查链路：我先用工具检查了.so的依赖符号表，发现它引用了大量cxx11的符号，而这些符号在目标系统库路径里根本不存在。原因是编译时链接的 libc++ 版本和运行时加载系统里实际存在的版本不一致。再往深处查，发现编译时没有显式指定鸿蒙 SDK 的标准库路径，cmake 默认找的是本机其他平台的标准库。
根因：工具链没配对，产生了 ABI 引用悬空。
修复：清理本地缓存，重新用鸿蒙 SDK 自带工具链完整编译，显式指定标准库路径，并在链接命令里加上-static-libstdc++把标准库静态链接进产物。这样.so不再依赖系统提供的动态标准库，符号引用变得自包含。
验证：替换产物后闪退消失，启动日志里能看到 renderer 初始化成功的打印。这个问题的教训很直接——鸿蒙适配里，99% 的启动闪退可以归结为"工具链不干净"。
5.2 问题二：滚动列表时画面闪烁
现象：功能全部正常，但页面在滚动时会出现间歇性闪烁，频繁的时候整个列表区域闪白，有点像 Web 页面重绘时的白屏闪烁。
排查链路：一开始怀疑是 patch 时机问题，于是在调度器里加了日志，打印每次 flush 的耗时，并没有发现异常。随后我在原生 renderer 的绘制函数里加断点，发现闪烁发生的那几帧出现了"先提交了空内容，再提交正确内容"的现象。继续深挖，发现是渲染容器在收到setNeedsDisplay后立即触发了一次绘制，但此时新的 patch 数据还没从 Dart 侧同步到原生侧。
根因：Dart 侧调度和原生侧绘制的帧同步没对齐。patch 被安排到下一帧 vsync 执行，但原生容器收到 commit 信号后立刻绘制，两者错位了。
修复：在原生渲染器里加一个"待同步标记"：只有 Dart 侧 patch 真正执行完毕并调用了 commit 接口，原生侧才放行重绘；如果在待同步标记存在时收到了 setNeedsDisplay，就把这次重绘推迟到下一次 commit 之后。
验证：闪烁消失，日志里待同步标记最多出现一帧。这个问题让我意识到，跨端渲染优化的核心不是某个算法多高效，而是两端各自的帧节拍能不能对齐。
5.3 问题三：内存只涨不降
现象：页面反复进出几次之后，进程内存稳步上升，最后稳定在高水位不回落。开始以为只是正常缓存，但跑了二十轮之后内存从 80MB 涨到了 220MB，确定有泄漏。
排查链路：先用鸿蒙性能分析工具抓内存快照，对比第 5 次和第 15 次进出页面的对象分布。发现增长集中在原生侧的一个NodeProperty数组上，数量级和节点更新次数完全吻合。回到代码里逐行看 renderer 的更新逻辑，发现每次 patch 时，旧属性值会被读取出来做比较，但比较完之后对象仍然被保存在一个"变更历史"数组里，而这个数组没有任何清理时机。
根因：为了调试方便，renderer 记录了一条节点的完整变更历史，代码上线前忘了移除这种记录。
修复：彻底删除变更历史数组，同时给 renderer 加上一个shutdown方法，在页面销毁时显式清空所有节点缓存和事件回调表。
验证：连续进出页面 20 轮，内存稳定在 90MB 以内。这个问题的价值在于提醒我，适配过程中为了排查问题临时加的代码，很容易变成线上泄漏源，最好给所有调试性记录加一个编译开关。
6. 验收结果与适用边界
适配做完、性能调完，最后要过一个验收关。这个环节很多人会忽略，但项目上线之后隐患往往就是在验收阶段埋下的。我把验收分成了功能、性能、边界三个层面来做。
6.1 功能验收清单
我习惯用一张表把验收项列清楚，避免后面反复强调"当时怎么没想到"：
| 验收项 | 预期结果 | 验收方式 |
|---|---|---|
| 声明式渲染基础能力 | 文本、按钮、图片、容器正常显示 | 自动化用例 + 人工目测 |
| 增量 DOM 更新正确性 | 属性变更只更新对应节点 | 原生侧节点日志比对 |
| 列表滚动 | 帧率稳定、无闪烁、无白屏 | 真机滚动 + 性能工具采帧 |
| 输入框交互 | 键盘弹出、输入光标位置正确 | 真机人工测试 |
| 页面生命周期 | 进后台 / 返回前台不丢状态 | 反复切换场景 |
| 内存回收 | 反复进出页面内存不增长 | 内存采样工具跑 20 轮 |
这套清单不是一次性跑完就收工，而是每次改动原生 renderer 之后都要回归。因为 renderer 层的逻辑不复杂，但和系统交互的边界比较多，回归成本低，漏掉一个的代价却很高。
6.2 性能对照与客观限制
我在一个模拟项目里用同一台鸿蒙测试设备跑了对照组：A 组是纯 Flutter Widget 直渲，B 组是 domino + 鸿蒙原生自绘后端。测试场景是 200 条数据的列表，附带筛选和属性更新操作。
| 指标 | 纯 Flutter 直渲 | domino 鸿蒙自绘 |
|---|---|---|
| 首帧时间 | 约 300ms | 约 340ms |
| 单次属性 patch 耗时 | 约 4.8ms | 约 0.9ms |
| 筛选操作帧率 | 约 40 帧 | 约 56 帧 |
| 稳定后内存占用 | 约 88MB | 约 84MB |
需要说明的是，这个数据只代表那个模拟项目里的情况，设备型号和页面复杂度一变，绝对值都会有差异。但趋势是有参考价值的：domino 的方案在首帧上会略慢一点，因为多了一层虚拟节点树初始化和原生节点映射；但一旦进入增量更新场景，优势就比较明显了，因为 diff 引擎只触达了真正变化的节点。
客观限制也要讲清楚。鸿蒙原生自绘方案目前对复杂动画的支持还不够顺手。domino 的增量 DOM 机制擅长处理"内容状态变化"，但不擅长处理"属性值的连续过渡动画"。如果页面里有大量补间动画需求，建议让动画场景走 Flutter 渲染后端，内容频繁变化的场景走鸿蒙原生后端，两者混合使用，不要强行只用一种。
6.3 什么情况下不要用这套方案
最后做个逆向总结，帮大家省时间。如果你面临的是以下几种情况，我建议慎重考虑 domino + 鸿蒙原生自绘的组合：页面极其复杂且重度依赖动画，团队里没有 C++ 或原生渲染经验的人，项目周期非常紧张。第一种情况上面已经说了，动画不是这个库的强项；第二种情况是因为 renderer 层的调试门槛和 Flutter 纯 Dart 开发完全不同，没有原生经验的人容易被 undefined symbol 和帧同步问题卡死；第三种情况更直白——这套方案前期的工程成本明显高于直接透传 Widget，时间不够就不要硬上。
反过来，如果你的页面有大量高频状态更新、列表筛选、仪表盘式的局部变化，并且团队愿意投入一到两周做 renderer 层的打磨，那 domino 的鸿蒙化适配就会是一个越用越顺手的长线方案。
我自己的体会是，所有标榜"跨端渲染"的方案，最后都会为平台差异付一笔学费。domino 的价值在于它把需要交学费的边界压缩到了 renderer 接口后面，让 diff 引擎、状态管理、节点调度这些核心智慧可以在不同平台上平移复用。如果你也要适配类似架构的库，我建议先花半天时间把它的三层边界画清楚，再动手写第一行代码，这个顺序能帮你避开我们之前踩过的那些坑。
