重磅官宣：Android UI 开发正式进入 Compose-first 时代

2026 年 5 月 19 日，Android 团队宣布 Android UI 开发进入 Compose-first。

这不是把 View 系统删掉，也不是让老项目马上重写。变化在于默认路线已经切到 Jetpack Compose：新 UI API、新工具能力、新设计适配、新文档和示例，后续都会优先围绕 Compose 展开。

维护模式

Android View 体系会继续存在。android.view 和 android.widget 不会消失，已有 App 也不会因为这条公告突然不能运行。

官方提到，View-based UI toolkit 进入维护模式。android.widget、Fragment、RecyclerView、ViewPager、Layout Editor、Navigation Editor、AppCompat、Material XML View 等能力会继续收到兼容性和关键修复，但后续不会再承接新的 UI 开发重点。

这个信号对团队决策很直接。新页面、新组件、新交互、新形态适配，不应该再默认用 XML 和 View 起项目。继续用 View 能跑，但会越来越像"维护旧系统"，不是 Android UI 的主路线。

新项目

新项目直接用 Compose。原因不是"新技术更现代"这种空话，而是 Android 后续能力会优先给 Compose：自适应布局、动画、Material 3 Expressive、文本、触控、可访问性、预览、测试和 AI 生成 UI 的链路都会围绕 Compose 设计。

一个新的 Activity 通常不需要 XML 布局入口，直接把 UI 放进 setContent：

bash 复制代码

class MainActivity : ComponentActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)

        setContent {
            AppTheme {
                HomeScreen()
            }
        }
    }
}

项目模板也应该跟着改。以前很多团队模板会内置 BaseActivity、BaseFragment、RecyclerView.Adapter、XML toolbar、DataBinding 或 ViewBinding。新模板更应该内置主题、导航、状态管理、Preview、测试入口和设计 token。

老项目

老项目不用一刀切重写。Compose 和 View 的互操作已经足够成熟，适合按页面、模块、组件逐步替换。

最常见的落点是新页面先用 Compose。原来的 Activity 或 Fragment 不动，只在局部挂一个 ComposeView：

bash 复制代码

class ProfileFragment : Fragment(R.layout.profile_fragment) {
    override fun onViewCreated(view: View, savedInstanceState: Bundle?) {
        view.findViewById<ComposeView>(R.id.compose_container)
            .setContent {
                AppTheme {
                    ProfileScreen()
                }
            }
    }
}

另一种情况是 Compose 页面里还要复用旧 View，比如地图、播放器、广告、复杂输入控件或还没迁移的内部组件。这时用 AndroidView 包一层：

bash 复制代码

@Composable
fun LegacyMapPanel() {
    AndroidView(
        factory = { context -> LegacyMapView(context) },
        update = { mapView ->
            mapView.setUserTrackingEnabled(true)
        }
    )
}

这两种互操作能把迁移压力拆开。UI 层开始切 Compose，不代表所有基础组件、业务流程、埋点、权限和三方 SDK 都要同一天迁。

RecyclerView

RecyclerView 仍然能用，但新列表优先用 LazyColumn、LazyRow、LazyVerticalGrid。这能减少 Adapter、ViewHolder、DiffUtil、XML item 布局之间的样板代码。

一个基础列表可以写得很短：

bash 复制代码

@Composable
fun MessageList(messages: List<Message>) {
    LazyColumn {
        items(
            items = messages,
            key = { it.id }
        ) { message ->
            MessageRow(message)
        }
    }
}

这里的 key 不要省。列表数据会插入、删除、重排时，稳定 key 能帮助 Compose 保持 item 状态，减少不必要的重组和滚动位置问题。

复杂列表迁移要更谨慎。分页、曝光埋点、视频自动播放、吸顶、嵌套滚动、局部刷新、可访问性焦点和性能采样都要补齐。不要只看代码行数变少，老 RecyclerView 里沉淀的业务细节也要跟着搬。

Fragment

Fragment 的位置也会变化。它不会消失，但不再适合作为新 UI 架构的默认单元。

Compose 里页面边界更适合用 composable function 表达，状态放在 ViewModel 或更清晰的状态持有对象里，导航用 Navigation Compose 或团队自己的路由层管理。Fragment 继续承担旧页面容器、生命周期桥接、三方 SDK 容器和渐进式迁移入口。

一个更清楚的页面边界通常长这样：

bash 复制代码

@Composable
fun ProfileRoute(
    viewModel: ProfileViewModel = viewModel(),
    onBack: () -> Unit,
) {
    val uiState by viewModel.uiState.collectAsStateWithLifecycle()

    ProfileScreen(
        state = uiState,
        onBack = onBack,
        onRetry = viewModel::retry
    )
}

Route 负责连接 ViewModel、生命周期和导航事件，Screen 负责展示。这样 Preview、单测和 UI 测试会更容易拆。

工具链

Compose-first 也会影响 Android Studio 的工具链。后续 UI 预览、设计检查、动画调试、截图测试、AI 辅助生成和多设备适配，会更偏向 Compose。

XML Layout Editor 和 Navigation Editor 仍然会维护，但它们不再是新 UI 能力的中心。团队如果还把页面验收建立在 XML 预览和 Design 视图上，后面会越来越吃力。

Compose Preview 应该进入日常开发。一个页面至少保留核心状态的 Preview，比如空态、加载态、错误态、长文本、大字号和深色模式：

bash 复制代码

@Preview(showBackground = true)
@Composable
private fun ProfileScreenPreview() {
    AppTheme {
        ProfileScreen(
            state = ProfileUiState.fake(),
            onBack = {},
            onRetry = {}
        )
    }
}

Preview 不是截图装饰。它能让 UI 状态在代码审查前暴露出来，也能倒逼 Screen 不直接依赖真实 ViewModel、网络请求和系统服务。

迁移检查

团队迁移 Compose 不要只建一个"学习 Compose"的任务。更有效的是把新 UI 的默认规则写进工程规范。

先从新增页面开始：新增页面默认 Compose，新增列表默认 Lazy 组件，新增主题默认 Material 3，新增可复用组件默认 Composable。旧页面只在改动足够大时迁移，不因为小需求强行重写。

迁移前可以先过一遍检查项：

bash 复制代码

新页面：默认 Compose，不再新增 XML 布局
列表：优先 LazyColumn / LazyRow / LazyGrid，并补稳定 key
状态：Route 连接 ViewModel，Screen 只展示 state
预览：覆盖空态、加载态、错误态、深色模式和长文本
互操作：ComposeView / AndroidView 有清晰边界
测试：保留关键 UI 测试和截图验证
性能：复杂列表、动画、嵌套滚动要做专项采样

最容易出问题的是"写法像 Compose，架构还是旧 View"。比如 composable 里直接发网络请求，直接读全局单例，直接处理复杂业务分支，或者把一个 800 行 XML 页面翻译成 800 行 composable。这些写法短期能跑，后期维护成本不会低。

最后

Compose-first 之后，View 体系仍然是 Android 的重要存量基础，但新 UI 开发的默认答案已经改变。

对团队来说，下一步不是重写所有页面，而是把"新增 UI 默认 Compose"写进模板、规范、代码审查和测试流程里。老页面按业务节奏迁，新增页面不要再继续扩大 View 的存量。

#Android #JetpackCompose #ComposeFirst #Kotlin #AndroidUI