📚 课程目录第1章 Navigation组件整体架构概览

第一章 Navigation组件整体架构概览：组件角色、模块边界、系统分层、数据流主线

1.1 组件角色与模块边界

Navigation 组件是 Android Jetpack 家族中负责页面间导航调度的标准化框架。它的核心目标是解决 Fragment/Activity 之间手动管理返回栈、传递参数、动画编排等繁琐且易错的问题，为单 Activity 架构提供官方推荐的路由方案。从模块边界来看，Navigation 组件由四个关键部分组成：

组件模块	角色定义	边界职责
Navigation Graph	导航图的 XML/声明式定义	描述所有可导航的页面（Destination）及其连接（Action）
NavHost	导航容器	负责解析导航图，承载并切换页面内容
NavController	导航控制器	管理导航状态、返回栈、Action 执行（核心引擎）
Safe Args	类型安全参数插件	编译时生成类型安全的方向与参数类，消除 Bundle 手工地狱

架构要点：Navigation 组件的模块边界是“栈机模型”，NavController 维护一个独立于 Activity 的 Fragment 栈，每个栈条目关联一个 NavDestination。组件不允许直接操作底层 FragmentManager，所有交互只能通过 Navigation API 完成，以此隔离核心状态。

1.2 系统分层：从声明到渲染

Navigation 组件在 Android 应用架构中处于业务逻辑层与 UI 层之间的编排层。它不直接参与数据获取或状态管理，而是定义页面切换的契约。

声明层：Navigation Graph（XML / Kotlin DSL）定义“从哪来，到哪去”。
控制层：NavController 解析 Graph，管理 Action 与返回栈。
渲染层：NavHost 将当前目标页面渲染到容器。

1.3 整体架构分层与数据流主线

下图展示了 Navigation 组件的层级关系与核心流转路径。箭头表示控制流向，虚线表示数据参数传递。

1.4 组件职责细化

各部分职责必须严格分离，避免架构污染。下表对比了 Fragment 原生导航与 Navigation 组件的职责差异：

职责维度	Fragment 原生方案	Navigation 组件方案
导航触发	FragmentManager.beginTransaction()	NavController.navigate(@IdRes actionId)
返回栈管理	手动 addToBackStack()	自动管理，基于 Navigation Graph 规则
参数传递	Bundle + arguments，无类型安全	Safe Args 在编译时生成类型安全类
深层链接	需自行设计 Intent 过滤	内建深层链接支持，自动匹配 Destination
动画/过渡	只能设置全局 Fragment 动画	支持按 Action 配置进入/退出/弹出动画

  架构权衡要点

  选 Navigation vs 自定义 Router：Jetpack Navigation 适合标准单 Activity 多层页面应用；如果项目需要跨模块路由分发、动态下发、深度解耦，可以考虑自建 Router（如 ARouter / WMRouter），但会失去返回栈标准化管理。
风险点：Navigation 组件强依赖于 FragmentManager 的内部状态。当返回栈中某个 Fragment 被系统回收重建时，NavController 会尝试重建状态栈，此时若 Destination 参数非序列化（Parcelable/Serializable）可能引发 IllegalStateException。

1.5 数据流与控制流主线

我们通过一个典型的导航启动流程来理解 Navigation 组件的信任链路与数据流动：

用户点击按钮 → 调用 findNavController().navigate(R.id.action_A_to_B)。
NavController 接收导航命令 → 根据 Action ID 从当前导航图中查找目标 Destination ID、参数类型、动画规则。
参数打包 → Safe Args 生成 Args 类，自动构建 Bundle，并验证参数完整性。
返回栈操作 → 若 Action 带有 popUpTo 或 popUpToInclusive，执行栈回退。
NavHost 触发页面切换 → 执行 FragmentTransaction，替换当前 Fragment 为目标页面，并应用过渡动画。
状态持久化 → NavController 序列化当前栈状态到 SavedStateHandle，以备重建。

信任链路破坏风险
不要在 Fragment/Activity 中直接操作返回栈（如 fragmentManager.popBackStackImmediate()），否则会导致 NavController 的状态与 FragmentManager 不一致，引发 Navigation 异常。所有返回操作必须通过 NavController.navigateUp() 或 onBackPressedDispatcher 委托给 NavController。

1.6 落地步骤（第一章节）

本章仅作为全景概览，不涉及具体编码。但从架构落地角度，需要理解 Navigation 组件在项目中的初始化部署步骤：

在 build.gradle 中添加 Navigation 依赖（Fragment / Compose 对应不同 artifact）。
创建 nav_graph.xml 文件，定义起始页与跳转关系。
在 Activity 布局中使用 NavHostFragment 作为容器。
通过 setupActionBarWithNavController() 或 onSupportNavigateUp() 绑定 TopBar 与 NavController。
集成 Safe Args 插件，确保参数传递类型安全。

1.7 验收标准

第一章的架构概览完成后，应满足以下理解性验收点：

验收项	通过标准
模块边界认知	能清晰区分 Navigation Graph、NavController、NavHost、Safe Args 的职责
分层架构理解	能画出声明层 → 控制层 → 渲染层的分层示意图
数据流主线	能口头描述从用户点击到页面切换的 6 步主线
信任链路风险意识	知道不能直接操作 FragmentManager，所有导航要通过 NavController