第三篇：UI篇 —— Jetpack Compose 声明式界面第5章 列表与导航：构建复杂应用骨架在上一章，我们学会了制作单个页面。但在真实世界中，App 是由无数个页面组成的，且每个页面通常包含大量的列表数据（如微信聊天列表、朋友圈、微博信息流）。如果你试图用Column硬塞几百条数据，你的 App 会瞬间卡死并爆内存。这一章，我们将攻克 Android 开发中最核心的两个难点：高性能列表和多页面导航。我们将深入源码级别的优化策略，并通过一个完整的“新闻客户端”案例，让你掌握 2026 年工业级的应用架构。5.1 LazyColumn：RecyclerView 的终结者在 XML 时代，高性能列表意味着复杂的RecyclerView、繁琐的Adapter、容易出错的ViewHolder。在 Compose 中，这一切被简化为一行代码：LazyColumn。核心概念：Lazy（惰性）LazyColumn只会渲染屏幕上可见区域的 Item。当用户滑动时，滚出屏幕的 Item 会被回收，新的 Item 会被创建。这就是它高性能的原因。5.1.1 基础用法与参数详解@ComposablefunSimpleList(){LazyColumn(modifier=Modifier.fillMaxSize(),contentPadding=PaddingValues(16.dp),// 列表整体的内边距verticalArrangement=Arrangement.spacedBy(8.dp),// Item 之间的间距reverseLayout=false,// 是否反转布局（从底部开始）horizontalAlignment=Alignment.CenterHorizontally// 子项水平对齐){// item 表示单个元素item{Text("这是列表头部",style=MaterialTheme.typography.headlineSmall)}// items 表示一组数据items(100){index-// 生成 100 个 ItemText(text="Item #$index",modifier=Modifier.fillMaxWidth().padding(vertical=8.dp))}}}5.1.2 列表优化：防止重组抖动（核心考点）痛点：当列表数据更新时（比如中间插入一条数据），Compose 默认会重组整个列表，导致性能灾难。解决方案：使用key。// 假设我们有一个数据类dataclassMessage(valid:Int,valcontent:String)@ComposablefunMessageList(messages:ListMessage){LazyColumn{items(items=messages,key={message-message.id}// 告诉 Compose 每个 Item 的唯一标识){message-Text(text=message.content)}}}原理：有了key，Compose 就能精确知道哪个 Item 变了，只重组那个 Item，而不是整个列表。这在 2026 年是强制规范。5.1.3 粘性头部（Sticky Headers）很多 App 都有按字母分组的功能（如通讯录）。Compose 原生支持粘性头部。@OptIn(ExperimentalFoundationApi::class)@ComposablefunContactsList(contacts:ListContact){valgroupedContacts=contacts.groupBy{it.name.first()}LazyColumn{groupedContacts.forEach{(initial,contactsForInitial)-// 粘性头部stickyHeader{Text(text=initial.toString(),modifier=Modifier.fillMaxWidth().background(MaterialTheme.colorScheme.primaryContainer).padding(8.dp))}// 该分组下的 Itemitems(contactsForInitial){contact-ContactItem(contact)}}}}5.1.4 下拉刷新（Pull-to-Refresh）在 XML 时代，实现下拉刷新需要嵌套SwipeRefreshLayout。在 Compose 中，这是一个独立的 Composable。@OptIn
