其他分享
首页 > 其他分享> > 一文搞懂Google Navigation Component

一文搞懂Google Navigation Component

作者：互联网

一文搞懂Google Navigation Component

应用中的页面跳转是一个常规任务, Google官方提供的解决方案是Android Jetpack的Navigation component.

本文概括介绍一下基本使用的关键点(详细的how to guide看官方就好了),
结合源码梳理一下基本的navigation component的设计, 帮助大家更好地理解和使用这个库.

首先, 官网的介绍很全面了: https://developer.android.com/guide/navigation
如果想按步骤操作一番请移步官方文档.

这里表扬一下Android Studio, 越来越人性化了.
在添加navigation资源的时候会自动加依赖.

Navigation Editor可以显示destination, 拖拽, 连线加action, 添加编辑参数, 设置动画和返回行为等属性, 提供了一个集中可视化的图.

基本组成部分

从Navigation Component推出之初的宣传视频, 比如这个, 可以看出它和single activity的思想是紧密结合的.

所以官方推荐的经典做法是这样:
一个activity和多个fragments: activity关联一个navigation graph, 包含一个NavHostFragment, 用来放置不同的fragments.

navigation host

多个Activity怎么办

当然具体的应用可以选择自己想要的方式, 适合自己的才是最好的.

如果有多个activity, 那么每个activity有自己的navigation graph.

以这个简单的例子举例:

multiple activities sample

如果Login和Main页面是两个Activity, 它们各自的layout里都有一个NavHostFragment, 这样做的目的有两个:

它们又都有各自的navigation graph, 里面列出了可以到达的结点.
因为我们只能到达在同一个graph中列出的节点.

这里LoginActivity需要跳转到MainActivity, 所以在navigation graph中有mainActivity的destination结点.
如果MainActivity也需要跳转到LoginActivity, 就需要在自己的navigation graph中增加一个loginActivity的destination结点.

顶级页面非全屏/子页面全屏的处理

有一个具体的应用case是, 如果app的主要入口是非全屏的(有共享UI部分, 比如bottom bar), 而部分页面需要全屏, 应该如何处理.

比较简单的一种方式就是如上面的例子, 把全屏的页面放在一个单独的Activity. 但这样就会导致很多Activity的出现.

另外一种方式是动态处理nav host和bottom navigation的布局.
比如需要显示一个全屏的Fragment的时候, bottom bar消失, nav host布局充满屏幕.
这就涉及到一些UI的操作和恢复, 可能还需要动画过渡.

多module项目中的导航

当项目慢慢变大之后, 我们会拆分module来组织代码, 除了基础组件的拆分, 各个feature也可能会拆到不同的module中去.

官方建议的方式, 如图所示, app module作为总入口, 依赖feature modules.
navigation graph也放在app module中.

multi-module project

因为navigation graph是支持嵌套和include的, 即navigation里面也可以嵌套navigation, 子的navigation有自己的start destination.
所以navigation graph也可以拆分, 各个module管理自己的navigation graph, 最终include到app module中去.

跨module导航的行为, 是deep link的方式.
具体代码见navigation-multi-module

源码实现是通过字符串匹配找到destination, 然后根据具体的类型找到navigator进行导航.

需要注意, 即便是app module, 它想导航到一个比较深的结点, 推荐的方式也是通过deep link.

当我们嵌套navigation时, 总navigation图的可见结点只到子graph为之, 其内部结点都不可见, 导航会发生destination找不到的错误.

大多数情况, app module也只关心几个入口结点.

跨module导航还有一个缺点是safe args不支持.

navigation classes

NavHost接口的唯一实现类是:NavHostFragment.
在NavHostFragment中创建了NavController, 这里也是所有方法最终获得到的NavController的来源.
通过Fragment的生命周期onCreate()触发了graph的创建.

NavController负责了导航行为的控制.
NavController中有很多navigate()方法的重载, 可以根据不同的参数进行导航.
popBackStack()是回退操作.

最终的实现都是从destination中获取到navigator的名字, 然后调用具体的Navigator的navigate()或popBackStack()方法.

NavHostController是NavController的子类, 提供了一些连接外部依赖的设置方法.
App通常不会构造controller, 而是从navigation host获取.

NavController中有字段NavigatorProvider, 而NavigatorProvider中有一个navigators的HashMap.

destination and navigator

NavDestination是一个描述不同目的地的数据结构基类.
具体实现在不同类型的Navigator中都有对应的类.

NavGraph也是NavDestination的子类. 只不过NavGraph中记录了destination节点信息.

Navigator是一个抽象类.

包含的方法中对应导航行为和回退行为的是:

下面几种子类: 对应不同destination的导航.

这个子类:

可以查看这几个类的导航实现.
比如点进FragmentNavigator的navigate()方法实现, 我们就会发现最终执行的是replace()操作.
Navigation component是支持自定义Navigator的, 我们可以仿照这个类写出自己的版本, 达到定制化的目的.

初始化和导航过程

初始化过程

导航的setup过程大致如下:
navigation setup flow

这里展示的是xml的navigation graph, 其中解析xml的工作由NavInflator来完成.
解析完成后由navigator进行具体的destination类型创建.

这里graph创建完成之后还会导航到start destination.

导航跳转过程

要跳转到具体某个destination时, 流程如下:
navigation navigate flow

这里解释了为什么只能导航到同一个图下的目的地.
以及最终的导航动作, 是找到对应destination的navigator实现来进行的.
这样对NavController来说就不必关心具体实现.

获取NavController的几种方式

获取NavController的方式有三种(先不说Compose).

第一种: Activity

fun Activity.findNavController(@IdRes viewId: Int): NavController =
        Navigation.findNavController(this, viewId)

参数传入view的id. 之后会调用findViewNavController()

第二种: Fragment

fun Fragment.findNavController(): NavController =
        NavHostFragment.findNavController(this)

首先向根部遍历, 找到NavHostFragment, 然后getNavController().

找不到还会尝试在view中找, 或者在dialog的view中找.

当然如果拿得到NavHostFragment可以直接get.

第三种: View

fun View.findNavController(): NavController =
        Navigation.findNavController(this)

最后的本质依然是调用到了findViewNavController().

不断递归找view的parent, 然后getNavController, 找到为止.

这个地方NavController是写在View的tag里.
查了一下这个方法的调用是NavHostFragment的onViewCreated()里.

findNavController的几种方式总结

findNavController()

所以以上提到的这三种方式, 归根结底是要找到NavHostFragment中的那个NavController.

DSL和Jetpack Compose Navigation

DSL

navigation component还提供了DSL的方式来声明graph, 取代xml的版本.
这种方式可以用于动态构建一个navigation graph.

代码看起来像这样:

val navController = findNavController(R.id.nav_host_fragment)
navController.graph = navController.createGraph(
    startDestination = mav_routes.home
) {
    fragment<HomeFragment>(nav_routes.home) {
        label = resources.getString(R.string.home_title)
    }

    fragment<PlantDetailFragment>(${nav_routes.plant_detail}/${nav_arguments.plant_id}) {
        label = resources.getString(R.string.plant_detail_title)
        argument(nav_arguments.plant_id) {
            type = NavType.StringType
        }
    }
}

DSL方式的局限性也是不能和safe args结合.

Jetpack Compose Navigation

Compose版本的navigation包是: androidx.navigation:navigation-compose.
有了前面的铺垫, 我们可以发现compose导航库的实现是DSL版本的写法, 结合新的ComposeNavigator.
compose destination and navigator

NavHost(navController = navController, startDestination = "profile") {
    composable("profile") { Profile(/*...*/) }
    composable("friendslist") { FriendsList(/*...*/) }
    /*...*/
}

所以同样的, NavController要和一个NavHost关联, NavHost其中有一个navigation graph定义了所有的destinations.
每个destination有一个唯一的route字符串来定义自己的路径.

navigation graph同样也可以嵌套.
并且和View的Navigation Component是有Interoperability支持的.

结论

Navigation Component是一个很基础却很有意思的库.

它封装了导航行为, 方便了开发者调用, 也解耦了导航动作和具体结点的实现类.
解决了参数传递的类型安全问题.
提供了可视化的导航图编辑预览工具.
提供了导航UI组件并提供了默认行为, 让开发者直接获得符合设计的默认效果.

它的设计跟单Activity的架构相关, 支持拓展destination类型, 支持dsl写法.

本文结合源码讨论了一下这个库的设计和使用的关键点, 希望对大家有帮助.

References

标签：Google,导航,NavController,graph,destination,Component,Navigation,搞懂,navigation
来源： https://www.cnblogs.com/mengdd/p/google-navigation-component-source-code.html