接手过不少用 ViewPager 承载 Fragment 的项目页面向来回切换几次之后什么卡顿、数据重复请求、空白页、状态丢失的问题就全冒出来了。最典型的一种情况是Fragment 的 onCreateView 被反复调用每次切走再切回来整个布局都要重新 inflate 一遍如果 onCreate 里写了网络请求那更是雪上加霜。这篇文章就围绕 ViewPager 场景下 Fragment 重复加载这件事把我实际排查和改造的完整思路分享出来包括问题根因、方案选型、核心代码和踩过的坑适合用 ViewPager Fragment 做内容型页面比如首页 Tab、多标签列表、分类浏览页的开发同学参考。1. 问题剖析重复加载到底是怎么发生的1.1 先从 ViewPager 的“预加载”机制说起很多刚接触 ViewPager 的人会有一个直觉我只看当前页ViewPager 是不是就只加载这一页其实不是。ViewPager 的底层设计目标是保证滑动足够流畅所以它会提前把相邻页面的 View 创建出来。这个提前创建的页数就是setOffscreenPageLimit()控制的值默认值是 1也就是说当前页左边一页、右边一页都会被预加载。这里有个非常容易踩的认知误区很多人以为setOffscreenPageLimit(0)能关掉预加载实测之后发现页面照样被创建了两次。因为 ViewPager 内部对传入的 limit 有保护逻辑0会被直接忽略最低也按照 1 来处理。这个特性的直接后果就是只要你的页面之间是相邻关系即使没滑过去Fragment 也会经历完整的创建流程。“重复加载”这个词在排查时往往对应着不同的现象。一种是重复“创建”也就是 Fragment 实例被反复 new 出来、onCreateView 被反复执行另一种是重复“加载”也就是 onResume、网络请求这类逻辑被反复触发。这两种现象的解决方案是完全不一样的必须先搞清楚你遇到的是哪一种否则很容易对着错误的方向瞎折腾。1.2 为什么 Fragment 会被反复创建和销毁传统 ViewPager 搭配 FragmentPagerAdapter 使用的时候Adapter 内部会维护一个已经实例化的 Fragment 集合。但有个细节经常被忽略ViewPager 在滑动过程中会根据当前位置动态调整 Fragment 的 attach 和 detach。具体来说离开当前展示范围足够远超过 offscreen 范围的 Fragment会被 FragmentManager 执行 detach。detach 之后 Fragment 并不会被销毁只是 View 被销毁了。所以在 FragmentPagerAdapter 的逻辑里切回来时会重新调用 onCreateView把布局重新 inflate 一遍。如果你在 onCreateView 里做了一些耗时操作比如 findViewById、设置数据、初始化状态那每一轮切页都在重复劳动。更严重的一种场景是直接使用 FragmentStatePagerAdapter。这个适配器会把 Fragment 存放进 Bundle页面滑远之后直接销毁整个 Fragment 实例切回来时再重新创建。在这种机制下重复加载的问题是规避不了的只能通过状态保存和恢复机制来弥补。另一个隐蔽的重建场景是 Activity 因为内存不足或配置变更被系统回收。FragmentManager 会通过onSaveInstanceState()保存 Fragment 的状态然后重建时恢复。但如果你在 Fragment 里有非静态内部类持有 View 引用、Handler 持有 Activity 引用这类写法重建过程中很容易出现 View 关联错乱、状态不对的问题。这些都是“莫名其妙就重复加载”的高发原因。1.3 现象放大为什么页面越切越卡、数据越刷越多如果只看单次 Fragment 重建好像影响也不大——inflate 一个布局能有多少成本但实际项目里多个页面叠加、图片加载、列表刷新、网络回调一起堆上去的时候问题就很明显了。我遇到过一个真实案例Fragment 的 onCreateView 里做了一次网络请求用户快速滑动 ViewPager 三个 Tab 来回切换。由于 FragmentPagerAdapter 的 detach/attach 机制每切回来一次就请求一次接口。用户滑了十几下接口被调了十几次后端日志里密密麻麻全是一条重复请求记录页面本身也因为频繁刷新数据导致列表闪烁、滑动严重掉帧。还有一类问题更难发现onCreateView 反复 inflate 之后旧 View 没有被正确释放或者被长时间的异步任务持有导致内存占用只增不减。用户划了几下就觉得“变卡了”但 Open Profile 又看不出具体哪里泄漏 —— 实际上就是 Fragment 在反复创建销毁的过程中旧对象的生命周期没有被及时收回。这也是“重复加载”最隐蔽的危害。2. 方案选型用什么样的设计避免重复加载2.1 FragmentPagerAdapter 和 FragmentStatePagerAdapter 怎么选改造之前要先做适配器选型。这两个适配器的核心区别在于“非展示状态的 Fragment 会被处理到什么程度”。FragmentPagerAdapter 适合页面数量少、每个页面内容层级较深的场景。它只销毁 Fragment 的 View不销毁 Fragment 实例。好处是状态保存相对容易缺点是占用资源偏高页面数量多的时候不推荐。FragmentStatePagerAdapter 正好相反它会销毁 Fragment 实例并保存状态到 Bundle适合页面数量多、内容较轻量的场景。问题是 Fragment 实例被销毁后切回来必然要重新走一遍创建流程如果业务逻辑没有配合状态恢复那体验真的很糟糕。用 AndroidX 之后这两个适配器都已经“退役”了官方推荐使用FragmentStateAdapter。但这个适配器的行为更接近 FragmentStatePagerAdapter它会灵活处理 Fragment 的销毁重建。所以后面讲代码的时候我不会完全依赖适配器本身而是把处理逻辑放在 Fragment 内部保证无论适配器如何管理生命周期页面都不会重复加载。2.2 三种主流解决路线和适用场景我把实际项目里常见的做法归成三条路线大家可以根据自己的场景选路线 A调大 offscreenPageLimit让所有页面常驻这个做法的门槛最低代码改动也最少。但本质上是“用内存换时间”页面一多内存占用就会很夸张。它的适用场景很窄最多适合两三个 Tab 内比较重型的页面治标不治本。路线 B用 show/hide 切换不销毁 View这条路线需要重写 FragmentPagerAdapter 的instantiateItem()方法改成 FragmentTransaction 的show()和hide()来切换页面。特点是从头到尾 Fragment 只创建一次View 不销毁、不重建状态天然保留切换速度极快。缺点是所有页面从一开始就全部加载完成页面数据多的话首屏会受影响内存占用也比较高。路线 C保证 onCreateView 只创建一次 View 业务加载逻辑与生命周期解耦推荐处理思路是onCreateView 里判断如果 View 已经存在就直接复用否则才 inflate数据的拉取和 UI 刷新放在合适时机不要绑在创建流程里。这种方式既保留 ViewPager 的预加载滑动体验也不会因为切页而重复请求接口或重复重建布局。主流商业应用中大部分都有这套影子重构起来对现有代码的侵入也最小。2.3 要不要用“单例 Fragment”来避免重复创建开发群里经常看到有人提出“直接把 Fragment 做成单例不就行了”的思路。确实能保证实例只被创建一次。但从工程角度看单例 Fragment 不是最优解甚至有一些风险。主要原因有两个。第一Fragment 的生命周期由 FragmentManager 管理它需要根据页面状态动态创建、恢复、销毁实例如果你硬要搞单例FragmentManager 在重建时会发现实例状态对不上轻则恢复状态错乱重则直接抛“Fragment already added”之类的异常。第二单例 Fragment 天然持有 View 和 Activity 的引用Activity 销毁后 Fragment 未跟着销毁会造成内存泄漏而且这种泄漏往往在 LeakCanary 里都很难定位。所以我个人的结论是遇到重复创建问题优先从前面的路线 A/B/C 里选不要贪图单例写法的一时省事。3. 核心实现从创建到状态恢复的完整代码实战3.1 容器 Activity 的基础框架假设我们要做一个三个 Tab 的首页分别叫“首页”“发现”“我的”。Activity 这边主要职责是初始化 ViewPager 和 Adapter并把 Fragment 的管理权交给系统。class MainActivity : AppCompatActivity() { private val fragments listOf( HomeFragment.newInstance(), DiscoverFragment.newInstance(), MineFragment.newInstance() ) override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) val viewPager: ViewPager findViewById(R.id.viewPager) val pagerAdapter object : FragmentStateAdapter(supportFragmentManager, lifecycle) { override fun getItemCount(): Int fragments.size override fun createFragment(position: Int): Fragment fragments[position] } viewPager.adapter pagerAdapter viewPager.offscreenPageLimit 1 } }这里注意一点在FragmentStateAdapter的新 API 里createFragment()返回的 Fragment 在页面滑出范围后仍然可能被销毁和重建。如果把它和外部 list 绑定起来会导致重建时传进去的实例被重复使用。所以更稳妥的做法是让createFragment()每次返回一个按照位置新建的 Fragment如下override fun createFragment(position: Int): Fragment when (position) { 0 - HomeFragment() 1 - DiscoverFragment() 2 - MineFragment() else - HomeFragment() }另一个细节是offscreenPageLimit的传值。前面已经说了最少为 1如果你想三个页面都常驻可以写成 2问题不大。不过我的建议是保持默认或者 1让 Fragment 自己处理好创建复用不要把压力全压在内存上。3.2 ViewBinding 场景下的 onCreateView 复用我自己比较喜欢用 ViewBinding 写界面因为可以减少 findViewById 的样板代码。但它有一个坑ViewBinding 的bind()方法要求传入的 View 必须来自这次 inflate并且返回的 binding 实例和 View 是一一对应的。如果你在 Fragment 里反复调用 onCreateView每次都会生成一个新的 binding 实例如果旧的 binding 还被持有就会造成旧 View 的泄漏。所以复用的核心思路是把根 View 缓存起来binding 也只在初始化时绑定一次。class HomeFragment : Fragment() { private var _binding: FragmentHomeBinding? null private val binding get() _binding!! private var rootView: View? null private var dataLoaded false override fun onCreateView( inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle? ): View? { // 已有缓存 View直接复用跳过重复 inflate同时避免 binding 覆盖 if (rootView ! null) { return rootView } _binding FragmentHomeBinding.inflate(inflater, container, false) rootView binding.root initView() // 只执行一次的初始化逻辑 loadDataIfNeeded() // 按需加载 return rootView } override fun onDestroyView() { super.onDestroyView() // 只释放 binding保留 rootView 引用 _binding null } private fun loadDataIfNeeded() { if (dataLoaded) return // 网络请求或本地数据加载 dataLoaded true } }这里有个很容易被忽略的点onDestroyView()里如果把binding置空而rootView没有置空那么在 Fragment View 重建的时候rootView会提前拿到旧的 View。这个行为正是我们想要的——避免重复 inflate。不过要注意如果你在onDestroyView里把rootView null那这个优化就不成立了。至于为什么不能把 rootView 也清掉因为 FragmentPagerAdapter 的 detach 之后重新 attach要走 onCreateView如果旧 View 被清理掉那就又回到重复 inflate 的老路上了。3.3 数据的“懒加载”避免每切一次页面就拉一次接口Fragment 的 onCreateView 只负责“创建 View”那数据什么时候加载如果放在 onCreateView 里那么每次 detach/attach 之后切回来数据都会重新加载页面闪烁、请求堆积的问题就来了。所以数据的加载应该和 Fragment 的可见状态绑定。在传统 ViewPager 场景下可以使用setUserVisibleHint()这个方法来做页面可见性的判断。这个方法在 Fragment 对用户可见或者不可见时都会被调用而且调用时机早于 onCreateView适合做懒加载状态标记。class DiscoverFragment : Fragment() { private var isViewCreated false private var isVisibleToUser false private var dataLoaded false override fun setUserVisibleHint(isVisibleToUser: Boolean) { super.setUserVisibleHint(isVisibleToUser) this.isVisibleToUser isVisibleToUser if (isVisibleToUser isViewCreated) { onVisibleLazyLoad() } } override fun onViewCreated(view: View, savedInstanceState: Bundle?) { super.onViewCreated(view, savedInstanceState) isViewCreated true if (isVisibleToUser) { onVisibleLazyLoad() } } private fun onVisibleLazyLoad() { if (!dataLoaded) { // 在这里执行真正的数据加载 dataLoaded true } } }这样做的效果是页面只有在这个 Fragment 真正对用户可见时才会加载数据不管是第一次进入还是从其他 Tab 切回来只要数据已经加载过就不会二次请求。不过在 AndroidX 下setUserVisibleHint()已经被标记为 deprecated新版推荐通过Lifecycle或者onHiddenChanged()来判断。假如你还在用传统 ViewPager用setUserVisibleHint不会有兼容性问题但如果升级到 ViewPager2就需要换用OnPageChangeCallback或者FragmentTransaction的setMaxLifecycle()方案了具体情况我会在后面补充。3.4 进阶方案用 show/hide 保证 View 不销毁如果你接受“页面数量少、内容较重”的场景展示一种 show/hide 的实现。这个方案下Fragment 永远不会走 detach因此 onCreateView 只会执行一次重复加载问题从根本上被抹掉了。class NoDestroyPagerAdapter( fragmentManager: FragmentManager, private val fragments: ListFragment ) : FragmentPagerAdapter(fragmentManager, BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) { private val fragmentTags mutableListOfString() override fun getItem(position: Int): Fragment fragments[position] override fun instantiateItem(container: ViewGroup, position: Int): Any { val tag makeFragmentName(container.id, position) fragmentTags.add(tag) val fragment fragmentManager.findFragmentByTag(tag) ?: fragments[position].also { fragmentManager.beginTransaction() .add(container.id, it, tag) .hide(it) .commitNow() } val activeFragment fragmentManager.findFragmentByTag(tag) as Fragment if (!activeFragment.isHidden) return activeFragment fragmentManager.beginTransaction() .show(activeFragment) .commitNow() return activeFragment } override fun destroyItem(container: ViewGroup, position: Int, object: Any) { // 不销毁保持 Fragment 存活 } private fun makeFragmentName(viewId: Int, index: Int): String { return android:switcher:$viewId:$index } }这段代码有几个地方要特别说明。首先destroyItem()留空意思是滑动远离的页面不销毁。这是该方案的关键点不过它也有一些副作用比如页面数量多时全部 Fragment 都会被创建、都驻扎在内存里。其次我用commitNow()而不是commit()。因为computeScroll期间如果采用异步 commit可能导致 Fragment 显示状态在本次布局前没有被及时更新视觉上会有闪烁甚至白屏。commitNow()是同步操作切换时更稳定。第三instantiateItem并不是只调一次所以每次调用要考虑给已经存在的 Fragment 做 show 操作其他 Fragment 保持 hide这样 ViewPager 的滑动实际上就变成了 Fragment 的显隐切换。这个方案的优点是页面切换极快相当于“全部预加载完成”。缺点是所有 Fragment 从 Activity 创建那一刻就全部执行了初始化首屏的耗时和数据流量都会增加。如果页面很多不建议无脑套用适合内容比较少、层级比较浅的 Tab 型页面。3.5 ViewPager2 下的方案差异虽然标题写的是 ViewPager但很多项目其实已经升级到 ViewPager2 了。ViewPager2 内部基于 RecyclerView 实现生命周期管理更加严格Fragment 的销毁重建也更容易发生。它对应的适配器是FragmentStateAdapter它的行为决定了页面滑出一定范围后 Fragment 会被彻底销毁。这样的设计下节省了内存但“重复加载”的频率反而更高。针对 ViewPager2有几个可行的做法一是利用FragmentStateAdapter默认对相邻页面的预创建配合 Fragment 的onResume()来做数据懒加载。不要用setUserVisibleHint它已经废弃且可能与 ViewPager2 的行为冲突。二是在 Fragment 这边保留 View 缓存逻辑参考 3.2 节但要注意 ViewPager2 的 Fragment 在onDestroyView()之后系统可能已经销毁了那个 View所以缓存的 rootView 如果非空就还有重新使用的可能如果系统销毁了rootView 可能已经 detach 了需要判断 rootView.parent 是否为空为空了就重新 inflate。三是考虑使用behavior参数。FragmentStateAdapter 有内部策略可以让你决定 Fragment 在何时进入STARTED、RESUMED状态但控制力度有限。真正确保不重建还得是“保留 View 手动管理展示状态”这条路只是实现复杂度更高。如果你正处在旧代码升级到 ViewPager2 的节点上建议先把 Fragment 内部逻辑改成“独立于生命周期”的加载方式而不是依赖onCreateView。这样无论容器怎么变化都不会重复请求和重复渲染。4. 常见问题与排查技巧实录4.1 高频问题排查速查表现象可能原因排查思路解决方案切回页面后网络请求再次发起数据加载写在 onCreateView / onResume 里打点日志观察调用时机用 isViewCreated isVisibleToUser 做懒加载页面闪烁或列表突然滚动到顶部数据重新加载后刷新了整个布局观察是否重复 inflate缓存 rootView 并在 onCreateView 复用内存泄漏反复切页后内存只升不降detach/attach 没有释放旧 View 引用Memory Profiler 分析 Fragment 实例数量在 onDestroyView 里解绑图片、清空异步任务引用切换回来时数据还是旧的没有实现 onSaveInstanceState 状态恢复复现后检查 Bundle 内容onSaveInstanceState 保存关键数据onViewCreated 恢复“Fragment already added”崩溃多个地方重复调用 add/commit 同一个 Fragment确认 Fragment 是否已被 FragmentManager 持有使用 findFragmentByTag 判断避免重复添加使用单例 Fragment 后状态混乱单例实例和 FragmentManager 恢复机制冲突检查是否手动 new Fragment不要使用单例 Fragment改为容器管理4.2 我在实战中踩过的三个坑第一个坑是 ViewBinding 的绑定时机问题。最开始我在复用 rootView 的同时也在onCreateView里每次重新FragmentHomeBinding.bind(rootView)结果切换回来时某些控件的点击事件失效了。原因是最新绑定生成的 binding 对象与旧 View 里的状态冲突尤其是 Adapter 的 Item 点击和 RecyclerView 的滚动位置全部对不上了。后来我把 binding 和相关控件的初始化全部收敛到 onCreateView 的“只执行一次”分支里问题立刻消失。第二个坑是offscreenPageLimit设置的副作用。某个页面里嵌了一个比较大的 RecyclerView我想让所有页面保持存活就把 limit 设置成fragments.size - 1。结果首屏启动时三个 Fragment 全部一起创建、一起请求数据接口瞬间被打爆。后来我才想明白分页加载不一定要靠“驻留”而是靠“懒加载”来控制请求时机两者配合才能达到“既流畅又不浪费”的效果。第三个坑是onDestroyView里清空资源的尺度。为了追求严格的内存释放我在 onDestroyView 里把binding、rootView、RecyclerView 的 adapter 全都置空。结果 detach/attach 回来后onCreateView 找不到缓存的 rootView只能重新 inflate网络又重来了一遍。后来我把“清空资源”和“保留 View”分开只有 Fragment 真正销毁时才卸掉所有引用只是 detach 切换时保留 View。这个尺度才是平衡之道。4.3 排查技巧如何验证 Fragment 到底有没有重建排查重复加载问题时我会在 Fragment 的关键生命周期方法里打日志然后在操作页面的时候观察 Logcat。override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) Log.d(TAG, onCreate, instance - $this) } override fun onCreateView(...): View? { Log.d(TAG, onCreateView, existingRoot - ${rootView ! null}) ... } override fun onDestroyView() { super.onDestroyView() Log.d(TAG, onDestroyView) } override fun onDestroy() { super.onDestroy() Log.d(TAG, onDestroy) }如果看到onCreate被反复执行说明 Fragment 实例被重建了问题在 FragmentManager 或适配器层。如果只有onCreateView和onDestroyView被反复执行则是 View 层的重建问题在 ViewPager 的 detach/attach 机制。重点观察这两种日志的差异基本能确定问题的层次。再配合 Memory Profiler 抓一个 Java Heap Dump如果同一个 Fragment 的实例数量明显大于页面数量说明确实存在不必要的重复创建。这时就要从“实例复用”“状态保存”和“加载时机”三个方向去查代码。写在最后处理 ViewPager 中的 Fragment 重复加载最忌讳的就是盲目堆缓存。真正稳的做法是在动手前先弄明白是“View 重建”还是“实例重建”再决定走哪条路。我个人推荐路线 C让 Fragment 自己保证只创建一次 View同时把数据加载和页面可见性解耦。这套思路不仅在常见 ViewPager 里通用也基本可以无缝迁移到 ViewPager2算是性价比最高的方案。最后再分享一个实践细节如果你决定用缓存 View 的方式一定注意 Fragment 在onDestroyView()之后旧的 rootView 可能已经从原来的父布局中移除也可能会保留某些监听器。稳妥的做法是在复用之前判断rootView.parent null不为空就先从父布局移除。这个判断能避免很多诡异的重绘问题如果你正在重构这类页面值得在代码里加一行。