ArkUI 两种开发范式怎么选

小知识

很多人把 ArkUI 和 ArkTS 混为一谈。ArkUI 是方舟 UI 框架的名字，ArkTS 是它推荐使用的语言。前者是"用什么画界面"，后者是"用什么语言描述界面"。ArkUI 提供的是一整套基础设施——组件、布局、动画、交互事件、状态管理，还有实时预览工具。

一句话定位：ArkUI 是鸿蒙应用界面的完整技术底座，从界面语法到渲染管线都覆盖了。

两种开发范式

ArkUI 提供了两种写界面的方式，对应两拨不同背景的开发者。

维度	声明式开发范式	类 Web 开发范式
语言	ArkTS（TypeScript 扩展）	HML + CSS + JavaScript
写法	描述"界面应该是什么样"	三段式：结构 + 样式 + 逻辑
数据驱动	状态变量变化自动刷新 UI	单向数据绑定，数据变 UI 更新
渲染链路	更精简，无 JS 框架 DOM 管理	需要 JS 框架做页面 DOM 管理
内存占用	更少	更多
适用场景	复杂应用、新项目	界面简单的中小型应用、Web 开发转岗
演进趋势	主推，持续演进	兼容维护

两张图说明核心差异。声明式范式里，你写的是状态和结构，框架负责渲染；类 Web 范式里，你直接操作类似 DOM 的结构。

声明式开发范式：
  状态变量(@State) ──变化──> 框架感知 ──> 精确更新受影响的组件
  ├── 你写：UI 结构和状态
  └── 框架做：渲染、更新、生命周期

类 Web 开发范式：
  数据(JS) ──绑定──> HML 标签树 ──样式──> CSS 渲染
  ├── 你写：HML 结构 + CSS 样式 + JS 逻辑
  └── 框架做：DOM 构建、布局计算、事件分发

架构分层

两种范式共用一套 UI 后端引擎和语言运行时，这是理解 ArkUI 性能优势的关键。声明式范式省掉了类 Web 范式里 JS 框架做 DOM 管理这一步，所以渲染更新链路更短。

┌─────────────────────────────┐
│       声明式 UI 前端          │  ← 语言规范 + 内置组件/布局/动画 + 状态管理
├─────────────────────────────┤
│       语言运行时（方舟）       │  ← 范式语法解析、跨语言调用、TS 高性能运行
├─────────────────────────────┤
│     声明式 UI 后端引擎        │  ← C++ 构建：渲染管线、组件、布局、动效、事件、状态管理、绘制
├─────────────────────────────┤
│         渲染引擎             │  ← 把渲染指令绘制到屏幕
├─────────────────────────────┤
│        平台适配层            │  ← 抽象系统接口：渲染管线、生命周期调度
└─────────────────────────────┘

注意后端引擎是 C++ 写的。这意味着声明式语法在编译后，真正干活的是一套高性能的 C++ 组件和渲染管线，Java/TS 层只负责描述意图。这也是 ArkUI 性能优于类 Web 范式的底层原因。

应用模型与范式的匹配

不是所有场景都能任意选范式。要看应用模型（Stage 还是 FA）和页面形态（普通页面还是卡片）。

应用模型	页面形态	可用范式
Stage 模型（推荐）	应用/服务页面	声明式（推荐）
Stage 模型	卡片	声明式（推荐）+ 类 Web
FA 模型	应用/服务页面	声明式 + 类 Web
FA 模型	卡片	仅类 Web

新项目用 Stage 模型 + 声明式范式，这是官方主推路径。FA 模型是历史模型，只在迁移老项目时才会遇到。

声明式范式能做什么

从官方开发流程表能看出声明式范式的完整能力地图，按功能可归为八类：

1. 语言：ArkTS 基本语法、状态管理、渲染控制
2. 导航：页面路由（Navigation/NavDestination 栈式管理）
3. 布局：线性、层叠、弹性、相对、栅格，以及列表/宫格/轮播
4. 组件：文本、按钮、选择、弹窗、媒体展示等系统组件 + 自定义组件
5. 图形：图片显示、形状绘制、画布自定义绘制
6. 动画：属性动画、显式动画、自定义转场动画、动画 API
7. 交互：触摸/鼠标/键盘/焦点事件 + 单击/长按/拖动/捏合/旋转/滑动手势及组合手势
8. 自定义能力：自定义组合、自定义扩展（Modifier）、自定义节点（FrameNode/RenderNode/BuilderNode）、自定义渲染

三层自定义能力

ArkUI 的自定义能力是分层的，从下往上越来越底层，也越灵活：

自定义渲染       ← 最底层，完全接管绘制（XComponent/Canvas）
    ↑
自定义节点       ← FrameNode / RenderNode / BuilderNode，操作底层节点
    ↑
自定义扩展       ← Modifier，给组件扩展属性
    ↑
自定义组合       ← 最常用，把系统组件组合成自定义组件

大部分业务用"自定义组合"就够了——把几个系统组件包成一个 @Component，做成可复用单元。只有做特殊 UI 表现或需要底层渲染控制时，才往下走到 Modifier、FrameNode 甚至 NDK 构建 UI。

选型建议

给三条落地建议，对应三种情形：

1. 新项目：无脑选 Stage 模型 + 声明式范式。官方主推，性能好，未来能力持续演进。

2. 有 Web 前端背景、界面简单：可以用类 Web 范式快速上手，HML/CSS/JS 和 Web 三件套接近。但要知道这条路不是主推方向。

3. 需要底层渲染控制或已有 C/C++ 库：走 NDK 构建 UI，用 C/C++ 代码直接创建组件、操作 UI 树、设置属性和监听事件。

模拟器的能力边界

ArkUI 支持模拟器，但和真机有差异，主要是这几个组件/能力不支持：

• Image 的 enableAnalyzer（图像 AI 分析）
• @Preview 装饰器
• EmbeddedComponent 嵌入组件
• toolbar 属性
• restoreId 属性

涉及这些能力的功能，模拟器上验证不了，需要真机。开发时留意别在模拟器上白调试半天。