简介面向安卓开发者的碎片嵌套实践资源聚焦标签页布局与滑动容器组合实现多标签页界面内容涵盖子碎片管理、事件回调、生命周期处理、分页适配器及性能优化等关键点。工程内共三百三十个文件压缩包约十点四二兆包含二十五个Java源码文件、四十个XML布局与配置、六十五个编译后的类文件以及九个依赖库、一百七十五张截图和可直接安装的应用安装包方便对照学习代码与界面效果。已有1201人学习下载。若想掌握碎片高效复用、理顺嵌套碎片事务或排查多标签页切换问题这份完整可运行的工程可提供登录注册模块、首页碎片与分类标签栏等核心实现并涵盖源码级排错思路适合作为项目改造或技能提升的参考资料。 做 Android 开发这些年Fragment 嵌套 Fragment 这类需求几乎绕不开尤其是做首页多 tab 的场景外层一个 Fragment 作为容器内部又要承载好几个 tab 页面。项目标题里写的是“Fragment嵌套Fragment实现多tab页面”我拿到这个标题第一反应就是当年被 childFragmentManager 和 getChildFragmentManager 搞到头秃的日子所以今天就把这套方案从设计思路到踩坑细节完整拆一遍给正在做首页改造、底部 tab 升级、或者被“Fragment 莫名空白/崩溃/状态丢失”折磨的同学一个可以直接落地的参考。这套方案核心解决的是三个问题外层 Fragment 里怎么再塞多个独立页面“切换 tab”时怎么不丢状态、不闪白屏以及 Activity 被系统回收后多级 Fragment 怎么安全自动恢复。内容偏实战不会绕概念代码以 Java 为主Kotlin 项目里注意把 fragmentManager 换成 childFragmentManager 属性就行。1. 为什么用嵌套 Fragment而不是其他多 tab 方案1.1 常见多 tab 实现方式对比先摆结论多 tab 页面有无数种写法但“外层是 Fragment、内层又要分 tab”这个特定场景下嵌套 Fragment 基本是绕不开的最优解。实现方式核心原理优点缺点适用场景ViewPager FragmentStatePagerAdapter通过 ViewPager 左右滑动切换 Fragment滑动顺畅、自带预加载需要管理 FragmentStateAdapter 的嵌套 Manager预加载会多创建页面tab 数量少、需要滑动切换Fragment show/hide外层容器持有所有 Fragment切换时隐藏/显示状态保留最好、切换速度快所有 Fragment 同时存在内存稍高tab 数量少、页面重、不想重建Fragment replace每次切换把旧的移除再添加新的内存占用最小每次重建、状态需手动恢复、容易闪白屏页面轻、tab 内容不敏感嵌套 Fragment 手动切换外层 Fragment 用 childFragmentManager 管理子 tab Fragment职责清晰、模块化强、可各自维护对 Manager 和生命周期要求高首页这种多层结构Compose 多屏状态声明式 UI 的状态管理没有 Fragment 的复杂度需要整体迁移、老项目接入成本高新项目、团队已切 Compose如果你只是 Activity 直接做 tabViewPager 或 show/hide 都行。但一旦“首页”本身就是一个 Fragment你再在 Activity 的 FragmentManager 里去 add 子 tab这几个子 Fragment 就和承载它们的外层 Fragment 变成了“平级”关系生命周期完全不跟外层走于是各种诡异问题就来了。所以在首页 Fragment 里再开 tab必须把这一层 Fragment 交给外层 Fragment 自己的 childFragmentManager。1.2 嵌套 Fragment 的设计价值从产品角度说用嵌套 Fragment 把首页拆成“外层壳 多个 tab 页”最大的好处是解耦。比如底部 tab 有“推荐、热点、关注、视频”四个页签每个页签后续大概率是不同小组在维护如果我直接把四个页面全写在一个 Fragment 的布局里协作效率会非常低。拆成独立 Fragment 后每组只管自己那一块逻辑外层只负责切换和容器控制。从技术状态管理角度说嵌套 Fragment 能天然保住每个 tab 的滚动位置、表单输入、列表加载状态。只要不是 replace 那种暴力做法子 Fragment 被 hide 后 View 还在ViewModel 还在回来的时候体验和原生 App 切换 tab 是一致的不会出现用户切出去再切回来列表突然顶到第一行这种体验。当然嵌套也不是越多越好官方文档也建议 Fragment 嵌套层级尽可能浅。我的个人红线是Activity - 外层 Fragment - 子 Fragment到这里就封顶。超过三层之后状态恢复逻辑会变得非常脆弱再加上转场动画、数据回调排查问题的时间成本成倍上涨。2. 核心细节Manager 用对嵌套就成了一半2.1 childFragmentManager 为什么必须是它这是嵌套 Fragment 最核心的一个点也是很多人第一次写就踩坑的地方。每个 Fragment 内部都有一个 childFragmentManagerKotlin 里可以直接访问 childFragmentManager 属性Java 里调用 getChildFragmentManager()它专门用来管理这个 Fragment 内部的子 Fragment。我用一个不太严谨但特别好理解的类比Activity 是酒店前台FragmentManager 是前台手里的房卡总记录外层 Fragment 是楼层管家childFragmentManager 就是这个管家手里的本子。你要给 3 层的客人送餐不应该去前台翻总记录直接找楼层管家最快最准。如果硬要用 Activity 的 FragmentManager 去操作首页内部的 tab 子 Fragment相当于跨楼层派人虽然也能送到但管家那边完全没有记录Activity 一恢复重建子 Fragment 就“失联”了。实际代码层面错误示范是// 错误用 Activity 的 FragmentManager 管理子 Fragment getActivity().getSupportFragmentManager() .beginTransaction() .replace(R.id.tab_container, new RecommendFragment()) .commit();正确做法// 正确在外层 Fragment 内部用 childFragmentManager 管理子页签 getChildFragmentManager() .beginTransaction() .replace(R.id.tab_container, new RecommendFragment()) .commit();同样一套操作Manager 不一样行为天差地别。用 getChildFragmentManager() 时子 Fragment 的生命周期会跟着外层 Fragment 走外层被移除、被销毁子 Fragment 自动清理外层重建子 Fragment 状态也会由 childFragmentManager 帮忙恢复。而用 Activity 的 Manager子 Fragment 直接挂在 Activity 层级下外层 Fragment 已经重建了子 Fragment 可能还残留着旧实例这就是“刷新页面后 tab 空白”“返回时闪退”最常见的起源。2.2 嵌套 Fragment 的生命周期联动嵌套之后生命周期不再只由 Activity 驱动而是父 Fragment 和子 Fragment 联动。比如外层 HomeFragment 被 add 到 ActivityActivity.onStart() 触发 HomeFragment.onStart()HomeFragment.onStart() 触发子 tab Fragment.onStart()Activity.onStop() 触发 HomeFragment.onStop()再触发子 Fragment.onStop()外层 HomeFragment 被 remove 或隐藏时需要看具体事务类型子 Fragment 也会收到 onDestroyView/onDestroy这个联动机制本身是系统自动处理的前提是你所有子 Fragment 操作都走 childFragmentManager。最怕的是有人手动把生命周期和业务逻辑搅在一起比如在 onResume 里执行数据加载又在 hide/show 子 Fragment 时自己手动调 findViewById 控制 View结果 hide 后子 Fragment 的 View 明明还在业务层却以为它已经销毁数据重复请求。2.3 用 FragmentContainerView 代替 FrameLayout以前容器喜欢用 FrameLayout后来 Android 官方出了 FragmentContainerView本质是优化过的布局容器专门用来放 Fragment。它比 FrameLayout 更智能的地方在于系统做 View 状态恢复时能更准确定位到 Fragment 的实例不会出现 id 冲突导致的“找不到 Fragment”问题。如果你从旧项目迁移建议顺手把根布局里的 FrameLayout 容器改成 FragmentContainerViewandroidx.fragment.app.FragmentContainerView android:idid/tab_container android:layout_widthmatch_parent android:layout_heightmatch_parent /它不能用作普通布局容器塞别的 View只能放 Fragment这个限制反而是好事能避免布局结构混乱。3. 完整实现外层 Fragment 多 tab 子页面下面直接进入正题用一个“首页 HomeFragment 内部四个 tab”的例子把完整流程走一遍。这个结构在实际项目里非常常见底部四个 tab 分别是推荐、热点、关注、视频顶部可能还有一个标题栏但不管顶部怎么设计核心就是中间内容区的容器管理和子 Fragment 切换。3.1 基础工程与依赖准备新建 Android 项目用 AndroidX依赖里确保有implementation androidx.fragment:fragment:1.6.2 implementation androidx.viewpager2:viewpager2:1.0.0 // 如果底部 tab 用 Material 的 BottomNavigationView 或 TabLayout再加对应依赖 implementation com.google.android.material:material:1.9.0Fragment 库版本建议保持在 1.5.0 以上后面我讲的状态恢复问题新版本处理得更好。如果项目里用的还是老版本 support 包还是尽早统一切到 AndroidX 再搞嵌套不然各种管理器类名都不一样维护成本很高。3.2 外层 Fragment 布局和代码框架HomeFragment 的布局主要是一个横向的 tab 切换栏和一个内容容器LinearLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:layout_widthmatch_parent android:layout_heightmatch_parent android:orientationvertical LinearLayout android:idid/tab_switch_bar android:layout_widthmatch_parent android:layout_height48dp android:orientationhorizontal !-- 这里放四个按钮或两个自定义 tab生产环境可直接用 TabLayout -- TextView android:idid/tab_recommend android:padding12dp android:gravitycenter android:layout_width0dp android:layout_heightmatch_parent android:layout_weight1 android:text推荐 android:background?attr/selectableItemBackground / TextView android:idid/tab_hot android:padding12dp android:gravitycenter android:layout_width0dp android:layout_heightmatch_parent android:layout_weight1 android:text热点 / !-- 关注、视频同理 -- /LinearLayout androidx.fragment.app.FragmentContainerView android:idid/tab_container android:layout_widthmatch_parent android:layout_height0dp android:layout_weight1 / /LinearLayout然后 HomeFragment 里的核心代码public class HomeFragment extends Fragment { private static final String TAG_RECOMMEND tab_recommend; private static final String TAG_HOT tab_hot; private static final String TAG_FOLLOW tab_follow; private static final String TAG_VIDEO tab_video; private Fragment currentFragment; Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { return inflater.inflate(R.layout.fragment_home, container, false); } Override public void onViewCreated(NonNull View view, Nullable Bundle savedInstanceState) { super.onViewCreated(view, savedInstanceState); // 初始化默认显示推荐页 if (savedInstanceState null) { switchContent(new RecommendFragment(), TAG_RECOMMEND); } } /** * 切换 tab 页面使用 show/hide 方式避免重建 */ public void switchContent(Fragment targetFragment, String tag) { FragmentManager childManager getChildFragmentManager(); FragmentTransaction transaction childManager.beginTransaction(); if (currentFragment ! null) { transaction.hide(currentFragment); } Fragment cachedFragment childManager.findFragmentByTag(tag); if (cachedFragment ! null) { transaction.show(cachedFragment); currentFragment cachedFragment; } else { // addToBackStack(null) 不要加tab 切换不需要入返回栈 transaction.add(R.id.tab_container, targetFragment, tag); currentFragment targetFragment; } transaction.commit(); } }这里的 switchContent 是一个很简单但实用的切换方法。每次切换先把当前 Fragment hide 掉然后看目标 Fragment 之前在不在 childFragmentManager 里在就直接 show不在就 add。show/hide 模式下每个子 Fragment 的 onHiddenChanged 会触发但 onStop/onStart 不会随便触发所以状态保存非常好。3.3 为什么不用 replace 而用 show/hide很多人会问replace 不也能切换吗是的但 replace 会把旧 Fragment 彻底销毁重建带来两个问题第一是性能问题。每次切 tab如果旧页面有列表、有图片加载都要重新创建 View、重新请求数据真实使用中你会明显感觉到切换变卡而且在弱网环境下用户非常容易看到空页面加载态。第二是状态丢失。列表滚动到第 30 条、表单填了一半、播放器播放进度切换再回来全都没了。用 replace 不是不能恢复你得手动把每一个状态暂存到 outState产品一迭代字段多了就很容易漏属于吃力不讨好。show/hide 的记忆体开销其实没那么夸张。对它最大的误解是“会让所有 Fragment 同时存活内存爆掉”。实际正常情况下 tab 数量控制在 4~6 个占用内存完全可接受。真正要防的是每个子 Fragment 在 hide 后还在疯狂做网络请求、动画播放、传感器监听这类重操作那才可能出现性能和耗电问题。针对这个问题我建议每个 tab 页在 onHiddenChanged 回调里做对应处理Override public void onHiddenChanged(boolean hidden) { super.onHiddenChanged(hidden); if (hidden) { // 不在当前前台暂停视频播放、停止轮播、暂停统计计时 } else { // 回到当前页面如果数据过期则刷新、恢复轮播 } }3.4 滑动滑切场景ViewPager2 FragmentStateAdaptershow/hide 解决了“点击切换”但如果你要的是“顶部 tab 能左右滑动”那最好用 ViewPager2。ViewPager2 内部本身就处理了 Fragment 的保留和销毁关键是它的 Adapter 构造时要传 childFragmentManager不是 Activity 的。public class HomeTabPagerAdapter extends FragmentStateAdapter { private final ListFragment fragments; public HomeTabPagerAdapter(NonNull Fragment fragment) { super(fragment); // 关键传外层 Fragment fragments new ArrayList(); fragments.add(new RecommendFragment()); fragments.add(new HotFragment()); fragments.add(new FollowFragment()); fragments.add(new VideoFragment()); } NonNull Override public Fragment createFragment(int position) { return fragments.get(position); } Override public int getItemCount() { return fragments.size(); } }然后在 HomeFragment 里ViewPager2 viewPager2 view.findViewById(R.id.view_pager); viewPager2.setAdapter(new HomeTabPagerAdapter(this)); // 关键传 this即外层 Fragment TabLayoutMediator mediator new TabLayoutMediator(tabLayout, viewPager2, (tab, position) - { tab.setText(tabTitles[position]); }); mediator.attach();FragmentStateAdapter 构造方法有两个一个是传 Activity一个是传 Fragment。传 Fragment 时它内部会自动使用该 Fragment 的 childFragmentManager 和 lifecycle这就是嵌套 Fragment 和 ViewPager2 结合的正确姿势。如果你传的是 getActivity()那 ViewPager2 内部的 Fragment 又跑到 Activity 层级去了和最开始说的错误是同源问题。另外补充一个注意点ViewPager2 默认会预加载相邻页面如果你不想预加载可以用 setOffscreenPageLimit(1) 调节但不要为了省内存设置成 0会造成滑动时频繁重建体验反而差。4. 常见问题与排查技巧实录4.1 崩溃现场commit 时抛 IllegalStateException错误日志很常见类似java.lang.IllegalStateException: Can not perform this action after onSaveInstanceState原因很简单调用了 fragmentTransaction.commit()但此时 Activity 已经执行完 onSaveInstanceState再提交事务系统无法保证恢复后的状态一致性所以直接抛异常。最常见触发场景是在网络请求回调、异步任务里做 tab 切换。比如用户点了 tab 后我们发起请求请求回来的时候用户可能已经按了 Home 键Activity 处于 stopped 状态这时候 commit 就炸了。解决方式有两种尽量确保事务在用户交互的同步流程里提交。实在需要在异步回调里提交用fragmentTransaction.commitAllowingStateLoss()但它牺牲了状态一致性若 Activity 即将销毁这次提交可能丢失。我个人建议是能不用 commitAllowingStateLoss 就不用不如在回调里先判断isAdded()和getContext() ! null再执行切换。4.2 页面恢复后重复创建 Fragment这个坑我自己踩过多次现象是应用切到后台被系统回收再从最近任务打开结果 tab 容器里同时出现了两个一样的 Fragment或者闪白屏。根因是 Fragment 的状态恢复机制。系统为了帮你恢复 Fragment会在 Activity 重建时把原来还在事务管理中的 Fragment 再拉回来而你的代码里如果写死了if (savedInstanceState null)才 add那么 savedInstanceState 不为 null 时系统已经恢复了子 Fragment你又没去 find 它再手动 add 一个就重复了。正确做法是先 findFragmentByTag有就直接 show没有才 add。上面的 switchContent 方法已经写了这段逻辑核心就是这几行Fragment cachedFragment childManager.findFragmentByTag(tag); if (cachedFragment ! null) { transaction.show(cachedFragment); }4.3 嵌套 Fragment 的点击事件和手势冲突这个不是崩溃类问题但经常被人问。如果你是外层 Fragment 用 ScrollView内部子 Fragment 是 RecyclerView你会发现在列表里上下滑动时经常被外层 ScrollView 劫持掉。解决办法是内层列表使用 NestedScrollView 或者让 RecyclerView 实现 NestedScrollingChild 接口RecyclerView 默认支持然后在切换 tab 的时候调整外层是否可滚动// 外层滚动容器 nestedScrollView.setOnTouchListener((v, event) - { // 当前如果处于推荐页并且内部列表可以下拉就禁止外层滑动 if (currentFragment instanceof RecommendFragment) { return ((RecommendFragment) currentFragment).canScrollVertically(); } return false; });更优雅的方案是直接用 CoordinatorLayout AppBarLayout 处理嵌套滑动让系统按嵌套滑动机制协调。原则就一句话能靠系统机制协调的别自己动手拦截。4.4 高频问题速查表现象大概率原因处理办法子 Fragment 空白用了 Activity 的 FragmentManager 管理子页面一律换 getChildFragmentManager()切换回来数据丢失用了 replace 导致页面重建换成 show/hide恢复后台回来页面重复没判断 savedInstanceState 也没去 findFragmentByTag先查找已有实例存在则 showtransaction 提交崩溃在 onSaveInstanceState 之后异步 commit用 commitAllowingStateLoss 或延迟提交页面恢复后走不到 onResumeFragment 事务在 lifecycle 之前恢复确保 Fragment 库版本较新检查 lifecycle state子 Fragment 点击事件没有响应嵌套层级过深焦点被父容器抢占给容器设置 android:focusableInTouchModetrue或优化嵌套层级ViewPager2 和 Fragment 组合闪跳TabLayoutMediator 重复 attach每次 attach 前先 detach或者用 lifecycle 感知组件4.5 补充经验返回键和状态保存多 tab 页面还要考虑返回键行为。如果用户点开了二级页面通常会期望第一次返回是退出二级页第二次返回才是退出整个 tab 页面这个逻辑在嵌套结构里也有点门道。简单方案是在 Activity 里重写 OnBackPressedDispatcher根据当前 Fragment 类型和子 Fragment 数量决定是让子 Fragment 自己处理还是默认回退requireActivity().getOnBackPressedDispatcher().addCallback(this, new OnBackPressedCallback(true) { Override public void handleOnBackPressed() { if (currentFragment instanceof OnBackPressedHandler) { if (!((OnBackPressedHandler) currentFragment).handleBackPressed()) { setEnabled(false); requireActivity().getOnBackPressedDispatcher().onBackPressed(); } } else { setEnabled(false); requireActivity().getOnBackPressedDispatcher().onBackPressed(); } } });这个处理之后当子 Fragment 返回 false 表示“我这边没有拦截需求”就继续走系统默认流程逻辑不难但能避免用户按返回键直接退出整个 App 的生硬感。状态保存方面如果你有特殊字段必须保存比如当前选中的 tab 位置可以覆写 onSaveInstanceState 保存然后在 onViewCreated 里恢复private static final String STATE_SELECTED_TAB selected_tab; Override public void onSaveInstanceState(NonNull Bundle outState) { super.onSaveInstanceState(outState); outState.putInt(STATE_SELECTED_TAB, currentIndex); }然后在 onViewCreated 里if (savedInstanceState ! null)读取并恢复选中 tab。注意千万不要在 Fragment 的 onCreate 里做 View 操作那时候 View 还没创建。最后再分享一点个人体会嵌套 Fragment 做多 tab 这个事我做了不止一个项目最大的心得就是把 childFragmentManager 当成“另一个世界”来理解。只要你记住Activity 有一个 FragmentManager外层 Fragment 有自己的 childFragmentManager内层 Fragment 再有自己的 childFragmentManager每一层都用自己所属的 Manager逻辑基本就不会乱。相对容易出错的地方反而在业务侧有了嵌套内层 Fragment 一定要在 onHiddenChanged 里处理暂停和恢复别让后台 tab 继续播放视频、定时刷新这既是对产品体验的优化也是对自己代码的减负。希望这篇文章能让你少走一些我当年走过的弯路有不同看法欢迎一起讨论。本文还有配套的精品资源点击获取