一套鸿蒙 App，如何跑在手机 / 平板 / TV？
子玥酱掘金 / 知乎 / CSDN / 简书 同名大家好我是子玥酱一名长期深耕在一线的前端程序媛 。曾就职于多家知名互联网大厂目前在某国企负责前端软件研发相关工作主要聚焦于业务型系统的工程化建设与长期维护。我持续输出和沉淀前端领域的实战经验日常关注并分享的技术方向包括前端工程化、小程序、React / RN、Flutter、跨端方案在复杂业务落地、组件抽象、性能优化以及多端协作方面积累了大量真实项目经验。技术方向前端 / 跨端 / 小程序 / 移动端工程化内容平台掘金、知乎、CSDN、简书创作特点实战导向、源码拆解、少空谈多落地文章状态长期稳定更新大量原创输出我的内容主要围绕前端技术实战、真实业务踩坑总结、框架与方案选型思考、行业趋势解读展开。文章不会停留在“API 怎么用”而是更关注为什么这么设计、在什么场景下容易踩坑、真实项目中如何取舍希望能帮你在实际工作中少走弯路。子玥酱 · 前端成长记录官 ✨ 如果你正在做前端或准备长期走前端这条路 关注我第一时间获取前端行业趋势与实践总结 可领取11 类前端进阶学习资源工程化 / 框架 / 跨端 / 面试 / 架构 一起把技术学“明白”也用“到位”持续写作持续进阶。愿我们都能在代码和生活里走得更稳一点 文章目录引言一、多端最大的误区把“适配”理解成“缩放”二、手机 / 平板 / TV 最大差异是什么三、为什么“手机页面直接搬 TV”一定会崩手机上的操作TV 上的操作一个典型错误四、真正的多端核心能力统一而不是页面统一正确模型五、什么叫“Adaptive UI”示例但它们共享六、推荐的多端架构Task LayerState LayerAdaptive UI七、为什么 Store 必须中心化正确做法八、为什么 Task 比页面更重要例如九、TV 最大的特殊点焦点系统一个典型错误正确做法TV 的核心不是布局十、为什么 AI 会放大多端问题十一、真正优秀的鸿蒙多端项目长什么样十二、推荐一个完整结构shared/phone/tablet/tv/十三、一个非常关键的认知十四、总结页面只是“终端形态”引言很多人第一次接触鸿蒙时最容易被一句话吸引一次开发 多端部署听起来像是写一个 App 所有设备自动适配于是很多团队会自然觉得手机能跑 平板应该没问题 TV 大不了放大一点但真正做下去之后很快就会进入一种熟悉的状态手机正常 平板奇怪 TV 完全不能用甚至遥控器无法操作TV 焦点乱跳布局比例崩掉字体尺寸失控页面逻辑越来越复杂最后很多人会开始怀疑鸿蒙不是“多端统一”吗为什么适配还是这么痛苦但问题其实不在鸿蒙真正的问题是很多项目本质上仍然在用“手机 App 思维”做全场景系统。一、多端最大的误区把“适配”理解成“缩放”很多团队第一次做多端时会这样.width(100%).height(100%)或者if(isPad){width600}再或者if(isTV){fontSize30}看起来页面能显示但真正的问题是多端不是“缩放 UI”。而是重新定义交互模型二、手机 / 平板 / TV 最大差异是什么很多人以为只是屏幕尺寸不同其实真正不同的是设备核心交互手机手指触控平板双手触控TV遥控器焦点PC鼠标键盘也就是说设备变了 交互语义也变了三、为什么“手机页面直接搬 TV”一定会崩因为 TV 本质上不是大屏手机而是焦点系统手机上的操作点击 滑动 拖拽TV 上的操作上下左右 焦点切换 确认键 返回键一个典型错误很多人会这样List(){}然后直接跑 TV结果焦点丢失无法导航用户不知道当前选中什么四、真正的多端核心能力统一而不是页面统一很多团队会执着所有设备长一样其实这是错误方向真正应该统一的是Task State 能力而不是像素布局正确模型Task ↓ State ↓ Adaptive UI五、什么叫“Adaptive UI”这是鸿蒙多端里非常核心的一件事不是一套页面强行适配所有设备而是同一状态不同展示。示例订单列表手机单列平板双列TV大卡片 焦点导航但它们共享同一个 OrderStore 同一个 OrderTask六、推荐的多端架构真正稳定的鸿蒙多端项目通常会这样Task Layer ↓ State Layer ↓ Adaptive UI LayerTask Layer负责创建订单登录搜索支付State Layer负责用户状态订单状态会话状态Adaptive UI负责不同设备的呈现方式七、为什么 Store 必须中心化很多项目的问题手机StateorderTVglobalOrder结果状态来源不同后面一定数据错乱分布式同步异常多端状态覆盖正确做法所有设备统一Store 中心化示例:classOrderStore{orders:Order[][]}手机orderStore.ordersTVorderStore.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/负责StoreTaskRepositoryRuntime通用组件phone/负责手机 UItablet/负责平板 UItv/负责TV 焦点 UI十三、一个非常关键的认知很多人以为多端 多页面其实真正的多端应该是同一能力 不同呈现未来真正统一的不是UI而是State FlowTask FlowRuntimeIntent十四、总结如果用一句话总结鸿蒙多端的核心不是“适配页面”。真正核心的是统一状态 统一任务 统一能力页面只是“终端形态”手机触控 UITV焦点 UI平板多栏 UI但它们共享同一个系统很多团队做鸿蒙多端越来越痛苦并不是因为ArkUI 不够强TV 太特殊平板适配太难真正的问题其实只有一个仍然在用“手机页面思维”做全场景系统。记住一句话真正统一的 不是页面 而是状态与任务。当你真正建立Store 中心化Task 驱动Adaptive UIFocus FlowRuntime分布式状态同步你会明显感觉到一套鸿蒙 App 才真正“跑起来了”
)
