鸿蒙 PC + 手机 + 平板：一次真正的多端应用实战

网罗开发 （小红书、快手、视频号同名）

大家好，我是 展菲，目前在上市企业从事人工智能项目研发管理工作，平时热衷于分享各种编程领域的软硬技能知识以及前沿技术，包括iOS、前端、Harmony OS、Java、Python等方向。在移动端开发、鸿蒙开发、物联网、嵌入式、云原生、开源等领域有深厚造诣。

图书作者：《ESP32-C3 物联网工程开发实战》
图书作者：《SwiftUI 入门，进阶与实战》
超级个体：COC上海社区主理人
特约讲师：大学讲师，谷歌亚马逊分享嘉宾
科技博主：华为HDE/HDG

我的博客内容涵盖广泛，主要分享技术教程、Bug解决方案、开发工具使用、前沿科技资讯、产品评测与使用体验 。我特别关注云服务产品评测、AI 产品对比、开发板性能测试以及技术报告，同时也会提供产品优缺点分析、横向对比，并分享技术沙龙与行业大会的参会体验。我的目标是为读者提供有深度、有实用价值的技术洞察与分析。

展菲：您的前沿技术领航员

👋 大家好，我是展菲！

📱 全网搜索"展菲"，即可纵览我在各大平台的知识足迹。

每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

文章目录

• • 引言
  • 一、多端开发，最大的误区是什么？
  • 二、一个真实项目里的变化
  • [三、真正的多端，不是"多个 UI"](#三、真正的多端，不是“多个 UI”)
  • • 手机
    • 平板
    • PC
  • [四、为什么传统 App 很难真正多端？](#四、为什么传统 App 很难真正多端？)
  • 五、多设备下，"页面"已经失去意义
  • • 手机上的页面：
    • [PC 上：](#PC 上：)
    • 平板：
  • [六、真正应该共享的是 State，而不是 UI](#六、真正应该共享的是 State，而不是 UI)
  • [七、鸿蒙真正强的，不是 UI，而是"状态流转"](#七、鸿蒙真正强的，不是 UI，而是“状态流转”)
  • • 手机上的操作
  • 八、真正的挑战：状态一致性
  • [九、PC 的出现，会彻底放大架构问题](#九、PC 的出现，会彻底放大架构问题)
  • 十、一个真正可持续的多端架构
  • • 架构变成：
    • 手机：
    • 平板：
    • PC：
  • [十一、为什么这种结构特别适合 AI](#十一、为什么这种结构特别适合 AI)
  • 十二、为什么很多"伪多端"项目后期会越来越乱
  • 十三、真正的多端，本质是"一个系统"
  • 总结

引言

很多团队第一次听到"鸿蒙多端开发"时，第一反应通常是：

"是不是一套 UI 跑多个设备？"

于是项目很容易演变成：

• 手机版拉伸到平板
• 平板再适配 PC
• 然后加几个响应式布局

最后看起来：

像是"多端"

但真正做过鸿蒙 PC + 手机 + 平板联合项目之后，你会慢慢发现：

真正困难的，从来不是"适配 UI"。

而是：

如何让多个设备，共享同一个"状态系统"。

因为：

一旦进入多端
问题就不再是"页面"
而是"状态同步"

一、多端开发，最大的误区是什么？

很多人会天然认为：

多端 = 多套界面

所以重点会放在：

• 响应式布局
• 断点适配
• 屏幕尺寸
• Flex 布局

这些当然重要。但真正决定系统复杂度的，其实是：

设备之间的数据关系

二、一个真实项目里的变化

我们曾经做过一个典型场景：

PC 负责编辑
平板负责批注
手机负责消息和快速操作

一开始团队的设计方式很简单：

每个设备
独立维护自己的页面和状态

结果很快出现问题：

• 手机修改内容，PC 不同步
• 平板批注后，编辑器状态错乱
• 多设备切换时焦点丢失
• 数据版本开始冲突

最后整个系统越来越像：

"三套 App 强行互联"。

三、真正的多端，不是"多个 UI"

这是整个鸿蒙体系最容易被误解的一点。真正的多端系统其实应该是：

一个状态系统
多个 UI 投影

也就是说：

手机

只是：

状态的一种移动表达

平板

只是：

状态的一种触控表达

PC

只是：

状态的一种复杂工作流表达

四、为什么传统 App 很难真正多端？

因为传统 App 的核心模型是：

页面驱动

比如：

页面 A
↓
页面 B
↓
页面 C

每个页面：

• 持有自己的状态
• 管理自己的生命周期
• 控制自己的 UI

这种结构在单设备没问题。但一旦进入：

多个设备同时运行

问题立刻爆炸。

五、多设备下，"页面"已经失去意义

举个最简单的例子。

手机上的页面：

订单详情页

PC 上：

可能变成：

• 左侧订单列表
• 中间订单详情
• 右侧 AI 分析面板

平板：

可能又变成：

全屏批注模式

你会发现：

"页面"已经无法统一表达系统结构。

真正统一的只能是：

状态

六、真正应该共享的是 State，而不是 UI

这是整个架构最关键的一步。

错误做法：

手机维护一份状态
PC 再维护一份状态

结果：

同步地狱

正确做法应该是：

GlobalState
   ↓
PhoneUI
TabletUI
PCUI

UI 不再是核心，真正核心的是：

状态唯一

七、鸿蒙真正强的，不是 UI，而是"状态流转"

很多人关注：

• ArkUI
• 分布式界面
• 跨端拖拽

但真正强的其实是：

状态天然可流动

比如：

手机上的操作

globalState.currentDoc = "doc_1"

PC 自动更新：

编辑器切换文档

平板同步：

批注区域刷新

整个过程：

没有页面跳转
没有 UI 通知

因为：

UI 本质只是状态映射。

八、真正的挑战：状态一致性

很多团队做多端，最后崩的原因其实不是：

UI 适配

而是：

状态一致性

比如：

• 谁拥有最终状态？
• 多设备同时修改怎么办？
• 离线后如何恢复？
• Workspace 如何同步？

这些问题：

都已经不是"页面开发"问题。

而是：

系统设计问题。

九、PC 的出现，会彻底放大架构问题

很多移动端项目：

页面还能凑合

但一旦接入 PC：

• 多窗口
• 多输入源
• 键盘焦点
• 并行 Workspace

复杂度会瞬间上升，这时候：

页面模型开始失效

因为：

PC 本质是"多状态并行系统"。

十、一个真正可持续的多端架构

后来我们重构时，核心变化只有一句话：

状态统一，UI 分离。

架构变成：

GlobalState
   ↓
WorkspaceState
   ↓
DeviceUI

手机：

只负责：

轻交互

平板：

负责：

触控与批注

PC：

负责：

复杂工作流

但底层状态：

完全一致

十一、为什么这种结构特别适合 AI

因为 AI 天然不理解：

页面

AI 真正理解的是：

状态
上下文
意图

比如：

state.currentDoc
state.selection
state.activeWorkspace

AI 可以直接：

• 修改状态
• 驱动系统
• 自动更新 UI

这时候：

多设备会天然协同。

十二、为什么很多"伪多端"项目后期会越来越乱

因为本质上：

只是多个 App 在同步数据

而不是：

一个系统在共享状态

这两者复杂度完全不同。

十三、真正的多端，本质是"一个系统"

这是整个鸿蒙最核心的一件事，很多人以为：

鸿蒙多端 = 一套代码跑多个设备

但真正重要的是：

多个设备共享同一个状态系统

而 UI：

只是设备侧的投影

总结

关于鸿蒙 PC + 手机 + 平板，很多人讨论的重点还停留在：

• 响应式布局
• UI 适配
• 多端界面统一

但真正的变化其实是：

应用开始从"单设备页面系统"，变成"跨设备状态系统"。

对比一下：

维度	传统多端	鸿蒙多端
核心	页面	状态
多设备关系	数据同步	状态共享
UI	独立实现	状态投影
系统结构	多 App	一个系统

最终你会发现：

真正难的
从来不是"多端适配"
而是"多端状态组织"

因为：

设备可以有很多个，但状态只能有一个。