这两三年做 Android 的开发者应该都有同感AI 功能已经不是接不接的问题而是怎么接得又快又稳。但真上手你会发现最耗时的从来不是调模型接口而是围绕模型交互搭 UI。打字机效果、思考中动画、流式消息里的 Markdown 渲染、错误重试、多模态消息混合展示——这套东西在传统 UI 开发里没有现成范式每个团队都在用自己的方式重复造轮子。所以当 Android Compose 生态里终于出现专门的 AI 组件库时我的第一反应是该来的总算来了。这篇文章不打算写成某个框架的官方文档而是以一个实际使用者的视角聊聊这类组件库到底解决了什么问题、核心能力怎么拆、接入的时候要注意哪些坑、以及什么样的项目适合引入。如果你正打算在 App 里加一个 AI 对话界面或者已经在用 Compose 做 AI 相关改造这篇文章应该能帮你少走不少弯路。1. AI 交互和传统 UI 开发不在一个维度三个不确定性先说一个我在多个项目里反复验证过的结论AI 交互页面的开发难度比传统列表页、表单页高一个数量级。这不是说单行代码多复杂而是整个 UI 设计的思考模式需要换一遍。传统界面是确定性渲染数据到位、状态枚举清楚、交互路径固定RecyclerView 刷新一下页面就稳定了。但 AI 交互天然带着三个不确定性直接冲击了我们习惯的那套开发模型。1.1 不确定性一响应时间不可控用户发一句话出去模型要经过网络传输、排队、推理、流式返回最短两三秒长则十几秒甚至更久。中间这段时间界面必须保持一个合理的等待状态而且不能是那种干巴巴的转圈。用户需要看到系统正在思考的反馈最好还能感知到它真的在动。很多团队第一次做这里就翻车——把 loading 状态做成一刀切转圈转到底才一次性渲染结果体验非常差用户等 5 秒以上就会觉得它卡死了。行业里普遍接受的做法是用流式输出缓解等待焦虑第一个字越快出来越好哪怕后面生成得很慢用户也会觉得系统是活的。这也是为什么打字机效果在 AI 组件库里面不是装饰而是核心体验的一部分。1.2 不确定性二内容形态不可控传统 UI 的字段长度、图片尺寸、文本行数设计和开发在排期阶段就定死了。AI 的输出完全不确定一句话可能只回答好的也可能给你输出三千字的分析中间还夹着 Markdown 表格、代码块、多级列表。这就要求 UI 组件不仅要能承载任意长度的文本还得懂 Markdown 渲染、代码高亮、表格布局。更进一步现在的模型还支持图片识别、文件上传、多模态回复内容载体种类越来越多。1.3 不确定性三内容边界不可控流式输出意味着你永远不知道消息什么时候结束。普通界面只需要处理完整数据AI 界面则要处理无数个中间态收到半个字、收到半段代码、收到一个还没闭合的 Markdown 标记、模型中途停止、网络中断、上下文超限……这些情况都会以增量文本的形式堆到你面前。如果把这些中间态都当成正常状态来处理UI 的逻辑复杂度会爆炸。我的观察是成熟的 AI 组件库本质上做了一件事把这三种不确定性封装起来向上层暴露一个相对稳定的状态模型。开发者只需要关心有没有新增量和消息处于什么阶段剩下的 UI 呈现细节由组件层消化。这个思路贯穿了组件库的几乎所有 API 设计。2. 组件库的能力地图它提供了什么、边界在哪里很多人一听到AI 组件库下意识会以为它是个 AI SDK。这种理解不太对至少我接触到的 Compose 版本 AI 组件库定位非常明确管 UI不管模型。也就是说你可以对接任何后端的模型接口、任何厂商的推理服务组件库只负责把你喂给它的流式数据变成界面。这个边界意识很重要它决定了你引入这个库之后不会被任何模型厂商绑定。从能力上看一个成熟的 Compose AI 组件库通常会覆盖下面这几块模块解决的问题典型使用场景流式文本渲染增量文本到 UI 的可靠映射含打字机光标、Markdown、代码高亮对话回复、内容生成AI 会话容器消息列表 输入区 语音入口的一体化布局聊天助手、客服问答思考过程组件展示模型的推理链路支持折叠展开深度问答、复杂任务状态反馈组件思考中、生成中、工具调用、中断重试所有 AI 交互场景多模态消息文本 / 图片 / 文件的混合展示与布局多模态助手、文档问答2.1 流式文本渲染核心中的核心流式文本渲染是这类组件库和普通文本控件最本质的区别。普通 TextView 拿到一次性字符串就能布局流式文本组件却要持续接收增量片段并保证每个片段都正确呈现在界面上。这里背后有两件难事一个是增量文本的拼接和边界处理另一个是 Markdown 的增量解析。增量整治还好说麻烦的是 Markdown。模型通常是一个字一个字地把 Markdown 吐出来你收到一段不完整的时要不要提前渲染成代码块样式收到半个**加粗标记时怎么处理如果每次增量都重新解析全量 Markdown那性能会迅速崩掉如果解析得太激进又会看到大量格式闪烁。有经验的组件库会做节流渲染比如每 100~200ms 或每帧最多解析一次同时对未闭合的代码块做占位渲染等它闭合后再一次性高亮。这些细节自己从头写的话没有一两周磨不出来。2.2 会话容器和状态反馈省掉重复劳动的大头消息列表的双层气泡布局、输入框与发送按钮的联动、新消息到达时自动滚动到底部、生成过程中的隐藏式重试入口……这些交互逻辑在传统聊天 UI 里也算熟悉但 AI 场景给它加了一堆新状态思考中、工具调用中、流式生成中、出错、重试、停止生成。每个状态都有对应的视觉呈现。组件库会把这些状态机封装好开发者只需要往状态对象里写值界面自己切换省掉的不只是代码还有测试用例。2.3 组件库的定制度你需要关心扩展点大多数这类库不会把你锁死在默认外观上。常见做法是提供 Composable 插槽允许你替换消息气泡、输入框、甚至整个会话容器的局部样式。你在评估一个组件库的时候建议先看它的定制扩展点是否够用——尤其是有设计团队的项目UI 稿里大概率不会接受一套标准库样式直接上线。3. 接入实战半小时跑通一个带流式输出的对话页理论讲再多不如跑通一个页面来得实在。这里我用一个模拟项目 X 演示接入链路API 名字如果你用的库不一样可能会有差异但数据流的走向是一致的理解了这个链路换哪个库都能快速上手。3.1 添加依赖和基础配置假设组件库已经发布到了某个 Maven 仓库你的模块 build.gradle 里加上implementation(com.example.ai:compose-ai:0.1.0)初始化通常在 Application 的onCreate里做一次配置主题色、代码高亮风格、默认的渲染节流窗口class App : Application() { override fun onCreate() { super.onCreate() ComposeAI.init { codeTheme CodeTheme.DEFAULT renderThrottleMillis 150 defaultTextStyle TextStyle(fontSize 16.sp) } } }renderThrottleMillis 150的意思是增量文本到达后最多每 150ms 触发一次 UI 刷新。太短会频繁重组太长会感觉响应迟钝150ms 是我个人用下来比较平衡的值。3.2 写一个最简可运行的聊天页面Composable fun AiChatRoute(viewModel: AiChatViewModel viewModel()) { val chatState rememberAIChatState() AIChatScreen( state chatState, onSend { input - viewModel.sendMessage(input) } ) }AIChatScreen里面已经封装好了消息列表、输入框、思考状态、自动滚动这些内容你不需要自己拼布局。rememberAIChatState返回的可变状态对象是UI 组件层和业务逻辑层之间的桥梁。AiChatViewModel里做的是典型的流式数据转发class AiChatViewModel : ViewModel() { val chatState AIChatState() fun sendMessage(input: String) { chatState.addUserMessage(input) chatState.markThinking() viewModelScope.launch { val replyId chatState.createAssistantMessage() repository.streamChat( input input, onDelta { delta - chatState.appendDelta(replyId, delta) }, onDone { chatState.finishMessage(replyId) }, onError { e - chatState.markError(replyId, e) } ) } } }消息流转链路非常清晰用户在输入框打字 → 发送 → 用户消息先上屏 → 状态切成思考中 → 创建一条空的助手消息 → 远端模型开始流式返回 → 每收到一段增量文本就拼到对应消息后面 → 结束后标记完成出错则标记错误。3.3 数据流设计的关键单一状态源我见过不少团队在接入组件库时犯同一个错误把增量文本放在 ViewModel 里维护了一个MutableStateFlowString然后又在 Composable 里单独维护一个完整消息列表两边同步改来改去最后状态错乱。正确做法是让AIChatState成为唯一事实来源它内部维护消息列表和每一条消息的当前内容所有 UI 组件只消费它暴露出来的StateFlow。业务层只调用它的方法追加数据不直接操作 UI。这样即便消息数量很大、状态切换频繁也能把复杂度限制在可控范围内。4. 流式输出与重组状态管理的正确姿势流式输出是让 Compose 性能翻车的高发区所以单独拿出来详细讲。核心原则一句话高频更新的状态要尽量局部化不要让整个页面跟着每次 token 刷新。Compose 的声明式模型决定了状态一变读了这个状态的 Composable 就会重组。如果你把整个会话状态放在页面最顶层那么每收到一个 token整个消息列表、输入框、状态栏全部重组一遍中端机上很快就能感受到明显卡顿。4.1 生命周期感知的收集方式在 Compose 里收集流现在的主流方案是collectAsStateWithLifecycle它只在生命周期处于 STARTED 以上时收集数据避免页面在后台时还在做无谓的重组。用普通collectAsState会在后台也触发重组对长会话场景来说电量消耗和掉帧都是实打实的。val uiState by viewModel.chatState.stateFlow.collectAsStateWithLifecycle()4.2 消息级重组隔离好的 AI 组件库会在内部做消息级隔离。也就是新 Delta 到达时只有正在更新的那条消息气泡发生重组其他历史消息和输入区不受影响。这意味着消息列表的key设计必须用稳定的消息 ID不能只依赖索引。官方 LazyColumn 文档里也强调过稳定 key 能大幅降低重组和滚动错乱的概率。4.3 渲染节流的性能收益我在一个模拟项目里做过一次简单压测让模型持续输出一段 800 字的回答消息列表同时承载之前的 60 条历史消息。不开启节流时中端机帧率掉到 30fps 以下快速滑动列表时有明显掉帧。开启 150ms 节流后帧率稳定在 55fps 以上肉眼基本感受不到卡顿。差距非常明显。这里补充一个原理流式更新在渲染层面其实是插入文本、重新测量、重新绘制。如果 token 到达频率高于一帧的时间16.6ms每帧可能要处理多次文本插入渲染队列积压卡顿就是这么来的。时间窗口节流相当于把多次内存态更新合并为一次 UI 刷新本质是拿小幅度延迟换流畅度。UI 上用户几乎感知不到因为模型生成本身就有停顿150ms 的合并延迟远小于人类能感知的交互延迟。4.4 长消息的拆分策略另一种优化思路是把一条超长的流式消息拆成多个逻辑段来管理。比如一段 3000 字的回答模型输出过程可以分成 5~6 个片段组件库内部按片段分批渲染而不是每 10 个 token 就整体重建一次文本布局。这种增量分段 局部更新的设计配合节流窗口才能把长时间流式输出场景的性能压住。5. 五个真实踩坑记录与排查链路接入过程中我没少踩坑挑几个有代表性的记录下来每个都附上排查思路你直接照着排查能省不少时间。5.1 自动滚动被新消息反复打断现象是用户正在往上翻历史消息新回复一到列表强行被拽回底部阅读体验被反复打断。我一开始以为这是很简单的功能加个scrollToItem(lastIndex)就行实际上什么时候不该滚比怎么滚更重要。排查链路分三步。第一步确认自动滚动的触发条件。第二步观察用户的滚动方向——如果用户正在向上滑动阅读历史说明他主动离开了底部区域。第三步加上一个距离阈值判断val shouldAutoScroll remember { derivedStateOf { val layoutInfo listState.layoutInfo val lastVisibleItem layoutInfo.visibleItemsInfo.lastOrNull() val totalItems layoutInfo.totalItemsCount // 距离底部小于 200dp 时才触发自动滚动 lastVisibleItem ! null lastVisibleItem.index totalItems - 3 lastVisibleItem.offset 200.dp.roundToPx() } }这个距底部小于 200dp的阈值来自实测太激进会打断阅读太保守会把新消息遮住。体验调平之后用户上翻历史时新消息静默累积回到底部附近才猛然滚动到底既不错过内容也不打扰阅读。5.2 中文文本偶尔出现半个乱码字符流式对话偶尔会出现这是典型的 UTF-8 字符边界问题。后端按字节流发送数据一个中文 UTF-8 字符占 3 个字节缓冲区可能恰好在第二个字节处切断了前端拿到残缺字节解码就成了乱码。排查时我先抓了原始流数据发现确实在字节级别存在截断然后写了一个缓冲工具类检测不完整的 UTF-8 序列等下一次增量到达时拼接完成再放入状态fun decodeIncrementalText(buffer: ByteArray, bytes: Int): String { // 检查末尾是否有未完成的 UTF-8 序列 var cut bytes for (i in bytes - 1 downTo maxOf(0, bytes - 3)) { if (i 0) break val b buffer[i].toInt() and 0xFF if (b 0x80) break if (b and 0xC0 0xC0) { cut i; break } } val chunk buffer.copyOfRange(0, cut) remainder buffer.copyOfRange(cut, bytes) return String(chunk, Charsets.UTF_8) }这段逻辑强烈建议你在接入流式接口时统一放到底层 SDK 里不要在 UI 层处理字节否则每一处拼接点都要重复这个校验容易出现漏网之鱼。5.3 Markdown 代码块渲染闪烁流式生成代码块时页面会反复闪动。这是因为未闭合的代码块标记在每次增量到来时都被重新解析视觉效果就是内容一会儿变宽一会儿变窄背景色闪来闪去。我加了日志确认问题出在部分代码块被当成完整代码块反复处理。解决方案有两层。第一层是组件库提供的占位渲染——代码块未闭合前用等宽字体加灰色底纹先占住区域闭合后再交给代码高亮器统一上色。第二层是调大解析节流窗口让代码块的解析频率降下来避免一帧内多次测量布局。5.4 深色模式下代码高亮几乎看不清默认配置里代码高亮色板是针对浅色主题设计的切到深色模式后文字对比度很低。排查时发现主题对象没有从全局透传到渲染器。解决方案是在初始化时显式传入深色主题的colorScheme或者直接使用组件库提供的isSystemInDarkTheme自适应配色。这种问题最容易在浅色模式测试通过就上线的项目里埋雷建议你在排期里就把深色模式适配当成独立测试用例。5.5 转屏之后会话内容丢失一开始我把chatState放在 Composable 层用remember持有Activity 旋转重建时状态全部清零用户已经聊了半小时的上下文瞬间没了。排查方向很明确凡是需要跨配置变更存活的会话状态必须提升到 ViewModel 层。我改成了viewModelScope内的AIChatState并在SavedStateHandle里持久化关键消息元数据历史消息数量大时走数据库缓存。这里想提醒一句对话上下文对 AI 功能来说不是临时 UI 状态它本身就是核心业务数据长期来看建议做持久化否则进程一旦被杀用户会直接失去一段完整对话。6. 引入之前想清楚的三件事项目要不要引入这样一个组件库不是看它功能多不多就能决定的。我的经验是先回答清楚三个问题再决定要不要用。6.1 你们有没有自研的对话 UI 体系如果团队已经沉淀了一套成熟的聊天 UI 框架且经过多版本迭代那突然引入一个 AI 组件库会造成两套体系共存维护成本可能不降反升。反过来如果你们是第一次做 AI 对话功能或者老聊天体系本身已经很老迈那直接用组件库的完整能力比从零维护更划算。迁移成本评估时建议做一个最小可行场景测试只把 AI 助手页切换过去跑通再扩大范围。6.2 设计稿的定制程度组件库默认样式一般能满足通用对话场景但设计团队通常不会接受标准库样式直接上线。评估时重点看三件事消息气泡是否支持自定义插槽、输入区是否可替换 Composable、代码高亮能否配置主题。如果三样都支持定制空间基本够用如果只有颜色可改而设计稿里有大量非标准布局建议慎重考虑引入。6.3 依赖体量与维护活跃度这类组件库通常有一定的依赖体积会包含 Markdown 解析、代码高亮、文本测量等底层库对 APK 体积敏感的项目要提前评估。另外AI 交互是高频演进领域库的 API 迭代速度也比较快。你至少应该看一眼最近版本的发布时间、issue 回复速度、以及是否有企业级使用案例。一个长期不更新的库在 AI 场景下风险比普通 UI 库更高。7. 最后分享几个提升体验的小配置接入完成后有三组细节配置我强烈建议你做对最终体验影响极大。第一代码高亮语言兜底。模型输出的代码块经常不标注语言类型甚至标注得很模糊。我当时给组件库配了一个按内容推断语言 默认 kotlin 兜底的策略代码块显示效果立刻上升了一个档次。第二输入区的停止生成按钮。长回复生成到一半用户想打断这时候必须有一个易触达的停止按钮。从实际反馈来看这个按钮的使用频率比我想象中高得多。组件库会在模型流结束时自动隐藏它但你要确保它也覆盖网络中断等异常结束路径否则按钮会卡在界面上。第三消息留白和行距。模型输出的长文本如果按默认排版密度渲染阅读起来非常吃力。我给助手消息设置了 1.6 倍行高、段后间距 12dp把 Markdown 列表和标题的层次感保留出来。可能有人觉得这是细节但在真实对话中用户要长时间盯着文本看这个细节直接关系到读得下去还是读几行就想退出。最后再分享一点整体感受。我把一个老项目里的消息页面迁移到这套 AI 组件库之后最大的收获不是省了多少模板代码而是团队终于有了统一的 AI 交互语言。此前每个人都在按照自己的理解画思考中和流式回复的样式效果五花八门。现在大家讨论的是消息状态机怎么扩展重试策略怎么设计这类真正影响产品质量的问题。如果你也在考虑给 App 加一个 AI 对话入口我的建议是先拿一个中等复杂度的场景试水别一上来就追求大而全。组件库解决的是通用问题和重复劳动真正让产品产生差异化的定制能力还是得靠自己动手补。跑通一个页面只是开始把状态管理、异常处理、性能调优这层补齐了才算是真正把 AI 交互接稳了。 
长河君 · 2026/10/20 22:14:20 · 阅读 1.2k Compose AI 组件库实战：流式文本渲染与状态管理指南
这两三年做 Android 的开发者应该都有同感AI 功能已经不是接不接的问题而是怎么接得又快又稳。但真上手你会发现最耗时的从来不是调模型接口而是围绕模型交互搭 UI。打字机效果、思考中动画、流式消息里的 Markdown 渲染、错误重试、多模态消息混合展示——这套东西在传统 UI 开发里没有现成范式每个团队都在用自己的方式重复造轮子。所以当 Android Compose 生态里终于出现专门的 AI 组件库时我的第一反应是该来的总算来了。这篇文章不打算写成某个框架的官方文档而是以一个实际使用者的视角聊聊这类组件库到底解决了什么问题、核心能力怎么拆、接入的时候要注意哪些坑、以及什么样的项目适合引入。如果你正打算在 App 里加一个 AI 对话界面或者已经在用 Compose 做 AI 相关改造这篇文章应该能帮你少走不少弯路。1. AI 交互和传统 UI 开发不在一个维度三个不确定性先说一个我在多个项目里反复验证过的结论AI 交互页面的开发难度比传统列表页、表单页高一个数量级。这不是说单行代码多复杂而是整个 UI 设计的思考模式需要换一遍。传统界面是确定性渲染数据到位、状态枚举清楚、交互路径固定RecyclerView 刷新一下页面就稳定了。但 AI 交互天然带着三个不确定性直接冲击了我们习惯的那套开发模型。1.1 不确定性一响应时间不可控用户发一句话出去模型要经过网络传输、排队、推理、流式返回最短两三秒长则十几秒甚至更久。中间这段时间界面必须保持一个合理的等待状态而且不能是那种干巴巴的转圈。用户需要看到系统正在思考的反馈最好还能感知到它真的在动。很多团队第一次做这里就翻车——把 loading 状态做成一刀切转圈转到底才一次性渲染结果体验非常差用户等 5 秒以上就会觉得它卡死了。行业里普遍接受的做法是用流式输出缓解等待焦虑第一个字越快出来越好哪怕后面生成得很慢用户也会觉得系统是活的。这也是为什么打字机效果在 AI 组件库里面不是装饰而是核心体验的一部分。1.2 不确定性二内容形态不可控传统 UI 的字段长度、图片尺寸、文本行数设计和开发在排期阶段就定死了。AI 的输出完全不确定一句话可能只回答好的也可能给你输出三千字的分析中间还夹着 Markdown 表格、代码块、多级列表。这就要求 UI 组件不仅要能承载任意长度的文本还得懂 Markdown 渲染、代码高亮、表格布局。更进一步现在的模型还支持图片识别、文件上传、多模态回复内容载体种类越来越多。1.3 不确定性三内容边界不可控流式输出意味着你永远不知道消息什么时候结束。普通界面只需要处理完整数据AI 界面则要处理无数个中间态收到半个字、收到半段代码、收到一个还没闭合的 Markdown 标记、模型中途停止、网络中断、上下文超限……这些情况都会以增量文本的形式堆到你面前。如果把这些中间态都当成正常状态来处理UI 的逻辑复杂度会爆炸。我的观察是成熟的 AI 组件库本质上做了一件事把这三种不确定性封装起来向上层暴露一个相对稳定的状态模型。开发者只需要关心有没有新增量和消息处于什么阶段剩下的 UI 呈现细节由组件层消化。这个思路贯穿了组件库的几乎所有 API 设计。2. 组件库的能力地图它提供了什么、边界在哪里很多人一听到AI 组件库下意识会以为它是个 AI SDK。这种理解不太对至少我接触到的 Compose 版本 AI 组件库定位非常明确管 UI不管模型。也就是说你可以对接任何后端的模型接口、任何厂商的推理服务组件库只负责把你喂给它的流式数据变成界面。这个边界意识很重要它决定了你引入这个库之后不会被任何模型厂商绑定。从能力上看一个成熟的 Compose AI 组件库通常会覆盖下面这几块模块解决的问题典型使用场景流式文本渲染增量文本到 UI 的可靠映射含打字机光标、Markdown、代码高亮对话回复、内容生成AI 会话容器消息列表 输入区 语音入口的一体化布局聊天助手、客服问答思考过程组件展示模型的推理链路支持折叠展开深度问答、复杂任务状态反馈组件思考中、生成中、工具调用、中断重试所有 AI 交互场景多模态消息文本 / 图片 / 文件的混合展示与布局多模态助手、文档问答2.1 流式文本渲染核心中的核心流式文本渲染是这类组件库和普通文本控件最本质的区别。普通 TextView 拿到一次性字符串就能布局流式文本组件却要持续接收增量片段并保证每个片段都正确呈现在界面上。这里背后有两件难事一个是增量文本的拼接和边界处理另一个是 Markdown 的增量解析。增量整治还好说麻烦的是 Markdown。模型通常是一个字一个字地把 Markdown 吐出来你收到一段不完整的时要不要提前渲染成代码块样式收到半个**加粗标记时怎么处理如果每次增量都重新解析全量 Markdown那性能会迅速崩掉如果解析得太激进又会看到大量格式闪烁。有经验的组件库会做节流渲染比如每 100~200ms 或每帧最多解析一次同时对未闭合的代码块做占位渲染等它闭合后再一次性高亮。这些细节自己从头写的话没有一两周磨不出来。2.2 会话容器和状态反馈省掉重复劳动的大头消息列表的双层气泡布局、输入框与发送按钮的联动、新消息到达时自动滚动到底部、生成过程中的隐藏式重试入口……这些交互逻辑在传统聊天 UI 里也算熟悉但 AI 场景给它加了一堆新状态思考中、工具调用中、流式生成中、出错、重试、停止生成。每个状态都有对应的视觉呈现。组件库会把这些状态机封装好开发者只需要往状态对象里写值界面自己切换省掉的不只是代码还有测试用例。2.3 组件库的定制度你需要关心扩展点大多数这类库不会把你锁死在默认外观上。常见做法是提供 Composable 插槽允许你替换消息气泡、输入框、甚至整个会话容器的局部样式。你在评估一个组件库的时候建议先看它的定制扩展点是否够用——尤其是有设计团队的项目UI 稿里大概率不会接受一套标准库样式直接上线。3. 接入实战半小时跑通一个带流式输出的对话页理论讲再多不如跑通一个页面来得实在。这里我用一个模拟项目 X 演示接入链路API 名字如果你用的库不一样可能会有差异但数据流的走向是一致的理解了这个链路换哪个库都能快速上手。3.1 添加依赖和基础配置假设组件库已经发布到了某个 Maven 仓库你的模块 build.gradle 里加上implementation(com.example.ai:compose-ai:0.1.0)初始化通常在 Application 的onCreate里做一次配置主题色、代码高亮风格、默认的渲染节流窗口class App : Application() { override fun onCreate() { super.onCreate() ComposeAI.init { codeTheme CodeTheme.DEFAULT renderThrottleMillis 150 defaultTextStyle TextStyle(fontSize 16.sp) } } }renderThrottleMillis 150的意思是增量文本到达后最多每 150ms 触发一次 UI 刷新。太短会频繁重组太长会感觉响应迟钝150ms 是我个人用下来比较平衡的值。3.2 写一个最简可运行的聊天页面Composable fun AiChatRoute(viewModel: AiChatViewModel viewModel()) { val chatState rememberAIChatState() AIChatScreen( state chatState, onSend { input - viewModel.sendMessage(input) } ) }AIChatScreen里面已经封装好了消息列表、输入框、思考状态、自动滚动这些内容你不需要自己拼布局。rememberAIChatState返回的可变状态对象是UI 组件层和业务逻辑层之间的桥梁。AiChatViewModel里做的是典型的流式数据转发class AiChatViewModel : ViewModel() { val chatState AIChatState() fun sendMessage(input: String) { chatState.addUserMessage(input) chatState.markThinking() viewModelScope.launch { val replyId chatState.createAssistantMessage() repository.streamChat( input input, onDelta { delta - chatState.appendDelta(replyId, delta) }, onDone { chatState.finishMessage(replyId) }, onError { e - chatState.markError(replyId, e) } ) } } }消息流转链路非常清晰用户在输入框打字 → 发送 → 用户消息先上屏 → 状态切成思考中 → 创建一条空的助手消息 → 远端模型开始流式返回 → 每收到一段增量文本就拼到对应消息后面 → 结束后标记完成出错则标记错误。3.3 数据流设计的关键单一状态源我见过不少团队在接入组件库时犯同一个错误把增量文本放在 ViewModel 里维护了一个MutableStateFlowString然后又在 Composable 里单独维护一个完整消息列表两边同步改来改去最后状态错乱。正确做法是让AIChatState成为唯一事实来源它内部维护消息列表和每一条消息的当前内容所有 UI 组件只消费它暴露出来的StateFlow。业务层只调用它的方法追加数据不直接操作 UI。这样即便消息数量很大、状态切换频繁也能把复杂度限制在可控范围内。4. 流式输出与重组状态管理的正确姿势流式输出是让 Compose 性能翻车的高发区所以单独拿出来详细讲。核心原则一句话高频更新的状态要尽量局部化不要让整个页面跟着每次 token 刷新。Compose 的声明式模型决定了状态一变读了这个状态的 Composable 就会重组。如果你把整个会话状态放在页面最顶层那么每收到一个 token整个消息列表、输入框、状态栏全部重组一遍中端机上很快就能感受到明显卡顿。4.1 生命周期感知的收集方式在 Compose 里收集流现在的主流方案是collectAsStateWithLifecycle它只在生命周期处于 STARTED 以上时收集数据避免页面在后台时还在做无谓的重组。用普通collectAsState会在后台也触发重组对长会话场景来说电量消耗和掉帧都是实打实的。val uiState by viewModel.chatState.stateFlow.collectAsStateWithLifecycle()4.2 消息级重组隔离好的 AI 组件库会在内部做消息级隔离。也就是新 Delta 到达时只有正在更新的那条消息气泡发生重组其他历史消息和输入区不受影响。这意味着消息列表的key设计必须用稳定的消息 ID不能只依赖索引。官方 LazyColumn 文档里也强调过稳定 key 能大幅降低重组和滚动错乱的概率。4.3 渲染节流的性能收益我在一个模拟项目里做过一次简单压测让模型持续输出一段 800 字的回答消息列表同时承载之前的 60 条历史消息。不开启节流时中端机帧率掉到 30fps 以下快速滑动列表时有明显掉帧。开启 150ms 节流后帧率稳定在 55fps 以上肉眼基本感受不到卡顿。差距非常明显。这里补充一个原理流式更新在渲染层面其实是插入文本、重新测量、重新绘制。如果 token 到达频率高于一帧的时间16.6ms每帧可能要处理多次文本插入渲染队列积压卡顿就是这么来的。时间窗口节流相当于把多次内存态更新合并为一次 UI 刷新本质是拿小幅度延迟换流畅度。UI 上用户几乎感知不到因为模型生成本身就有停顿150ms 的合并延迟远小于人类能感知的交互延迟。4.4 长消息的拆分策略另一种优化思路是把一条超长的流式消息拆成多个逻辑段来管理。比如一段 3000 字的回答模型输出过程可以分成 5~6 个片段组件库内部按片段分批渲染而不是每 10 个 token 就整体重建一次文本布局。这种增量分段 局部更新的设计配合节流窗口才能把长时间流式输出场景的性能压住。5. 五个真实踩坑记录与排查链路接入过程中我没少踩坑挑几个有代表性的记录下来每个都附上排查思路你直接照着排查能省不少时间。5.1 自动滚动被新消息反复打断现象是用户正在往上翻历史消息新回复一到列表强行被拽回底部阅读体验被反复打断。我一开始以为这是很简单的功能加个scrollToItem(lastIndex)就行实际上什么时候不该滚比怎么滚更重要。排查链路分三步。第一步确认自动滚动的触发条件。第二步观察用户的滚动方向——如果用户正在向上滑动阅读历史说明他主动离开了底部区域。第三步加上一个距离阈值判断val shouldAutoScroll remember { derivedStateOf { val layoutInfo listState.layoutInfo val lastVisibleItem layoutInfo.visibleItemsInfo.lastOrNull() val totalItems layoutInfo.totalItemsCount // 距离底部小于 200dp 时才触发自动滚动 lastVisibleItem ! null lastVisibleItem.index totalItems - 3 lastVisibleItem.offset 200.dp.roundToPx() } }这个距底部小于 200dp的阈值来自实测太激进会打断阅读太保守会把新消息遮住。体验调平之后用户上翻历史时新消息静默累积回到底部附近才猛然滚动到底既不错过内容也不打扰阅读。5.2 中文文本偶尔出现半个乱码字符流式对话偶尔会出现这是典型的 UTF-8 字符边界问题。后端按字节流发送数据一个中文 UTF-8 字符占 3 个字节缓冲区可能恰好在第二个字节处切断了前端拿到残缺字节解码就成了乱码。排查时我先抓了原始流数据发现确实在字节级别存在截断然后写了一个缓冲工具类检测不完整的 UTF-8 序列等下一次增量到达时拼接完成再放入状态fun decodeIncrementalText(buffer: ByteArray, bytes: Int): String { // 检查末尾是否有未完成的 UTF-8 序列 var cut bytes for (i in bytes - 1 downTo maxOf(0, bytes - 3)) { if (i 0) break val b buffer[i].toInt() and 0xFF if (b 0x80) break if (b and 0xC0 0xC0) { cut i; break } } val chunk buffer.copyOfRange(0, cut) remainder buffer.copyOfRange(cut, bytes) return String(chunk, Charsets.UTF_8) }这段逻辑强烈建议你在接入流式接口时统一放到底层 SDK 里不要在 UI 层处理字节否则每一处拼接点都要重复这个校验容易出现漏网之鱼。5.3 Markdown 代码块渲染闪烁流式生成代码块时页面会反复闪动。这是因为未闭合的代码块标记在每次增量到来时都被重新解析视觉效果就是内容一会儿变宽一会儿变窄背景色闪来闪去。我加了日志确认问题出在部分代码块被当成完整代码块反复处理。解决方案有两层。第一层是组件库提供的占位渲染——代码块未闭合前用等宽字体加灰色底纹先占住区域闭合后再交给代码高亮器统一上色。第二层是调大解析节流窗口让代码块的解析频率降下来避免一帧内多次测量布局。5.4 深色模式下代码高亮几乎看不清默认配置里代码高亮色板是针对浅色主题设计的切到深色模式后文字对比度很低。排查时发现主题对象没有从全局透传到渲染器。解决方案是在初始化时显式传入深色主题的colorScheme或者直接使用组件库提供的isSystemInDarkTheme自适应配色。这种问题最容易在浅色模式测试通过就上线的项目里埋雷建议你在排期里就把深色模式适配当成独立测试用例。5.5 转屏之后会话内容丢失一开始我把chatState放在 Composable 层用remember持有Activity 旋转重建时状态全部清零用户已经聊了半小时的上下文瞬间没了。排查方向很明确凡是需要跨配置变更存活的会话状态必须提升到 ViewModel 层。我改成了viewModelScope内的AIChatState并在SavedStateHandle里持久化关键消息元数据历史消息数量大时走数据库缓存。这里想提醒一句对话上下文对 AI 功能来说不是临时 UI 状态它本身就是核心业务数据长期来看建议做持久化否则进程一旦被杀用户会直接失去一段完整对话。6. 引入之前想清楚的三件事项目要不要引入这样一个组件库不是看它功能多不多就能决定的。我的经验是先回答清楚三个问题再决定要不要用。6.1 你们有没有自研的对话 UI 体系如果团队已经沉淀了一套成熟的聊天 UI 框架且经过多版本迭代那突然引入一个 AI 组件库会造成两套体系共存维护成本可能不降反升。反过来如果你们是第一次做 AI 对话功能或者老聊天体系本身已经很老迈那直接用组件库的完整能力比从零维护更划算。迁移成本评估时建议做一个最小可行场景测试只把 AI 助手页切换过去跑通再扩大范围。6.2 设计稿的定制程度组件库默认样式一般能满足通用对话场景但设计团队通常不会接受标准库样式直接上线。评估时重点看三件事消息气泡是否支持自定义插槽、输入区是否可替换 Composable、代码高亮能否配置主题。如果三样都支持定制空间基本够用如果只有颜色可改而设计稿里有大量非标准布局建议慎重考虑引入。6.3 依赖体量与维护活跃度这类组件库通常有一定的依赖体积会包含 Markdown 解析、代码高亮、文本测量等底层库对 APK 体积敏感的项目要提前评估。另外AI 交互是高频演进领域库的 API 迭代速度也比较快。你至少应该看一眼最近版本的发布时间、issue 回复速度、以及是否有企业级使用案例。一个长期不更新的库在 AI 场景下风险比普通 UI 库更高。7. 最后分享几个提升体验的小配置接入完成后有三组细节配置我强烈建议你做对最终体验影响极大。第一代码高亮语言兜底。模型输出的代码块经常不标注语言类型甚至标注得很模糊。我当时给组件库配了一个按内容推断语言 默认 kotlin 兜底的策略代码块显示效果立刻上升了一个档次。第二输入区的停止生成按钮。长回复生成到一半用户想打断这时候必须有一个易触达的停止按钮。从实际反馈来看这个按钮的使用频率比我想象中高得多。组件库会在模型流结束时自动隐藏它但你要确保它也覆盖网络中断等异常结束路径否则按钮会卡在界面上。第三消息留白和行距。模型输出的长文本如果按默认排版密度渲染阅读起来非常吃力。我给助手消息设置了 1.6 倍行高、段后间距 12dp把 Markdown 列表和标题的层次感保留出来。可能有人觉得这是细节但在真实对话中用户要长时间盯着文本看这个细节直接关系到读得下去还是读几行就想退出。最后再分享一点整体感受。我把一个老项目里的消息页面迁移到这套 AI 组件库之后最大的收获不是省了多少模板代码而是团队终于有了统一的 AI 交互语言。此前每个人都在按照自己的理解画思考中和流式回复的样式效果五花八门。现在大家讨论的是消息状态机怎么扩展重试策略怎么设计这类真正影响产品质量的问题。如果你也在考虑给 App 加一个 AI 对话入口我的建议是先拿一个中等复杂度的场景试水别一上来就追求大而全。组件库解决的是通用问题和重复劳动真正让产品产生差异化的定制能力还是得靠自己动手补。跑通一个页面只是开始把状态管理、异常处理、性能调优这层补齐了才算是真正把 AI 交互接稳了。