随着 Android 开发进入 Compose 时代,许多开发者选择在现有的 ViewPager2 架构中引入 Compose,通过这种"混合模式"平滑过渡。虽然两者可以共存,但由于 View 系统与 Compose 的底层渲染机制存在差异,实际落地时有几个**"深坑"**必须避开。
本文总结了在 ViewPager2 + Fragment 中使用 Compose 的四大核心要点。
1. 内存泄漏的"隐形杀手":ViewCompositionStrategy
在 Fragment 中使用 ComposeView 时,最常见的问题是 Composition(组合)的销毁时机。
- 痛点:Fragment 的 View 生命周期与 Fragment 对象本身的生命周期是不一致的。如果 Compose 不知道 View 已经销毁,它可能会继续持有引用,导致内存泄漏或崩溃。
- 对策 :必须在
onCreateView中明确指定销毁策略。
Kotlin
kotlin
override fun onCreateView(
inflater: LayoutInflater, container: ViewGroup?, savedInstanceState: Bundle?
): View {
return ComposeView(requireContext()).apply {
// 关键代码:确保 View 被销毁时,Composition 也能正确清理
setViewCompositionStrategy(
ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed
)
setContent {
MaterialTheme {
MyPagerScreen()
}
}
}
}
2. 状态丢失:记住 rememberSaveable
ViewPager2 默认会销毁超出缓存范围(offscreenPageLimit)的 Fragment 视图。
-
痛点:当我们从第 1 页滑动到第 10 页,再滑回第 1 页时,原本输入的文字或滑动的位置可能消失了。
-
对策:
- Compose 内部状态 :使用
rememberSaveable代替remember。 - 业务逻辑状态 :将状态托管在
ViewModel中,并利用collectAsStateWithLifecycle()进行观察。
- Compose 内部状态 :使用
3. 滑动冲突:横向滚动的博弈
ViewPager2 本质上是一个横向滑动的 RecyclerView,而 Compose 里的 LazyRow 也是横滑。
- 痛点:当我们在 Compose 内部滑动列表时,可能会意外触发 ViewPager 的翻页。
- 现状:Compose 1.2+ 已经支持了嵌套滚动(Nested Scrolling)。但在某些复杂交互(如内嵌地图或自定义绘图)中,我们仍需手动干预。
- Tips :如果遇到极端的滑动冲突,可以通过
Modifier.pointerInput结合requestDisallowInterceptTouchEvent(true)来强制让 Compose 优先获得控制权。
4. 预加载与性能调优:OffscreenPageLimit
Compose 的首次渲染(Initial Composition)相对 View 来说更消耗 CPU 资源。
-
问题:快速滑动 ViewPager2 时,Compose 界面可能会出现短暂的白屏或掉帧。
-
优化方案:
- 设置预加载 :
viewPager2.offscreenPageLimit = 1。这会提前初始化相邻页面的 Compose 内容,牺牲少量内存换取丝滑的滑动体验。 - 基线配置文件 (Baseline Profiles) :在生产环境下使用 Baseline Profiles,可以显著提升 Compose 组件的冷启动性能,减少滑动卡顿。
- 设置预加载 :
总结
在 ViewPager2 中嵌套 Fragment + Compose 是目前的黄金过渡方案。只要记住**"策略销毁、状态持久、预加载优化"**这三板斧,就能在享受 Compose 开发效率的同时,保证应用的稳定性。
💡 避坑 checklist:
- 是否设置了
DisposeOnViewTreeLifecycleDestroyed? - 关键 UI 状态是否使用了
rememberSaveable? - 是否针对
ViewPager2开启了合理的offscreenPageLimit?