分布式能力不是功能，而是一种架构约束

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

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

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

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

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

👋 大家好，我是展菲！

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

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

💬 微信端添加好友"fzhanfei"，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。

📅 最新动态：2025 年 3 月 17 日

快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

文章目录

• • 引言
  • 一、为什么很多项目用不好分布式能力
  • • 典型错误
  • 二、分布式能力真正改变的是什么
  • • [传统 App](#传统 App)
    • 鸿蒙分布式
  • 三、架构上的三个强制变化
  • • [1 状态必须"可同步"](#1 状态必须“可同步”)
    • [2 UI 不能依赖本地上下文](#2 UI 不能依赖本地上下文)
    • [3 任务必须可迁移](#3 任务必须可迁移)
  • 四、一个典型错误案例
  • 五、分布式架构应该怎么设计
  • • 推荐结构
    • 示例
  • 六、分布式带来的"约束思维"
  • • [1 不再假设"本地唯一"](#1 不再假设“本地唯一”)
    • [2 不再假设"顺序执行"](#2 不再假设“顺序执行”)
    • [3 不再假设"UI 是中心"](#3 不再假设“UI 是中心”)
  • [七、和 AI 架构的结合](#七、和 AI 架构的结合)
  • • [AI 关注：](#AI 关注：)
    • 分布式提供：
  • 八、为什么说它是"架构约束"
  • 九、本质
  • 总结

引言

很多开发者第一次接触鸿蒙分布式能力时，理解是这样的：

跨设备传数据
多端同步
远程调用

于是大家把它当成：

"一个可以用的功能模块"

比如：

• 需要同步数据 → 用分布式数据
• 需要跨设备 → 调 startAbility

听起来没问题。

但如果你真的做过一个"跨设备可用"的鸿蒙 App，很快就会发现：

分布式能力不是"你想用就用"，而是"你必须围绕它设计"。

也就是说：

它不是功能，而是一种架构约束。

一、为什么很多项目用不好分布式能力

因为大多数项目一开始是这样设计的：

单设备思维
↓
开发完成
↓
再加分布式能力

结果会出现：

• 数据不同步
• 状态混乱
• 页面无法恢复
• 跨设备体验割裂

典型错误

// 本地状态
this.currentUser = user

// 想同步时再写
kvStore.put("user", user)

问题在于：

你的数据模型从一开始就不是"分布式的"。

二、分布式能力真正改变的是什么

很多人以为它改变的是：

数据同步方式

但本质上，它改变的是：

系统的"边界定义"。

传统 App

设备 = 系统边界

所有东西都在：

一个设备
一个进程
一个状态

鸿蒙分布式

用户 = 系统边界

也就是说：

多个设备共享一个"逻辑应用"

这意味着：

你的应用，从"单机系统"变成了"分布式系统"。

三、架构上的三个强制变化

这才是最关键的地方。

1 状态必须"可同步"

传统写法：

@State count: number = 0

只存在于当前设备。

分布式设计：

class DistributedState {

  async set(key: string, value: any) {
    await kvStore.put(key, value)
  }

  async get(key: string) {
    return await kvStore.get(key)
  }

}

所有核心状态：

必须可以被同步

2 UI 不能依赖本地上下文

错误写法：

this.deviceId // 强依赖当前设备

正确思路：

render(state) {
  return state.user
}

UI 应该只依赖：

状态，而不是设备

3 任务必须可迁移

传统任务：

只能在当前设备执行

分布式任务：

class Task {

  async execute(deviceId?: string) {
    if (deviceId) {
      return await remoteExecute(deviceId)
    }
    return await localExecute()
  }

}

任务必须支持：

跨设备执行

四、一个典型错误案例

很多人会这样写：

aboutToAppear() {
  this.loadLocalData()
}

问题：

换设备 → 数据丢失

正确做法：

aboutToAppear() {
  this.loadDistributedData()
}

甚至更进一步：

onPageShow() {
  this.state = await distributedState.get("app_state")
}

五、分布式架构应该怎么设计

推荐结构

UI（设备无关）
   ↓
State（分布式）
   ↓
Service（业务逻辑）
   ↓
Distributed Layer（同步 / 通信）

示例

class UserService {

  async getUser() {
    return await distributedState.get("user")
  }

}

UI：

aboutToAppear() {
  this.user = await userService.getUser()
}

UI 完全不关心：

数据来自哪个设备

六、分布式带来的"约束思维"

这是最重要的一点。

1 不再假设"本地唯一"

错误：

我这里就是唯一状态

正确：

状态可能在别的设备被修改

2 不再假设"顺序执行"

错误：

A → B → C

正确：

A / B / C 可能在不同设备执行

3 不再假设"UI 是中心"

传统：

UI 控制一切

分布式：

状态才是中心

七、和 AI 架构的结合

有意思的是： 分布式能力和 AI 架构是天然契合的。

AI 关注：

任务
能力
状态

分布式提供：

跨设备执行能力

例如：

await agent.run("打开会议文档")

系统可能：

// 平板展示文档
openOnTablet()

// 手机做控制
bindControl()

用户完全无感：

设备切换

八、为什么说它是"架构约束"

因为一旦你决定支持分布式，你就必须：

• 重构状态管理
• 重构数据流
• 重构任务模型

否则结果就是：

功能能跑
体验崩溃

九、本质

如果用一句话总结：

分布式能力不是"你可以用"，而是"你必须围绕它设计"。

对比：

维度	传统 App	分布式鸿蒙
系统边界	设备	用户
状态	本地	全局
任务	单点执行	可迁移
UI	中心	表现层

总结

很多开发者会把分布式能力当成：

一个高级功能

但真正做过项目的人会发现：

它更像是一种"约束规则"。

如果你不遵守：

• 架构会崩
• 状态会乱
• 体验会断

但如果你从一开始就按分布式设计，你会得到一个完全不同的应用：

跨设备
无缝体验
任务连续