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 的存量。