一套鸿蒙 App，如何跑在手机 / 平板 / TV？

大家好，我是子玥酱，一名长期深耕在一线的前端程序媛 👩‍💻。曾就职于多家知名互联网大厂，目前在某国企负责前端软件研发相关工作，主要聚焦于业务型系统的工程化建设与长期维护。

我持续输出和沉淀前端领域的实战经验，日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案，
在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。

技术方向：前端 / 跨端 / 小程序 / 移动端工程化
内容平台：掘金、知乎、CSDN、简书
创作特点：实战导向、源码拆解、少空谈多落地
文章状态：长期稳定更新，大量原创输出

我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”，而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍，希望能帮你在实际工作中少走弯路。

子玥酱 · 前端成长记录官 ✨
👋 如果你正在做前端，或准备长期走前端这条路
📚 关注我，第一时间获取前端行业趋势与实践总结
🎁 可领取11 类前端进阶学习资源（工程化 / 框架 / 跨端 / 面试 / 架构）
💡 一起把技术学“明白”，也用“到位”

持续写作，持续进阶。
愿我们都能在代码和生活里，走得更稳一点 🌱

引言

很多人第一次接触鸿蒙时，最容易被一句话吸引：

一次开发 多端部署

听起来像是：

写一个 App 所有设备自动适配

于是很多团队会自然觉得：

手机能跑 平板应该没问题 TV 大不了放大一点

但真正做下去之后，很快就会进入一种熟悉的状态：

手机正常 平板奇怪 TV 完全不能用

甚至：

• 遥控器无法操作
• TV 焦点乱跳
• 布局比例崩掉
• 字体尺寸失控
• 页面逻辑越来越复杂

最后很多人会开始怀疑：

鸿蒙不是“多端统一”吗？

为什么适配还是这么痛苦？

但问题其实不在鸿蒙，真正的问题是：

很多项目本质上仍然在用“手机 App 思维”做全场景系统。

一、多端最大的误区：把“适配”理解成“缩放”

很多团队第一次做多端时，会这样：

.width('100%').height('100%')

或者：

if(isPad){width=600}

再或者：

if(isTV){fontSize=30}

看起来：

页面能显示

但真正的问题是：

多端不是“缩放 UI”。

而是：

重新定义交互模型

二、手机 / 平板 / TV 最大差异是什么

很多人以为：

只是屏幕尺寸不同

其实真正不同的是：

也就是说：

设备变了 交互语义也变了

三、为什么“手机页面直接搬 TV”一定会崩

因为 TV 本质上不是：

大屏手机

而是：

焦点系统

手机上的操作

点击 滑动 拖拽

TV 上的操作

上下左右 焦点切换 确认键 返回键

一个典型错误

很多人会这样：

List(){}

然后：

直接跑 TV

结果：

• 焦点丢失
• 无法导航
• 用户不知道当前选中什么

四、真正的多端核心：能力统一，而不是页面统一

很多团队会执着：

所有设备长一样

其实这是错误方向，真正应该统一的是：

Task State 能力

而不是：

像素布局

正确模型

Task ↓ State ↓ Adaptive UI

五、什么叫“Adaptive UI”

这是鸿蒙多端里非常核心的一件事，不是：

一套页面强行适配所有设备

而是：

同一状态，不同展示。

示例

订单列表，手机：

单列

平板：

双列

TV：

大卡片 + 焦点导航

但它们共享：

同一个 OrderStore 同一个 OrderTask

六、推荐的多端架构

真正稳定的鸿蒙多端项目，通常会这样：

Task Layer ↓ State Layer ↓ Adaptive UI Layer

Task Layer

负责：

• 创建订单
• 登录
• 搜索
• 支付

State Layer

负责：

• 用户状态
• 订单状态
• 会话状态

Adaptive UI

负责：

不同设备的呈现方式

七、为什么 Store 必须中心化

很多项目的问题，手机：

@Stateorder

TV：

globalOrder

结果：

状态来源不同

后面一定：

• 数据错乱
• 分布式同步异常
• 多端状态覆盖

正确做法

所有设备统一：

Store 中心化

示例:

classOrderStore{orders:Order[]=[]}

手机：

orderStore.orders

TV：

orderStore.orders

平板：

orderStore.orders

八、为什么 Task 比页面更重要

传统 App：

页面是核心

鸿蒙多端：

Task 才是核心

例如

用户说：

帮我播放昨天没看完的电影

系统可能，手机：

展示控制器

TV：

直接播放视频

平板：

显示影片详情

但本质上：

都是同一个 Task

九、TV 最大的特殊点：焦点系统

这是很多团队第一次踩的大坑，手机：

没有焦点概念

TV：

所有操作围绕 Focus

一个典型错误

Column(){}

里面：

几十个按钮

但：

没有 Focus 管理

结果：TV 完全不可操作。

正确做法

必须建立：

Focus Flow

示例:

.focusable(true)

或者：

.defaultFocus(true)

TV 的核心不是布局

而是：

焦点路径

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

因为 AI 天然是：

跨设备任务系统

例如：

awaitagent.run("继续播放我昨天看的电影")

系统可能：

• 手机上的任务继续
• TV 上自动播放
• 平板显示评论区

如果：

Task 不统一 State 不统一

整个体验一定：

彻底割裂

十一、真正优秀的鸿蒙多端项目长什么样

不是：

所有设备页面一样

而是：

所有设备能力一致

通常具备：

• Store 中心化
• Task 驱动
• 响应式布局
• Focus Flow
• 分布式状态同步
• AI Runtime

这些东西：

比“页面复用”重要得多。

十二、推荐一个完整结构

app/ ├── state/ ├── task/ ├── runtime/ ├── ui/ │ ├── phone/ ├── tablet/ ├── tv/ │ └── shared/

shared/

负责：

• Store
• Task
• Repository
• Runtime
• 通用组件

phone/

负责：

手机 UI

tablet/

负责：

平板 UI

tv/

负责：

TV 焦点 UI

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

很多人以为：

多端 = 多页面

其实真正的多端应该是：

同一能力 不同呈现

未来真正统一的，不是：

UI

而是：

• State Flow
• Task Flow
• Runtime
• Intent

十四、总结

如果用一句话总结：

鸿蒙多端的核心，不是“适配页面”。

真正核心的是：

统一状态 统一任务 统一能力

页面只是“终端形态”

手机：

触控 UI

TV：

焦点 UI

平板：

多栏 UI

但它们共享：

同一个系统

很多团队做鸿蒙多端越来越痛苦，并不是因为：

• ArkUI 不够强
• TV 太特殊
• 平板适配太难

真正的问题其实只有一个：

仍然在用“手机页面思维”做全场景系统。

记住一句话：

真正统一的， 不是页面， 而是状态与任务。

当你真正建立：

• Store 中心化
• Task 驱动
• Adaptive UI
• Focus Flow
• Runtime
• 分布式状态同步

你会明显感觉到：

一套鸿蒙 App 才真正“跑起来了”