摘要

从 2019 年 HarmonyOS 首次发布至今，鸿蒙生态已经逐渐完成了从「分布式操作系统」理念提出，到「HarmonyOS NEXT 全栈自研生态」逐步落地的发展历程。对于开发者而言，这几年的变化远不止 API 数量的增加，更重要的是开发思想、应用架构以及跨设备能力的不断演进。

如果说 HarmonyOS 3.x、4.x 时代，开发者更多关注的是分布式能力和 ArkUI 的逐步成熟，那么进入 HarmonyOS 6.1 后，一个更加明显的趋势开始出现——系统能力越来越多地服务于用户体验本身。例如悬浮页签、沉浸光感、实况窗等新能力，不再只是简单的组件更新，而是围绕「降低交互成本」「增强实时信息表达」「提升多设备体验一致性」进行的一次整体升级。

与此同时，HarmonyOS 7.0 也逐渐进入开发者视野。随着开发工具、系统能力以及应用框架持续演进，我们可以明显感受到鸿蒙正在从「支持多设备开发」逐步迈向「围绕场景构建统一体验」。

作为一名持续关注鸿蒙生态发展的开发者，我也经历了从 Java FA 模型，到 Stage 模型，再到 ArkTS 声明式开发的整个过程。一路走来，有过不少踩坑经历，也见证了鸿蒙开发效率不断提升的变化。

本文将结合 HarmonyOS 6.1 的实际开发体验，对多个创新能力进行分析，并结合 HarmonyOS 7.0 已公开的发展方向，分享个人对于未来鸿蒙应用开发的一些思考，希望能够给正在学习或者准备进入鸿蒙生态的开发者提供一些参考。

一、为什么我仍然坚持学习鸿蒙开发

说实话，刚开始接触鸿蒙的时候，我并没有意识到它和传统移动开发到底有什么本质区别。

那时候很多人讨论最多的话题还是：

鸿蒙是不是 Android？

对于刚入门的开发者来说，这类讨论其实意义并不大。真正影响开发体验的，是每天写下的每一行代码，是一次次编译运行后的效果，也是一个页面从设计稿真正变成可以交互的应用时带来的成就感。

第一次打开 DevEco Studio，我最大的感受就是「陌生」。

ArkTS 与传统 Java、Kotlin 的写法不同，ArkUI 声明式开发也和 XML 布局时代完全不是一个思路。刚开始的时候，我甚至会下意识地去寻找类似 Android Fragment、Activity 的开发方式，却发现鸿蒙已经采用了完全不同的 Stage 模型。

这种陌生感持续了很长一段时间。

例如：

• 为什么页面状态改变以后 UI 会自动刷新？
• 为什么不用 findViewById？
• 为什么组件几乎都是链式调用？
• 为什么生命周期和以前不一样？

这些问题困扰了我很久。

直到真正完成几个完整项目之后，我才逐渐理解官方为什么要推动声明式开发。

传统 UI 开发，本质上是在告诉系统：

我要如何修改页面。

而 ArkUI 更倾向于表达：

当前页面应该是什么样。

这种思想上的变化，看似只是写法不同，实际上意味着整个开发模式发生了改变。

页面开始围绕状态进行构建。

UI 成为了状态的映射。

开发者更多关注业务本身，而不是繁琐的界面刷新逻辑。

当真正适应这种开发方式以后，再回头看以前大量操作 View 的代码，反而会觉得复杂。

随着项目越来越多，我也开始注意到另外一个变化。

鸿蒙官方近年来越来越强调"体验一致性"。

以前我们更多讨论：

页面怎么写？

动画怎么做？

组件怎么封装？

而现在官方文档越来越多地提到：

• 用户体验连续性
• 跨设备体验一致性
• 实时信息展示
• 系统级交互能力
• AI 与系统能力融合

这些关键词说明，鸿蒙的发展重点已经不仅仅停留在应用开发层面，而是在逐步构建完整的操作系统生态。

对于开发者而言，这意味着未来竞争力不仅来自代码能力，更来自对系统能力的理解和运用。

我也曾经怀疑过：

现在学习鸿蒙还有没有意义？

后来参加一些开发者活动、阅读官方更新日志、体验新版本系统之后，我发现答案其实越来越明确。

一个平台是否值得投入，并不只是看它今天拥有多少应用，而要看它是否仍然保持快速演进。

从 ArkUI 的持续完善，到 ArkTS 能力不断增强，再到 HarmonyOS 6.1 一系列新特性的推出，可以看到鸿蒙仍然保持着较快的发展节奏。

对于开发者来说，这意味着：

每一次版本升级，都可能带来新的开发机会。

而真正能够抓住这些机会的人，往往不是等生态完全成熟以后才开始学习，而是在生态不断成长过程中持续积累经验。

我想，这也是我一直坚持学习鸿蒙开发的重要原因。

二、HarmonyOS 生态的发展变化：从分布式理念到场景化体验

很多开发者第一次接触鸿蒙时，都会将它与 Android、iOS 进行比较。

这种比较并没有错，因为对于绝大多数移动开发者来说，已有的开发经验就是理解新平台最直接的参照物。

但真正深入学习一段时间以后，我越来越觉得，HarmonyOS 与传统移动操作系统最大的不同，并不只是系统底层架构，而是它对于"设备"这一概念的重新定义。

在 Android 开发中，我们通常默认应用运行在一部手机上。

页面属于手机。

数据属于手机。

能力属于手机。

即使后来出现了平板、电视、手表等终端，开发模式依然更多是"针对不同设备开发不同版本"。

而 HarmonyOS 从设计之初提出的理念，就是希望打破这种设备之间天然存在的边界。

官方提出的"一次开发，多端部署"、"分布式能力"、"超级终端"等概念，本质上都是围绕这一目标展开。

刚开始接触这些概念时，我一度觉得它们距离实际开发还有些遥远。

直到后来真正开始尝试开发跨设备应用，才逐渐理解官方为什么一直强调"场景"而不是"设备"。

因为对于最终用户来说，他们关注的从来不是应用运行在哪一块屏幕上，而是希望自己的任务能够自然地延续。

例如：

早晨出门前，我可以在手机上查看待办事项；

进入汽车后，导航信息能够自然接续；

回到办公室后，同一份文档继续在平板上编辑；

晚上回家后，再通过智慧屏查看当天的数据统计。

整个过程中，用户完成的是同一件事情，而不是分别操作四个不同设备。

这正是 HarmonyOS 希望构建的体验。

2.1 从设备中心到场景中心

官方文档中多次提到"场景化体验"。

第一次看到这个词的时候，我理解得并不深。

后来在阅读更多开发资料，并结合自己做项目的过程后，我发现这个词实际上意味着开发思路发生了明显变化。

过去开发应用时，我们通常会先问自己：

这个页面放在哪里？

这个按钮应该怎么布局？

这个功能属于哪个 Activity？

而现在更多思考的问题变成：

用户完成这个任务需要经历哪些步骤？

哪些系统能力能够主动参与？

哪些信息应该持续展示？

哪些能力可以跨设备共享？

这种思维方式的改变，看似只是问题不同，实际上直接影响整个应用架构。

举一个很简单的例子。

以前开发一个运动记录应用，大多数逻辑都会集中在手机端完成。

开始运动。

记录数据。

结束运动。

生成报告。

整个过程始终围绕手机展开。

但在 HarmonyOS 场景下，情况开始发生变化。

手表负责实时采集心率。

耳机负责播放运动提醒。

手机负责地图与数据展示。

智慧屏负责运动总结。

每一个设备承担不同角色，但共同完成一次运动体验。

开发者关注的不再是哪一个设备，而是整个运动场景。

这种变化，也意味着系统能力越来越重要。

2.2 Stage 模型带来的开发模式变化

如果说 ArkTS 改变的是语言表达方式，那么 Stage 模型改变的就是整个应用架构。

很多刚从 Android 转过来的开发者都会有类似疑问：

为什么没有 Activity？

为什么页面生命周期变了？

为什么 Ability 和以前理解的不一样？

其实官方已经给出了非常明确的发展方向。

HarmonyOS 当前推荐开发者全面采用 Stage 模型。

相比早期的 FA（Feature Ability）模型，Stage 更强调应用整体生命周期管理。

刚开始迁移项目时，我最大的感受就是：

以前很多生命周期逻辑需要重新整理。

例如页面初始化。

资源释放。

Ability 之间通信。

窗口管理。

这些能力都进行了统一调整。

一开始确实有些不习惯。

尤其是以前很多代码依赖生命周期执行顺序。

迁移以后，需要重新思考整个业务流程。

但随着项目逐渐完成，我发现 Stage 最大的优势其实是结构更加清晰。

应用生命周期。

页面生命周期。

窗口生命周期。

它们各自职责更加明确。

很多以前容易混淆的问题，现在官方都进行了规范。

这对于大型项目而言尤其重要。

2.3 ArkTS：不仅仅是一门语言

很多刚开始学习鸿蒙的人都会把 ArkTS 理解成：

"TypeScript 加一点语法糖。"

实际上，这只是表面现象。

ArkTS 最大价值并不仅仅是语言本身，而是它与 ArkUI、状态管理、声明式开发之间形成了一套完整开发体系。

第一次真正理解状态驱动 UI，是在写一个简单计数器的时候。

以前 Android 时代：

修改数据。

找到 TextView。

调用 setText()。

刷新页面。

整个过程都需要开发者主动控制。

而 ArkUI 中更倾向于：

状态变化。

UI 自动更新。

页面只是状态的一种映射。

刚开始觉得这种方式有些"神奇"。

后来真正写复杂页面以后才发现，这种模式可以明显减少很多重复代码。

例如一个订单页面。

订单状态改变以后。

按钮颜色。

文字内容。

进度提示。

操作入口。

全部都会随着状态自动更新。

开发者几乎不用再关心哪个组件需要刷新。

这种开发体验，对于复杂业务来说提升非常明显。

当然，它也意味着开发者需要改变以前的思维方式。

不要再想着：

"我要修改哪个控件。"

而应该思考：

"当前状态是什么。"

UI 自然就会变化。

2.4 声明式开发真正改变了什么

很多介绍 ArkUI 的文章都会强调：

声明式开发。

响应式更新。

状态驱动。

这些概念大家都已经很熟悉。

但真正让我感受到变化的，并不是这些名词，而是维护成本。

以前一个页面几百行代码。

其中相当一部分其实都是：

初始化。

查找控件。

绑定事件。

修改属性。

控制显示隐藏。

业务逻辑反而没有多少。

后来项目越来越大。

维护成本越来越高。

经常修改一个按钮状态，就需要在多个地方同步调整。

而声明式开发最大的优势就在于：

页面描述的是最终结果。

而不是修改过程。

例如：

当用户登录成功。

头像显示。

昵称显示。

退出按钮显示。

未登录提示隐藏。

整个页面实际上只依赖一个登录状态。

开发者无需逐个修改组件。

代码可读性也明显提升。

这种变化，在团队协作时尤其明显。

新人阅读代码，不需要沿着几十个回调去寻找 UI 更新逻辑。

只要理解状态来源，就能够快速理解整个页面。

2.5 HarmonyOS 6.1 为什么更加重视系统能力

如果说前几个版本更多是在完善开发框架，那么 HarmonyOS 6.1 给我最大的感受，就是越来越强调"系统参与体验"。

例如官方新增的一些能力：

• 实况窗（Live View）
• 悬浮页签
• 沉浸光感
• 更多系统级交互体验优化

这些能力看似只是几个新特性。

实际上体现的是设计理念变化。

以前应用更多是：

打开。

使用。

退出。

整个生命周期几乎完全发生在应用内部。

而现在越来越多的信息，会直接出现在系统层。

用户甚至不用打开应用，就能够了解到当前状态。

例如：

外卖配送。

打车进度。

导航状态。

运动记录。

会议提醒。

物流更新。

这些实时信息如果仍然完全依赖应用页面展示，交互成本其实很高。

而系统级能力的加入，让信息展示更加自然。

开发者需要思考的不再只是"页面怎么设计"，而是"哪些信息应该在系统层持续呈现，哪些交互适合放在应用内完成"。

这种能力也意味着，未来优秀的鸿蒙应用，不一定拥有最复杂的界面，而是能够更好地融入系统，为用户提供连续、一致、低打扰的体验。

2.6 从开发者角度看 HarmonyOS 7.0 的演进方向

随着 HarmonyOS 7.0 的推进，官方持续释放新的开发方向与能力演进信号。相比单纯增加 API 数量，我更关注的是几个长期趋势：

第一，是开发框架持续完善。ArkUI 与 ArkTS 的协同能力不断增强，声明式开发体验进一步成熟，开发者能够用更少的代码表达更复杂的界面逻辑。

第二，是跨设备体验进一步深化。开发目标不再局限于"适配更多设备"，而是围绕用户任务实现自然流转，让应用真正融入多终端协同场景。

第三，是系统能力开放更加丰富。越来越多系统级能力通过统一接口向开发者开放，使应用能够与通知、窗口、卡片、元服务等能力形成更紧密的协同关系。

第四，是开发工具链持续优化。从 DevEco Studio 到调试工具、性能分析工具，再到工程管理能力，都在不断降低开发和维护成本。

我认为，对于开发者而言，HarmonyOS 的价值已经不仅仅体现在学习一套新的 API，而是在学习一种新的应用设计理念——以用户场景为中心，以状态驱动界面，以系统能力构建连续体验。

三、HarmonyOS 6.1 创新特性适配实战：从“功能可用”到“体验优秀”

第一次看到 HarmonyOS 6.1 的更新说明时，我并没有急着去看新增了多少 API，而是先体验了一段时间系统。

因为我一直认为，一个操作系统版本真正有价值的地方，并不是增加了多少接口，而是这些能力是否真的能够改善用户体验。

开发者其实很容易陷入一种误区：认为版本更新就是学习几个新组件、调用几个新接口，项目就完成了适配。

但真正做过线上项目以后就会发现，用户几乎不会关心你的应用使用了哪个 API，他们只会感受到这个应用是不是更顺手、更自然、更符合自己的使用习惯。

HarmonyOS 6.1 给我的一个明显感受，就是系统开始更多地参与到应用体验之中。

以前，应用几乎是一个相对独立的空间。

用户打开应用、完成操作、退出应用。

而现在，越来越多的信息开始在系统层持续存在，越来越多的交互开始发生在应用之外。

这意味着开发者的思维也需要发生变化。

过去我们关注的是：

页面应该如何设计？

现在更多需要思考：

哪些能力应该交给系统完成？哪些信息需要持续陪伴用户？

这种理念上的变化，也是我认为 HarmonyOS 6.1 最值得学习的地方。

3.1 为什么说 HarmonyOS 6.1 更强调“体验设计”

刚开始学习鸿蒙的时候，我更关注的是：

页面怎么写？

动画怎么做？

状态怎么管理？

直到真正参与一个持续迭代的项目以后，我才发现，一个应用是否优秀，很多时候并不是因为页面炫酷，而是因为它能够减少用户操作。

举一个很简单的例子。

以前查看快递物流，大概需要这样几个步骤：

打开手机。

找到快递 App。

进入订单页面。

点击物流详情。

等待页面加载。

查看当前状态。

整个流程下来，需要用户主动完成多个操作。

但实际上，大多数时候用户真正关心的只有一句话：

快递现在到哪里了？

如果系统能够直接把这一信息展示出来，那么很多重复操作其实完全可以省略。

HarmonyOS 6.1 新增的一些系统能力，本质上就是围绕这种思路展开。

开发者需要做的，不再只是设计一个漂亮的页面，而是思考：

什么时候应该打开应用？

什么时候其实不用打开应用？

哪些信息应该一直存在？

哪些信息应该及时消失？

这是 HarmonyOS 官方近年来一直强调的"场景体验"。

3.2 实况窗（Live View）带来的体验变化

在 HarmonyOS 6.1 的更新内容中，我最关注的就是实况窗。

第一次看到官方演示时，我想到的并不是它有多炫，而是：

终于有一种能力，可以让应用的信息持续存在，而不是停留在应用页面里。

很多应用其实都有实时状态。

例如：

• 外卖配送
• 打车订单
• 地图导航
• 倒计时
• 健身记录
• 航班动态
• 快递运输
• 比赛比分

这些信息最大的特点就是：

持续变化。

如果仍然依赖用户不断打开应用刷新，其实体验并不好。

因此，HarmonyOS 将这些实时变化的信息，通过系统能力统一呈现。

对于开发者而言，这意味着：

应用不仅仅是一个页面集合，而是系统体验的一部分。

哪些业务适合接入实况窗？

根据官方推荐场景，以及我自己的理解，大概可以分成几类。

第一类，是实时进度型。

例如：

• 快递运输
• 外卖配送
• 打车接驾
• 文件下载

特点都是：

状态不断变化。

用户频繁关注。

第二类，是持续计时型。

例如：

运动。

会议。

直播。

录音。

倒计时。

这些业务都具有明显时间属性。

第三类，是导航类。

包括：

驾车导航。

骑行导航。

步行导航。

用户需要持续获取当前位置。

第四类，是赛事或活动。

例如：

体育比赛。

演唱会。

会议签到。

课程提醒。

这些信息更新频率高，同时用户希望第一时间看到。

因此，并不是所有应用都适合接入实况窗。

如果只是普通资讯阅读，其实没有必要为了适配而适配。

3.3 接入新能力之前，我踩过哪些坑？

第一次准备尝试这些新能力时，我最大的误区就是：

把它当成普通页面开发。

后来发现完全不是这样。

例如：

以前开发订单详情。

所有信息都放在页面里面。

进入页面以后：

查询接口。

刷新列表。

更新状态。

退出页面。

整个生命周期结束。

但是系统级能力意味着：

即使应用已经退到后台。

甚至页面已经销毁。

系统仍然需要知道：

订单是不是更新了？

配送是不是继续？

导航是不是结束？

因此后台状态同步就显得更加重要。

以前很多项目：

状态保存在页面。

页面销毁。

状态一起消失。

后来重新设计以后。

更多状态开始交给统一的数据层管理。

页面只是展示。

系统能力也是展示。

这样整个架构就清晰很多。

3.4 悬浮页签适配实践

如果让我评价 HarmonyOS 6.1 哪一个能力最容易提升用户体验。

我会选择：

悬浮页签。

原因其实很简单。

很多应用页面越来越复杂。

例如：

新闻。

商城。

社区。

视频。

音乐。

一个页面里面经常有：

推荐。

关注。

热门。

最新。

附近。

多个 Tab。

以前用户切换这些内容时，经常需要：

重新滑动。

重新定位。

重新寻找。

而 HarmonyOS 新的交互方式，让页面切换更加自然。

刚开始我认为：

这只是 UI 优化。

后来真正自己做页面以后发现：

其实背后最大的挑战，是状态同步。

例如：

用户停留在哪一个 Tab？

滚动位置是多少？

返回以后是否恢复？

不同 Tab 是否缓存？

这些都直接影响体验。

以前项目里，我曾经因为没有保存滚动状态。

导致用户每次返回页面。

都重新回到顶部。

后来自己体验以后才发现：

这种小问题，比页面不好看更容易影响使用感受。

因此后来所有列表页面。

我都会优先考虑：

状态恢复。

数据缓存。

页面连续性。

这也是 HarmonyOS 官方一直强调：

减少用户操作成本。

3.5 沉浸光感：细节体验的重要性

第一次看到官方介绍沉浸光感时，我其实有一点疑惑。

"颜色变化真的有那么重要吗？"

后来真正体验系统以后，我发现：

很多体验，其实并不会让用户主动说出来。

但是一旦没有，就会觉得哪里不舒服。

例如：

播放器。

相册。

视频。

阅读。

这些应用都有明显主题色。

如果整个系统仍然保持固定背景。

界面就会显得比较割裂。

而 HarmonyOS 希望做到：

应用内容。

页面背景。

系统元素。

共同形成一致视觉体验。

虽然开发过程中，我们更多还是按照官方规范适配。

但是从最终效果来看。

整体沉浸感确实提升不少。

3.6 从 6.0 升级到 6.1，我总结出的几点经验

经过几个项目升级之后，我逐渐形成了一套自己的升级流程。

第一，不要一开始就改业务代码。

先升级 SDK。

确认工程能够正常编译。

第二。

阅读官方 Release Note。

不要直接开始修改。

先了解：

新增哪些能力。

废弃哪些接口。

哪些行为发生变化。

第三。

优先适配官方推荐能力。

例如：

新的系统体验。

新的交互规范。

新的设计要求。

第四。

完成适配以后。

一定要重新测试：

页面生命周期。

后台恢复。

深浅色模式。

横竖屏。

字体缩放。

分屏模式。

很多问题。

其实都不是代码错误。

而是新的系统行为导致。

第五。

最后再进行性能分析。

观察：

页面启动时间。

内存占用。

动画流畅度。

资源释放。

这些往往比新增几个功能更加重要。

本章小结

HarmonyOS 6.1 带给开发者的价值，并不仅仅在于增加了新的系统能力，更重要的是推动开发者重新思考应用与系统之间的关系。

过去，我们习惯将应用看作一个相对独立的空间，所有交互都围绕页面展开；而在 HarmonyOS 的设计理念中，应用开始逐渐融入整个操作系统生态，与系统能力共同构建完整的用户体验。

实况窗让实时信息能够持续陪伴用户，而不是局限于应用内部；悬浮页签优化了复杂内容场景下的导航效率，使页面切换更加自然；沉浸光感则通过系统级视觉协同，进一步提升了界面的整体一致性。这些能力看似各自独立，但背后体现的是同一种设计思想——以用户任务为中心，而不是以页面为中心。

对于开发者而言，真正需要适配的不只是新增接口，更是开发思维。从功能实现到体验设计，从页面开发到场景构建，这种转变也是 HarmonyOS 持续演进过程中最值得关注的方向。

四、基于 HarmonyOS 6.1 构建智慧待办应用实战——从工程搭建到完整开发

前面几章更多讨论的是 HarmonyOS 的开发理念以及 HarmonyOS 6.1 的新能力。但如果这些理念最终不能落地到真实项目，那么学习它们的意义就会大打折扣。

因此，从这一章开始，我不再单独介绍某一个 API，而是结合一个完整项目，把前面提到的开发思想串联起来。

项目名称我暂时命名为 SmartTodo（智慧待办）。

之所以选择待办类应用，并不是因为它足够简单，而是因为它几乎能够覆盖鸿蒙应用开发中的大多数基础能力：

• ArkUI 声明式页面开发；
• Stage 模型应用架构；
• Navigation 路由导航；
• @State、@Prop、@Link 等状态管理；
• Preferences 数据持久化；
• 生命周期管理；
• 深色模式适配；
• 响应式布局；
• HarmonyOS 6.1 新交互体验适配。

虽然只是一个看似普通的待办应用，但如果按照企业项目的思路进行设计，它已经足以覆盖一个中小型鸿蒙应用的大部分开发流程。

4.1 项目需求分析

真正开始编码之前，我习惯先把需求写下来，而不是直接创建页面。

很多开发者刚开始学习的时候，喜欢边写边想。

页面写一点。

功能补一点。

最后发现整个工程越来越乱。

后来做项目越来越多，我逐渐养成了一个习惯：

先画流程。

再设计数据。

最后再开始写代码。

SmartTodo 的核心需求如下：

用户功能

• 新建待办事项；
• 编辑待办事项；
• 删除待办事项；
• 完成待办事项；
• 查看今日任务；
• 查看全部任务；
• 根据优先级排序；
• 根据完成状态筛选。

系统功能

• 自动保存数据；
• 页面状态恢复；
• 深色模式支持；
• 横竖屏适配；
• 大字体适配；
• 页面动画；
• 长按菜单；
• 下拉刷新。

这些需求看起来并不复杂，但已经覆盖了 HarmonyOS 官方推荐的大部分开发能力。

4.2 工程目录设计

刚开始学习的时候，我所有页面都会放在 pages 目录。

后来项目越来越大。

几十个页面以后。

根本找不到代码。

于是我开始按照官方推荐思路重新整理目录。

entry
│
├── ets
│
├── pages
│     HomePage
│     DetailPage
│     EditPage
│
├── model
│     TodoModel
│
├── viewmodel
│     TodoViewModel
│
├── service
│     PreferenceService
│
├── common
│     Constants
│
├── utils
│
├── component
│     TodoCard
│     EmptyView
│     FilterDialog
│
└── resources

为什么这样划分？

因为页面负责展示。

组件负责复用。

数据模型负责描述对象。

业务逻辑放到 ViewModel。

数据存储交给 Service。

这样即使项目继续扩大。

整个目录依然保持清晰。

这一点，也是后来我阅读不少官方示例之后最大的收获。

不要让页面承担所有事情。

4.3 数据模型设计

很多初学者喜欢直接定义几个变量：

title

content

time

虽然能运行。

但是后期维护会越来越困难。

因此我更喜欢先定义数据对象。

例如：

export class TodoItem {

  id:number

  title:string

  content:string

  createTime:number

  finish:boolean

  priority:number

}

这样以后：

新增字段。

接口返回。

本地存储。

都保持统一。

数据模型一旦稳定。

整个项目都会轻松很多。

4.4 页面状态管理

如果让我评价 ArkUI 最大的优势。

我一定会选择：

状态驱动。

第一次真正理解这一点。

是在开发列表页面的时候。

以前 Android 开发。

新增一个待办。

通常需要：

查询数据库。

刷新 Adapter。

notifyDataSetChanged()

重新计算数量。

重新刷新标题。

整个过程需要开发者自己控制。

而 ArkUI 完全不同。

例如：

@State
todoList:TodoItem[]=[]

新增数据以后。

页面自动刷新。

列表自动更新。

统计数字自动变化。

组件状态同步更新。

开发者几乎不用关心刷新逻辑。

这种开发体验。

第一次使用的时候确实会觉得非常舒服。

@State 为什么适合页面状态

很多刚接触 ArkTS 的开发者容易混淆：

什么时候使用 @State？

什么时候使用 @Prop？

什么时候使用 @Link？

我自己踩过不少坑。

后来总结出来一句话：

页面自己拥有的数据。

就是 State。

例如：

当前列表。

当前输入内容。

当前按钮状态。

当前加载状态。

这些都属于页面自身维护的数据。

因此使用：

@State

即可。

不要什么变量都放到全局。

否则后面会越来越难维护。

4.5 页面拆分的重要性

很多人的第一个项目都会写成这样：

HomePage

1500 行代码

包括：

顶部导航。

列表。

弹窗。

按钮。

菜单。

事件。

全部写一起。

刚开始感觉方便。

后来任何一个地方修改。

都会影响整个页面。

因此后来我的原则就是：

一个组件。

负责一件事情。

例如：

TodoCard

负责展示任务。

@Component
struct TodoCard{

}

FilterDialog

负责筛选。

@Component

struct FilterDialog{

}

EmptyView

负责空页面。

@Component

struct EmptyView{

}

最后。

HomePage 只负责：

组织组件。

管理状态。

页面一下就清晰很多。

4.6 Navigation 路由管理

HarmonyOS 新版开发推荐使用 Navigation。

相比以前字符串路由。

Navigation 最大优势就是：

页面组织更加清晰。

例如：

首页。

详情页。

编辑页。

可以形成完整导航关系。

以前我喜欢：

点击按钮。

直接跳页面。

后来项目复杂以后。

越来越容易出现：

返回异常。

页面重复。

生命周期混乱。

而 Navigation 将整个页面栈统一管理。

阅读官方文档以后。

我开始慢慢把项目全部迁移。

迁移完成最大的感受就是：

调试轻松很多。

尤其大型项目。

页面关系一目了然。

4.7 数据持久化

待办应用最大的特点就是：

退出以后。

数据不能丢。

很多开发者第一反应就是：

数据库。

其实对于这种轻量数据。

HarmonyOS 官方提供的 Preferences 已经足够。

例如：

保存任务。

保存主题。

保存配置。

保存排序方式。

读取速度快。

接口简单。

维护成本低。

真正复杂的数据。

再考虑关系数据库。

不要为了"高大上"。

什么项目都直接上数据库。

4.8 页面生命周期

HarmonyOS Stage 模型以后。

生命周期也发生了变化。

刚迁移的时候。

我最大的错误就是：

把所有初始化都写在页面创建里面。

后来发现。

有些数据。

页面回来以后。

已经变化了。

于是又开始手动刷新。

代码越来越乱。

后来阅读官方文档以后。

重新整理：

页面创建。

负责初始化。

页面显示。

负责刷新。

页面隐藏。

暂停任务。

页面销毁。

释放资源。

职责一下清晰很多。

4.9 页面性能优化

真正影响用户体验的。

很多时候不是功能。

而是流畅度。

我以前做列表。

喜欢：

进入页面。

一次加载全部。

后来数据越来越多。

明显开始卡顿。

后来调整以后：

分页。

懒加载。

按需刷新。

页面明显流畅很多。

另外。

图片。

动画。

定时器。

网络请求。

都尽量做到：

不用的时候立即释放。

这些优化。

平时感觉不到。

但是上线以后。

用户最容易感受到。

本章小结

通过 SmartTodo 项目的搭建，我最大的体会是：HarmonyOS 应用开发已经不再只是页面和接口的简单组合，而是一套围绕声明式开发、状态管理和工程化设计展开的完整开发体系。

从工程目录划分到数据模型设计，从状态驱动到组件拆分，再到 Navigation 路由管理和数据持久化，每一个环节都体现出官方推荐的开发理念——降低页面耦合、提升代码可维护性、增强应用的长期演进能力。

对于个人开发者来说，这种开发方式可能需要一定的适应过程；但当项目规模逐渐扩大后，它带来的收益会越来越明显。代码更容易阅读，模块更容易复用，后续迭代和多人协作的成本也会显著降低。