【HarmonyOS/OpenHarmony】创新体验：从 phone 设备配置看全场景适配的第一步

前言 🌟

提到 HarmonyOS / OpenHarmony，很多人会自然想到“全场景”“多设备”“分布式能力”。这些方向确实很重要，但在真实项目中，不能一上来就说自己实现了全场景智慧生活。

当前项目是一个基础 ArkTS 工程，目前在 module.json5 中只声明了 phone 设备类型。因此，这篇文章不会夸大项目能力，而是从当前真实配置出发，分析一个 OpenHarmony 项目如何迈出全场景适配的第一步。

本文对应四大主题中的 创新体验。这里的创新，不是已经完成跨设备协同，而是从工程配置开始，为未来多场景扩展打基础。

当前项目的设备类型配置 📱

当前项目的模块配置位于：

entry/src/main/module.json5

其中有这样一段配置：

"deviceTypes": [
  "phone"
]

这说明当前模块面向的设备类型是手机。也就是说，从当前工程状态看，这个项目并没有声明平板、智慧屏、车机、穿戴等设备类型。

这一点非常重要。写文章时必须明确：当前项目是手机端基础应用，不是已经完成全场景适配的应用。

deviceTypes 在工程中的位置 🧭

deviceTypes 位于模块配置中，而不是页面代码中。这说明设备类型属于模块能力声明的一部分。

当前项目的链路可以这样理解：

module.json5
  -> deviceTypes: phone
  -> EntryAbility
  -> pages/Index

系统先根据模块配置理解这个模块面向什么设备，再通过主入口 Ability 加载页面。页面 Index.ets 本身并不负责声明设备范围，它只负责绘制 UI。

这种分层很重要。设备范围、入口能力、页面展示各自有不同职责。后续如果要扩展设备类型，不能只改页面，也不能只改配置，而是要让两者配合。

为什么 phone 配置也值得写？🚀

很多人觉得只有配置多个设备类型，才算全场景。其实从工程角度看，明确当前设备范围也是全场景适配的第一步。

因为全场景不是“所有设备都写上去”这么简单，而是要回答几个问题：

1. 当前应用首先服务哪类设备？
2. 当前页面布局是否适合这个设备？
3. 后续扩展到其他设备时，哪些代码可以复用？
4. 哪些资源需要做多场景适配？
5. 哪些能力需要按设备类型判断？

当前项目先声明 phone，说明它的第一目标是手机端。这样比一开始盲目写多个设备类型更真实，也更符合基础工程阶段。

手机端是全场景体验的起点 📌

很多全场景体验都不是脱离手机存在的。手机往往是用户最常接触的入口，也是内容浏览、账号登录、消息通知和基础交互的核心设备。

当前项目名是 xiaohongshu，从定位上更接近内容浏览类应用。对这类应用来说，手机端体验本身就很关键。先把手机端页面、资源、入口和日志打牢，再谈其他设备扩展，会更合理。

比如当前首页虽然只是一个文本，但它已经能展示状态变化：

.onClick(() => {
  this.message = 'Welcome';
})

这说明项目至少已经具备基础交互闭环。未来做更多场景时，这种状态驱动交互仍然会继续发挥作用。

从 phone 到多设备，需要考虑什么？🧩

如果后续项目要向全场景扩展，不能只改 deviceTypes。比如从手机扩展到平板，至少要考虑：

1. 页面是否支持更宽屏幕。
2. 字体大小是否仍然合适。
3. 页面是否需要从单栏变成双栏。
4. 图片资源是否清晰。
5. 交互方式是否仍然自然。
6. 入口 Ability 是否仍然适合。

当前项目首页代码是：

RelativeContainer() {
  Text(this.message)
    .fontSize($r('app.float.page_text_font_size'))
    .fontWeight(FontWeight.Bold)
}
.height('100%')
.width('100%')

这个页面在手机上能展示，但如果放到更大屏设备上，居中文本可能显得过于简单。全场景适配不仅是设备类型配置，更是布局、资源、交互和信息密度的综合调整。

设备配置和资源配置要一起看 🎨

当前项目虽然只声明 phone，但资源目录中已经有：

base/element/float.json
base/element/color.json
dark/element/color.json

这意味着后续如果要适配更多设备，不一定所有视觉变化都写进页面代码。字号、颜色、启动背景、图标等内容，可以优先考虑资源化。

例如当前首页字号来自：

.fontSize($r('app.float.page_text_font_size'))

这种写法比硬编码更适合后续扩展。虽然当前还没有多设备资源目录，但资源化已经迈出了第一步。

当前项目具备哪些适配基础？✅

虽然当前项目只声明了 phone，但它已经有一些适配基础：

1. 使用 StageMode 工程结构。
2. 入口 Ability 与页面分离。
3. 页面通过 loadContent('pages/Index') 加载。
4. 字号使用 $r('app.float.page_text_font_size') 资源引用。
5. 启动背景有 base 和 dark 资源。
6. 应用图标使用资源引用。

这些都不是完整全场景能力，但它们是后续适配的基础。

比如字号资源化之后，后续可以根据不同设备或不同资源目录调整视觉表现。页面入口清晰之后，后续多页面扩展也更容易组织。

全场景不是简单堆设备类型 ⚠️

如果只是把配置改成：

"deviceTypes": [
  "phone",
  "tablet"
]

但页面布局、资源、交互都没有适配，那并不是真正的全场景体验。

真正的全场景适配应该关注用户在不同设备上的使用感受。例如：

1. 手机上强调单手操作和信息聚焦。
2. 平板上可以展示更多内容。
3. 大屏上更关注远距离可读性。
4. 穿戴设备上更关注轻量信息。

当前项目还没有这些实现，所以本文只讨论“第一步”：明确当前设备类型，并理解它对后续扩展的意义。

写 CSDN 时应该怎么表达？📌

为了保证真实性，文章中可以这样写：

当前项目只声明 phone 设备类型，说明项目目前面向手机端。
全场景扩展不是简单增加 deviceTypes，而是需要结合布局、资源和交互逐步适配。

不要写成：

本项目已经实现 HarmonyOS 全场景智慧生活。

这两种表达差别很大。前者真实、稳妥；后者会显得虚。

后续扩展方向 🚀

基于当前项目，后续可以逐步扩展：

1. 增加响应式首页布局。
2. 抽取页面资源 token。
3. 为不同屏幕尺寸设计不同内容密度。
4. 增加更多页面并验证导航链路。
5. 根据官方能力逐步了解多设备适配要求。

这些是未来方向，不是当前项目已完成内容。

全场景文章的真实写法 ✅

这类文章最重要的是把“当前已有”和“未来扩展”分清楚。

当前已有的是：

1. phone 设备声明。
2. StageMode 工程结构。
3. 页面加载链路。
4. 资源化字号和颜色。
5. 基础交互状态。

未来扩展的是：

1. 更多设备类型。
2. 响应式布局。
3. 多场景资源。
4. 更复杂的跨端体验。

这样写，既能贴合全场景主题，也不会把项目没有完成的能力说成已经完成。

总结 🌈

这篇文章对应 创新体验 方向。

当前项目的 deviceTypes 只配置了：

"phone"

这说明项目当前是手机端基础应用。但正因为它足够基础，才适合作为理解全场景适配的起点。

全场景不是一句口号，也不是把多个设备名写进配置就结束。它需要从设备范围、页面布局、资源管理、入口链路和交互体验一步步建立。当前项目已经具备基础工程结构，后续如果继续扩展，就可以从 phone 这个明确起点出发，逐步走向更完整的多场景体验。