HarmonyOS 与 Android 架构对比：从“写页面”到“设计系统”的差异

HarmonyOS 与 Android 架构对比

------同样是做 App，为什么思路完全不一样？

很多 Android 开发者在刚接触 HarmonyOS 时，都会有一个明显感受：

API 不难，但"写法很别扭"。

比如：

为什么这么强调状态？
为什么 UI 层几乎不写逻辑？
为什么组件像函数？
为什么没有 Activity / Fragment？

这些困惑，本质不是 API 问题，而是------

架构哲学的变化

一、架构设计目标对比（根本差异）

维度	Android	HarmonyOS
诞生背景	手机优先	多设备优先
核心目标	页面 + 生命周期	状态 + 响应
UI 思想	命令式	声明式
架构重心	页面驱动	状态驱动
推荐范式	MVVM	Unidirectional Data Flow

Android 关心"页面怎么切"
HarmonyOS 关心"状态怎么变"

二、UI 架构：命令式 vs 声明式

Android（命令式 UI）

java 复制代码

textView.setText("Hello");
button.setEnabled(false);

开发者告诉系统"怎么做"
状态和 UI 分离
很容易漏更新

HarmonyOS（声明式 UI）

ts 复制代码

Text(this.title)
Button("提交").enabled(this.canSubmit)

UI 是状态的"结果"
不操作控件
状态变化 → UI 自动刷新

HarmonyOS 不鼓励"操作 UI"，而是"描述 UI"

三、页面体系：Activity vs Page

Android

复制代码

Activity
 ├─ Fragment
 │   ├─ View
 │   └─ ViewModel

生命周期复杂
Fragment 嵌套多
页面 = 逻辑单元

HarmonyOS

复制代码

Page
 ├─ Component
 │   └─ SubComponent

页面轻量
组件是核心
页面只是容器

HarmonyOS 中 页面 ≠ 逻辑中心

四、生命周期对比（复杂度差异巨大）

Android 生命周期（节选）

复制代码

onCreate
onStart
onResume
onPause
onStop
onDestroy

再加上 Fragment：

复制代码

onAttach
onCreateView
onActivityCreated
...

生命周期驱动逻辑

HarmonyOS 生命周期

ts 复制代码

onPageShow()
onPageHide()
onPageDestroy()

只保留"业务有意义"的生命周期

五、状态管理体系对比（分水岭）

Android：状态是"分散的"

ViewModel
LiveData / StateFlow
SavedStateHandle
Bundle

kotlin 复制代码

viewModel.text.observe(this) {
  textView.text = it
}

UI 与状态靠"绑定"维系

HarmonyOS：状态是"一等公民"

ts 复制代码

@Local title: string = 'Hello'

状态直接驱动 UI：

ts 复制代码

Text(this.title)

不需要 observe / collect / notify

六、状态作用域对比

作用域	Android	HarmonyOS
页面内	ViewModel	@Local
父子组件	参数	@Param
全局	Singleton / DI	@Provider
只读派生	LiveData map	@Computed

HarmonyOS 把"状态作用域"写进语言层

七、导航与路由思想

Android

Intent
NavGraph
BackStack 手动维护

kotlin 复制代码

findNavController().navigate(R.id.detail)

HarmonyOS

ts 复制代码

router.pushUrl({
  url: 'pages/Detail',
  params: { id: 1 }
})

路由简单

不推荐在页面写复杂跳转逻辑

更强调"路由集中管理"

八、多页面架构方式对比

Android 常见问题

多 Activity
多 Fragment
状态丢失
返回栈错乱

HarmonyOS 推荐模式

复制代码

AppRoot
 ├─ Login
 └─ MainShell
     ├─ Home
     ├─ Detail
     └─ Profile

Root 决策
Shell 承载
Page 只做业务

结构先于代码

九、异步与后台任务对比

能力	Android	HarmonyOS
后台线程	Thread / Coroutine	Worker
任务调度	WorkManager	TaskPool
生命周期感知	LifecycleOwner	Page 生命周期
通信	Handler / Flow	MessagePort

HarmonyOS 更强调"系统统一调度"

十、系统能力调用方式

Android

Context
Service
Permission + Intent

kotlin 复制代码

startService(...)

HarmonyOS

明确权限声明
明确能力调用
统一异步回调

更"像系统开发"，而不是 App 脚本

十一、对开发者心智的影响

Android 开发者习惯：

我要在什么时候，做什么事？

HarmonyOS 开发者需要转变为：

在什么状态下，系统应该呈现什么？

从"过程思维"到"结果思维"

十二、HarmonyOS 的优势与挑战

优势

✔ 架构更清晰

✔ UI 状态一致性高

✔ 多端一致性强

✔ 组件复用能力强

挑战

⚠ 学习曲线陡

⚠ 思维转变难

⚠ 早期容易写"伪声明式代码"

结语

Android 是"工程驱动的系统"，HarmonyOS 是"架构驱动的系统"。

如果你只是"照着写"，HarmonyOS 会很别扭；

但一旦你开始先设计状态和结构，你会发现：

很多 Android 中的复杂问题，在 HarmonyOS 里天然不存在。