传统 App 与鸿蒙 ArkUI：UI 架构差异解析

子玥酱（掘金 / 知乎 / ZEEKLOG / 简书 同名）

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、ZEEKLOG、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕 前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读 展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取 11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

文章目录

• 引言
• 传统 App 的 UI 架构是怎样的
  • 页面是 UI 的核心容器
• ArkUI 的 UI 架构为什么不同
  • ArkUI 页面其实是一个组件
  • 状态管理方式的差异
  • ArkUI 响应式状态
• 传统 UI 更新 vs ArkUI 更新
• 组件复用方式的差异
• UI 布局思想的差异
• 跨设备 UI 是最大不同
  • ArkUI 响应式布局示例
• 分布式 UI 是鸿蒙最大的不同
• 对开发者意味着什么
  • 第一 页面思维 → 组件思维
  • 第二 生命周期思维 → 状态思维
  • 第三 单设备 UI → 分布式 UI
• 总结

引言

如果你过去做过 iOS、Android 或 Flutter 开发，大概率已经形成了一套非常熟悉的 UI 架构思维：

• 页面（Page / ViewController）
• 组件（View / Widget）
• 状态（State）
• 路由（Router）

换句话说，大多数传统 App 的 UI 架构，其实都围绕一个核心展开：

页面（Page）

页面负责：

• 承载 UI
• 管理状态
• 响应用户事件
• 调用业务逻辑

但当开发者开始接触 鸿蒙 ArkUI 时，很快会发现一件事情：

ArkUI 的 UI 架构思维，并不是传统 App 那一套。

很多 iOS / Android 开发者第一次写 ArkUI 时都会有一种感觉：

• UI 写法很像 SwiftUI / Compose
• 但系统结构又完全不同
• 页面概念似乎被“弱化”了

这背后的原因，其实是：

鸿蒙 UI 架构从一开始就不是为“单设备 App”设计的。

而是为 分布式系统 UI 设计的。

传统 App 的 UI 架构是怎样的

在理解 ArkUI 之前，我们先看传统 App 的 UI 结构。几乎所有移动 App 都遵循类似结构：

App ├── Tab │ ├── Page │ │ ├── View │ │ ├── View │ │ └── View │ └── Page └── Page 

典型流程是：

用户 → 打开 App → 进入页面 → 与组件交互

核心结构就是：

页面 → 组件 → 状态

页面是 UI 的核心容器

在 iOS 中，一个页面通常就是一个 UIViewController：

classArticleViewController:UIViewController{overridefuncviewDidLoad(){super.viewDidLoad()let label =UILabel() label.text ="Hello iOS" view.addSubview(label)}}

在 Android 中：

class ArticleActivity :AppCompatActivity(){overridefunonCreate(savedInstanceState: Bundle?){super.onCreate(savedInstanceState)setContentView(R.layout.activity_article)}}

在 Flutter 中：

classArticlePageextendsStatelessWidget{@overrideWidgetbuild(BuildContext context){returnScaffold( body:Text("Hello Flutter"),);}}

这些 UI 框架虽然写法不同，但核心思想是一致的：

UI 必须挂在页面下面。

页面是：

• 生命周期中心
• 状态中心
• UI 渲染中心

ArkUI 的 UI 架构为什么不同

在 ArkUI 中，你很少看到：

• Activity
• ViewController
• Fragment

ArkUI 的核心不是“页面类”，而是：

组件（Component）

页面只是一个 组件入口。

ArkUI 页面其实是一个组件

例如一个简单 ArkUI 页面：

@Entry@Component struct HomePage {build(){Column(){Text("Hello ArkUI").fontSize(24)Button("点击")}}}

这里看起来像是“页面”，但实际上：

HomePage └── Column ├── Text └── Button 

ArkUI 的 UI 本质是：

组件树（Component Tree）

而不是页面树。

状态管理方式的差异

传统 App 的状态通常放在：

• ViewController
• ViewModel
• Bloc
• Store

但 ArkUI 更强调：

响应式状态

ArkUI 响应式状态

@Entry@Component struct CounterPage {@State count:number=0build(){Column(){Text(`Count: ${this.count}`).fontSize(30)Button("增加").onClick(()=>{this.count++})}}}

这里有一个关键变化：

状态变化 → UI 自动更新 

开发者不需要：

• 手动刷新 UI
• 通知 View
• 调用 setState

ArkUI 会自动完成。

传统 UI 更新 vs ArkUI 更新

传统 UI 更新逻辑：

用户点击 ↓ 修改状态 ↓ 通知 UI 更新 ↓ 重新渲染 

例如 Flutter：

setState((){ count++;});

而 ArkUI：

this.count++

ArkUI 会自动触发 UI 更新，本质是：

声明式 UI + 响应式状态

组件复用方式的差异

传统 App 的 UI 复用通常通过：

• 自定义 View
• 自定义 Widget
• Fragment

例如 Flutter：

classCardViewextendsStatelessWidget{finalString title;CardView(this.title);@overrideWidgetbuild(BuildContext context){returnCard( child:Text(title),);}}

而 ArkUI：

@Component struct CardView { title:stringbuild(){Row(){Text(this.title)}}}

ArkUI 的组件结构更轻量。

UI 布局思想的差异

传统 UI 布局通常依赖：

• ConstraintLayout
• AutoLayout
• Flexbox

例如 iOS：

View ├── Top constraint ├── Leading constraint └── Width constraint 

而 ArkUI 主要依赖：

• Column
• Row
• Flex
• Stack

例如：

Column(){Text("标题")Row(){Button("确认")Button("取消")}}

布局逻辑更接近：

线性布局 + 组合布局

而不是复杂约束系统。

跨设备 UI 是最大不同

传统 App 的 UI 只需要考虑：

• 手机屏幕

但鸿蒙需要考虑：

• 手机
• 平板
• PC
• 车机
• IoT

这意味着 UI 架构必须具备：

跨设备适配能力

ArkUI 响应式布局示例

@Entry@Component struct AdaptivePage {build(){Column(){if(DeviceInfo.deviceType ==='phone'){PhoneLayout()}else{TabletLayout()}}}}

同一套代码适配不同设备。

分布式 UI 是鸿蒙最大的不同

鸿蒙不仅支持跨设备 UI，还支持 分布式 UI。

例如：

• 手机点击按钮
• 平板展示内容

示例：

import distributedData from'@ohos.data.distributedData'asyncfunctionsyncData(){await kvStore.put("article_id","1001")}

另一设备读取：

let id =await kvStore.get("article_id")openArticle(id)

UI 不再局限在单设备。

对开发者意味着什么

如果你是传统 App 开发者，迁移到 ArkUI 需要改变三件事。

第一 页面思维 → 组件思维

过去：

页面 → 控制 UI 

现在：

组件 → 组成 UI 

页面只是组件入口。

第二 生命周期思维 → 状态思维

过去：

• viewDidLoad
• onResume
• onPause

现在更重要的是：

状态变化

第三 单设备 UI → 分布式 UI

过去只需要考虑：

• 一块屏幕

现在需要考虑：

• 多设备
• 多窗口
• 跨设备协同

总结

传统 App 的 UI 架构核心是：

页面驱动 

而鸿蒙 ArkUI 的 UI 架构核心是：

组件驱动 

两者的差异可以总结为：

理解这一点之后，你就会发现：

ArkUI 不是简单换了一套 UI 写法。

它背后的目标，是支持：

• 多设备
• 分布式
• AI 原生应用

这也是为什么越来越多开发者在学习鸿蒙时，会感觉：

这不仅是一套新的 UI 框架，更是一种新的应用架构。