做 Android 的应该都有过这种经历一个首页列表在手机上显示得挺漂亮拿到平板上直接拉成大长条或者左右两边空荡荡恨不得把字放大三倍才不显得寒酸。我第一次接平板适配需求时就是这么干的——改 XML 加权重、调 dimens折腾一下午结果手机预览一打开全乱了。后来才意识到真正的解法不在于改布局文件而在于怎么组织页面模块本身。这个问题的答案就是 Fragment。Fragment 这玩意在国内社区被骂了很多年生命周期复杂、状态恢复坑多、和 Activity 纠缠不清但不得不承认手机和平板兼顾的活到今天也没几个比它更顺手的方案。这篇文章不打算从源码层面讲 Fragment 的实现原理那东西看源码能看睡着我就从实战角度聊清楚三件事Fragment 到底解决了什么、生命周期和回退栈怎么影响你的适配设计、以及 ViewPager 与 Fragment 组合切换时那些让人头秃的坑。适合看这篇的人有两类一是刚接触 Fragment 的新手需要一个不绕弯子的入门路径二是写过一阵子 Fragment 但总觉得哪里不对的开发者比如为什么切换页面会白屏、为什么数据老丢、为什么 replace 和 add 用起来差别这么大。这些坑我在项目里基本都踩过一遍下面挨个说。1. 手机和平板“两全”的命题为什么偏偏落在 Fragment 头上1.1 没有 Fragment 的年代适配是怎么做的在 Fragment 出现之前Android 开发者面对一个问题Activity 是唯一的页面载体每个页面都是独立的、完整的、占据整个屏幕的。手机上一个页面就是一个 Activity平板上也一样。你做新闻 App手机端是列表页跳详情页两个 Activity平板端呢同样的列表和详情如果也用两个 Activity平板的屏幕利用率就非常难看——列表拉到全宽行间距被撑得巨大详情页在列表跳转后才出现用户根本没法边看列表边预览内容。那时候的常规做法是用 layout 文件夹做资源限定比如layout和layout-sw600dp里面各放一套 XML。但逻辑怎么办列表的点击跳转、数据加载、状态保存这些代码没法通过换 XML 来复用。你只能在 Activity 里写一堆if (isTablet)的分支判断判断这个、判断那个代码越来越臭最后连自己都懒得看。我见过一个项目主 Activity 里 800 多行全是适配逻辑每次需求变更都要小心翼翼地改那个 if-else 金字塔。这个阶段最难受的是逻辑复用和布局复用是割裂的。布局能通过资源目录切换逻辑只能靠复制粘贴或者继承抽象类硬凑。继承确实能解决一部分问题——抽一个 BaseListActivity 出来手机和平板都继承它——但页面之间的组合关系处理不了。手机是 A 跳 B平板是 A 和 B 同屏显示这已经不是继承能解决的粒度问题了。1.2 Fragment 的核心价值把页面拆成可以拼装的模块Fragment 引入后情况变了。你可以把列表和详情分别封装成两个 Fragment它们都是独立的模块有自己的布局、逻辑、生命周期。然后问题就变成了组合题手机端用两个独立的页面承载这两个 Fragment列表点一下跳详情。平板端同一个 Activity 里左边放列表 Fragment右边放详情 Fragment点击列表时只替换右侧的内容。同一个模块两种拼法代码不用复制。这才是 Fragment 最核心的价值——它不是简单的“子页面”而是一个可以自由组合的界面单元。后来越来越多人说“单 Activity 多 Fragment”架构本质就是把这个组合能力用到极致整个 App 一个 Activity所有页面都是 Fragment由 FragmentManager 统一调度。理解这一层你就明白为什么标题说的是“手机平板要兼顾”。Fragment 不是为了造一个新概念而存在的它就是解决“同一套代码在不同屏幕尺寸下呈现不同组合方式”这个问题的。后面讲的所有生命周期、回退栈、ViewPager 切换都是在为这个组合能力服务的。2. Fragment 的生命周期与回退栈想清楚这两件事适配才不翻车2.1 生命周期比 Activity 复杂在“视图”和“实例”是两条线Fragment 的生命周期是绕不开的第一个坎。很多新手看 Fragment 生命周期图第一反应是“这什么鬼怎么比 Activity 多了这么多回调”。确实多但多出来的回调都是有原因的。直接对比最直观Activity 回调Fragment 回调说明onCreateonAttach / onCreate实例创建onAttach 绑定了宿主 Activity(无)onCreateView / onViewCreated创建视图这是 Fragment 独有的onStartonStart界面可见onResumeonResume可交互onPauseonPause不可交互但可见onStoponStop完全不可见(无)onDestroyView视图销毁但实例还活着onDestroyonDestroy / onDetach实例销毁关键区别在于onCreateView和onDestroyView这一对。Fragment 的实例和它的视图是可以不同步的。你切换 Fragment 时比如 replace 或者 ViewPager 滑走系统可能只销毁了它的 View但 Fragment 实例还活在 FragmentManager 里。到了onDestroyView之后View 上的所有引用都不能再用了否则轻则空指针、重则内存泄漏。我见过最典型的问题有人在 Fragment 里写了一个成员变量保存 View 引用比如private View rootView在onCreateView里赋值之后到处用它。平时没毛病但一旦 Fragment 的 View 被销毁重建比如屏幕旋转、切后台被系统回收再回来这个引用就指向一个已经 detached 的旧 View操作它直接崩。正确做法是在onViewCreated里初始化所有 View 引用在onDestroyView里置空或者干脆不要缓存 View每次都通过getView()获取。生命周期这条线想清楚了你才敢放心地把 Fragment 放进 ViewPager 里让它随意切换。否则你会遇到那种“滑了几下之后突然闪退”的诡异问题。2.2 回退栈FragmentManager 是怎么管理页面历史的Fragment 的第二个核心机制是回退栈BackStack。默认情况下你用FragmentTransaction.add()把一个 Fragment 放上来用户按返回键Activity 直接 finish——这个 Fragment 压根没有参与返回逻辑。要让 Fragment 遵循类似 Activity 的返回栈行为你需要调用supportFragmentManager.beginTransaction() .replace(R.id.container, DetailFragment()) .addToBackStack(null) .commit()加了addToBackStack(null)之后这次事务被压入回退栈。用户按返回键时事务被逆序回滚——replace 的旧 Fragment 被恢复新 Fragment 被销毁。这套机制实现了一种直觉上的返回逻辑列表进详情详情进编辑按返回是逐级回退而不是一下跳出整个页面。实际项目里回退栈的管理需要你想清楚一件事什么时候该入栈什么时候不该入栈。底部 Tab 的页面切换就不该入栈——用户在 Tab1 滑到 Tab2再按返回键正确行为是退出 App而不是跳回 Tab1。而“列表进详情”这种层级关系就该入栈。判断标准只有一个这个返回行为符不符合用户的心智模型。用replace还是add也在这里出现分支。replace会把当前容器里的旧 Fragment 移除再添加新的适合全屏跳转add是把新 Fragment 叠加在旧 Fragment 上面适合弹层、半屏浮层这类场景。很多人只记住了“跳转用 replace”遇到浮层需求就硬用 replace结果背景 Fragment 被销毁了关闭弹层后一片空白这就是没理解 add 和 replace 的语义差异。2.3 一个典型误用把 Fragment 当 Thread 用社区里还有一种常见误解就是有人觉得“Fragment 可以作为后台任务的载体”。曾有一个项目开发者把网络请求放到 Fragment 里发Fragment 不显示任何界面纯粹为了“在 Fragment 生命周期里自动管理请求”。且不说这种设计把生命周期和网络任务强行耦合单说回退栈一个无界面的 Fragment 进入回退栈会带来一堆状态恢复问题页面转了转屏幕请求状态全乱了。Fragment 的正确定位是界面模块不是后台任务载体。凡是跟界面无关的职责都应该放到 ViewModel、Repository 或者其他纯逻辑层。如果你有“想在页面销毁时自动取消网络请求”的需求onDestroyView里做取消操作可以接受但不要因此把 Fragment 本身当作一个“有生命周期的 Task”。这个思路理顺了你的架构才算真正用对了 Fragment。3. 三种组合方式拆解静态嵌套、动态切换、ViewPager2 滑动3.1 静态嵌套简单但别滥用最基础的用法是在 XML 里直接声明 Fragment 标签LinearLayout xmlns:androidhttp://schemas.android.com/apk/res/android android:layout_widthmatch_parent android:layout_heightmatch_parent android:orientationhorizontal fragment android:idid/list_fragment android:namecom.example.NewsListFragment android:layout_width0dp android:layout_heightmatch_parent android:layout_weight1 / fragment android:idid/detail_fragment android:namecom.example.NewsDetailFragment android:layout_width0dp android:layout_heightmatch_parent android:layout_weight1 / /LinearLayout这种写法的坑在于name属性写死了类名如果想在代码里根据条件动态替换成不同的 Fragment 子类静态嵌套是做不到的。而且静态 Fragment 的生命周期和宿主 Activity 绑定remove 也 remove 不掉——你只能移除动态添加的 Fragment。所以我的建议是除非你的布局结构完全固定比如平板 master-detail 双栏且两栏内容确定不变否则别用静态嵌套。一旦后续要在这个位置切换不同的 Fragment你还得把 XML 改成 FrameLayout 动态 add反而多折腾一遍。3.2 动态切换加一个容器全用代码说了算动态切换是开发中最常用的方式。核心思路是XML 里放一个FrameLayout当容器代码里用 FragmentTransaction 往容器里放 Fragment。用 Kotlin 写大致是这样class MainActivity : AppCompatActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContentView(R.layout.activity_main) if (isTablet()) { // 平板双栏左右各放一个 Fragment supportFragmentManager.beginTransaction() .replace(R.id.left_container, NewsListFragment()) .replace(R.id.right_container, NewsDetailFragment()) .commit() } else { // 手机单栏只放列表 supportFragmentManager.beginTransaction() .replace(R.id.fragment_container, NewsListFragment()) .commit() } } private fun isTablet(): Boolean { val metrics resources.configuration return metrics.smallestScreenWidthDp 600 } }这段代码的核心在于isTablet()的判断。这里强烈建议用smallestScreenWidthDp 600来判断而不是用屏幕物理尺寸。因为screenWidthDp会随着横竖屏变化改变而smallestScreenWidthDp是设备独立的最小宽度维度横竖屏切换时数值稳定。我之前在横竖屏判断上吃过亏——平板竖屏时screenWidthDp才 500 多被误判成手机列表 Fragment 全屏显示用户一旋转就变样。换用smallestScreenWidthDp后问题消失。动态切换看起来简单但其实有一个隐藏问题每次 replace 都会销毁旧 Fragment 的 View如果切换频繁会有性能损耗。而且旧 Fragment 的滚动位置、表单输入内容等状态如果不在onSaveInstanceState里保存replace 之后再回来就全丢了。这个坑在后面的 ViewPager 部分还会详细说。3.3 ViewPager2 Fragment滑动切换的最佳搭档现在 Android 里做左右滑动的多页面基本都用 ViewPager2。相比旧的 ViewPagerViewPager2 用 RecyclerView 做底层实现支持 RTL 布局、竖直滑动也修掉了很多旧版动效问题。ViewPager2 搭配 Fragment 的正确姿势是实现FragmentStateAdapterclass NewsPagerAdapter(activity: FragmentActivity) : FragmentStateAdapter(activity) { private val pages listOf( HomeFragment::class.java, CategoryFragment::class.java, ProfileFragment::class.java ) override fun getItemCount(): Int pages.size override fun createFragment(position: Int): Fragment { return when (position) { 0 - HomeFragment() 1 - CategoryFragment() else - ProfileFragment() } } }用的时候viewPager2.adapter NewsPagerAdapter(this)注意FragmentStateAdapter可以被子类化关键在于要传一个FragmentActivity参数给父类构造函数这样 Adapter 内部才能拿到正确的 FragmentManager 和 Lifecycle。ViewPager2 和 Fragment 的组合之所以强是因为它天然解决了滑动切换时 Fragment 生命周期管理的负担。你不需要自己控制 Fragment 的 add/replaceViewPager2 内部通过 FragmentStateAdapter 来创建、缓存、销毁 Fragment配合setOffscreenPageLimit控制保留数量。很多人会把 ViewPager2 和 TabLayout 搭配来做顶部导航。这里有个好习惯ViewPager2 只用registerOnPageChangeCallback监听页面切换事件TabLayout 用addOnTabSelectedListener监听 Tab 点击再用TabLayoutMediator把两者关联。别手动在两边互调容易出现“点 Tab 后 pager 没动、滑动后 Tab 没变”的死锁。4. ViewPager 与 Fragment 切换的经典翻车现场四段真实排查记录4.1 FragmentStateAdapter 和 FragmentPagerAdapter 到底选哪个很多人项目里还留着旧版 ViewPager 的代码所以这个问题到现在还在问FragmentPagerAdapter 和 FragmentStatePagerAdapter 选谁对比项FragmentPagerAdapterFragmentStatePagerAdapter页面保存方式持有 Fragment 实例引用只保存状态销毁不可见 Fragment内存占用高页面多时明显低状态恢复View 可能被销毁但实例存活实例和 View 都可能被销毁适用场景2-3 个固定 Tab大量页面、无限滑动ViewPager2 对应不存在FragmentStateAdapter旧版 ViewPager 里如果你只有两个 Tab用哪个都行但页面超过 5 个我会无脑选 FragmentStatePagerAdapter——它会在 Fragment 滑远后销毁实例只保留状态内存占用明显更小。ViewPager2 出来以后官方只提供了一个FragmentStateAdapter相当于把选择封装掉了反而简单了。但有个真实存在的坑如果项目里同时用了新旧版本你可能会把 FragmentPagerAdapter 的代码照搬到 ViewPager2 里然后发现getItem()方法不存在了。ViewPager2 的FragmentStateAdapter用的是createFragment(position)而不是旧版的getItem(position)。如果你把旧代码硬拷过来编译器大概率会直接报错但如果你用了 Java 反射或某些兼容库可能出现“运行时才崩”的尴尬。所以迁移时的第一件事就是把这个方法名改掉别在复制粘贴上偷懒。4.2 切换时状态丢失的完整排查链路这是我实际踩过的一个坑过程很典型。当时做一个阅读类 App 的首页顶部三个 Tab推荐、关注、视频用 ViewPager2 FragmentStateAdapter。现象是用户在推荐 Tab 往下划了几屏切到关注再切回来推荐 Tab 的滚动位置丢了回到顶部有时更严重数据直接被清空重新加载。我先怀疑是 Fragment 被销毁了——毕竟 FragmentStateAdapter 会把不可见的 Fragment 实例销毁。但我只设置了 3 个页面setOffscreenPageLimit也设成了 2理论上不会销毁。那就继续排查。后来发现问题不在 Fragment 销毁而在 View 重建。ViewPager2 在页面离屏时即使 Fragment 实例还活着它的 View 也可能被销毁重建。如果数据、滚动位置存在 View 持有的变量里比如 RecyclerView 的 LayoutManagerView 一重建就全没了。确认这个原因之后我做了三件事第一数据层和界面层解耦。数据通过网络加载存进 ViewModel不让 Fragment 重新创建时重新发请求。第二滚动位置在onSaveInstanceState里保存在onViewCreated里恢复。第三检查了onViewCreated与onCreateView的区别所有 View 的初始化都放到onViewCreated里完成避免出现“View 还没准备好就开始操作”的问题。排查链路复盘一下出现状态丢失不要第一反应就是“Fragment 被销毁了”优先检查 View 是否重建、数据是否被重新加载、状态是否走了onSaveInstanceState这三个点。80% 的状态丢失问题都出在这三处。4.3 setOffscreenPageLimit调大还是调小这是个问题setOffscreenPageLimit(n)的意思是当前页面左右两侧各预加载 n 页。默认值是 1也就是说在屏幕中央有第 2 页的时候第 1 页和第 3 页都已经加载好了滑过去不用等。调大这个值能提升滑动流畅度因为页面提前加载好了但代价是内存占用上升——每个预加载的 Fragment 都要创建 View页面里如果有列表还有图片内存压力会很明显。调小到 0 也不推荐因为这样快速滑动时会出现动画过程中页面没准备好的白屏体验很糟糕。我自己的经验是普通 Tab 场景保持默认的 1 就够了如果想做“无限滑动动态加载列表”的那种场景可以把 offscreenPageLimit 设成 1 到 2千万不要为了流畅把所有页面都提前加载——一旦数据量大OOM 不是吓你的。这里有一个容易踩的小坑ViewPager2 的setOffscreenPageLimit最低接收的值是 1传 0 会被忽略并保持默认值 1。所以网上那种“setOffscreenPageLimit(0) 来完全关闭预加载”的说法在 ViewPager2 里实际上不生效。如果你真的想控制加载策略正确做法是控制 Fragment 内部的数据加载时机而不是去调这个参数。4.4 快速滑动导致的 Fragment 白屏问题这个是 ViewPager Fragment 的高频事故用户快速左右滑滑到某个页面时整个区域一片空白只有 Fragment 的根布局背景色在那。这个问题的根因通常在于 Fragment 的onViewCreated中做了耗时操作比如准备 RecyclerView 的 LayoutManager而 ViewPager2 在快速滑动时可能在新的 Fragment 的 View 还没调用onViewCreated之前就要求它显示出来。表面上看是“页面还没加载完就显示”实际上是对 Fragment 生命周期时序的误解。排查思路是这样的我在白屏位置打了日志发现onViewCreated是在白屏出现之后才执行的。这就说明 Fragment 的 View 虽然在但里面的内容没初始化完就显示了。解决办法是在 Fragment 的根布局上用 ViewStub 加一个简单的 LoadingFrameLayout数据加载完成后再替换成真实内容。这样即使 Fragment 的 View 被提前要求显示用户看到的是一个友好的 loading 样式而不是一个看起来像 bug 的空白块。这个方案比“调大 offscreenPageLimit 让它提前加载”更可靠因为它是从 UI 状态管理层面兜底而不是依赖预加载时机。5. 从 Fragment 走向单 Activity 架构我的取舍与迁移经验5.1 为什么单 Activity 多 Fragment 是当前最稳定的架构形态聊到这里你已经看到了 Fragment 在手机/平板适配中的核心地位。但 Fragment 不是孤立的它的价值在单 Activity 架构里会被放大到极致。单 Activity 架构简单说就是一个 App 只有一个 Activity页面全部由 Fragment 承载。优点是状态保存统一。Activity 的onSaveInstanceState在系统回收、屏幕旋转时会替你处理 Fragment 的状态不需要每个页面单独写状态恢复逻辑。动效统一。Fragment 之间的切换动画在 FragmentTransaction 里统一设置不像 Activity 那样需要在 startActivity 和 overridePendingTransition 之间来回折腾。数据传递变简单。多个 Fragment 共享同一个 Activity 的 ViewModel天然解决页面间的数据通信问题。但代价也有单 Activity 意味着 Activity 的职责全部集中到一个地方FragmentManager 的管理复杂度全部摊到你面前。如果你用了add()而不是replace()又没管理好回退栈内存里会无意义堆积一堆 Fragment 实例。对于大多数非巨型 App单 Activity 多 Fragment 是目前最稳的架构形态。Google 后来推出的 Navigation 组件就是在 FragmentManager 之上再包一层提供了可视化的导航图、类型安全的参数传递把单 Activity 架构的体验进一步拉平。如果你还在犹豫是否采用单 Activity 架构我的建议是新项目直接上老项目先抽一个模块试点运行一个月没问题再全面铺。5.2 从 Fragment 到 Compose换的是 UI 写法不变的是模块化思想这两年 Compose 热得不行很多人问我Fragment 是不是要被淘汰了我目前在整个项目里迁了差不多一半页面到 Compose我可以告诉你我的真实感受。Compose 确实把很多人从生命周期泥潭里解放出来了——界面和状态分离、代码更简洁。但“手机/平板适配”这个命题在 Compose 里依然要你做决策你应该用WindowSizeClass来判断当前设备类型然后决定是显示单栏列表还是双栏主从界面。这个思路和 Fragment 时代用smallestScreenWidthDp判断是完全一致的。区别只是形式Fragment 时代你在 XML 和 Fragment 里拼装界面模块Compose 时代你在 Composable 函数里根据条件分支调出不同的 UI 结构。思想是一脉相承的——依然是“同一套业务逻辑不同屏幕尺寸下呈现不同的界面组合方式”。所以如果你现在熟练掌握了 Fragment 的适配方案迁移到 Compose 并不是推倒重来而是把“Fragment 容器”换成了“Composable 容器”。如果你正在维护一个老项目新页面用 Compose、老页面用 Fragment 共存是完全可行的Google 官方也提供了 Compose 嵌 Fragment、Fragment 嵌 Compose 的双向兼容方案。我目前就是这种共存状态跑得很稳。最后分享一个我在项目里反复验证过的体会无论你用 Fragment 还是 Compose手机平板适配的难点从来不在某个组件本身而在于你是否养成了“屏幕无关”的设计习惯——把数据和状态保存从 UI 层剥离把页面拆成可复用的模块然后在布局组合层面根据屏幕尺寸做分支。做到了这一点换 UI 框架只是换汤不换药做不到换什么框架你都会遇到同样的痛点。这篇是关于 Fragment 的实战复盘希望能帮你在适配这条路上少踩几个坑。如果还有 ViewPager 切换或 Fragment 状态恢复方面的具体问题欢迎在评论区把你的排查过程说出来我们一起捋一捋。