Android开发转型指南：从XML到Jetpack Compose的实战进阶
1. 为什么现在必须学Compose？一个老Android的视角
如果你还在用XML写Android界面，每次改个布局都要在AS里等半天预览刷新，或者被RecyclerView的Adapter、ViewHolder折磨得死去活来，那今天这篇内容就是为你准备的。我不是来给你讲“Jetpack Compose是声明式UI框架”这种教科书定义的，我是以一个从AbsoluteLayout（暴露年龄了）时代一路踩坑过来的老Android身份，跟你聊聊为什么2024年了，Compose已经从“值得一看”变成了“必须上手”。
首先，最直接的动力是效率。我最近一个需求，用XML写一个带复杂状态（如加载、空态、错误态）的列表页，从画UI到联调，至少一天。用Compose，配合LazyColumn和状态管理，半天搞定，而且代码量少了近一半。这不仅仅是“写”得快，更是“改”得快。产品经理指着设计稿说“这个间距调大点，那个颜色变一下”，在Compose里可能就是改一两个参数，热重载（Live Edit）几乎秒级响应。而在XML+View体系里，改完dimens.xml或colors.xml，还得同步到Java/Kotlin代码里，然后重新编译运行，几分钟就没了。时间就是金钱，这个道理在卷成麻花的移动端领域尤其正确。
其次，是心智模型的简化。传统的View体系是命令式的，你需要告诉系统每一步怎么做：findViewById获取引用，setText设置文字，setOnClickListener设置监听。UI状态分散在Activity、Fragment、ViewModel甚至自定义View里，状态变更后，你需要手动找到所有依赖这个状态的View并更新它们，极易遗漏，导致UI与数据不同步。Compose是声明式的，你只需要描述在某个状态下，UI应该长什么样。当状态变化时，Compose会自动找到需要更新的部分并高效地重组（Recompose）。这就像从手动挡换成了自动挡，你只需要关心目的地（最终UI状态），而不需要操心换挡离合（繁琐的UI更新命令）。
再者，看看生态和趋势。Google官方从2021年Compose 1.0发布以来，几乎所有的新样本、新文档、新工具（如Android Studio的Compose预览增强）都在向Compose倾斜。Material Design 3的官方实现库material3对Compose的支持是最原生、最现代的。越来越多的知名开源库（如Coil图片加载、Paging分页库）都提供了Compose-first的API。更重要的是，Kotlin Multiplatform Mobile的UI部分，Compose Multiplatform是官方主推的解决方案。这意味着，你今天在Compose上投入的学习成本，未来可能会在跨平台（iOS、Desktop）开发上获得回报。逆水行舟，不进则退，这个道理在技术栈选择上同样适用。
最后，对于个人开发者或小团队，Compose能显著降低项目的维护成本。没有繁杂的XML文件，减少了View与数据绑定的胶水代码，用Kotlin一种语言统一业务逻辑和UI描述，让代码更紧凑，更易于理解和调试。虽然学习曲线存在，但一旦越过那个坡，你会发现开发体验是一种质的提升。
所以，别再观望了。这篇内容，我会假设你是一个有Android基础（熟悉Kotlin，了解Activity/Fragment生命周期）但从未接触过Compose的开发者，带你从最核心的概念和最小的可运行代码块开始，一步步构建出包含列表、下拉刷新、上拉加载等完整功能的现代Android界面。我们的目标不是面面俱到，而是让你能立刻动手，做出东西，在实战中建立信心和理解。
2. 搭建第一个Compose项目：避开初学者最常见的三个坑
理论说再多，不如跑一行代码。我们直接从创建项目开始。打开Android Studio（我假设你用的是最新稳定版，如Giraffe或Hedgehog），选择“New Project”，在模板中选择“Empty Activity”，注意在配置页面，有一个“Minimum SDK”的选择。
2.1 坑一：API版本与Compose兼容性
这里是你可能遇到的第一个坑。Compose本身对最低API级别有要求。虽然官方说支持到API 21（Android 5.0），但为了获得最佳体验和用到所有最新特性，我强烈建议将minSdkVersion设置为API 24（Android 7.0）或更高。原因有三：
- 性能：Compose的底层渲染引擎
Skia在较新系统上有更好的优化。 - 功能完整性：一些Material Design 3的组件和动画效果在低版本上可能无法完美呈现或需要回退。
- 开发体验：模拟器和真机调试更流畅。在实际项目中，根据你的用户群体分布做决定，但对于学习和新项目，从API 24起步是更稳妥的选择。
创建完成后，打开项目级的build.gradle.kts（或build.gradle）文件。确保buildscript的dependencies里包含了最新版的com.android.tools.build:gradle插件（例如8.1.0以上）。然后打开模块级的build.gradle.kts（通常是app/build.gradle.kts）。
2.2 坑二：依赖配置的“玄学”错误
Compose的依赖配置有一系列需要协同工作的库，版本号必须兼容。一个配置错误就可能导致编译失败。下面是一个经过我多个项目验证的、稳定的基础配置模板，适用于build.gradle.kts：
plugins { id("com.android.application") id("org.jetbrains.kotlin.android") } android { namespace = "com.yourpackage.yourapp" compileSdk = 34 // 使用最新的稳定版SDK defaultConfig { applicationId = "com.yourpackage.yourapp" minSdk = 24 // 建议24+ targetSdk = 34 versionCode = 1 versionName = "1.0" } buildTypes { release { isMinifyEnabled = true proguardFiles(getDefaultProguardFile("proguard-android-optimize.txt"), "proguard-rules.pro") } } compileOptions { sourceCompatibility = JavaVersion.VERSION_17 targetCompatibility = JavaVersion.VERSION_17 } kotlinOptions { jvmTarget = "17" } buildFeatures { // 关键！启用Compose支持 compose = true } composeOptions { // 关键！指定Kotlin编译器插件版本 kotlinCompilerExtensionVersion = "1.5.4" // 此版本需与Compose BOM版本匹配 } } dependencies { // 核心Compose BOM (Bill of Materials)，统一管理版本 val composeBom = platform("androidx.compose:compose-bom:2023.10.01") implementation(composeBom) androidTestImplementation(composeBom) // 基础依赖 implementation("androidx.core:core-ktx:1.12.0") implementation("androidx.lifecycle:lifecycle-runtime-ktx:2.6.2") implementation("androidx.activity:activity-compose:1.8.0") // 提供setContent implementation("androidx.compose.ui:ui") implementation("androidx.compose.ui:ui-graphics") implementation("androidx.compose.ui:ui-tooling-preview") // 预览支持 implementation("androidx.compose.material3:material3") // Material Design 3 // 测试依赖 testImplementation("junit:junit:4.13.2") androidTestImplementation("androidx.test.ext:junit:1.1.5") androidTestImplementation("androidx.test.espresso:espresso-core:3.5.1") androidTestImplementation("androidx.compose.ui:ui-test-junit4") debugImplementation("androidx.compose.ui:ui-tooling") debugImplementation("androidx.compose.ui:ui-test-manifest") }关键点解析：
buildFeatures { compose = true }：这个开关必须打开，否则Android Studio不会识别Compose代码，也无法使用预览功能。composeOptions：kotlinCompilerExtensionVersion是Compose编译器插件的版本，它必须与你使用的Compose库版本兼容。使用BOM可以简化版本管理，但这里仍需指定。上例中1.5.4与BOM2023.10.01是兼容的。最稳妥的方法是查看 官方Compose版本地图 ，找到对应关系。- BOM的使用：
platform(“androidx.compose:compose-bom:xxx”)引入BOM后，下面的implementation(“androidx.compose.ui:ui”)等依赖就可以不写版本号了，BOM会帮你统一管理。这能极大避免版本冲突。
同步Gradle后，打开MainActivity.kt，你会看到熟悉的onCreate方法。将setContentView(R.layout.activity_main)这行替换掉。
2.3 坑三：setContent与预览函数
在onCreate里，调用setContent这个Compose的入口函数：
class MainActivity : ComponentActivity() { override fun onCreate(savedInstanceState: Bundle?) { super.onCreate(savedInstanceState) setContent { // 这里就是Compose的世界了 YourAppTheme { // 稍后我们会定义这个主题 GreetingScreen() } } } }同时，在同一个文件（或新建一个）里，我们写第一个Composable函数（用于预览）：
import androidx.compose.foundation.layout.Box import androidx.compose.foundation.layout.fillMaxSize import androidx.compose.material3.Text import androidx.compose.runtime.Composable import androidx.compose.ui.Alignment import androidx.compose.ui.Modifier import androidx.compose.ui.tooling.preview.Preview @Composable fun GreetingScreen() { Box( modifier = Modifier.fillMaxSize(), contentAlignment = Alignment.Center ) { Text(text = "Hello, Compose!") } } @Preview(showBackground = true) // 这个注解让函数可以在Android Studio右侧预览 @Composable fun GreetingScreenPreview() { YourAppTheme { // 预览也需要在主题内 GreetingScreen() } }写完后，在Android Studio右侧找到“Split”或“Design”视图，稍等片刻，你应该就能看到“Hello, Compose!”的预览了。如果没出现，尝试点击预览面板上的“刷新”按钮或执行“Build -> Make Project”。
注意：
YourAppTheme是我们自定义的主题，暂时可以先用一个简单的MaterialTheme代替：MaterialTheme { GreetingScreen() }。我们会在后面详细讲主题。
至此，你的第一个Compose项目已经跑起来了。这个过程看似简单，但很多新手会在Gradle配置和预览不显示上卡很久。记住上面的三个坑和配置模板，能帮你节省大量排查时间。
3. 理解Compose的基石：状态、重组与Modifier
现在屏幕上显示了文字，但我们写的GreetingScreen是个静态函数。UI是动态的，如何让UI响应用户操作或数据变化？这就是Compose最核心的三个概念：状态（State）、重组（Recomposition）和修饰符（Modifier）。理解它们，就理解了Compose一半的精髓。
3.1 状态驱动UI：mutableStateOf与remember
在命令式UI中，你改变一个TextView的文本，是调用textView.setText(“新文本”)。在声明式UI中，你改变的是描述UI的数据（状态），然后由系统根据新数据重新绘制UI。
在Compose中，使用mutableStateOf()来创建一个可观察的状态。当这个状态的值发生变化时，所有读取（使用）了该状态的Composable函数都会被标记，并可能被重新执行以更新UI，这个过程就叫重组。
但这里有个关键问题：Composable函数在重组时可能会被多次调用。如果每次调用都mutableStateOf()，状态就会被重置，无法保持。所以我们需要remember。
@Composable fun Counter() { // 错误写法：每次重组count都会变回0 // var count = mutableStateOf(0) // 正确写法：remember将状态在重组间缓存起来 var count by remember { mutableStateOf(0) } Column(horizontalAlignment = Alignment.CenterHorizontally) { Text(text = "你点击了 $count 次") Button(onClick = { count++ }) { Text(text = "点击我") } } }mutableStateOf(0)：创建一个持有整数0的可观察状态对象。remember { … }：将这个状态对象“记住”，使其在初次组合（第一次调用Counter函数）时被创建，并在后续重组中返回同一个实例，而不是创建新的。by：这是Kotlin的委托属性语法，它允许我们直接通过count来读写状态的值，而不是count.value，让代码更简洁。需要在文件顶部导入import androidx.compose.runtime.getValue和import androidx.compose.runtime.setValue。
当你点击按钮，onClicklambda执行count++，这改变了状态的值。由于Text组件读取了count，Counter函数（以及其内部的Text）会被重组，Text显示出新的数字。这就是状态驱动UI的完整闭环。
3.2 重组：高效更新的核心魔法
你可能会担心：每次状态变一点，整个函数都重跑，性能不会很差吗？这就是Compose聪明的地方。重组不是重建整个UI树，而是Compose运行时智能地比较前后两次调用Composable函数的结果，只更新发生变化的部分。
在上面的例子中，重组发生时：
- Compose运行时知道
count状态变了。 - 它调用
Counter函数。 - 将这次调用
Counter的结果（一个包含Text和Button的布局树）与上一次的结果进行比较。 - 它发现只有
Text的text参数从“你点击了 X 次”变成了“你点击了 X+1 次”。 - 于是，它只去更新屏幕上对应的那个
Text节点的内容，Button节点完全不会被触动。
这个过程非常高效。但为了让它正确工作，你必须遵守一个关键原则：Composable函数应该是没有副作用的，并且应该是幂等的（多次调用相同参数产生相同结果）。不要在Composable函数中直接进行网络请求、数据库读写或修改全局变量。这些副作用应该放在ViewModel或使用LaunchedEffect等副作用API中处理。
3.3 Modifier：UI的瑞士军刀
如果说状态是UI的灵魂，那Modifier就是UI的肉体塑造师。几乎所有的Composable函数都有一个可选的modifier参数，用于定义组件的尺寸、布局、外观、手势以及各种行为。
Modifier的使用是链式的，顺序有时很重要：
@Composable fun FancyButton() { Text( text = "一个 fancy 的按钮", modifier = Modifier .background(color = Color.Blue, shape = RoundedCornerShape(8.dp)) // 1. 先设置背景 .padding(16.dp) // 2. 在背景内部增加内边距 .clickable { /* 处理点击 */ } // 3. 设置点击区域（包含padding） .border(2.dp, Color.Red, RoundedCornerShape(8.dp)) // 4. 在背景和padding外添加边框 ) }background：设置背景色和形状。padding：在内容周围添加空间。注意顺序：如果padding在background之后，则padding区域也会有背景色；如果在background之前，则背景色只在内容区域。clickable：使组件可点击。border：在组件外部添加边框。
Modifier的强大之处在于它的可组合性。你可以创建自定义的Modifier来复用样式。例如，一个项目中常用的卡片阴影样式：
fun Modifier.cardElevation(): Modifier = this .shadow( elevation = 4.dp, shape = RoundedCornerShape(8.dp), clip = true // 阴影是否裁剪到形状内 ) .background(MaterialTheme.colorScheme.surface, RoundedCornerShape(8.dp))然后在任何地方使用：Modifier.cardElevation().padding(16.dp)。
理解状态、重组和Modifier，你就掌握了构建动态、交互式Compose UI的基础工具。接下来，我们用它们来构建更复杂的布局。
4. 构建现代列表页：LazyColumn、状态管理与分页加载
列表是移动端最常用的组件。在View时代，RecyclerView的配置堪称繁琐。在Compose中，LazyColumn和LazyRow让列表变得异常简单。我们将构建一个完整的列表页，包含下拉刷新和上拉加载更多。
4.1 使用LazyColumn构建基础列表
首先，我们定义一些数据和一个列表项Composable。
data class Message(val id: Long, val title: String, val content: String) @Composable fun MessageItem(message: Message) { Card( modifier = Modifier .fillMaxWidth() .padding(horizontal = 16.dp, vertical = 8.dp), elevation = CardDefaults.cardElevation(defaultElevation = 2.dp) ) { Column(modifier = Modifier.padding(16.dp)) { Text( text = message.title, style = MaterialTheme.typography.titleMedium, fontWeight = FontWeight.Bold ) Spacer(modifier = Modifier.height(8.dp)) Text( text = message.content, style = MaterialTheme.typography.bodyMedium, maxLines = 2, overflow = TextOverflow.Ellipsis ) } } }然后，在屏幕Composable中使用LazyColumn：
@Composable fun MessageList(messages: List<Message>) { LazyColumn( modifier = Modifier.fillMaxSize(), contentPadding = PaddingValues(vertical = 8.dp) // 列表顶部和底部的内边距 ) { items(messages) { message -> // items函数遍历列表 MessageItem(message = message) } } }LazyColumn是“惰性”的，它只组合和布局当前可见的项，以及前后少量的缓冲项，这和RecyclerView的视图复用机制类似，保证了超长列表的性能。items是一个DSL（领域特定语言）函数，它接收一个列表和一个lambda，为每个列表项生成一个Composable。
4.2 集成下拉刷新：SwipeRefresh
下拉刷新是一个非常普遍的需求。我们可以使用accompanist-swiperefresh库（现已迁移到androidx.compose.material:material的扩展库中，但用法类似）。首先，确保添加了Material依赖（我们之前用BOM已经包含了）。
我们使用rememberSwipeRefreshState来管理刷新状态，并将其与SwipeRefresh组件结合。
import androidx.compose.material3.* import androidx.compose.material3.pullrefresh.PullRefreshIndicator import androidx.compose.material3.pullrefresh.pullRefresh import androidx.compose.material3.pullrefresh.rememberPullRefreshState @Composable fun MessageListScreen( viewModel: MessageListViewModel = viewModel() // 假设我们有一个ViewModel ) { val uiState by viewModel.uiState.collectAsStateWithLifecycle() // 收集UI状态 // 创建下拉刷新状态，与ViewModel中的刷新状态绑定 val refreshState = rememberPullRefreshState( refreshing = uiState.isRefreshing, // 是否正在刷新 onRefresh = { viewModel.refreshData() } // 触发刷新的回调 ) Box(modifier = Modifier.fillMaxSize()) { // LazyColumn包裹在pullRefresh修饰符中 LazyColumn( modifier = Modifier .fillMaxSize() .pullRefresh(refreshState), // 应用下拉手势 contentPadding = PaddingValues(vertical = 8.dp) ) { items(uiState.messages) { message -> MessageItem(message = message) } // 这里可以添加加载更多的item，见下一节 } // 下拉刷新指示器，放置在Box的顶部居中位置 PullRefreshIndicator( refreshing = uiState.isRefreshing, state = refreshState, modifier = Modifier.align(Alignment.TopCenter) ) } }关键点：
- 状态提升：刷新状态
isRefreshing和列表数据messages都应该存放在ViewModel中。ViewModel是UI状态的管理者，负责处理业务逻辑（如发起网络请求）。Composable函数只负责根据状态显示UI。 collectAsStateWithLifecycle()：这是一个来自androidx.lifecycle:lifecycle-runtime-compose库的扩展函数，它能在Lifecycle处于STARTED及以上状态时收集Flow，并在进入STOPPED状态时自动取消收集，避免资源泄露。比普通的collectAsState()更安全。rememberPullRefreshState：将UI的刷新状态（是否正在转圈）与手势状态绑定。当用户下拉时，refreshState会更新；当refreshing为true时，指示器显示。
4.3 实现上拉加载更多：监听滚动位置
上拉加载更多需要监听LazyColumn的滚动状态，判断用户是否已经滚动到底部。我们可以使用LazyListState。
首先，在ViewModel中管理加载更多的状态：
class MessageListViewModel : ViewModel() { // UI状态数据类 data class MessageListUiState( val messages: List<Message> = emptyList(), val isRefreshing: Boolean = false, val isLoadingMore: Boolean = false, // 是否正在加载更多 val hasMore: Boolean = true // 是否还有更多数据 ) private val _uiState = MutableStateFlow(MessageListUiState()) val uiState: StateFlow<MessageListUiState> = _uiState.asStateFlow() fun loadMoreData() { if (_uiState.value.isLoadingMore || !_uiState.value.hasMore) return viewModelScope.launch { _uiState.update { it.copy(isLoadingMore = true) } // 模拟网络请求 delay(1000) val newMessages = /* ... 获取新数据 ... */ _uiState.update { currentState -> currentState.copy( messages = currentState.messages + newMessages, isLoadingMore = false, hasMore = newMessages.isNotEmpty() // 假设空列表表示没有更多了 ) } } } // ... refreshData等其他方法 }然后，在Composable中监听滚动：
@Composable fun MessageListScreen(viewModel: MessageListViewModel = viewModel()) { val uiState by viewModel.uiState.collectAsStateWithLifecycle() val refreshState = rememberPullRefreshState(...) // 关键：记住LazyListState val lazyListState = rememberLazyListState() // 副作用：监听滚动状态，触发加载更多 LaunchedEffect(lazyListState) { snapshotFlow { // 计算是否接近底部 val layoutInfo = lazyListState.layoutInfo val totalItems = layoutInfo.totalItemsCount val lastVisibleItem = layoutInfo.visibleItemsInfo.lastOrNull()?.index ?: -1 // 当最后一个可见项是列表倒数第5项时，触发加载更多 totalItems > 0 && lastVisibleItem >= totalItems - 5 } .distinctUntilChanged() // 只有状态改变时才触发 .collect { shouldLoadMore -> if (shouldLoadMore && !uiState.isLoadingMore && uiState.hasMore) { viewModel.loadMoreData() } } } Box(modifier = Modifier.fillMaxSize()) { LazyColumn( state = lazyListState, // 将状态赋予LazyColumn modifier = Modifier .fillMaxSize() .pullRefresh(refreshState), contentPadding = PaddingValues(vertical = 8.dp) ) { items(uiState.messages) { message -> MessageItem(message = message) } // 在列表末尾添加一个加载更多的Item item { if (uiState.isLoadingMore) { Box( modifier = Modifier .fillMaxWidth() .padding(16.dp), contentAlignment = Alignment.Center ) { CircularProgressIndicator() } } else if (!uiState.hasMore && uiState.messages.isNotEmpty()) { Box( modifier = Modifier .fillMaxWidth() .padding(16.dp), contentAlignment = Alignment.Center ) { Text(text = "没有更多内容了", style = MaterialTheme.typography.bodySmall) } } } } PullRefreshIndicator(...) } }关键点解析：
rememberLazyListState()：创建并记住LazyColumn的滚动状态。LaunchedEffect：这是一个副作用API。它会在LaunchedEffect进入组合时启动一个协程，并在退出组合或key（这里是lazyListState）变化时取消。我们在这里监听滚动状态。snapshotFlow：将lazyListState.layoutInfo这个状态转换为Flow，便于我们以响应式的方式监听其变化。- 加载更多触发逻辑：我们判断“最后一个可见项的索引”是否大于等于“总项数 - 5”，这是一个常见的预加载阈值，可以在用户滚动到底部前提前加载，体验更流畅。
- 列表尾部Item：我们在
LazyColumn的items块外，用item { }添加了一个特殊的项。根据isLoadingMore和hasMore状态，显示加载指示器、没有更多内容的提示，或者什么都不显示。
至此，一个功能完整的、包含下拉刷新和上拉加载更多的现代列表页就完成了。整个逻辑清晰地位于ViewModel和Composable中，状态管理集中，UI响应式更新。
5. 主题、样式与实战中的性能优化
当你的应用有多个界面时，保持一致的视觉风格至关重要。Compose通过MaterialTheme提供了强大的主题系统。同时，随着UI复杂度的提升，了解一些性能优化技巧也必不可少。
5.1 定义与应用自定义主题
在View系统中，我们定义styles.xml和themes.xml。在Compose中，主题是纯Kotlin代码。通常，我们会在一个独立的文件（如ui/theme/Theme.kt）中定义主题。
import androidx.compose.foundation.isSystemInDarkTheme import androidx.compose.material3.* import androidx.compose.runtime.Composable import androidx.compose.ui.graphics.Color private val DarkColorScheme = darkColorScheme( primary = Color(0xFFBB86FC), secondary = Color(0xFF03DAC6), tertiary = Color(0xFF3700B3), background = Color(0xFF121212), surface = Color(0xFF1E1E1E), onPrimary = Color.Black, onSecondary = Color.Black, onBackground = Color.White, onSurface = Color.White, ) private val LightColorScheme = lightColorScheme( primary = Color(0xFF6200EE), secondary = Color(0xFF03DAC6), tertiary = Color(0xFF3700B3), background = Color.White, surface = Color.White, onPrimary = Color.White, onSecondary = Color.Black, onBackground = Color.Black, onSurface = Color.Black, ) @Composable fun YourAppTheme( darkTheme: Boolean = isSystemInDarkTheme(), content: @Composable () -> Unit ) { val colorScheme = if (darkTheme) DarkColorScheme else LightColorScheme val view = LocalView.current if (!view.isInEditMode) { SideEffect { val window = (view.context as Activity).window window.statusBarColor = colorScheme.primary.toArgb() WindowCompat.getInsetsController(window, view).isAppearanceLightStatusBars = darkTheme } } MaterialTheme( colorScheme = colorScheme, typography = Typography, // 可以自定义Typography shapes = Shapes, // 可以自定义Shapes content = content ) }然后在MainActivity的setContent和所有@Preview函数中，用YourAppTheme包裹你的UI内容。这样，所有内部的Material组件（如Button、Card、TextField）都会自动使用你定义的颜色、字体和形状。
使用主题中的颜色和字体：
Text( text = "使用主题色", color = MaterialTheme.colorScheme.primary, // 使用主题的主色 style = MaterialTheme.typography.headlineMedium // 使用主题的标题字体样式 )5.2 性能优化关键：稳定性与避免不必要的重组
Compose的重组虽然高效，但不当的写法仍会导致性能问题。核心原则是：让尽可能少的Composable在状态变化时重组。
1. 将参数包装为稳定的（Stable）类型：Compose通过比较重组前后Composable的参数是否“相等”来决定是否跳过重组。对于data class，确保所有属性都是val（不可变）且类型是稳定的（基本类型、String、其他@Stable类）。对于函数类型参数（如onClick），使用remember或将其提升到不会频繁变化的层级。
2. 使用derivedStateOf处理派生状态：如果一个状态是由其他多个状态计算而来，并且计算成本较高，使用derivedStateOf。它只会在其依赖的状态变化时重新计算，并且其结果是State，可以触发重组。
@Composable fun ExpensiveComputation(list: List<Item>, filter: String) { val filteredList by remember(list, filter) { derivedStateOf { // 这是一个昂贵的过滤操作 list.filter { it.name.contains(filter, ignoreCase = true) } } } LazyColumn { items(filteredList) { item -> ... } } }3. 使用key和contentType优化Lazy列表：在LazyColumn的items或itemsIndexed函数中，始终提供一个稳定的、唯一的key参数。这能帮助Compose在列表项位置变动时（如插入、删除）高效地识别和移动项，而不是重建它们。
items( items = messages, key = { message -> message.id } // 使用唯一ID作为key ) { message -> ... }对于异构列表（多种类型的项），使用contentType参数。Compose可以对相同contentType的项进行更有效的复用。
LazyColumn { items( items = list, key = { it.id }, contentType = { it.type } // 例如 “header”, “item”, “footer” ) { item -> when (item.type) { “header” -> HeaderItem(item) “item” -> DataItem(item) } } }4. 避免在Composable函数中创建不稳定对象：不要在Composable函数体或@Composablelambda中直接创建ArrayList、HashMap或ViewModel实例。这些对象在每次重组时都是新的，会导致子Composable不必要地重组。应该使用remember来记住它们，或者通过参数传入。
5. 使用Modifier的顺序影响性能：像drawBehind、graphicsLayer这样的绘制型Modifier比较耗时。如果它们依赖的状态频繁变化（如动画值），尽量将它们放在Modifier链的末端，或者考虑使用Canvas等低级API。
5.3 调试重组：使用重组计数
Android Studio的Layout Inspector for Compose提供了可视化重组高亮的功能。你可以在运行应用时，打开Layout Inspector，勾选“Show Recomposition Counts”。屏幕上每个Composable的边框会以颜色显示其重组次数（蓝色表示次数少，红色表示次数多）。这是一个非常直观的定位性能热点的方法。
从0上手Jetpack Compose，核心在于转变思维：从命令式的“如何做”转变为声明式的“是什么”。通过状态驱动UI，用Modifier描述样式，用LazyColumn等组件简化复杂布局。在实战中，牢记状态提升的原则，将UI状态和逻辑放在ViewModel中管理。对于性能，理解重组的机制，善用remember、derivedStateOf、key等工具来优化。