【OpenHarmony/HarmonyOs 】页面层架构设计实战：从首页模块化到详情页信息分层

一、前言 🧱

在很多 HarmonyOS 项目里，大家会优先关注组件、动画、数据存储或者功能实现，但如果页面层没有设计好，后面做再多优化都会比较吃力。

页面层的作用，不只是“把内容展示出来”，更重要的是：

• 决定用户从哪里进入
• 决定内容怎么分块
• 决定主路径和次路径如何切换
• 决定页面之间能不能自然扩展

我当前做的“历史视界”项目，就是一个很适合写“页面层架构设计”的例子。因为它已经不是单页 Demo，而是形成了比较完整的页面体系：

• 首页 Index
• 今日页 TodayPage
• 挑战页 ChallengePage
• 人物页 FiguresPage
• 成就页 AchievementsPage
• 我的页 MinePage
• 事件详情页 EventDetailPage
• 收藏页、设置页、卡片管理页等次级页面

这篇文章我就结合项目现有代码，聊聊一个 HarmonyOS 学习类应用，是如何从页面层去搭建完整结构的。

---

二、为什么页面层设计很重要？ 👀

一个项目如果页面层设计混乱，通常会有几个明显问题：

• 首页内容越来越臃肿
• 页面跳转关系不清晰
• 详情页和列表页边界模糊
• 功能越加越散，后期维护成本飙升

而“历史视界”目前比较好的地方，在于它没有把所有能力塞进一个页面，而是形成了比较清晰的层级：

1. 一级页面负责核心入口

例如：

• 今日
• 挑战
• 人物
• 成就
• 我的

这些页面承接的是用户最常访问的主路径。

2. 二级页面负责具体任务

例如：

• 事件详情页
• 设置页
• 收藏页
• 卡片管理页
• 题目挑战页

这些页面不是常驻入口，而是承接某个具体动作之后的深入操作。

这种层级划分本身，就是一个很值得写进文章的页面层设计思路。

---

三、入口层：用 Index.ets 把全局页面关系组织起来 🧭

项目的页面层入口很清晰，主入口由 Index.ets 承担。
它不是单一业务页，而是整个应用的导航容器。

代码节选如下：

private navItems: NavItem[] = [
  { index: 0, name: '今日', icon: '📅' },
  { index: 1, name: '挑战', icon: '⚡' },
  { index: 2, name: '人物', icon: '👤' },
  { index: 3, name: '成就', icon: '🏅' },
  { index: 4, name: '我的', icon: '🎯' }
];

这个设计有几个优点：

• 首页不是内容页，而是“全局页面调度页”
• 主模块边界清楚，不容易互相侵入
• 新增功能时，容易判断它属于哪个页面层级

换句话说，Index 相当于整个项目的页面骨架，而不是普通页面之一。

---

四、内容首页：TodayPage 是典型的模块化页面设计 📚

如果说 Index 负责入口调度，那么 TodayPage 更像这个项目的内容核心页。

它最值得讲的地方，是没有把首页做成一个单纯信息流，而是拆成了多个学习模块：

/** 0数据 1脉络 2今日 3事件库 4考点 */
@State activeTodayModule: number = 2;

这段代码其实很能说明页面层思路。
因为它意味着首页不是一个静态页面，而是一个“由多个内容区块构成的组合页”。

从页面层设计角度看，这种做法有明显优势：

• 首页可以承接更多内容，但不会失控
• 每个模块都可以单独演进
• 后续可以根据用户行为调整模块优先级

例如目前的首页结构大致可以理解为：

• 学习概况
• 历史脉络
• 今日历史
• 事件库
• 考点卡片

这比单纯堆列表更像真正的学习型首页。

---

五、页面层里的“列表页”和“详情页”边界很清晰 🔍

很多项目后面越写越乱，一个很常见的原因就是列表页和详情页没有分工。

而这个项目里，事件相关内容就分得比较清楚：

1. 列表或聚合页负责发现内容

例如：

• 今日页里展示今日历史事件
• 事件库里负责筛选浏览
• 时间轴里负责串联历史脉络

2. 详情页负责承接深阅读

EventDetailPage.ets 里就很典型：

Text(this.event.title)
Text(this.event.description)
Text(this.event.impact)

同时还补了关联内容：

• 事件经过
• 历史影响
• 同朝代事件
• 收藏状态

这就说明页面层已经形成了比较成熟的阅读链路：

1. 在聚合页面发现内容
2. 点击进入详情页
3. 在详情页完成深读、收藏和关联跳转

这个路径非常适合写进文章，因为它符合内容型应用最核心的页面组织原则。

---

六、功能型页面和内容型页面，在页面层中承担不同职责 ⚙️

除了内容页，这个项目还有一批很典型的功能型页面，比如：

• SettingsPage
• FavoritesPage
• CardManagePage
• ChallengePage

这类页面和 TodayPage、FiguresPage 这种内容承载页不一样，它们更多负责“操作”和“状态管理”。

1. 设置页是系统控制型页面

设置页的角色非常明确：

• 主题切换
• 反馈入口
• 恢复默认设置
• 版本信息

也就是说，它不是用来承载内容的，而是给用户一个“管理应用状态”的地方。

2. 收藏页是资产整理型页面

收藏页把事件、人物、题目等内容做了聚合管理，这类页面在页面层中的价值是：

• 把分散内容重新组织
• 提供统一查看与移除入口
• 形成用户自己的学习资产空间

3. 卡片管理页是工具型页面

卡片管理页支持：

• 搜索
• 年级筛选
• 删除卡片
• 统计数量

它更像一个学习工具页，而不是内容浏览页。

从页面层角度看，清楚地区分这些页面职责，后续扩展会轻松很多。

---

七、人物页和成就页，分别体现了两种不同的页面层设计思路 👤🏅

1. 人物页是“列表 + 弹层详情”的页面模式

FiguresPage.ets 中，人物卡片列表是主视图，点击后通过弹层展示详情：

this.showDetail = true;
this.selectedFigure = figure;

这种模式适合：

• 信息量中等
• 用户希望快速浏览多个对象
• 不一定需要切走当前上下文

也就是说，人物页采用的是“轻详情”思路。

2. 成就页是“状态总览 + 分类切换”的页面模式

AchievementsPage.ets 的重点不在详情，而在总览和筛选：

@State selectedCategory: AchievementCategory = 'all';
@State unlockedCount: number = 0;

它更像一个成长看板页，主要承担：

• 显示解锁进度
• 展示分类成果
• 强化反馈与激励

这说明项目在页面层上并没有套同一种模板，而是根据业务类型选择了更适合的页面结构。

---

八、页面跳转关系清晰，是页面层是否成熟的重要标志 🔁

项目当前的主页面关系其实已经比较清楚了，可以概括为下面这几条线：

1. 主导航线

Index -> Today / Challenge / Figures / Achievements / Mine

2. 内容深入线

TodayPage -> EventDetailPage

3. 我的页面功能线

MinePage -> FavoritesPage / CardManagePage / SettingsPage / AboutPage

4. 挑战任务线

ChallengePage -> ChallengeKnowledgePage -> ChallengeQuizPage

这几条线分工明确以后，页面职责就不会乱。
用户也更容易理解自己当前处在哪个层级。

对于 CSDN 文章来说，你完全可以把这一部分画成一个页面关系图，读者会更容易感受到项目的结构完整度。

---

九、从工程角度看，这样的页面层还有哪些好处？ 🛠️

页面层清晰之后，不只是用户体验更好，开发上也有很多收益：

1. 页面职责明确，便于协作

以后无论是继续加新功能，还是多人协作开发，都更容易拆工。

2. 公共逻辑更容易抽取

比如：

• 设备判断抽到 DeviceUtils
• 动画抽到 AnimationUtils
• 收藏逻辑抽到 FavoritesManager

页面只负责自己的展示和交互，不会变成“大杂烩”。

3. 扩展新页面更自然

比如后续如果新增：

• 错题本页面
• 学习报告页
• 朝代专题页

都能比较容易找到它在当前页面层中的位置。

---

十、如果继续优化，我会怎么升级这个项目的页面层？ 🚀

基于当前结构，我觉得后面可以继续往这几个方向优化：

1. 首页模块进一步组件化

把“今日历史”“历史脉络”“事件库”“考点卡片”都抽成更明确的首页区块组件。

2. 平板上引入更多双栏页面

比如事件详情页、收藏页、人物页，都可以在平板上改成并排结构。

3. 页面间状态传递进一步标准化

目前已经有 router.pushUrl 和参数传递，后续可以继续梳理详情页、收藏页、挑战页之间的状态同步机制。

4. 二级页面视觉语言进一步统一

比如顶部返回栏、标题区、操作区、列表区的结构可以再统一一层。

---

十一、结语 📝

页面层设计，决定了一个 HarmonyOS 项目后续能走多远。

“历史视界”这个项目之所以适合写页面层文章，不只是因为页面数量多，而是因为它已经具备了比较清晰的结构意识：用 Index.ets 做全局入口层，用 TodayPage 做模块化内容首页，用 EventDetailPage 承接深阅读，用 SettingsPage、FavoritesPage、CardManagePage 等页面承接功能操作，再用 ChallengePage 这类任务型页面形成完整学习路径。

对于 OpenHarmony / HarmonyOS 应用开发来说，这样的页面层设计非常有参考价值。因为真正成熟的项目，不是页面越多越好，而是每个页面都知道自己该解决什么问题。只要页面层站稳了，后面的组件化、动效优化、多端适配和智能能力集成，都会变得顺畅很多。🌟