获课：xingkeit.top/14888/

在 Android 开发的历史长河中，2019 年 Jetpack Compose 的横空出世，不亚于一场地震。它彻底抛弃了沿袭多年的 XML 布局和命令式 UI 更新，用声明式的 Kotlin 代码重构了界面的构建方式。然而，对于绝大多数已存续数年、拥有庞大代码库的大厂应用来说，全盘推翻重来是不现实的。现实中的场景往往是：老旧的核心业务逻辑和成熟的第三方 SDK 深埋在 View 体系中，而团队又极度渴望 Compose 带来的开发效率和 Material Design 3 的现代美学。于是，Compose 与 View 的互操作（Interoperability） 成为了横亘在所有 Android 开发者面前的一道必答题。如何让新旧代码在同一个 APK 中和睦共处，平滑过渡，是混合迁移方案落地的核心。

理解互操作的起点，在于认清一个事实：Compose 本质上并没有脱离 Android 的 View 系统，它只是运行在 View 之上的一个独立渲染层。无论是 ComposeView 还是 AndroidView，它们都是 ViewGroup 的子类。这意味着，将 Compose 植入 View 的世界，或把 View 嵌入 Compose 的海洋，在技术层面是完全可行的，关键在于设计一套符合业务节奏的迁移策略。

最常见的场景是 “View 中嵌入 Compose”，这适用于在旧页面中局部引入新功能。比如，在一个用 XML 写的详情页底部，增加一个高度交互的“猜你喜欢”卡片，用 Compose 来编写这个卡片会非常高效。实现方式极其简单：在 XML 布局文件中放置一个 androidx.compose.ui.platform.ComposeView，然后在 Activity 或 Fragment 中通过 findViewById 拿到它的引用，调用 setContent 即可填充 Compose 的 @Composable 函数。这一过程无需改动原有页面的其他逻辑。这种方案的引入成本极低，适合试水阶段，让团队先在一个小模块上感受 Compose 的开发节奏。但需要注意，ComposeView 的创建和重组会消耗资源，如果在一个 RecyclerView 的每个 Item 中都使用独立的 ComposeView，可能会因为频繁的重绘和测量导致滑动卡顿。

反过来，在 Compose 中嵌入 View，则是混合迁移中更具挑战性的方向，通常用于复用存量代码中那些难以被 Compose 替代的组件。比如，你有一个封装了复杂音视频播放器的自定义 SurfaceView，或者一个基于 OpenGL 渲染的图表库，要用 Compose 重写这些逻辑成本极高。这时，AndroidView 这个 Composable 函数就派上了用场。在 @Composable 中调用 AndroidView(factory = { context -> MyCustomView(context) })，你就可以把老旧的 View 当作一个普通组件塞进 Compose 的布局树中。更强大的是，update 回调参数允许你在 Compose 重组时精确控制 View 的属性更新，实现数据绑定。但这里有一个深坑：由于 Compose 的渲染频率远高于传统 View，如果 update 中频繁触发 View 的 invalidate 或布局请求，会造成巨大的性能开销。最佳实践是只在数据变化时才通过 State 触发更新，避免无关重组波及到内部的 View。

解决了组件嵌套的问题，导航与路由的融合是决定迁移成败的关键。在纯 View 体系中，我们使用 Fragment 和 NavController；在纯 Compose 中，我们使用 NavHost 和 composable 路由。混合项目中，必须统一路由栈。官方推荐的方案是依赖 Navigation Compose 库，它允许你在 Compose 的 NavHost 中混合声明 composable 目标（跳转到 Compose 页面）和 dialog 或 fragment 目标（跳转到旧 View 页面）。通过 Navigator 的扩展，我们可以让 Compose 页面无缝启动一个旧的 Activity 或 Fragment，且返回时能正确处理 onActivityResult 或 SharedElement 转场动画。保持导航栈的单一是为了避免用户点击返回键时，在 Compose 和 View 的 FragmentManager 之间出现混乱的“双重栈”体验。

状态管理（State Management） 是另一个需要特别关注的断层。传统 View 体系依赖 LiveData 或 RxJava 驱动 UI 更新，而 Compose 依赖 State 和 MutableState。在互操作中，我们强烈建议将 ViewModel 作为唯一的可信数据源。无论是 Compose 还是 View，都从同一个 ViewModel 中获取数据流。Compose 可以通过 observeAsState() 将 LiveData 或 Flow 转化为 Compose 的 State，从而实现自动重组。View 则保持原有的 Observer 订阅。这种设计确保了无论屏幕上的内容是 Compose 还是 View 渲染的，它们看到的数据永远是同步的。

在这套混合体系中，主题与样式的统一往往是最容易被忽视但用户感知最强的细节。一个应用里不能出现一半页面是深色 Material 3，另一半却是旧版的 Holo 或 AppCompat 风格。解决方案是在根布局（通常是 ComposeView 所在的 Activity）包裹 MaterialTheme，并为旧的 View 体系设置继承自该主题的 ContextThemeWrapper。你需要手动在 attrs.xml 中定义颜色引用，让 XML 布局也能引用到 Compose Theme 中定义的 colorPrimary 和 typography。这一步虽然繁琐，却是保证应用视觉一致性的底线。

渐进式迁移的终极形态，并不是将所有 XML 都改写为 @Composable，而是实现 “新写用 Compose，维护用 View” 的共存状态。在团队实践中，最稳妥的路线是：从下到上，由内而外。先在新开发的独立功能模块（如设置页、个人中心）中使用纯 Compose；然后将这些模块通过 ComposeView 挂载到旧版的主页容器中；最后，当 Compose 页面达到一定比例后，再将宿主 Activity 迁移为纯 Compose 结构，并把剩余的旧页面通过 AndroidView 包裹起来作为遗留资产保留。整个过程可以持续一年甚至更长，期间每次发版都只迁移一小部分，将风险降到最低。

最后，必须提及性能监控与排查。混合布局容易引发过度重绘问题，因为 Compose 的测量逻辑与 View 的 measure/layout/draw 流水线存在差异。务必在开发阶段开启开发者选项中的“显示布局边界”和“GPU 过度绘制”调试工具。如果发现 ComposeView 频繁导致整个父布局重绘，可以尝试为其设置 setZOrderOnTop(true) 或使用 AndroidView 中的 view.shouldDelayChildPressedState() 来优化触摸事件冲突。

总而言之，Compose 与 View 的互操作并非一门“零和游戏”，而是一场“灰度革命”。它考验的不是开发者对某个 API 的记忆，而是对业务模块划分的洞察力以及对架构解耦的掌控力。在未来的两三年里，绝大多数成熟的 Android 应用都将处于这种“新老交替”的混沌状态。拥抱这套混合迁移方案，意味着你可以既享受 Compose 带来的生产力飞跃，又不辜负过往积累的海量代码资产。当你的项目顺利完成 50% 的页面迁移时，你将发现团队士气显著提升，开发新需求的周期大幅缩短——这才是混合迁移战役的真正胜利。