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

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

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

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

展菲：您的前沿技术领航员
👋 大家好，我是展菲！
📱 全网搜索“展菲”，即可纵览我在各大平台的知识足迹。
每周定时推送干货满满的技术长文，从新兴框架的剖析到运维实战的复盘，助您技术进阶之路畅通无阻。

引言

很多人第一次做鸿蒙多端开发时，都会有一种期待：

一套代码
多端运行

听起来非常美好，于是很多团队会觉得：

手机能跑
平板肯定也能跑
TV 应该也没问题

结果真正上线后，很快就会发现：

虽然“能运行”
但体验非常奇怪

典型问题包括：

• 手机正常，平板布局崩掉
• TV 焦点混乱
• 折叠屏切换闪烁
• 多设备状态不同步
• 字体和间距比例失控
• AI 功能跨设备异常

最后很多项目会进入一种状态：

代码虽然统一了
体验却完全不统一

这也是很多鸿蒙项目最容易踩的坑：

“跨端运行” ≠ “跨端体验”。

一、真正的问题：很多人只做了“适配”

很多团队做多端时：

只是让页面不要报错

例如：

if (isPad) {
  width = 600
}

或者：

if (isTV) {
  fontSize = 40
}

看起来：

好像完成了适配

但实际上：

只是“把 UI 拉伸了一下”

真正优秀的多端系统，从来不是：

页面兼容

而是：

交互模型统一。

二、为什么鸿蒙比传统 App 更容易出现体验问题

因为鸿蒙天然具备：

• 手机
• 平板
• 折叠屏
• TV
• 车机
• PC

这些设备：

并不是“大屏小屏”的区别

而是：

交互模式完全不同

例如：

手机核心：

触摸

TV 核心：

遥控器焦点

PC 核心：

键鼠

车机核心：

低干扰

所以真正问题不是：

页面怎么缩放

而是：

交互怎么变化

三、第一个大坑：把手机 UI 直接放大

这是最常见的问题，很多团队：

手机写完
直接跑平板

结果：

页面巨大留白

或者：

信息密度过低

为什么

因为：

大屏不只是“小屏放大”

例如，手机：

一次聚焦一个任务

平板：

适合多信息并行

正确做法

手机：

单栏

平板：

双栏

TV：

远距离大卡片

不同设备：

应该重新组织信息结构。

四、第二个大坑：状态没有设备隔离

很多项目：

多个设备共享同一个状态

例如：

globalStore.currentPage

结果：

手机切页面
TV 也跟着变

甚至：

焦点状态同步错乱

正确原则

必须拆：

全局状态

例如：

用户
登录
订单
消息

设备状态

例如：

当前焦点
窗口尺寸
页面布局

推荐结构

GlobalState
   ↓
DeviceState
   ↓
UIState

五、第三个大坑：忽略 TV 焦点系统

很多移动开发者第一次做 TV：

完全不理解焦点系统

结果：

• 无法选中按钮
• 焦点乱跳
• 遥控器失效

因为 TV 的核心不是：

Touch

而是：

Focus Navigation

错误思维

TV = 大屏手机

正确思维

TV = 焦点操作系统

所以必须建立：

• Focus 管理
• 焦点路径
• 焦点状态
• 遥控器事件系统

六、第四个大坑：布局完全依赖 px

很多项目：

固定宽高

例如：

.width(375)
.height(200)

问题：

设备一变
布局直接崩

正确做法

使用：

• 百分比
• Flex
• Grid
• Breakpoint

例如：

.width('100%')

或者：

GridRow()

七、第五个大坑：页面驱动，而不是能力驱动

很多项目：

每个设备一套页面

最后：

维护成本爆炸

正确模型

未来真正稳定的多端结构：

能力统一
UI 分化

例如：

Order Task

统一：

创建订单能力

不同设备

手机：

简洁流程

平板：

多栏信息

TV：

卡片化展示

核心：

Task 不变，UI 可变。

八、第六个大坑：AI 状态跨设备失控

AI Native 鸿蒙 App 最大问题之一：

AI 操作多个设备

例如：

await agent.run(
  "继续昨天的视频"
)

系统可能：

• TV 播放
• 手机控制
• 平板同步评论

如果没有：

设备级状态隔离

很容易出现：

设备状态互相污染

正确做法

必须拆：

Task State
Device State
UI State

而不是：

所有状态共享

九、第七个大坑：组件没有响应式能力

很多组件：

默认按手机设计

例如：

Column()

在 TV：

可能需要横向布局

正确做法

组件必须：

根据设备动态切换结构

例如：

if (isTablet) {
  renderPad()
} else {
  renderPhone()
}

十、真正优秀的鸿蒙多端架构

真正稳定的结构一定是：

Task
 ↓
State
 ↓
Adaptive UI
 ↓
Device Runtime

核心思想

能力统一，例如：

订单系统
支付系统
AI 系统

状态隔离

例如：

不同设备不同 UIState

UI 自适应

根据：

• 屏幕
• 输入方式
• 距离
• 场景

动态变化。

十一、为什么未来 AI 会放大多端问题

因为 AI 会让：

跨设备协同

越来越频繁，传统 App：

一个设备
一个页面

AI Native：

一个任务
多个设备

所以未来真正核心的是：

设备 Runtime。

十二、一个非常关键的认知

很多团队会觉得：

多端适配 = UI 适配

其实不是，真正本质是：

交互系统适配。

因为不同设备：

本质是不同“操作系统体验”

而不是：

不同分辨率

十三、总结

如果用一句话总结：

很多鸿蒙 App 多端体验差，本质上是“把不同设备当成同一种设备”。

过去：

一套页面适配所有设备

未来：

统一能力
差异化交互

才是真正稳定的方向。

很多鸿蒙项目最后多端体验崩掉，并不是因为：

• ArkUI 不够强
• 分布式不好用
• 设备太多

真正的问题只有一个：

系统没有真正“设备化思维”。

记住一句话：

多端开发最难的，
从来不是“页面适配”，
而是“交互重构”。

当你真正建立：

• Device Runtime
• 状态隔离
• Focus System
• Adaptive UI
• Task 中心化
• 多设备状态流

你会明显感觉到：

鸿蒙多端体验终于“像一个系统”