企业官网建设流程全解析

先说一个我印象很深的线上问题。去年年底我负责的一款资讯类App上线后收到反馈：用户在底部Tab间来回切换时，列表页总是转圈很久，后台日志里同一个接口短时间内被请求了十几次，更夸张的是偶发页面重叠闪烁。团队第一反应是网络鉴权失败触发了重试，结果翻了半天代码，网络请求只在Fragment的onCreateView里写了一次。最后定位到的问题，就是ViewPager + Fragment组合下的“重复加载”——这几乎是每个做多Tab页面的Android开发者都会撞上的坑。

这篇文章就把这个坑彻底摊开：先梳理重复加载的典型症状，再从ViewPager底层机制讲清楚为什么会发生，然后给出三套亲测有效的解决方案，最后附上一套完整的排查链路。不管你是刚接手项目的新人，还是被这个Bug折磨到怀疑人生的老手，都能在这里找到能直接落地的答案。

1. 先说现象：Fragment重复加载到底长什么样

1.1 线上最常见的四种症状

如果你怀疑自己的项目也存在Fragment重复加载，先别急着改代码，对照下面这份症状清单确认一下：

• 每次从其他Tab切回当前Fragment，列表都重新请求网络，甚至出现接口短时间多次命中的日志
• Fragment的onCreateView、onViewCreated在非首次创建时依然被反复执行，断点打进去会看到同一个页面多次进入
• 快速左右滑动ViewPager后，页面出现叠影，或者原本的布局被重复添加到父容器，直接抛IllegalStateException: Already have a parent
• App旋转屏幕或从后台切回前台后，ViewPager显示的页面和实际恢复的Fragment“对不上”，出现白屏或错页

这四种现象背后的触发机制不完全相同，但对外表现都像是“页面被重新加载了一遍”。如果你遇到过其中任何一种，恭喜你，你已经站在这个坑的边缘了。

1.2 一个看起来完全正常的复现工程

很多人在自查时一开始都不相信代码有问题，因为写法看起来太标准了。我见过最多的写法是这样的：

public class HomeFragment extends Fragment { private String title; public static HomeFragment newInstance(String title) { HomeFragment fragment = new HomeFragment(); Bundle args = new Bundle(); args.putString("title", title); fragment.setArguments(args); return fragment; } @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { View view = inflater.inflate(R.layout.fragment_home, container, false); loadData(); // 在这里发请求，看起来没毛病 return view; } }

Activity侧：

viewPager.setAdapter(new FragmentPagerAdapter(getSupportFragmentManager(), BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT) { @Override public Fragment getItem(int position) { return HomeFragment.newInstance(titles.get(position)); } @Override public int getCount() { return titles.size(); } });

这套代码几乎每个教程都这么写，但恰恰是这种“标准写法”把重复加载的问题掩盖了。原因后面会详细拆，这里先记住一个结论：getItem负责的是“创建Fragment实例”，但ViewPager对Fragment的销毁和重建是另一套独立逻辑，两者叠加时，重复加载就开始出现了。

1.3 先分清：预加载其实不是Bug

这里必须先给ViewPager正个名。ViewPager为了保证滑动时的流畅性，默认会预加载当前页左右各一页的页面。也就是说，当你停在Tab 1时，Tab 2的Fragment其实已经在后台被创建了。这属于正常预加载，不是重复加载。

预加载的本质是空间换时间：让你划过去的那一下，页面已经准备好，而不是现创建现加载。真正需要警惕的是重复加载：同一个位置的业务数据被反复请求、同一个View被反复创建、同一个Fragment在FragmentManager里出现多份实例。把预加载和重复加载分清楚，后续选方案时才不会搞错方向。

2. 扒开根因：ViewPager的缓存机制与Fragment生命周期

2.1 ViewPager到底是怎么“养活”前后两页的

经典ViewPager内部不是RecyclerView，而是一个自己管理的容器。它内部维护了一个ArrayList<ItemInfo>，核心方法是populate()：每次页面切换时会计算当前页mCurItem的前后各mOffscreenPageLimit个页面，需要的就通过Adapter的instantiateItem()去创建并添加，不需要的则通过destroyItem()销毁。

默认情况下setOffscreenPageLimit的值是1，所以ViewPager屏幕外最多保留左右各1个页面。具体到FragmentPagerAdapter，它内部会通过FragmentManager.beginTransaction()对Fragment进行add、attach、detach、remove。关键在于：detach不等于销毁实例，Fragmeng实例还留在FragmentManager里，只是View被销毁了。

这里才是问题的第一个闸口：很多开发者以为“Fragment被销毁了”，所以每次进入都重新初始化数据，但Fragment实例和它的状态其实一直活着。

2.2 FragmentPagerAdapter与FragmentStatePagerAdapter的差异

这两种Adapter是所有重复加载问题的源头，必须分清楚：

很多人用FragmentPagerAdapter最大的误解是：反正实例不销毁，切回来应该不会重新走onCreateView。但实际上detach后View被销毁，重新attach时Fragment的onCreateView会再次执行，网络请求如果放在这里，就会表现为“重复加载”。

FragmentStatePagerAdapter则更直接：页面滑出缓存范围后实例被移除，滑回来时再创建一个全新的实例。这种模式下如果不加缓存控制，重复加载问题会更频繁。

2.3 最容易触发重复加载的四个写法

结合排查经验，绝大多数重复加载都出自下面这四种情况：

1. 在onCreateView或onResume里直接请求数据。这是最常见的一种。onCreateView每次重建View都会执行，onResume每次切入都会执行，网络请求放在这些位置天然容易重复。
2. Activity重建后Adapter继续用新实例列表。旋转屏幕、深色模式切换、进程重建都会导致Activity重新创建，而FragmentManager会恢复之前的所有Fragment实例。这时如果你在Activity的onCreate里又构造了一组新的Fragment传给Adapter，旧实例和新实例同时存在，页面就会叠加或互相抢位置。
3. 手动在页签切换时add Fragment。有的项目为了让切换更可控，在TabLayout的监听里手动add或show/hideFragment，这等于在ViewPager自己的事务之外又维护了一份Fragment集合。两份事务互相覆盖，非常容易出现重复添加。
4. 动态调整offscreenPageLimit或调用notifyDataSetChanged。尤其是调小缓存页数，原本正在存活范围内的页面突然被destroy，滑回来时又重新创建，用户肉眼感受就是“每次回来都在重新加载”。

2.4 onCreateView反复执行的真相

之前有个同事跟我争论：“我的Fragment明明只有一个实例，为什么onCreateView每次切换都执行？”这个问题的答案，正是理解整个重复加载问题的最佳切入点。

在FragmentPagerAdapter的机制里，页面滑出屏幕后，Fragmment会进入detach状态，此时onDestroyView()会被调用——注意不是onDestroy()。View被销毁，但Fragment实例及其持有的数据仍然被FragmentManager管理着。当你再次滑回来时，ViewPager会重新attach这个Fragment，系统为了让页面更省内存，选择重建View。于是onCreateView再次执行。

所以，onCreateView的重复执行是Android生命周期设计的一部分，它不是异常，更不是“系统故障”。真正需要解决的是：不要让这些生命周期回调反复触发重量级业务逻辑。我们做优化，不是去阻止onCreateView执行，而是让业务加载这件事变得可控、可复用、可防重。

3. 解法一：用FragmentManager按Tag复用实例，挡住“多实例叠加”

3.1 重复实例是怎么来的

如果你看到页面叠影，或者Fragment的onCreate在短时间内被调用了两次，那基本可以断定：FragmentManager里出现了同一页面的多个实例。

出现这种情况的常见路径是：Activity首次创建时getItem返回了new HomeFragment()，同时Activity重建时FragmentManager恢复了之前的旧实例。之后ViewPager重新布局，发现当前页需要Fragment，于是又通过getItem创建了一个新的。旧实例在FragmentManager里，新实例又加进来，两个都认为自己属于当前页，页面自然叠在一起。

还有一种路径是程序员自己不小心：在代码里除了ViewPager，还手动调用了add(fragment)。如果这个fragment实例和ViewPager内部实例不是同一个对象，重复就产生了。

3.2 正确按“android:switcher:”规则查找实例

FragmentPagerAdapter内部给每个Fragment设定了一个稳定tag，规则是：

"android:switcher:" + viewPager.getId() + ":" + position

所以最稳妥的做法是：在getItem中不再无条件new，而是先尝试从FragmentManager里按这个tag查找已有实例。查得到就直接复用，查不到才创建。

public class SafeFragmentPagerAdapter extends FragmentPagerAdapter { private FragmentManager fragmentManager; private int containerId; public SafeFragmentPagerAdapter(FragmentManager fm, int containerId) { super(fm, BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT); this.fragmentManager = fm; this.containerId = containerId; } @Override public Fragment getItem(int position) { String tag = "android:switcher:" + containerId + ":" + position; Fragment fragment = fragmentManager.findFragmentByTag(tag); if (fragment == null) { fragment = HomeFragment.newInstance(titles.get(position)); } return fragment; } }

这里有个细节：containerId是ViewPager这个控件的id，不是它的父容器id。因为FragmentPagerAdapter的tag规则用的是container.getId()，也就是你在XML里给ViewPager设置的android:id。把containerId通过构造器传进来，避免在getItem里去拿Activity，否则容易踩空指针。

3.3 这个方案的边界

这个方案解决的是“多实例叠加”和“Activity重建后新旧实例混乱”这两类问题。但它对“View重建导致的业务重复请求”帮助有限——单实例的Fragment依然会在每次attach时执行onCreateView，如果数据请求写在onCreateView里，该重复还是会重复。

所以在项目里，我通常把方案一作为第一道防线，让实例层次保持干净；再配合方案二或方案三去解决View和业务加载的问题。三道防线各司其职，才能把重复加载堵死。

4. 解法二：缓存根布局，挡住“重复Inflate与业务初始化”

4.1 最省事的View缓存写法

如果你希望Fragment反复切换时，View不用重新创建，布局状态也能原样保留，可以在Fragment里缓存根View。这也是很多老项目里广泛使用的一种技巧：

public class HomeFragment extends Fragment { private View rootView; @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { if (rootView == null) { rootView = inflater.inflate(R.layout.fragment_home, container, false); initView(rootView); loadData(); } else { // View已存在，先移除旧的父容器引用 ViewGroup parent = (ViewGroup) rootView.getParent(); if (parent != null) { parent.removeView(rootView); } } return rootView; } }

这个写法有两点必须解释清楚：

第一，为什么rootView为空时才加载数据？因为rootView的创建和业务初始化是一体的，View不销毁，就不用重新inflate，自然也不用重新走数据加载。这样即便Fragment被detach再attach，onCreateView虽然执行了，但进去直接被else分支挡住，页面保留原样。

第二，为什么必须removeView？当Fragment从ViewPager中被detach时，View其实还挂在ViewPager的容器ViewGroup里。如果不先移除，下次返回这个View给它时，系统会抛出“Already have a parent”的运行时异常。

4.2 与ViewBinding配合的正确姿势

现在很多新项目已经用ViewBinding替代了findViewById。如果我告诉你ViewBinding和View缓存不能简单混用，你可能会困惑。其实是有正确套路的。

ViewBinding和findViewById最大的区别是：inflate一次绑定对象后，如果对同一个View再次进行绑定，可能会导致监听器重复设置、Binding内部状态错乱。所以缓存的粒度要提升到Binding这一层，而不是View这一层：

public class HomeFragment extends Fragment { private FragmentHomeBinding binding; @Override public View onCreateView(LayoutInflater inflater, ViewGroup container, Bundle savedInstanceState) { if (binding == null) { binding = FragmentHomeBinding.inflate(inflater, container, false); binding.textTitle.setText("Hello"); loadData(); } return binding.getRoot(); } @Override public void onDestroyView() { super.onDestroyView(); // 释放Binding，避免内存泄漏 binding = null; } }

这里有个容易踩的坑：如果Fragment被detach后View销毁，但我们的缓存意味着View不会销毁，那onDestroyView会不会执行？答案是：detach一定会执行onDestroyView。所以一旦在onDestroyView里把binding置空了，下一次attach时binding为空，又会重新inflate，缓存失效。这是ViewPager下View缓存方案最大的矛盾点。

我自己实践下来的处理方式是：缓存方案只用于“页面确实需要保留状态”的场景，并且不在onDestroyView里无条件清空binding，而是用一个额外的布尔变量标记当前Fragment是否已经被ViewPager移除出缓存范围。如果只是常规的detach/attach切换，保留binding；只有当Fragment被真正remove时，才彻底清空。这需要和方案一的实例复用逻辑配合起来，建议对生命周期有足够把握后再用。

4.3 缓存View的代价与清理时机

View缓存并不是免费的。它的代价主要有三个：

• 内存占用上升：每个Fragment的完整View树都常驻内存。页面少还好，页面多了之后，几十上百个Fragment的View树会是一笔不小的开销。
• 状态过期风险：View被缓存后，页面内的数据不会自动刷新。如果列表数据需要实时更新，你还得手动提供刷新入口。
• 泄漏隐患：如果Fragment实例被销毁了，但它的View仍然被某个全局静态变量或者外部的ViewGroup持有，就形成了泄漏。这就是为什么缓存View时必须保证“View只存在于Fragment自己的生命周期范围内”。

我的建议是：缓存View方案适合页面数量少、单页View树简单、需要保留输入状态或滚动位置的多Tab场景。页面一旦超过五个，或者单个Fragment布局很深，优先考虑方案三的状态机懒加载，把内存控制权交还给系统。

5. 解法三：状态机懒加载，把“业务加载”牢牢锁住

5.1 懒加载到底想解决什么

前面两个方案分别解决了“实例重复”和“View重复创建”，但真正的业务重复加载——也就是网络请求重复发起——往往需要一个更直接的机制来约束。

懒加载的核心思想很朴素：Fragment可以预创建，但业务数据只有等用户真的看到这个页面时才加载，并且只加载一次。这样ViewPager的预加载机制完全保留，不会牺牲流畅性，同时重复请求问题从源头上被掐断。

5.2 三个标志位设计

我用三个布尔变量共同控制懒加载：

• mIsViewCreated：标记onViewCreated是否已经执行过，代表View层是否就绪
• mIsVisibleToUser：标记Fragment当前是否对用户可见
• mIsDataLoaded：标记业务数据是否已经加载，防止重复

加载的触发条件必须同时满足：View已创建、用户可见、数据未加载。三个条件缺一不可。这样的状态机比简单的“在onResume里发请求”可靠得多，因为onResume在页面从后台切回前台时也会执行，如果网络请求直接放在onResume里，一次前后台切换就能造成一次额外请求。

5.3 一份可复制的LazyFragment基类

下面是一份我在多个项目里用过、验证过稳定性的Java基类。把它作为所有ViewPager内Fragment的父类，子类只需要实现onLazyLoad()方法即可：

public abstract class LazyFragment extends Fragment { private boolean mIsViewCreated = false; private boolean mIsVisibleToUser = false; private boolean mIsDataLoaded = false; @Override public void onViewCreated(@NonNull View view, @Nullable Bundle savedInstanceState) { super.onViewCreated(view, savedInstanceState); mIsViewCreated = true; tryLoad(); } @Override public void setUserVisibleHint(boolean isVisibleToUser) { super.setUserVisibleHint(isVisibleToUser); mIsVisibleToUser = isVisibleToUser; tryLoad(); } private void tryLoad() { if (mIsViewCreated && mIsVisibleToUser && !mIsDataLoaded) { mIsDataLoaded = true; onLazyLoad(); } } protected abstract void onLazyLoad(); @Override public void onDestroyView() { super.onDestroyView(); mIsViewCreated = false; mIsDataLoaded = false; } }

子类这样使用：

public class HomeFragment extends LazyFragment { @Override protected void onLazyLoad() { // 只有第一次可见时才会走到这里 viewModel.loadHomeData(); } }

这个基类的关键逻辑，是tryLoad()里三个条件的“与”判断。setUserVisibleHint是ViewPager切换页面时用来告知当前页可见性的经典回调。首次创建时，如果页面恰好是默认页，onViewCreated会先执行；如果页面是预加载页，可见性为false，等滑动过来变成true时才触发。这样无论页面创建和可见的顺序如何，加载时机都不会错。

5.4 ViewPager2与show/hide下的可见性差异

这里必须插一段重要提醒：ViewPager2不再调用setUserVisibleHint，因为它底层改用了RecyclerView架构，Fragment的可见性是通过FragmentManager.setMaxLifecycle控制的。基于ViewPager2的项目，如果还用上面的基类，setUserVisibleHint永远不会被触发，懒加载会完全失效。

正确做法是改用onResume配合页面选中状态判断，或者在registerOnPageChangeCallback的onPageSelected里手动通知可见性。

另一个场景是FragmentTransaction.show/hide：这种方式也不会调用setUserVisibleHint，因为show/hide操作的是整个View的可见性，而不是ViewPager的滑动可见性。如果你用show/hide做多Tab切换，需要在onHiddenChanged(boolean hidden)回调里自己处理：

@Override public void onHiddenChanged(boolean hidden) { super.onHiddenChanged(hidden); if (!hidden) { mIsVisibleToUser = true; tryLoad(); } else { mIsVisibleToUser = false; } }

所以，继承LazyFragment之前，先确认你的容器是ViewPager还是ViewPager2，是滑动切换还是show/hide切换。机制不一样，可见性回调入口完全不一样，写错了一个地方，懒加载就静默失效。

6. 实测对比与排查链路：不同场景怎么选，出了事怎么查

6.1 三种方案的效果对比

我用一个三Tab的测试项目，对三种方案做了快速切换100次的实测。测试机型是开发常用的中端机，统计口径分别是：onCreateView执行次数、网络请求次数、页面切换后内存增量。

说明一下：方案一的onCreateView看起来还是高，是因为它本身不会阻止View重建；方案三允许onCreateView执行，但网络请求被锁住了，所以业务请求次数大幅下降。实际项目中使用时，方案一和方案三可以叠加：用方案一保证Fragment实例唯一，用方案三保证业务只加载一次，组合效果是最好的。

6.2 排查链路：从一份日志开始

如果项目里已经出现了疑似重复加载的问题，别急着套方案。先把现象定位清楚，对号入座去修复。我的排查步骤通常是这样的：

第一步，在Fragment的所有关键生命周期回调里打上带时间戳的Log，包括onCreate、onCreateView、onViewCreated、onResume、onPause、onDestroyView、onDestroy。连续切换Tab，观察Log输出序列。

第二步，判断是“多实例”还是“单实例重建”。在Activity里打印getSupportFragmentManager().getFragments().size()，如果同一页面出现了两个HomeFragment实例的记录，基本就是实例叠加问题，走方案一。

第三步，检查Adapter配置。重点看Activity每次重建时是否重新new了Adapter或Fragment列表；以及getItem里是否用了new Fragment()。这一步能排除大半的“Activity重建后状态混乱”。

第四步，检查Fragment的Tag。看看有没有手动传自定义tag，或者getItemId被重写时返回了不稳定值。tag不稳定，findFragmentByTag会失效，方案一就用不上。

第五步，用Android Studio的Layout Inspector看当前界面层级。如果发现两套相同的View叠在一起，可以确认是重复添加，优先检查是否有地方手动执行了add事务。

第六步，如果Log显示“单实例、无叠影、但网络请求依然重复”，直接上方案三懒加载。这类问题通常是业务代码放在了onCreateView或onResume这类高频回调中，需要用状态机把加载行为锁住。

6.3 隐藏细节与团队规范

排查过程中我还发现过几个容易让人误判的隐藏细节，这里一并分享：

• 不要用Fragment的有参构造传业务对象。Activity重建后系统会通过无参构造恢复Fragment，如果你在构造器里传了复杂的业务对象，恢复时拿不到，就会被迫创建新实例。正确方式是用newInstance()配合setArguments(Bundle)传参。
• 不要轻易做静态单例Fragment。我看到过有人把Fragment做成静态单例来“解决”重复创建，结果ViewPager销毁重建后，同一个实例被试图添加到不同的容器，直接崩溃。静态单例在这里是饮鸩止渴。
• onResume不等于“用户正在看这个Tab”。在ViewPager的BEHAVIOR_RESUME_ONLY_CURRENT_FRAGMENT模式下，默认只有当前页的onResume会被回调，但有些旧项目用的是旧的BEHAVIOR_SET_USER_VISIBLE_HINT模式，onResume的语义会不一样。排查时先确认项目用的是哪种Behavior。
• offscreenPageLimit调大要谨慎。有些人觉得设成2、3页可以避免滑动重建，但每多一页，就多一页的Fragment预创建和预加载，对内存和耗电都是负担。很多“重复请求”其实是被这个设置放大的。

团队协作上，我后来在code review里定了一条规矩：凡是ViewPager内的Fragment，网络请求和页面初始化的调用点必须收敛到onLazyLoad()或者一个明确的loadOnce()方法中，禁止散落在onCreateView、onResume、onStart里。这条规矩执行两个迭代周期之后，线上相关的重复加载反馈基本清零。

6.4 最后一点个人体会

那次排查花了我一个完整的下午，最后发现代码逻辑本身没毛病，问题全出在对ViewPager生命周期机制的误解上。后来我养成了一个习惯：每做一个多Tab页面，先问自己三个问题——Fragment实例是谁创建的，它的View什么时候会被销毁，业务加载函数会被哪些生命周期回调触发。把这三个问题的答案写清楚，重复加载的隐患自然就暴露出来了。

如果你现在也在被这个问题的日志刷屏，别对着getItem发呆，也别急着堆缓存代码。先用Log确定自己遇到的属于哪一种“重复”：实例叠加、View重建、还是业务请求重复。对号入座去选方案，基本都能干净解决。