007 与 XML 混合与渐进迁移：我的平稳过渡实践

今天我想和你聊聊在现有项目中引入 Compose 的实战经验。我们很少有机会从零开始一个全新项目，更多时候是在成熟的代码库上工作。一次性重写所有界面既不现实，风险也高。好在 Jetpack Compose 提供了优秀的互操作性，让我们可以“新旧混搭”，平稳过渡。

1. 为什么需要混合开发？

在我的项目迁移过程中，Compose 与 View 的互操作成了我的救命稻草。它主要支持两种场景：
- 在传统的 XML 布局里嵌入 Compose 界面：通过 ComposeView 这个“桥梁”。
- 在 Composable 函数里使用传统的 View：比如那些暂时还无法替换的地图控件或播放器。

这种混合模式给了我极大的灵活性，让我可以按照自己的节奏，一块一块地啃下迁移这块硬骨头。

2. 在 XML 布局中嵌入 Compose

这是我最开始尝试，也是觉得最顺手的方式。假设我们有一个老旧的 fragment_legacy.xml 文件，我想把其中一部分替换成 Compose。

首先，在 XML 里加入一个 ComposeView 容器：

<androidx.compose.ui.platform.ComposeView
    android:id="@+id/compose_root"
    android:layout_width="match_parent"
    android:layout_height="match_parent" />

然后，在对应的 Fragment 中，找到这个 View 并设置 Compose 内容：

override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
    val composeView = view.findViewById<ComposeView>(R.id.compose_root)
    composeView.setViewCompositionStrategy(
        ViewCompositionStrategy.DisposeOnViewTreeLifecycleDestroyed
    )
    composeView.setContent {
        MyAppTheme {
            LegacyFeatureScreen()
        }
    }
}

这里有个关键点：一定要设置 ViewCompositionStrategy。我一开始就忘了，结果遇到了生命周期不同步导致的内存泄漏。DisposeOnViewTreeLifecycleDestroyed 这个策略能确保 Compose 的 Composition 在 Fragment 或 View 被销毁时也一并清理，让它们俩的生命周期保持同步。

3. 在 Compose 中使用旧的 View

有些组件，比如第三方地图 SDK 的 MapView 或者复杂的自定义 View，短期内重写成本太高。这时候，AndroidView 这个 Composable 就派上用场了。

下面是我封装一个老地图控件的例子：

import androidx.compose.ui.viewinterop.AndroidView

@Composable
fun LegacyMapView(modifier: Modifier = Modifier) {
    AndroidView(
        modifier = modifier.fillMaxSize(),
        factory = { context ->
            MapView(context).apply { onCreate(null) }
        },
        update = { mapView ->
            // 当外部状态变化时，可以在这里更新 View
        }
    )
}

它的工作原理很直观：factory 回调负责创建 View 实例，而 update 块则在重组时被调用，用于根据新的状态更新这个 View。

如果你的老界面使用了 ViewBinding，还有一个更便捷的 AndroidViewBinding 可以用，它能帮你自动处理绑定和清理。

4. 我的渐进迁移策略

经过几个项目的摸索，我总结出了一个比较稳妥的迁移顺序，分享给你：

1. 从新功能开始：所有新开发的页面或功能，毫不犹豫地使用 Compose。这是最没有历史包袱的方式。
2. 攻克独立模块：先找那些功能相对独立、边界清晰的模块下手，比如一个工具类页面或者一个列表项组件。成功迁移这些小模块能快速建立信心。
3. 处理高价值界面：接着瞄准那些用户频繁使用、但维护成本高的核心界面，比如登录页、设置页或者复杂的列表页。用 Compose 重构它们，长期收益最大。
4. 包围复杂自定义 View：对于和业务逻辑深度耦合、难以替换的自定义 View，我的策略是“先包围，再替换”。先用 AndroidView 把它包裹起来，融入 Compose 的架构中，然后再找机会逐步重构其内部实现。

5. 主题与系统 UI 的衔接

这一点我踩过坑。Compose 的 MaterialTheme 和系统的状态栏、导航栏颜色需要手动同步，否则会出现“上下颜色割裂”的尴尬情况。

我的做法是在 Activity 的 onCreate 中，使用 WindowCompat.setDecorFitsSystemWindows 和 enableEdgeToEdge() 等 API（需要 AndroidX Activity 1.8+），来确保 Compose 的沉浸式体验和 XML 主题中 windowLightStatusBar 等属性的行为保持一致。这步操作虽然有点繁琐，但对于整体视觉的统一至关重要。

6. 我遇到的那些“坑”

• Context 陷阱：在 Compose 中通过 LocalContext.current 获取的 Context，在需要 Activity 上下文时（比如启动另一个 Activity），可能并不是你想要的。要特别注意这一点。
• 多个 ComposeView 的性能：一个屏幕里可以放多个独立的 ComposeView，它们互不影响。但如果不是必须，尽量将多个小块合并到一个 ComposeView 中，以减少多个 Composition 带来的开销。
• 在 RecyclerView 中使用：当把 ComposeView 作为 RecyclerView 的 item 时，要特别注意其创建和回收。务必设置正确的 dispose 策略，否则滑动列表时可能会内存泄漏或出现诡异的表现。

7. 官方指南，我的迁移路线图

在动手之前和遇到困惑时，我反复阅读了官方文档，建议你也按这个顺序看：
- 迁移策略总览：先建立宏观认知。
- 互操作 API 详解：解决具体技术问题。

8. 动手练习：你的第一个混合界面

我建议你找一个结构简单的旧 Fragment 练手，比如一个 只有顶部栏和列表 的页面。
尝试把它改造成：布局文件里放一个 ComposeView，然后在其中用 LazyColumn 实现列表。关键点是保留原有的 ViewModel 和数据接口层，只替换 UI 部分。这个练习能让你完整体验一次“嵌入”流程。

好了，混合开发的实战经验就分享到这里。当我们开始大规模使用 Compose 后，如何优化性能和调试就成了新课题，我们下一篇接着聊：008-副作用重组优化与调试.md