Android 单Activity多Fragment架构

Android 的“单 Activity + 多 Fragment”架构，就是把整 App 的**所有界面（或绝大部分）**都放在一个 Activity 里完成，通过动态切换/堆叠 Fragment 来实现页面间的导航。下面按“设计思路 → 典型实现 → 适用场景 → 优缺点”四段展开，并给出常用写法与注意点。

一、架构设计思路

1. 把 Activity 仅当作“容器”与“生命周期调度者”，不承载业务 UI。
2. 每个业务页对应一个 Fragment，全部在运行期动态 add/replace/hide/show。
3. 导航关系由开发者自己维护（FragmentTransaction 或 Jetpack Navigation），Fragment 返回栈即 App 的页面返回栈。
4. 跨页数据通过共享 ViewModel、Activity-level 仓库或接口回调完成，实现“页面解耦、数据集中”。

二、典型实现步骤（以 Jetpack Navigation 为例）

1. 依赖
   implementation "androidx.navigation:navigation-fragment-ktx:2.7.x"
   implementation "androidx.navigation:navigation-ui-ktx:2.7.x"

2. 布局
   activity_main.xml 只放一个 FragmentContainerView

   <androidx.fragment.app.FragmentContainerView
        android:id="@+id/nav_host"
        android:name="androidx.navigation.fragment.NavHostFragment"
        app:navGraph="@navigation/nav_graph"
        app:defaultNavHost="true"
        ... />
   

3. nav_graph.xml 把各 Fragment 串成图，声明跳转与参数。

4. Activity 里基本不用写业务代码，仅保留全局工具栏/底部导航的 UI 控制。

5. Fragment 之间通过 navigate() 跳转，通过 by navGraphViewModels(R.id.nav_graph) 拿到同作用域 ViewModel 共享数据 。

三、最适合的应用场景

1. 导航结构深、页面多，但想避免 Activity 爆炸（10+ 个 Activity 以上）。
2. 对转场动画、共享元素、统一右滑返回要求高的社交/电商/内容 App。
3. 横竖屏、折叠屏、分屏、Pad 多窗口适配：同一 Activity 内并排或堆叠 Fragment 即可响应不同尺寸 。
4. 需要底部/侧边 Tab 且 Tab 之间可互相跳转，用 Fragment + Navigation 能快速实现“全局单返回栈” 。
5. 对启动速度、内存占用敏感，希望减少重复 Activity 开销的轻量项目。

四、优缺点对比 优点

• 生命周期统一：全部页面走一个 Activity 回调，降低重复模板代码 。
• 资源&状态共享：ViewModel、数据库、Socket、地图等可在 Activity 域复用，避免多 Activity 重复初始化。
• 转场/动画更流畅：FragmentTransaction 原生支持淡入淡出、共享元素；Navigation 还能自动处理返回栈。
• 代码结构清晰：UI 拆成独立 Fragment，可单元测试；Activity 只负责导航与全局状态。
• 适配多窗口容易：动态 add/hide 即可实现双栏、悬浮、分屏 。

缺点

• 栈管理复杂：嵌套层级深时，需要手动维护回退栈、沉浸式、软键盘模式，容易踩坑。
• Fragment 生命周期“坑多”：异常重建、show/hide 与 replace 混用、子嵌套 Fragment 等都会带来重叠或状态丢失 。
• 通信耦合：Fragment 不能直接相互引用，必须走 Activity 或共享 ViewModel，滥用接口会让宿主 Activity 膨胀。
• 过度使用导致单 Activity 臃肿：所有全局 UI（对话框、悬浮球、底部 sheet）也挤在一个 Activity，一旦崩溃即整 App 崩溃。
• 测试粒度变细：虽然 Fragment 可单独测，但仍需 Robolectric 或 AndroidX-FragmentScenario 搭建环境，配置比 Activity 测试复杂 。

小结
“单 Activity + 多 Fragment”已是 Google 官方主推的 UI 架构之一，配合 Navigation、ViewModel、Hilt 等 Jetpack 组件，能把导航、生命周期、依赖注入全部标准化。但项目团队需要统一栈管理规范、制定 Fragment 通信协议，并预留异常重建场景下的恢复方案，才能真正发挥它“高复用、低内存、易适配”的优势，否则容易陷入“回调地狱”和“重叠 Bug”的泥潭。