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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
📣 公众号“Swift社区”，每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。
💬 微信端添加好友“fzhanfei”，与我直接交流，不管是项目瓶颈的求助，还是行业趋势的探讨，随时畅所欲言。
📅 最新动态：2025 年 3 月 17 日
快来加入技术社区，一起挖掘技术的无限潜能，携手迈向数字化新征程！

引言

很多团队在做鸿蒙分布式时，都会经历一个阶段：

功能跑通了
Demo 也 OK
跨设备也能跳

但一旦进入真实用户场景，很快就会出现一堆问题：

• 数据不同步
• 页面状态丢失
• 设备切换卡顿
• 操作“断层感”很强

于是你会得到一个非常真实的结论：

分布式能力“能用”，但不好用。

问题不在 API，也不在系统能力，而在：

你的架构仍然是“单设备思维”。

一、你以为在做“分布式”，其实只是“远程调用”

很多项目的分布式实现，本质是这样：

startAbility({
  deviceId: remoteDeviceId,
  abilityName: "DetailAbility"
})

看起来是：

跨设备能力

但本质是：

把页面打开在另一台设备

问题是：用户的任务没有被“延续”

典型表现

手机选了商品
↓
跳转到平板
↓
状态没带过去 错误

二、问题一：状态不是“全局的”

很多人状态是这样写的：

@State currentItem: Item | null = null

这是：

本地状态

当你跨设备：

另一台设备没有这个状态

正确做法：分布式状态

class GlobalState {

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

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

}

页面使用：

aboutToAppear() {
  this.currentItem = await globalState.get("item")
}

核心原则：

状态必须“随用户走”，而不是“留在设备上”。

三、问题二：任务被“打断”了

很多分布式流程是这样：

A 设备：操作一半
↓
跳转 B 设备
↓
重新开始

原因是： 你没有建模“任务”

错误写法

// 页面驱动流程
goToNextPage()

正确写法：任务驱动

class Task {

  state: any

  async resume() {
    // 根据 state 恢复执行
  }

}

跨设备：

await task.resume()

核心：

任务必须可以“暂停 / 迁移 / 恢复”

四、问题三：UI 绑定了设备

很多 UI 写法默认：

当前设备就是唯一环境

例如：

if (isPhone()) {
  renderMobileUI()
} else {
  renderPadUI()
}

问题，分布式场景下：

UI 不应该由设备决定

正确做法：状态驱动 UI

render(state) {
  if (state.mode === "compact") {
    return renderCompact()
  }
  return renderFull()
}

核心：

UI 应该适配“任务状态”，而不是“设备类型”

五、问题四：数据同步是“被动触发”的

很多代码是这样：

onClick() {
  kvStore.put("data", this.data)
}

问题：

只有操作时才同步

正确做法：订阅式同步

kvStore.on("dataChange", (key, value) => {
  this.data = value
})

核心：

分布式数据必须是“实时感知”的

六、问题五：没有“跨设备上下文”

很多系统只传：

数据

但缺少：

上下文

例如：

{
  itemId: 123
}

但实际上应该是：

{
  itemId: 123,
  step: "confirm",
  from: "phone",
  intent: "buy"
}

核心：

分布式不是“传数据”，而是“传上下文”

七、一个正确的分布式架构

推荐模型

User Intent
   ↓
Task（任务）
   ↓
State（分布式状态）
   ↓
Service（业务能力）
   ↓
UI（多设备展示）

示例

class BuyTask {

  async start(itemId: string) {
    await globalState.set("task", {
      type: "buy",
      itemId
    })
  }

  async resume() {
    const state = await globalState.get("task")
    return await orderService.create(state.itemId)
  }

}

设备切换：

await buyTask.resume()

用户体验：

无缝继续

八、为什么“能用但不好用”

因为大多数项目：

只做了能力调用
没做架构设计

所以结果是：

能力	状态
能跨设备跳转	错误 状态丢失
能传数据	错误 不完整
能执行功能	错误 体验断层

九、本质

如果用一句话总结：

你的分布式能力不好用，是因为你的架构仍然是“单设备应用”。

真正的分布式应用应该是：

以用户为中心
以任务为核心
以状态为纽带

总结

很多人做鸿蒙分布式，会卡在一个误区：

“功能已经有了，为什么体验不好？”

答案其实很简单：

因为你只是“用了分布式”，而不是“按分布式设计”。

如果你想把体验做好，必须改变三件事：

• 状态 → 分布式
• 流程 → 任务化
• UI → 去设备依赖

当你做到这一步，你会发现：

分布式不再是功能
而是应用的基础能力