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

Ne0inhk

— 7 min read
传统 App 与鸿蒙 ArkUI：UI 架构差异解析
在这里插入图片描述

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

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

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

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

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

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

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

文章目录

引言

如果你过去做过 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 架构核心是：

组件驱动

两者的差异可以总结为：

传统 App鸿蒙 ArkUI
页面中心组件中心
生命周期驱动状态驱动
单设备 UI分布式 UI
页面导航组件组合

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

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

它背后的目标，是支持：

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

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

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

Read more

突破并行瓶颈：Python 多进程开销全解析与 IPC 优化实战

突破并行瓶颈：Python 多进程开销全解析与 IPC 优化实战

突破并行瓶颈：Python 多进程开销全解析与 IPC 优化实战 在 Python 开发者的进阶之路上，有一个几乎无法绕过的“幽灵”——GIL（全局解释器锁）。为了绕过它，追求真正的多核并行，我们往往会投向 multiprocessing 的怀抱。然而，很多开发者在初次尝试后会产生疑惑：“为什么我加了进程，速度反而变慢了？”或者“为什么 CPU 占用率很高，吞吐量却上不去？” 作为一名在高性能后端与数据处理领域深耕多年的开发者，我见过太多被 IPC（进程间通信） 开销拖垮的系统。今天，这篇博文将带你深入 Python 并行的底层，揭开多进程开销的神秘面纱，并手把手教你如何利用共享内存与管道实现极致优化。 1. 缘起：从“胶水”到“引擎”的并行挑战 背景：Python 的魅力与枷锁 Python 自 1991

By Ne0inhk
用 Python 调用 Bright Data MCP Server：在 VS Code 中实现实时网页数据抓取

用 Python 调用 Bright Data MCP Server：在 VS Code 中实现实时网页数据抓取

用 Python 调用 Bright Data MCP Server：在 VS Code 中实现实时网页数据抓取，本文介绍了Bright Data的Web MCP Server，这是一款能实现实时、结构化网页数据访问的API，适用于AI应用等场景。其支持静态与动态网页，前3个月每月提供5000次免费请求，有远程托管和本地部署两种方式。文章以在VS Code中用Python调用其API抓取Google搜索结果为例，详解了准备工作、代码编写、参数说明等实战流程，还提及该工具免维护代理池等技术亮点及使用限制。 一、引言：为什么AI时代需要高效的网页数据访问工具？ 在大语言模型（LLM）和智能代理（Agent）快速发展的今天，"实时性"成为AI应用落地的关键瓶颈。想象一下：当你的AI助手需要回答"今天上海的天气预警"或"某款产品的最新用户评价"时，它必须依赖实时网页数据才能给出准确答案—

By Ne0inhk

Python：布尔类型

在 Python 中，布尔类型（bool）是最基本的数据类型之一，用于表示逻辑上的真与假。 它只有两个取值：True 和 False，是 int 类型的子类。 bool 布尔对象。逻辑值，仅有 True 与 False 两个常量。 在数值运算中，True 等价于 1，False 等价于 0。 1、表示方法 a = True       # 布尔真值b = False      # 布尔假值 print(int(True))   # 1print(int(False))  # 0print(True + 5)    # 6 → 等价于 1 + 5 2、

By Ne0inhk

零基础入门 Python 爬虫：手把手教你爬取苏宁商品评论（好评 + 差评）

作为编程新手，你是否也曾好奇：那些电商平台上成千上万的商品评论，能不能用代码批量抓取下来？是否想过通过分析这些评论，了解一款产品的优缺点？今天这篇文章，我将以 “爬取苏宁手机评论” 为例，从 0 开始讲解 Python 爬虫的实现过程，哪怕你是刚接触编程的小白，跟着步骤走也能轻松上手。 本文全程使用通俗易懂的语言，避开复杂的专业术语，结合完整可运行的代码，详细拆解每一个环节，最终实现 “自动爬取苏宁商品好评 + 差评，并保存到本地文件” 的完整功能。全文约 4000 字，包含环境搭建、代码解析、问题修复、功能扩展等核心内容，耐心看完，你将掌握 Selenium 爬虫的核心逻辑。 一、爬虫入门：先搞懂几个核心概念 在写代码之前，我们先花几分钟搞懂几个基础概念，避免后续看到代码一脸懵。 1.1 什么是爬虫？ 简单来说，爬虫就是模拟人的操作，自动访问网页、提取指定信息的程序。

By Ne0inhk