企业官网建设流程全解析

接手过不少用 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: List<Fragment> ) : FragmentPagerAdapter(fragmentManager, BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) { private val fragmentTags = mutableListOf<String>() 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 高频问题排查速查表

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，不为空就先从父布局移除。这个判断能避免很多诡异的重绘问题，如果你正在重构这类页面，值得在代码里加一行。