HarmonyOS 鸿蒙Next三层架构路由

HarmonyOS 鸿蒙Next三层架构路由 三层架构开发还有需要使用Navigation吗,普通router还能用吗?传统框架下router受到的限制,在三层架构下能得到释放吗

5 回复

【解决方案】

1、router可以使用但是推荐使用Navigation; 2、router仍有限制,具体如下: 当前HarmonyOS支持两套路由机制(NavigationRouter),Navigation作为后续长期演进及推荐的路由选择方案,其与Router比较的优势如下:

  • 易用性层面:
    • Navigation天然具备标题、内容、回退按钮的功能联动,开发者可以直接使用此能力;Router若要实现此能力,需要自行定义。
    • Navigation的页面是由组件构成,易于实现共享元素的转场;router仅用于被@Entry修饰的页面之间的跳转。
  • 功能层面:
    • Navigation天然支持一多,Router不支持。
    • Navigation没有路由数量限制,Router限制32个。
    • Navigation可以获取到路由栈NavPathStack,并对路由栈进行操作,Router不支持。
    • Navigation可以嵌套在模态对话框中,也就是说可以模态框中定义路由,Router不支持。
    • Navigation的组件全量由开发者自行控制,开发者可以自定义复杂的动效和属性的设置(背景、模糊等),Router的page对象不对外暴露,开发者无法对page进行处理。
  • 性能层面:
    • Navigation传递参数性能更优,Navigation通过引用传递,Router通过深拷贝完成。
    • Navigation可以配合动态加载,实现组件动态加载,Router页面使用@Entry进行修饰,当前模块加载时会生成全量页面。

使用场景选择

Navigation router
项目只有一个主模块,同一个模块内的页面之间跳转 项目包含多个模块,不同模块间的页面跳转。
比如项目有主项目,A、B模块,
主项目的H界面要跳转到A模块的I界面,
或者A模块的I界面要跳转到B模块的J界面

Navigation相比router功能更丰富,用法更灵活,且router后续不再演进新的功能,推荐使用Navigation。

更多关于HarmonyOS 鸿蒙Next三层架构路由的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html


核心区别

特性维度 组件导航 (Navigation) 页面路由 (Router / @ohos.router)
架构与定位 组件级容器,是ArkUI的一个组件,通常作为页面(@Entry)的根容器使用,内部管理NavDestination组件。 模块级API,是[@ohos](/user/ohos).router提供的一组方法,用于跳转到@Entry修饰的页面。
页面结构 分为导航页(Navbar)子页(NavDestination)。导航页包含标题栏、内容区、工具栏;子页是NavDestination组件。 每个页面都是一个独立的、由@Entry修饰的Component,需要在main_page.json中声明。
路由操作对象 通过导航控制器 (NavPathStack) 对象进行页面栈操作(如pushPathByName)。 通过[@ohos](/user/ohos).router模块的Router实例进行操作(如router.pushUrl)。
生命周期 生命周期以组件事件形式承载在NavDestination上(如onAppear, onDisappear),更精细。 生命周期是@Entry页面的通用方法(如aboutToAppear, onPageShow)。
核心优势 1. 更丰富的动效:支持系统/自定义转场、共享元素(geometryTransition)。
2. 更灵活的栈操作:支持移动页面(moveToTop)、清理指定路由(removeByName)。
3. 原生路由拦截:通过setInterception方法提供。
4. 一次开发多端部署:支持Auto模式,自适应单栏/分栏显示。
5. 内置标题栏/工具栏:可直接设置,支持沉浸式。
1. API简单直接,易于快速上手。
2. 历史较久,存量代码较多。

官方明确推荐

  1. Router已被降级和不推荐
    • Router的许多接口(如replaceUrl)已标记为 deprecated(废弃)
    • 文档标题明确标注Router为 “(不推荐)”
    • 在组件冻结等示例中,也注明“建议开发者使用组件导航(Navigation)代替页面路由(router)”。
  2. Navigation的优越性:Navigation在一多能力、路由拦截、共享元素动画、获取页面栈对象、沉浸式支持等方面均优于Router。

总结

  • Navigation 是ArkUI框架中功能更强、更现代、面向未来的路由解决方案。它提供了组件化的开发体验、更强大的动画和栈管理能力,并原生支持一次开发多端部署。
  • Router早期、正在逐步被替代的API,虽然目前仍可使用,但已不推荐在新项目中使用,官方引导开发者向Navigation迁移。
  • 对于新项目或重构现有项目,应首选并使用Navigation。从Router切换到Navigation是官方倡导的最佳实践。

能力对比

业务场景 Navigation Router
一次开发多端部署能力 支持,Auto模式自适应单栏跟双栏显示。 不支持
跳转指定页面 pushPath & pushDestination pushUrl & pushNameRoute
跳转HSP中页面 支持 支持
跳转HAR中页面 支持 支持
跳转传参 支持 支持
获取指定页面参数 支持 不支持
传参类型 传参为对象形式。 传参为对象形式,对象中暂不支持方法变量。
跳转结果回调 支持 支持
跳转单例页面 支持 支持
页面返回 支持 支持
页面返回传参 支持 支持
返回指定路由 支持 支持
页面返回弹窗 支持,通过路由拦截实现。 showAlertBeforeBackPage
路由替换 replacePath & replacePathByName replaceUrl & replaceNameRoute
路由栈清理 clear clear
清理指定路由 removeByIndexes & removeByName 不支持
转场动画 支持 支持
自定义转场动画 支持 支持,动画类型受限。
屏蔽转场动画 支持全局和单次。 支持,设置pageTransition方法duration为0。
geometryTransition共享元素动画 支持(NavDestination之间共享)。 不支持
页面生命周期监听 UIObserver.on(‘navDestinationUpdate’) UIObserver.on(‘routerPageUpdate’)
获取页面栈对象 支持 不支持
路由拦截 支持通过setInterception做路由拦截 。 不支持
路由栈信息查询 支持 getState() & getLength()
路由栈move操作 moveToTop & moveIndexToTop 不支持
沉浸式页面 支持 不支持,需通过window配置。
设置页面标题栏(titlebar)和工具栏(toolbar) 支持 不支持
模态嵌套路由 支持 不支持

HarmonyOS Next三层架构路由基于分布式软总线实现设备间通信,包含设备发现、连接建立、数据传输三个核心层。设备发现层通过Wi-Fi、蓝牙等协议自动识别周边设备;连接管理层负责安全认证与链路维护;数据传输层提供低延迟、高可靠的消息转发。该架构支持跨设备统一路由表,实现应用组件无缝迁移与协同。

在HarmonyOS Next的三层架构(应用级、模块级、页面级)中,路由机制有明确的划分,Navigation和普通Router的使用场景与之前有所不同。

  1. Navigation的使用:在三层架构中,Navigation主要用于应用内同一模块内的页面导航。它适用于模块内页面栈管理,例如在FA(Feature Ability)内部进行页面跳转。如果您的开发集中在单个模块内,Navigation仍然是推荐的方式。

  2. 普通Router的使用:普通Router(即router接口)仍然可用,但其主要职责更偏向于跨模块或应用级路由。例如,从应用的一个模块跳转到另一个模块,或通过URI方式启动其他Ability。在三层架构下,Router用于解耦模块间的直接依赖,支持动态路由和分发。

  3. 传统限制的释放:三层架构通过模块化设计,确实释放了传统路由的部分限制

    • 模块解耦:模块之间通过Router进行通信,而非硬编码依赖,便于独立开发、编译和部署。
    • 动态性增强:支持运行时动态加载和跳转到其他模块,提高了灵活性。
    • 导航清晰化:Navigation专注模块内,Router专注跨模块,职责分离更清晰。

总结:在三层架构下,Navigation和Router各司其职。模块内跳转优先使用Navigation,跨模块或应用级路由使用Router。这种设计提升了模块化程度和路由的灵活性,传统路由的限制在架构层面得到了优化。

回到顶部