前言
在 HarmonyOS 应用中,路由方案的选择直接影响应用架构。ArkUI 提供了两套路由方案:router(栈式)和Navigation(容器式)。xiexin 当前使用router方案,适用于简单栈场景。
本文将以 xiexin 的SplashPage.ets、Index.ets等页面为蓝本,详细剖析router和Navigation的差异,包括router.pushUrl/replaceUrl/back栈式路由、Navigation+NavDestination容器式路由,以及 xiexin 选择router的原因。
一、router 栈式路由
import { router } from '@kit.ArkUI'; // 压入新页面 router.pushUrl({ url: 'pages/ComposePage' }); // 替换当前页面 router.replaceUrl({ url: 'pages/Index' }); // 返回上一页 router.back(); // 返回指定页面 router.back({ url: 'pages/Index' });二、Navigation 容器式路由
import { Navigation, NavDestination } from '@kit.ArkUI'; @Entry @Component struct MyApp { build() { Navigation() { NavDestination() { Text('首页') } .title('首页') NavDestination() { Text('详情') } .title('详情') } } }三、方案对比
| 维度 | Router | Navigation |
|---|---|---|
| 路由模型 | 栈式 | 容器式 |
| 页面栈管理 | 自动管理 | 手动管理 |
| 参数传递 | params对象 | @State绑定 |
| 适用场景 | 简单栈场景 | 复杂嵌套场景 |
四、xiexin 的选型
xiexin 选择router的原因:
- 页面层级简单:最多 2-3 层栈深度
- 不需要嵌套导航:TabBar 在 Index 页面内部
- 代码量更少:
router比Navigation更简洁
HarmonyOS 功能实现示意图
总结
本文详细剖析了router和Navigation两套路由方案的差异,重点讲解了router.pushUrl/replaceUrl/back栈式路由、Navigation+NavDestination容器式路由,以及 xiexin 选择router的原因。
如果这篇文章对你有帮助,欢迎点赞👍、收藏⭐、关注🔔,你的支持是我持续创作的动力!
- HarmonyOS 应用开发指南:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/application-dev-guide
- HarmonyOS 状态管理概述:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-state-management-overview
- HarmonyOS 高性能编程实践:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-high-performance-programming
- HarmonyOS 自定义组件:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-custom-components
相关资源
- 开源鸿蒙跨平台社区:https://openharmonycrossplatform.csdn.net
- HarmonyOS Router 路由:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-routing
- HarmonyOS Navigation:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-navigation
十一、深度实现分析
11.1 核心原理
本功能的核心原理基于 ArkUI 的响应式状态管理机制。当 @State 或 @Prop 装饰的变量发生变化时,ArkUI 引擎会自动触发依赖该变量的 UI 部分重新渲染,无需手动操作 DOM。
11.2 数据流设计
graph LR A[用户交互] --> B[@State 变量变化] B --> C[ArkUI 引擎检测] C --> D[UI 重渲染] D --> E[用户看到新界面]11.3 性能考虑
- 避免不必要渲染:使用 @Watch 控制渲染时机
- 减少嵌套深度:保持组件树扁平化
- 合理使用缓存:计算结果可缓存避免重复计算
十二、实际项目应用
在 xiexin 项目中,本功能被应用于以下场景:
- 笔友列表:展示笔友通信状态和关系阶段
- 信件卡片:展示信件内容和状态标签
- 统计页面:展示写信趋势数据和统计指标
@Component export struct ExampleComponent { @Prop data: string[] = []; build() { Column() { ForEach(this.data, (item: string) => { Text(item).fontSize(14).padding(8) }, (item: string) => item) } } }十三、生产环境注意事项
- 错误处理:所有异步操作需要 try-catch 包围
- 日志记录:使用 hilog 记录关键操作和异常信息
- 性能监控:使用 hiTraceMeter 进行性能埋点分析
- 内存管理:及时清理定时器和监听器避免内存泄漏
try { await this.loadData(); hilog.info(0xFF00, 'TAG', 'Data loaded successfully'); } catch (err) { hilog.error(0xFF00, 'TAG', 'Failed to load: %{public}s', err.message); }十四、代码审查清单
- @Prop 变量是否已赋默认值
- 定时器是否在 aboutToDisappear 中清理
- 列表渲染的 keyGenerator 是否唯一且稳定
- 条件渲染是否使用 if/else 而非 Visibility.Hidden
- 复杂计算结果是否已缓存
- 事件监听器是否在 aboutToDisappear 中取消注册
十五、综合示例
@Entry @Component struct DemoPage { @State items: string[] = ['示例1', '示例2', '示例3']; @State count: number = 0; build() { Column({ space: 16 }) { Text('综合示例').fontSize(24).fontWeight(FontWeight.Bold) Text(`计数: ${this.count}`).fontSize(16) Row({ space: 8 }) { Button('增加').onClick(() => { this.count++ }) Button('减少').onClick(() => { if (this.count > 0) this.count-- }) Button('重置').onClick(() => { this.count = 0 }) } List() { ForEach(this.items, (item: string) => { ListItem() { Text(item).fontSize(14).padding(12) } }, (item: string) => item) }.height(200) }.padding(16).width('100%') } }十六、相关 API 参考
| API | 说明 | 版本要求 |
|---|---|---|
| @State | 组件内部状态管理 | API 9+ |
| @Prop | 父子单向传递 | API 9+ |
| @Link | 父子双向同步 | API 9+ |
| @Watch | 状态变化监听 | API 9+ |
| AppStorage | 全局状态存储 | API 9+ |
| PersistentStorage | 持久化存储 | API 9+ |
十七、代码规范与最佳实践
17.1 命名规范
- 组件命名使用 PascalCase,如
AvatarComponent、PenPalCard - 变量命名使用 camelCase,如
avatarSize、selectedIndex - 常量命名使用 UPPER_CASE,如
MAX_COUNT、DEFAULT_SIZE - 私有方法以下划线开头,如
_getAvatarColor - 文件命名使用 kebab-case,如
common-components.ets
17.2 代码组织
- 每个组件文件只包含一个 @Entry 组件
- 通用组件放在 components/ 目录下
- 页面组件放在 pages/ 目录下
- 常量配置放在 common/ 目录下
- 数据模型放在 model/ 目录下
十八、常见面试题
Q1: @State 和 @Prop 的区别是什么?
A: @State 是组件内部私有状态,只能在当前组件内修改;@Prop 是父组件传递进来的数据,在子组件中只能读取,修改不会影响父组件。
Q2: ForEach 的 keyGenerator 为什么重要?
A: keyGenerator 决定了 ForEach 进行 Diff 算法的依据。如果键值不稳定或重复,会导致列表项渲染异常,如闪烁、状态丢失等问题。
十九、调试技巧
- 使用 DevEco Profiler:监控帧率和布局耗时,定位卡顿根因
- 使用 hilog:打印关键日志,追踪代码执行路径
- 使用 hiTraceMeter:进行性能埋点分析,识别性能瓶颈
- 使用 @Watch:监听状态变化,调试状态更新逻辑
@State @Watch('onDebugChange') debugValue: string = ''; onDebugChange(): void { console.log('Value changed to:', this.debugValue); }二十、总结与最佳实践
20.1 核心要点总结
- 状态管理:合理选择 @State/@Prop/@Link/@StorageProp 装饰器
- 组件设计:遵循单一职责原则,保持组件聚焦
- 性能优化:大数据量使用 LazyForEach,组件复用使用 @Reusable
- 代码质量:编写单元测试,使用 Hypium 框架
- 样式管理:使用 AppColors 设计令牌统一管理颜色
20.2 避免的反模式
- 避免在 build 函数中执行耗时操作,这会阻塞 UI 渲染
- 避免在 @State 中存储大型对象,会导致不必要的重渲染
- 避免过度使用 @Link 增加组件耦合,优先使用 @Prop
- 避免在 aboutToAppear 中执行异步操作,使用生命周期合理分配
- 避免使用全局变量替代 @StorageProp,全局变量无法触发响应式更新
提示:以上最佳实践基于 xiexin 项目的实际开发经验总结,建议在项目开发中遵守这些原则,可以有效提升代码质量和开发效率。
如果这篇文章对你有帮助,欢迎点赞👍、收藏⭐、关注🔔,你的支持是我持续创作的动力!
相关资源:
- 开源鸿蒙跨平台社区:https://openharmonycrossplatform.csdn.net
- HarmonyOS 应用开发指南:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/application-dev-guide
- HarmonyOS 状态管理概述:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-state-management-overview
- HarmonyOS 高性能编程实践:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-high-performance-programming
- HarmonyOS 自定义组件:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-custom-components
- HarmonyOS 组件封装:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-component-encapsulation
- HarmonyOS @Builder 装饰器:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-builder
- HarmonyOS 组件复用:https://developer.huawei.com/consumer/cn/doc/harmonyos-guides/arkts-reusable
二十一、深度扩展阅读
21.1 组件设计原则
在 ArkUI 中设计组件时,需要遵循以下原则:
- 单一职责:每个组件只负责一个功能,避免职责过多
- 开闭原则:对扩展开放,对修改关闭,通过参数化配置实现
- 依赖倒置:依赖抽象而非具体实现,降低耦合度
- 接口隔离:使用小接口而非大接口,避免冗余依赖
21.2 性能优化策略
- 使用 LazyForEach:大数据量列表使用懒加载,只渲染可见项
- 组件复用:使用 @Reusable 装饰器复用组件,减少创建销毁开销
- 状态管理:合理使用 @State/@Prop/@Link,避免不必要重渲染
- 动画优化:使用 animateTo 替代 setInterval,减少 CPU 占用
21.3 代码示例
@Component export struct OptimizedComponent { @Prop items: string[] = []; @State selectedIndex: number = -1; build() { List() { LazyForEach(this.items, (item: string, index: number) => { ListItem() { Text(item).fontSize(16).padding(16) .backgroundColor(this.selectedIndex === index ? AppColors.AMBER_LIGHT : AppColors.WHITE) .onClick(() => { this.selectedIndex = index; }) } }, (item: string) => item) } .cachedCount(3) .scrollBar(BarState.Off) } }21.4 常见问题与解决方案
| 问题类型 | 具体问题 | 解决方案 |
|---|---|---|
| 编译错误 | @Prop 未赋默认值 | 在声明时添加默认值 |
| 运行时错误 | 路由参数未定义 | 添加空值检查 |
| 性能问题 | 列表渲染卡顿 | 使用 LazyForEach |
| 内存泄漏 | 定时器未清理 | 在 aboutToDisappear 中清理 |
| 状态丢失 | @State 变量未初始化 | 在声明时赋默认值 |
| 渲染异常 | ForEach 键值重复 | 使用唯一 ID 作为键值 |
21.5 推荐实践
- 使用 AppColors 设计令牌统一管理颜色,避免硬编码色值
- 使用 Constants.ets 集中管理常量,避免魔法数字
- 使用 DataStore 门面模式封装数据操作,统一访问入口
- 使用 @Builder 提取复用 UI 片段,减少重复代码
- 使用 @BuilderParam 实现组件插槽,提升组件灵活性
二十二、补充说明
提示:本文提供的代码示例基于 HarmonyOS API 12,适用于 HarmonyOS 5.0 及以上版本。如果你使用的是较低版本,部分 API 可能不兼容。
- 本文所有代码均可在 xiexin 项目中找到实际应用场景
- 建议结合 DevEco Studio 开发工具进行调试和验证
- 如有疑问,欢迎在评论区留言讨论,我会及时回复
- 更多 HarmonyOS 开发资源请参考官方文档和开发者社区
22.1 扩展阅读推荐
- HarmonyOS 应用开发指南
- ArkUI 声明式开发范式
- 状态管理详解
- 高性能编程实践
- 自定义组件
二十三、补充内容
23.1 代码规范与命名约定
在团队协作中,代码规范是保证代码质量的基础。以下是推荐的命名规范:
- 组件命名:使用 PascalCase,如
AvatarComponent、PenPalCard - 变量命名:使用 camelCase,如
avatarSize、selectedIndex - 常量命名:使用 UPPER_CASE,如
MAX_COUNT、DEFAULT_SIZE - 文件命名:使用 kebab-case,如
common-components.ets
23.2 注释规范
/** * 组件说明 * @param name 参数说明 * @param size 参数说明 */ @Component export struct MyComponent { @Prop name: string = ''; @Prop size: number = 48; }23.3 版本管理
- 每次发布前更新 versionCode 和 versionName
- 使用语义化版本号 X.Y.Z(主版本.次版本.修订版本)
- 记录版本变更日志,便于回溯问题
二十四、参考文档
- HarmonyOS 应用开发指南
- ArkUI 声明式开发范式
- 状态管理 V1
- 状态管理 V2
- 高性能编程实践
- 自定义组件
- 组件封装
- @Builder 装饰器