HarmonyOS 鸿蒙Next中Router有必要换成Navigation吗
HarmonyOS 鸿蒙Next中Router有必要换成Navigation吗 最近接手过来鸿蒙项目,发现一直用的router进行页面跳转,有必要替换成Navigation吗,我算了下,页面大概有70多个了,项目还算在初期,还有很多页面没迭代过来,
【解决方案】
Navigation相比router功能更丰富,用法更灵活,且router后续不再演进新的功能,推荐使用Navigation。
router与Navigation的差异可以参考:
当前HarmonyOS支持两套路由机制(Navigation和Router),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结构对比
- Navigation中的每个页面,承载在一个page里,通过NavDestination容器实现基于组件的页面跳转。
- Router的每一个页面配置在一个单独的page中,通过@Entry进行标识。
Navigation & Router能力对比
| 业务场景 | Navigation能力 | Router能力 |
|---|---|---|
| 跳转指定页面 | pushPath & pushDestination | pushUrl & pushNameRouter |
| 跳转HSP中页面 | 支持,需要先import页面 | 支持 |
| 跳转HAR中页面 | 支持,需要先import页面 | 支持 |
| 跳转传参 | 支持 | 支持 |
| 获取指定页面参数 | 支持 | 不支持 |
| 跳转结果回调 | 支持 | 支持 |
| 跳转单例页面 | 可通过判断栈内有没有此页面,调用moveToTop实现 | 支持 |
| 页面返回 | pop | back |
| 页面返回传参 | 支持 | 支持 |
| 返回指定路由 | popToName&popToIndex | 不支持 |
| 页面返回弹窗 | 通过路由拦截实现 | showAlertBeforeBackPage |
| 路由替换 | replacePath & replacePathByName | replaceUrl & replaceNameRouter |
| 路由栈清理 | clear | clear |
| 清理指定路由 | removeByIndexes & removeByName | 不支持 |
| 转场动画 | 支持 | 支持 |
| 自定义转场动画 | 支持 | 支持 |
| 屏蔽转场动画 | pushDestination(info: NavPathInfo, animated?: boolean) & pathStack.disableAnimation(true) | 支持 duration属性设置为0 |
| 共享元素动画 | 支持 | 不支持 |
| 页面生命周期监听 | UIObserver.on(‘navDestinationUpdate’) | UIObserver.on(‘routerPageUpdate’) |
| 获取页面栈对象 | 支持 | 不支持 |
| 路由拦截 | setInterception | 不支持 |
| 路由栈信息查询 | getAllPathName & getParamByIndex & getParamByName&size | getState() & getLength() |
| 路由栈操作 | moveToTop & moveIndexToTop | 不支持 |
| 沉浸式页面 | 支持 | 不支持,需通过window配置 |
| 设置页面属性(背景,模糊等) | 支持,backgroundBlurStyle | 不支持 |
| 设置页面标题栏(title)和工具栏(toolbar) | 支持 | 不支持 |
| 模态嵌套路由 | 支持 | 不支持 |
使用场景选择
| Navigation | router |
|---|---|
| 项目只有一个主模块,同一个模块内的页面之间跳转 | 项目包含多个模块,不同模块间的页面跳转。比如项目有主项目,A、B模块,主项目的H界面要跳转到A模块的I界面,或者A模块的I界面要跳转到B模块的J界面 |
更多关于HarmonyOS 鸿蒙Next中Router有必要换成Navigation吗的实战系列教程也可以访问 https://www.itying.com/category-93-b0.html
留着肯定是心病,不如早点整了,哈哈
6
router早就废弃了,只在某些特殊场景使用 ,
Navigation从24年下半年就是主流方案了
哎,我们项目也是24年开始的,我是第二个接手的,第一个哥们这个没选好,没考虑那么多,
若项目涉及复杂路由管理、高级动效或长期迭代,建议切换到Navigation;若仅需简单跨模块跳转且无新需求,可暂保留Router。混合使用时,务必确保Router目标页以Navigation为根容器,避免层级冲突。
太复杂也没,其实长远看,应该还是替换了好点,就是也费时间,
对比router 的优势是什么 我也一直用的router,
有要学HarmonyOS AI的同学吗,联系我:https://www.itying.com/goods-1206.html
老大没提你就装死。
活儿没派给你,为什么考虑干不干。
不存在老大,现在就我一个人搞,
一天改10个,一周就改完了。不然以后有什么新特性用不了,到时候再替换更多了
确实,分开处理好点,但是又有迭代任务,还得抽空,
建议替换,不然后面迁移太浪费时间,
现在70多个页面,替换起来也挺费时间,本来少我还想动下,多点我就有点犹豫,
在鸿蒙Next中,Router和Navigation是两种不同的导航机制。Router主要用于页面间跳转和参数传递,而Navigation提供了更丰富的导航栈管理和页面切换动画。是否替换取决于具体需求:若应用需要复杂的导航结构、统一的页面管理或更流畅的转场效果,Navigation是更合适的选择。对于简单的页面跳转,Router仍可满足需求。
在HarmonyOS Next中,Router和Navigation是两种不同的导航机制,各有其适用场景。是否需要替换,取决于你的具体需求。
Router 主要用于应用内页面间的URL路由跳转,适合基于URL进行解耦的页面导航,常用于Web化或需要深度链接的场景。
Navigation 是ArkUI框架提供的声明式导航组件,通过组件树管理页面栈,更适合在UI框架内构建结构清晰的单页面应用(SPA)体验,导航逻辑与UI绑定更紧密。
核心建议: 如果你的项目是典型的原生应用,页面间逻辑复杂且追求流畅的声明式开发体验,推荐使用Navigation。它更符合ArkUI范式,能更好地管理页面生命周期和状态。项目初期且页面多,迁移成本相对可控,长远看更利于维护。
若现有Router方案基于URL且已深度集成(如与后端路由耦合),或需要保持Web风格的导航特性,则可继续使用Router。两者并非互斥,也可在应用不同模块混合使用。
考虑到项目处于初期且页面数量较多,如果决定迁移,建议制定渐进式迁移计划,优先在新模块使用Navigation,逐步重构核心流程,避免一次性全量替换带来的风险。


