1. 从命令式到声明式AI组件库的架构选型思考Android 原生 UI 开发在过去很长一段时间里基本是ViewXML的天下。写一个聊天界面你得先定义RecyclerView再写Adapter再处理ViewHolder再手动 diff 刷新一套流程下来业务逻辑还没写几行样板代码已经堆了一屏。Jetpack Compose 出现之后这套玩法被彻底掀翻了——UI 变成了状态的函数状态变了界面自动重组开发者终于可以把精力放回业务本身。但问题也随之而来AI 类应用在移动端的交互形态跟传统 App 差别太大了。流式输出、打字机效果、Markdown 实时渲染、代码块高亮、多轮对话气泡、输入框动态高度、消息列表自动滚动……这些东西如果每个项目都从零手搓那 Compose 带来的效率红利基本就被抵消干净了。所以当我看到“Android Compose 版本的 AI 组件库”这个方向时第一反应是这个需求是真实存在的而且相当迫切。这篇文章想聊的就是这样一个组件库从设计到落地的完整思路。我会把重点放在为什么这么设计、核心组件怎么实现、实际踩过哪些坑上而不是简单罗列 API。如果你正在做 Android 端的 AI 对话类应用或者想基于 Compose 搭一套可复用的聊天 UI 体系那这篇内容应该能帮你省下不少试错时间。1.1 为什么是 Compose而不是继续用 View 体系先说结论AI 交互场景天然适合声明式 UI。原因有三点。第一流式数据的重组成本。AI 回复是一个 token 一个 token 吐出来的界面需要高频局部刷新。传统 View 体系下你要么用DiffUtil做增量更新要么直接notifyItemChanged全量刷新前者写起来繁琐后者性能堪忧。Compose 的mutableStateOf配合derivedStateOf天然支持细粒度重组只有依赖变化的那部分 UI 会重新绘制这个优势在流式场景下被放大了好几倍。第二动态布局的灵活性。AI 回复的内容长度不可预测可能是一行字也可能是几百行的代码块。Compose 的Column、Row、FlowRow组合起来配合IntrinsicSize和SubcomposeLayout处理这种不确定高度的内容比LinearLayout的weight机制舒服太多。第三状态管理的统一性。AI 应用的状态很复杂加载中、流式输出中、已完成、出错、被中断……这些状态如果散落在ViewModel、Adapter、Fragment里维护起来就是灾难。Compose 的State提升机制让状态可以集中管理UI 只负责消费逻辑清晰得多。当然Compose 也不是银弹。它的学习曲线、编译速度、以及跟现有 View 体系的混用成本都是真实存在的。但如果你的项目是全新的 AI 应用或者 AI 模块是独立页面那 Compose 几乎是当前最优解。1.2 组件库的边界该封装什么不该封装什么做组件库最容易犯的错误就是什么都想封。封得太浅用户觉得鸡肋封得太深用户觉得被绑架。我的经验是AI 组件库的边界应该划在交互模式这一层而不是业务逻辑这一层。具体来说应该封装的消息气泡的布局与样式用户消息、AI 消息、系统消息流式文本的渲染与打字机效果Markdown 与代码块的解析渲染输入框的自动增高、发送按钮状态联动消息列表的自动滚动与“回到底部”按钮加载态、错误态、重试态的统一样式不应该封装的具体的网络请求逻辑用 OkHttp 还是 Ktor是 SSE 还是 WebSocket交给用户数据模型的具体字段Message类里该有什么让用户自己定状态管理的具体方案ViewModel 还是 Presenter不强制主题色、字体、圆角这些视觉细节提供默认值但必须可覆盖这个边界划清楚之后组件库的 API 设计就会自然很多。用户拿到手只需要把数据喂进来把回调接出去中间那层交互细节全部由组件库兜底。2. 核心组件拆解从消息气泡到流式渲染这一部分我会逐个拆解组件库里的核心模块每个模块都会讲清楚设计意图、关键实现、以及实际使用中需要注意的细节。代码示例我会用 Kotlin Compose 写尽量保持可运行性但为了篇幅考虑会省略一些跟主题无关的 import 和辅助函数。2.1 消息数据模型的设计取舍组件库的第一块基石是数据模型。这里有个关键决策组件库要不要定义自己的 Message 类我的选择是定义一个最小化的接口而不是具体的 data class。interface ChatMessage { val id: String val role: MessageRole val content: String val timestamp: Long val status: MessageStatus } enum class MessageRole { USER, ASSISTANT, SYSTEM } enum class MessageStatus { SENDING, STREAMING, COMPLETED, ERROR }为什么用接口而不是 data class因为不同项目的消息模型差异太大了。有的项目需要tokenCount有的需要attachments有的需要parentMessageId。如果组件库强行定义一个包含所有字段的 data class用户就得做一层无意义的映射。用接口的话用户自己的Message类只需要实现这个接口或者写一个扩展函数做适配灵活得多。status字段是重点。很多新手做 AI 聊天界面只区分“发送中”和“已完成”结果流式输出的时候没法区分“正在吐字”和“已经吐完”导致光标闪烁逻辑、重试按钮的显示时机都很难处理。把STREAMING单独拎出来后面做打字机效果和中断逻辑会轻松很多。注意id字段建议用 UUID 或者时间戳随机数不要用列表索引。流式更新时列表内容会变用索引做 key 会导致 Compose 重组时状态错乱这个坑我踩过不止一次。2.2 消息气泡不只是画个圆角矩形消息气泡看起来简单实际上要考虑的东西不少。先看基础实现Composable fun MessageBubble( message: ChatMessage, modifier: Modifier Modifier ) { val isUser message.role MessageRole.USER val bubbleColor if (isUser) { MaterialTheme.colorScheme.primaryContainer } else { MaterialTheme.colorScheme.surfaceVariant } val alignment if (isUser) Alignment.End else Alignment.Start val shape if (isUser) { RoundedCornerShape(16.dp, 16.dp, 4.dp, 16.dp) } else { RoundedCornerShape(16.dp, 16.dp, 16.dp, 4.dp) } Box(modifier modifier.fillMaxWidth(), contentAlignment alignment) { Surface( color bubbleColor, shape shape, tonalElevation 1.dp ) { Column(modifier Modifier.padding(12.dp)) { MessageContent(message) if (message.status MessageStatus.STREAMING) { StreamingCursor() } } } } }几个细节值得展开说。圆角的不对称处理。用户消息右下角小圆角AI 消息左下角小圆角这是聊天界面的通用视觉语言能让人一眼分辨消息方向。别小看这 4dp 的差异它比颜色区分更直观。tonalElevation而不是shadow。Compose 的Surface用tonalElevation做层次感比传统的elevation阴影更符合 Material Design 3 的规范而且在深色模式下表现更自然。流式光标的放置。光标要放在Column内部、内容之后而不是气泡外部。这样光标会跟着文本自然流动不会出现“文本换行了但光标还在上一行末尾”的尴尬情况。最大宽度限制。实际使用中消息气泡不能占满整个屏幕宽度否则阅读体验很差。建议设置widthIn(max 280.dp)或者用fillMaxWidth(0.85f)。这个值需要根据屏幕尺寸动态调整平板和手机的合理值不一样。2.3 流式文本渲染打字机效果的三种实现路径流式渲染是 AI 组件库的灵魂。实现方式大致有三种各有优劣。方案一直接消费流式数据。网络层每收到一个 chunk就更新content状态Compose 自动重组。这是最自然的做法但问题是如果 chunk 到达速度不均匀网络抖动界面会出现“一顿一顿”的卡顿感。方案二缓冲区 定时器。维护一个目标文本和一个显示文本定时器每隔 16ms一帧从目标文本里取一部分追加到显示文本。这样无论网络多快多慢显示速度都是均匀的。缺点是实现复杂需要处理中断、暂停、加速等逻辑。方案三AnimatedContent或animateStringAsState。用 Compose 的动画 API 做插值代码最简洁但可控性最差不适合需要精确控制光标位置和滚动行为的场景。我最终选的是方案二核心逻辑大概是这样Composable fun StreamingText( targetText: String, isStreaming: Boolean, modifier: Modifier Modifier ) { var displayText by remember { mutableStateOf() } var lastUpdateTime by remember { mutableLongStateOf(0L) } LaunchedEffect(targetText, isStreaming) { if (!isStreaming) { displayText targetText returnLaunchedEffect } while (displayText.length targetText.length) { withFrameNanos { now - if (now - lastUpdateTime 16_000_000L) { val remaining targetText.length - displayText.length val step when { remaining 50 - 3 remaining 10 - 2 else - 1 } displayText targetText.substring(0, displayText.length step) lastUpdateTime now } } } } Text(text displayText, modifier modifier) }这里有个动态步长的设计剩余字符多的时候一次多吐几个剩余少的时候一次吐一个。这样既保证了长文本的显示速度又保证了结尾处的细腻感。实测下来这个策略比固定步长的体验好很多。提示withFrameNanos是 Compose 提供的帧同步 API比delay(16)更精确因为它跟屏幕刷新率对齐。在高刷屏上它会自动适配 120Hz不会出现固定 16ms 导致的抖动。2.4 Markdown 与代码块渲染别自己造轮子AI 回复里出现 Markdown 是常态尤其是代码块。自己写解析器不现实。我的建议是解析用成熟库渲染用 Compose 重写。解析层可以用commonmark-java或者markdown这类库把 Markdown 文本解析成 AST抽象语法树。渲染层则用 Compose 的AnnotatedString和Text组合来实现。Composable fun MarkdownText( markdown: String, modifier: Modifier Modifier ) { val blocks remember(markdown) { parseMarkdown(markdown) } Column(modifier modifier) { blocks.forEach { block - when (block) { is MarkdownBlock.Paragraph - { Text( text buildAnnotatedString(block), style MaterialTheme.typography.bodyMedium ) } is MarkdownBlock.CodeBlock - { CodeBlockView( code block.code, language block.language ) } is MarkdownBlock.ListBlock - { ListBlockView(block) } } } } }代码块渲染有几个关键点横向滚动代码行可能很长必须支持横向滚动否则会强制换行可读性极差。语法高亮可以用Highlights或者自己写简单的关键字匹配。如果性能要求高建议在后台线程做高亮把结果缓存起来。复制按钮代码块右上角放一个复制按钮这是刚需。复制的时候记得去掉行号和高亮标记只复制纯代码。语言标签显示代码语言方便用户判断内容类型。注意Markdown 解析和语法高亮都是 CPU 密集型操作千万不要在主线程做。用remember缓存解析结果用LaunchedEffectDispatchers.Default做异步解析否则流式输出的时候界面会卡成幻灯片。2.5 输入框自动增高与发送状态联动输入框的设计目标很明确用户打字的时候输入框高度跟着内容增长但不超过一个上限发送按钮根据输入内容是否为空自动启用或禁用。Composable fun ChatInputBar( onSend: (String) - Unit, modifier: Modifier Modifier ) { var inputText by remember { mutableStateOf() } val canSend inputText.isNotBlank() Row( modifier modifier .fillMaxWidth() .padding(8.dp), verticalAlignment Alignment.Bottom ) { BasicTextField( value inputText, onValueChange { inputText it }, modifier Modifier .weight(1f) .heightIn(min 40.dp, max 120.dp) .background( MaterialTheme.colorScheme.surfaceVariant, RoundedCornerShape(20.dp) ) .padding(horizontal 16.dp, vertical 10.dp), maxLines 5 ) Spacer(modifier Modifier.width(8.dp)) IconButton( onClick { if (canSend) { onSend(inputText) inputText } }, enabled canSend ) { Icon(Icons.Default.Send, contentDescription 发送) } } }heightIn(min 40.dp, max 120.dp)配合maxLines 5实现了自动增高但不超过 5 行的效果。超过 5 行之后输入框内部滚动。发送按钮的enabled状态跟canSend绑定视觉上可以用alpha做过渡让禁用状态看起来更自然。提示BasicTextField比TextField更灵活但需要自己处理 placeholder、光标颜色、背景等。如果不想折腾用TextField配合colors参数也能达到类似效果只是定制性差一些。3. 消息列表与滚动行为最容易被低估的模块消息列表看起来就是LazyColumn包一下但实际做起来滚动行为的处理是最容易出 bug 的地方。这一部分我单独拎出来讲因为它在 AI 聊天场景里的重要性远超普通列表。3.1 自动滚动到底部的正确姿势AI 回复的时候列表需要自动滚动到底部让用户看到最新内容。但这里有个矛盾如果用户手动往上滑看历史消息自动滚动就会把用户拽回底部体验极差。正确的逻辑应该是默认情况下新消息到达时自动滚动到底部。如果用户手动向上滚动进入“自由浏览”模式停止自动滚动。显示一个“回到底部”的悬浮按钮用户点击后恢复自动滚动。用户手动滚回底部时自动退出“自由浏览”模式。Composable fun MessageList( messages: ListChatMessage, modifier: Modifier Modifier ) { val listState rememberLazyListState() val isAtBottom by remember { derivedStateOf { val lastVisible listState.layoutInfo.visibleItemsInfo.lastOrNull() lastVisible null || lastVisible.index messages.lastIndex } } var autoScroll by remember { mutableStateOf(true) } LaunchedEffect(messages.size, messages.lastOrNull()?.content) { if (autoScroll messages.isNotEmpty()) { listState.animateScrollToItem(messages.lastIndex) } } LaunchedEffect(isAtBottom) { if (isAtBottom) autoScroll true } Box(modifier modifier) { LazyColumn( state listState, modifier Modifier.fillMaxSize(), verticalArrangement Arrangement.spacedBy(8.dp) ) { items(messages, key { it.id }) { message - MessageBubble(message message) } } if (!isAtBottom) { FloatingActionButton( onClick { autoScroll true }, modifier Modifier .align(Alignment.BottomEnd) .padding(16.dp) ) { Icon(Icons.Default.ArrowDownward, contentDescription 回到底部) } } } }这里的关键是derivedStateOf的使用。isAtBottom是根据listState计算出来的派生状态它只会在实际值变化时触发重组而不是每次滚动都触发。这个优化在长列表里非常明显。LaunchedEffect的 key 里我加了messages.lastOrNull()?.content这是为了处理流式输出的情况。流式输出时消息数量不变但最后一条消息的内容在变所以需要用内容作为 key 来触发滚动。注意animateScrollToItem在流式输出高频调用时可能会出现滚动动画排队、界面抖动的问题。如果遇到这种情况可以改成scrollToItem无动画或者加一个节流逻辑比如每 100ms 最多滚动一次。3.2 键盘弹出时的布局适配聊天界面另一个经典问题是键盘弹出时输入框要跟着上移消息列表要相应缩短而不是被键盘遮住。在Activity的windowSoftInputMode设置为adjustResize的前提下Compose 里可以用WindowInsets.ime来处理Column( modifier Modifier .fillMaxSize() .imePadding() ) { MessageList( messages messages, modifier Modifier.weight(1f) ) ChatInputBar(onSend { /* ... */ }) }imePadding()会自动把 IME输入法的高度作为 padding 加到底部输入框就会自然上移。这个 API 在 Compose 1.2 之后已经比较稳定了但不同厂商的 ROM 表现可能有差异建议在真机上多测几款。提示如果imePadding()在你的项目里表现异常可以检查一下Activity是否设置了WindowCompat.setDecorFitsSystemWindows(window, false)。这个设置跟imePadding()是配套使用的缺一不可。3.3 长列表的性能优化AI 聊天记录可能很长几百条消息是常态。LazyColumn本身已经做了懒加载但还有几个优化点key 的稳定性items的 key 必须用消息 id不能用索引。用索引的话插入新消息会导致所有 item 的状态错乱。contentType如果消息类型多样文本、图片、代码块给items加contentType参数Compose 会为不同类型复用不同的组合提升复用效率。避免在 item 内部做重计算Markdown 解析、语法高亮这些操作要么用remember缓存要么放到 ViewModel 里预处理。限制最大消息数如果消息超过 500 条考虑做分页加载或者截断不要一次性全部塞进列表。4. 常见问题与排查技巧实录这一部分是我在实际开发和社区反馈里整理出来的高频问题。每个问题都附上排查思路和解决方案希望能帮你少走弯路。4.1 流式输出时界面卡顿现象AI 回复的时候界面明显掉帧滚动不流畅。排查思路先看是不是在主线程做了重计算。Markdown 解析、语法高亮、正则匹配这些都是嫌疑对象。再看重组范围是不是过大。如果整个列表都在重组而不是只有最后一条消息在重组那性能肯定好不了。最后看状态更新频率。如果每个 token 都触发一次状态更新而 token 到达速度又很快那重组次数会爆炸。解决方案把 Markdown 解析放到Dispatchers.Default用produceState或者LaunchedEffect异步处理。用derivedStateOf缩小重组范围确保只有依赖变化的部分才重组。对状态更新做节流比如每 50ms 合并一次更新而不是每个 token 都更新。4.2 消息气泡宽度异常现象短消息的气泡也占满整行或者长消息的气泡超出了屏幕边界。排查思路Compose 的Box默认是fillMaxWidth的如果不加限制子元素会被拉伸。解决方案Box( modifier Modifier.fillMaxWidth(), contentAlignment if (isUser) Alignment.CenterEnd else Alignment.CenterStart ) { Surface( modifier Modifier.widthIn(max 280.dp), // ... ) { /* ... */ } }关键是widthIn(max ...)和contentAlignment的配合。widthIn限制最大宽度contentAlignment控制气泡在行内的对齐方式。4.3 键盘弹出后输入框被遮挡现象点击输入框键盘弹出但输入框被键盘盖住了。排查思路检查AndroidManifest.xml里对应 Activity 的windowSoftInputMode是不是adjustResize。检查是否调用了WindowCompat.setDecorFitsSystemWindows(window, false)。检查布局里是否用了imePadding()。解决方案这三个条件必须同时满足。缺任何一个imePadding()都不会生效。4.4 常见问题速查表问题现象可能原因解决方案流式输出卡顿主线程重计算异步解析 状态节流气泡宽度异常缺少宽度限制widthIn(max 280.dp)键盘遮挡输入框窗口模式配置错误adjustResizeimePadding()列表滚动错乱key 不稳定用消息 id 做 key光标位置不对光标放在 Column 外部光标移入内容 Column 内部代码块无法横向滚动缺少horizontalScroll给代码块加横向滚动修饰符深色模式颜色异常硬编码颜色值用MaterialTheme.colorScheme消息重复渲染状态提升不当检查remember的 key提示这个表格建议收藏遇到问题先对照排查能省下大量调试时间。4.5 几个容易被忽略的细节时间戳的显示。聊天界面通常需要显示消息时间但不需要每条都显示。常见的做法是相邻消息间隔超过 5 分钟才显示时间戳。这个逻辑要在数据预处理阶段做好不要放在 UI 层。错误消息的重试。AI 请求失败是常态错误消息旁边要有一个重试按钮。重试的时候要把这条消息的状态改回SENDING并重新发起请求。注意不要重复插入消息而是更新原消息的状态。长按复制。用户经常需要复制 AI 的回复。用combinedClickable实现长按弹菜单菜单里放“复制”选项。复制的内容应该是纯文本去掉 Markdown 标记。空状态处理。新会话开始时消息列表是空的。这时候应该显示一个引导页而不是一片空白。引导页可以放一些示例问题点击后自动填入输入框。5. 组件库的扩展性与主题定制一个组件库能不能被长期使用很大程度上取决于它的扩展性。如果用户想改个颜色、换个字体、加个自定义消息类型都要改源码那这个库的生命周期不会太长。5.1 主题系统的设计我的做法是提供一个ChatTheme组合局部CompositionLocal把所有可定制的视觉参数集中管理data class ChatThemeData( val userBubbleColor: Color, val assistantBubbleColor: Color, val userBubbleShape: Shape, val assistantBubbleShape: Shape, val bubbleMaxWidth: Dp, val messageSpacing: Dp, val inputBarHeight: Dp ) val LocalChatTheme compositionLocalOf { ChatThemeData(...) } Composable fun ChatTheme( data: ChatThemeData ChatThemeData.default(), content: Composable () - Unit ) { CompositionLocalProvider(LocalChatTheme provides data) { content() } }用户只需要在根节点包一层ChatTheme传入自定义的ChatThemeData整个组件库的视觉风格就变了。不需要改任何组件内部代码。5.2 自定义消息类型的扩展组件库内置了文本消息、代码块消息但用户可能还需要图片消息、文件消息、卡片消息。扩展方式应该是开放的Composable fun MessageBubble( message: ChatMessage, customContent: (Composable (ChatMessage) - Unit)? null ) { // ... if (customContent ! null message.role MessageRole.CUSTOM) { customContent(message) } else { MessageContent(message) } }通过传入customContent插槽用户可以渲染任意类型的消息内容而不需要修改组件库源码。5.3 状态管理的解耦组件库不应该强制用户使用某种状态管理方案。我的设计是组件库只接收数据和回调不持有状态。Composable fun ChatScreen( messages: ListChatMessage, inputText: String, onInputChange: (String) - Unit, onSend: () - Unit, onRetry: (String) - Unit ) { // ... }这样用户可以用ViewModel、Presenter、甚至Redux来管理状态组件库完全不关心。这种“无状态”的设计让组件库的适用范围大大扩展。注意无状态设计意味着组件库内部不能有remember的业务状态只能有 UI 状态比如滚动位置、动画进度。这个边界要守住否则组件库会变得越来越重。6. 从组件库到产品落地时的经验总结组件库写完之后真正把它用到产品里还会遇到一些组件库层面解决不了的问题。这部分我分享几个实际落地时的经验。6.1 网络层与 UI 层的契约流式输出的网络层通常用 SSEServer-Sent Events或者 WebSocket。不管用哪种UI 层需要的都是一个FlowString。网络层应该把协议细节封装掉只暴露一个流式的文本流。interface ChatRepository { fun sendMessage(content: String): FlowString }UI 层订阅这个 Flow每收到一个 chunk就更新对应消息的content。这个契约要提前定好不然后面改起来很痛苦。6.2 中断与取消的处理用户可能在 AI 回复到一半的时候点击“停止生成”。这时候需要取消网络请求的订阅。把消息状态从STREAMING改成COMPLETED。保留已经生成的内容不要清空。取消订阅用Job.cancel()或者Flow的takeWhile都可以。关键是状态要同步更新否则光标会一直闪。6.3 多轮对话的上下文管理AI 对话通常需要携带历史消息作为上下文。但历史消息不能无限增长否则 token 消耗会爆炸。常见的策略是保留最近 N 轮对话比如 10 轮。或者按 token 数量截断保留最近的 M 个 token。系统提示词System Prompt始终保留。这个逻辑应该在 ViewModel 或者 Repository 层做不要放在 UI 层。UI 层只负责展示完整的消息列表发送请求时由上层决定带哪些上下文。6.4 性能监控与优化上线之后建议加一些性能埋点首字延迟从发送到收到第一个 token 的时间。流式输出的平均帧率。消息列表的滚动帧率。内存占用长会话下的内存增长曲线。这些数据能帮你发现很多在开发阶段注意不到的问题。比如首字延迟过高可能是网络层的问题滚动帧率低可能是列表 item 太重。我个人在实际操作中的体会是AI 组件库的价值不在于代码有多复杂而在于它把那些琐碎但容易出错的交互细节都处理好了。流式渲染的节流、滚动行为的边界条件、键盘适配的兼容性、Markdown 渲染的性能……这些东西单独看都不难但全部凑在一起就是一个相当可观的工程量。有一个经过验证的组件库兜底团队可以把精力集中在业务逻辑和产品体验上而不是反复造轮子。最后再分享一个小技巧组件库的 API 设计尽量用“插槽”而不是“配置项”。配置项是封闭的用户只能在你预设的范围内定制插槽是开放的用户可以塞任何东西进去。比如消息气泡的内容区域与其提供textStyle、maxLines、overflow一堆参数不如直接暴露一个content: Composable () - Unit插槽让用户自己决定怎么渲染。这样组件库的维护成本会低很多用户的自由度也更大。