HarmonyOS 鸿蒙Next中Router有必要换成Navigation吗

HarmonyOS 鸿蒙Next中Router有必要换成Navigation吗 最近接手过来鸿蒙项目,发现一直用的router进行页面跳转,有必要替换成Navigation吗,我算了下,页面大概有70多个了,项目还算在初期,还有很多页面没迭代过来,

18 回复

【解决方案】

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

router与Navigation的差异可以参考:

当前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结构对比

  • 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,

有些功能好像用Navigation这个比较方便,我们也在接入直播,做小窗,也是基于这个,

有要学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,逐步重构核心流程,避免一次性全量替换带来的风险。

回到顶部