简介面向Android开发者与AI应用集成者的Kimi API流式输出实战工程聚焦大模型对话场景中逐字返回、实时渲染的接入难题帮助读者理解流式响应在移动端的完整落地路径。压缩包共813个文件、约14.99MB以flat、json、xml等配置与资源文件为主辅以dex、class、jar等编译产物以及kt源码、properties配置、gradle构建脚本和webp图片资源构成一个可直接导入Android Studio的完整工程结构。已有1233人学习下载说明该主题在移动端AI集成领域具备一定关注度。资源价值在于提供可运行的流式输出参考实现读者可据此对照请求参数构造、分块数据解析与UI增量刷新等关键环节理解SSE式响应在Android端的处理方式并借助现有目录结构与构建配置快速搭建自己的调试环境减少从零摸索的成本适合具备一定Android基础、希望将大模型能力接入移动应用的开发者参考。1. 流式输出不是玄学从一次“转圈十秒”的对话说起有个做 Android 端 AI 助手的朋友跟我吐槽用户点发送后界面要转圈十来秒才“啪”地蹦出一整段回答体验像在等一封邮件。后来他把 KIMI API 的流式输出接上同样的模型、同样的网络首字出现时间压到了一秒以内用户感知完全变了。这个项目的核心就一件事——把 KIMI 的对话接口从“一次性返回”改成“边生成边吐字”并把这套流式链路封装成 Android 端能直接调用的结构。适合两类人一是想在 App 里做打字机效果的 Android 开发者二是想搞清楚 SSE 流式响应到底怎么解析、怎么在 UI 层安全消费的后端或全栈同学。下面按“它是什么 → 怎么跑 → 怎么改”拆开讲。2. 项目定位与技术选型为什么是 SSE 而不是轮询2.1 这个项目到底解决什么问题大模型对话接口有两种返回模式。非流式是一次性把完整回答算完再返回客户端拿到的是一个完整 JSON流式则是服务端每生成一小段 token 就推一条数据下来客户端边收边渲染。KIMI 的对话接口支持后者返回格式是标准的text/event-stream也就是常说的 SSEServer-Sent Events。这个项目的价值不在于“调通一个接口”而在于把流式响应的完整生命周期管起来建立连接、逐块读取、按行切分、解析data:前缀、处理结束标记[DONE]、异常中断后的收尾。这些环节任何一个没处理好表现就是“字吐到一半卡住”“界面闪一下全没了”“连接泄漏导致下次请求失败”。项目把这些封装成可复用的流式客户端Android 层只负责把增量文本追加到 UI。技术选型上网络层用 OkHttp这是 Android 生态里最稳的 HTTP 客户端对流式响应的支持很直接——拿到ResponseBody的source()后可以按行阻塞读取不需要额外引入 SSE 库。JSON 解析用 Gson 或 kotlinx.serialization 都行取决于项目是 Java 还是 Kotlin 技术栈。UI 层用协程或回调把增量文本抛回主线程。这套组合的好处是依赖少、可控性强坏处是所有边界情况得自己兜后面避坑章节会细说。提示SSE 是单向的服务端推、客户端收不需要 WebSocket 那样的双向握手。对话场景天然适合它别为了“看起来高级”上 WebSocket复杂度白涨。2.2 目录结构长什么样项目按职责分层典型结构如下不同实现细节会有出入但分层逻辑一致kimi-stream-demo/ ├── app/ # Android 应用层 │ ├── ui/ # 对话界面、消息列表 │ └── viewmodel/ # 持有流式状态、转发增量文本 ├── core-network/ # 网络与流式解析 │ ├── KimiClient.kt # OkHttp 客户端封装 │ ├── StreamParser.kt # SSE 行解析器 │ └── model/ # 请求/响应数据类 ├── core-common/ # 通用工具、错误类型 └── build.gradle # 依赖与构建配置core-network是重点流式的所有“脏活”都在这里。app层保持薄只做状态渲染这样换 UI 框架Compose 换 View 体系时网络层不用动。core-common放统一的错误枚举比如NETWORK_ERROR、STREAM_INTERRUPTED、PARSE_ERROR方便上层做差异化提示。2.3 关键依赖与版本约束构建文件里需要的最小依赖集// app/build.gradle dependencies { implementation com.squareup.okhttp3:okhttp:4.12.0 // 流式读取核心 implementation com.squareup.okhttp3:logging-interceptor:4.12.0 // 调试用 implementation com.google.code.gson:gson:2.10.1 // JSON 解析 implementation org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.3 // 协程调度 }OkHttp 4.x 是必须的3.x 的ResponseBody.source()行为在部分场景下有差异流式读取容易踩坑。协程版本跟项目现有 Kotlin 版本对齐即可别单独升容易和 Compose 的协程依赖打架。logging-interceptor只在 debug 构建里加流式响应体很大全量打日志会拖慢调试。3. 流式链路拆解从发请求到 UI 吐字的完整代码3.1 构造请求把 stream 参数打开KIMI 对话接口的流式开关是一个请求体字段常见做法是stream: true。请求体结构大致如下data class ChatRequest( val model: String kimi-latest, // 模型标识按实际可用模型填 val messages: ListMessage, val stream: Boolean true, // 关键开关 val temperature: Double 0.7 // 采样温度0~1 之间 ) data class Message(val role: String, val content: String) fun buildRequestBody(messages: ListMessage): RequestBody { val req ChatRequest(messages messages) val json Gson().toJson(req) return json.toRequestBody(application/json.toMediaType()) }stream true是整条链路的前提漏了这个字段服务端会按非流式返回一个完整 JSON客户端按 SSE 解析就会一行都读不到表现为“请求成功但界面没反应”。temperature控制随机性做客服类应用建议调低到 0.3 左右做创意类可以到 0.8。messages里role取值通常是system、user、assistant多轮对话要把历史消息按顺序带上否则模型没有上下文。请求头里必须带鉴权信息常见是Authorization: Bearer token以及Accept: text/event-stream告诉服务端期望流式响应。token 不要硬编码在代码里放local.properties或构建配置注入这是血泪经验——硬编码的 token 进了 Git 历史清理起来很麻烦。3.2 建立连接并逐行读取核心读取逻辑用 OkHttp 的同步调用配合协程调度到 IO 线程suspend fun streamChat( messages: ListMessage, onDelta: (String) - Unit, // 每收到一段增量文本回调 onComplete: () - Unit, // 流正常结束 onError: (Throwable) - Unit // 异常回调 ) withContext(Dispatchers.IO) { val request Request.Builder() .url(https://api.example.com/v1/chat/completions) // 替换为实际接口地址 .addHeader(Authorization, Bearer $token) .addHeader(Accept, text/event-stream) .post(buildRequestBody(messages)) .build() try { client.newCall(request).execute().use { response - if (!response.isSuccessful) { onError(IOException(HTTP ${response.code})) returnuse } val source response.body?.source() ?: run { onError(IOException(empty body)) returnuse } // 按行阻塞读取直到流结束 while (!source.exhausted()) { val line source.readUtf8Line() ?: break StreamParser.parse(line)?.let { delta - withContext(Dispatchers.Main) { onDelta(delta) } } } withContext(Dispatchers.Main) { onComplete() } } } catch (e: Exception) { withContext(Dispatchers.Main) { onError(e) } } }几个关键点。execute()是同步阻塞调用必须放在Dispatchers.IO放主线程直接 ANR。use {}保证ResponseBody被关闭不关的话连接池会被占满后续请求全部超时——这是流式场景最常见的泄漏点。source.readUtf8Line()每次读一行SSE 的格式是每行以\n结尾空行表示一个事件结束所以按行读是正确姿势。source.exhausted()判断流是否读完配合readUtf8Line()返回 null 时 break双保险。onDelta回调切回主线程再更新 UI因为 OkHttp 的读取在 IO 线程直接改 UI 会崩。这里用withContext(Dispatchers.Main)逐段切换如果增量很密集每秒几十段可以考虑用Channel或Flow做背压避免主线程消息队列堆积。3.3 SSE 行解析data 前缀与 [DONE] 标记服务端推下来的每一行长这样data: {choices:[{delta:{content:你}}]}解析器要做三件事去掉data:前缀、跳过空行和注释行、识别[DONE]结束标记。object StreamParser { private const val PREFIX data: private const val DONE [DONE] fun parse(line: String): String? { val trimmed line.trim() if (trimmed.isEmpty()) return null // 空行是事件分隔跳过 if (trimmed.startsWith(:)) return null // 注释行心跳跳过 if (!trimmed.startsWith(PREFIX)) return null val payload trimmed.removePrefix(PREFIX).trim() if (payload DONE) return null // 结束标记由外层循环自然退出 return try { val obj Gson().fromJson(payload, JsonObject::class.java) obj.getAsJsonArray(choices) ?.firstOrNull() ?.asJsonObject ?.getAsJsonObject(delta) ?.get(content) ?.asString } catch (e: Exception) { null // 单行解析失败不中断整条流 } } }data:后面可能有一个空格removePrefix后要trim()。[DONE]是 OpenAI 兼容格式的结束约定KIMI 接口同样遵循遇到它直接返回 null外层循环读到流末尾自然结束。注释行以:开头是服务端发的心跳保活不处理会导致解析报错。单行 JSON 解析失败返回 null 而不是抛异常因为流式场景下偶发的半包、粘包不该让整个对话崩掉丢一段比全丢好。注意有些实现会在delta里同时带role字段第一段content可能为空。取值时判空别直接asString拿到null字符串塞进 UI。3.4 UI 层消费增量追加与状态机ViewModel 里维护一个消息列表流式过程中不断更新最后一条 assistant 消息的内容class ChatViewModel : ViewModel() { private val _messages MutableStateFlowListMessage(emptyList()) val messages: StateFlowListMessage _messages fun send(text: String) { val history _messages.value Message(user, text) _messages.value history Message(assistant, ) // 先占位 viewModelScope.launch { KimiClient.streamChat( messages history, onDelta { delta - val list _messages.value.toMutableList() val last list.last() list[list.lastIndex] last.copy(content last.content delta) _messages.value list }, onComplete { /* 可在此落库、打点 */ }, onError { e - /* 标记最后一条为失败态 */ } ) } } }先插入一条空的 assistant 消息占位再逐段追加UI 上就是打字机效果。用StateFlow而不是LiveData因为 Compose 直接collectAsState就能驱动重组。每次onDelta都复制整个列表消息多时有性能开销优化方向是用SnapshotStateList或只更新单条消息的MutableState这个在改造章节展开。状态机要覆盖四种态Idle、Streaming、Completed、Failed。Streaming时禁用发送按钮防止用户连点导致多条流并发写同一个列表。Failed时保留已收到的部分文本给一个“重试”入口别把半截回答清空——用户已经读了一半清掉等于白等。4. 跑起来与联调从零到看到第一个字4.1 环境准备与配置注入先把项目 clone 下来用 Android Studio 打开等待 Gradle sync 完成。需要准备的东西不多JDK 17AGP 8.x 要求、Android SDK 对应版本、一个可用的 API 凭证。凭证注入走local.properties不提交到版本库# local.properties kimi.api.tokenyour_token_here kimi.api.baseUrlhttps://api.example.com/v1/chat/completions然后在build.gradle里读取并写入BuildConfigandroid { defaultConfig { buildConfigField String, API_TOKEN, \${localProperties.getProperty(kimi.api.token)}\ buildConfigField String, BASE_URL, \${localProperties.getProperty(kimi.api.baseUrl)}\ } buildFeatures { buildConfig true } }代码里用BuildConfig.API_TOKEN取。这样换环境只改local.properties不用动源码。buildConfig特性在 AGP 8.0 之后默认关闭必须显式打开否则BuildConfig类不生成编译报“找不到符号”——这个坑很多人第一次踩。4.2 最小可运行验证跑通的标准不是“App 能启动”而是“输入一句话能看到字一个个蹦出来”。验证步骤启动 App进入对话页。输入“你好”点发送。观察日志StreamParser每解析出一段应打印delta你、delta好这样的片段。观察界面assistant 气泡内容逐字增长而不是一次性出现。流结束后发送按钮恢复可用。如果第 3 步日志有输出但界面不动问题在 UI 线程切换检查onDelta是否切回了主线程。如果日志一行都没有先看 HTTP 状态码401 是 token 问题404 是 URL 路径问题200 但无数据则大概率是请求体里stream没打开。联调阶段建议开logging-interceptor的BODY级别但只对非流式请求开流式响应体全量打印会刷屏且拖慢读取。更实用的做法是在StreamParser里加一行条件日志只在 debug 构建打印每段 delta 的长度和首字符。4.3 用 curl 先验接口再写代码写客户端之前先用命令行确认接口本身是通的能省掉一半排查时间curl -N -X POST $BASE_URL \ -H Authorization: Bearer $TOKEN \ -H Content-Type: application/json \ -H Accept: text/event-stream \ -d {model:kimi-latest,messages:[{role:user,content:你好}],stream:true}-N关闭 curl 的缓冲否则你会看到命令卡住然后一次性输出误以为服务端没流式。正常表现是data:行一条条往下滚。如果 curl 能看到流式、App 看不到问题一定在客户端解析或线程调度范围立刻缩小。这个习惯我每次接新接口都保留比在 IDE 里打断点快得多。5. 避坑与排查流式场景下最容易翻车的五件事5.1 现象字吐到一半卡住不动也不报错原因通常是连接被中间层缓冲了。某些网络环境或反向代理会对响应做缓冲攒够一定大小才下发流式就变成了“伪流式”。另一个可能是服务端发了心跳注释行客户端解析器没跳过卡在异常分支里静默吞掉。解决请求头加Cache-Control: no-cache服务端侧确认关闭了代理缓冲常见配置是X-Accel-Buffering: no。客户端解析器显式跳过:开头的行并且给整个流加一个读超时比如 60 秒无新数据就主动断开并报STREAM_INTERRUPTED别无限等。5.2 现象连续对话几次后新请求全部超时原因是ResponseBody没关闭连接池被占满。流式读取时如果中途抛异常或提前 returnuse {}块外的路径可能漏关。血泪经验是只要拿到ResponseBody无论走哪条分支都必须保证close()被调用。解决统一用response.use { }包住整个读取逻辑异常也在块内捕获。另外检查是否有地方对同一个Response读了两次 body第二次必然抛IllegalStateException。5.3 现象界面偶尔闪一下已显示的内容被清空原因是并发写。用户快速连点发送两条流同时往同一个消息列表追加后完成的流把列表覆盖了。或者onDelta和onComplete的线程切换顺序错乱onComplete先到把占位消息重置了。解决Streaming状态下禁用发送按钮这是最简单有效的。ViewModel 里加一个isStreaming标志send()入口先判断。另外onComplete里不要重置消息内容只改状态位。5.4 现象中文被截断成乱码或半个字原因是按字节读而不是按行读或者用了固定长度 buffer 切分 UTF-8 多字节字符。中文一个字符占 3 字节按字节边界切必然出现半个字符。解决坚持用readUtf8Line()按行读OkHttp 内部会处理 UTF-8 解码。如果自己实现 buffer 读取用BufferedReader的readLine()别手动read(byte[])再拼字符串。5.5 现象debug 包正常release 包流式失效原因是混淆把 JSON 数据类的字段名改了Gson 反序列化拿不到choices、delta、content解析全返回 null。debug 不混淆所以看不出来。解决给所有网络数据类加Keep注解或在proguard-rules.pro里保留对应包名-keep class com.example.corenetwork.model.** { *; } -keepclassmembers class com.example.corenetwork.model.** { fields; }发版前务必用 release 包实测一次流式别只信 debug。6. 二次开发把流式链路改成可复用组件接手这类项目后我做的第一件事通常不是加功能而是把streamChat从“回调三件套”改成Flow因为回调在复杂页面里会嵌套到没法读。改造后的签名fun streamChat(messages: ListMessage): FlowStreamEvent flow { // ... 建立连接、逐行读取 emit(StreamEvent.Delta(text)) emit(StreamEvent.Done) }.catch { e - emit(StreamEvent.Error(e)) }.flowOn(Dispatchers.IO)StreamEvent用密封类定义Delta、Done、Error三种UI 层collect时when分支处理取消收集即取消请求配合callbackFlow或ensureActive()检查。这样 ViewModel 里一行collect搞定测试也好写——用runTest加一个假的 Flow 就能验证状态流转不用起真网络。第二个改造点是增量渲染的性能。消息很长时每来一个 delta 就复制整个列表GC 压力大。换成SnapshotStateList直接list[lastIndex] list[lastIndex].copy(...)Compose 只重组变化的那一项。再进一步把 delta 先攒 50 毫秒再批量刷 UI肉眼几乎无感但重组次数降一个量级。第三个点是错误恢复。流中断后把已收到的部分文本和原始messages一起存下来重试时带上“请从断点继续”的 system 提示或者干脆重新生成。我一般选后者因为断点续传的提示词工程不稳定重新生成虽然费 token 但结果更可控。改造项改造前改造后收益接口形态三回调Flow 密封类可取消、可测试列表更新全量复制SnapshotStateList 单点更新重组次数下降UI 刷新每 delta 一次50ms 批量主线程压力降低错误恢复清空重来保留半截 重试入口用户感知更好改造完记得用 release 包再跑一遍第 5.5 条的混淆检查我吃过一次亏debug 下 Flow 改造一切正常release 包因为数据类字段被混淆Delta永远是空字符串排查了半天才想起看混淆规则。从那以后我每次改完网络层都强制走一遍“release 包 真机 完整对话”的验证流程不再只信 debug 的表现。希望帮到你。本文还有配套的精品资源点击获取
简介面向Android开发者与AI应用集成者的Kimi API流式输出实战工程聚焦大模型对话场景中逐字返回、实时渲染的接入难题帮助读者理解流式响应在移动端的完整落地路径。压缩包共813个文件、约14.99MB以flat、json、xml等配置与资源文件为主辅以dex、class、jar等编译产物以及kt源码、properties配置、gradle构建脚本和webp图片资源构成一个可直接导入Android Studio的完整工程结构。已有1233人学习下载说明该主题在移动端AI集成领域具备一定关注度。资源价值在于提供可运行的流式输出参考实现读者可据此对照请求参数构造、分块数据解析与UI增量刷新等关键环节理解SSE式响应在Android端的处理方式并借助现有目录结构与构建配置快速搭建自己的调试环境减少从零摸索的成本适合具备一定Android基础、希望将大模型能力接入移动应用的开发者参考。1. 流式输出不是玄学从一次“转圈十秒”的对话说起有个做 Android 端 AI 助手的朋友跟我吐槽用户点发送后界面要转圈十来秒才“啪”地蹦出一整段回答体验像在等一封邮件。后来他把 KIMI API 的流式输出接上同样的模型、同样的网络首字出现时间压到了一秒以内用户感知完全变了。这个项目的核心就一件事——把 KIMI 的对话接口从“一次性返回”改成“边生成边吐字”并把这套流式链路封装成 Android 端能直接调用的结构。适合两类人一是想在 App 里做打字机效果的 Android 开发者二是想搞清楚 SSE 流式响应到底怎么解析、怎么在 UI 层安全消费的后端或全栈同学。下面按“它是什么 → 怎么跑 → 怎么改”拆开讲。2. 项目定位与技术选型为什么是 SSE 而不是轮询2.1 这个项目到底解决什么问题大模型对话接口有两种返回模式。非流式是一次性把完整回答算完再返回客户端拿到的是一个完整 JSON流式则是服务端每生成一小段 token 就推一条数据下来客户端边收边渲染。KIMI 的对话接口支持后者返回格式是标准的text/event-stream也就是常说的 SSEServer-Sent Events。这个项目的价值不在于“调通一个接口”而在于把流式响应的完整生命周期管起来建立连接、逐块读取、按行切分、解析data:前缀、处理结束标记[DONE]、异常中断后的收尾。这些环节任何一个没处理好表现就是“字吐到一半卡住”“界面闪一下全没了”“连接泄漏导致下次请求失败”。项目把这些封装成可复用的流式客户端Android 层只负责把增量文本追加到 UI。技术选型上网络层用 OkHttp这是 Android 生态里最稳的 HTTP 客户端对流式响应的支持很直接——拿到ResponseBody的source()后可以按行阻塞读取不需要额外引入 SSE 库。JSON 解析用 Gson 或 kotlinx.serialization 都行取决于项目是 Java 还是 Kotlin 技术栈。UI 层用协程或回调把增量文本抛回主线程。这套组合的好处是依赖少、可控性强坏处是所有边界情况得自己兜后面避坑章节会细说。提示SSE 是单向的服务端推、客户端收不需要 WebSocket 那样的双向握手。对话场景天然适合它别为了“看起来高级”上 WebSocket复杂度白涨。2.2 目录结构长什么样项目按职责分层典型结构如下不同实现细节会有出入但分层逻辑一致kimi-stream-demo/ ├── app/ # Android 应用层 │ ├── ui/ # 对话界面、消息列表 │ └── viewmodel/ # 持有流式状态、转发增量文本 ├── core-network/ # 网络与流式解析 │ ├── KimiClient.kt # OkHttp 客户端封装 │ ├── StreamParser.kt # SSE 行解析器 │ └── model/ # 请求/响应数据类 ├── core-common/ # 通用工具、错误类型 └── build.gradle # 依赖与构建配置core-network是重点流式的所有“脏活”都在这里。app层保持薄只做状态渲染这样换 UI 框架Compose 换 View 体系时网络层不用动。core-common放统一的错误枚举比如NETWORK_ERROR、STREAM_INTERRUPTED、PARSE_ERROR方便上层做差异化提示。2.3 关键依赖与版本约束构建文件里需要的最小依赖集// app/build.gradle dependencies { implementation com.squareup.okhttp3:okhttp:4.12.0 // 流式读取核心 implementation com.squareup.okhttp3:logging-interceptor:4.12.0 // 调试用 implementation com.google.code.gson:gson:2.10.1 // JSON 解析 implementation org.jetbrains.kotlinx:kotlinx-coroutines-android:1.7.3 // 协程调度 }OkHttp 4.x 是必须的3.x 的ResponseBody.source()行为在部分场景下有差异流式读取容易踩坑。协程版本跟项目现有 Kotlin 版本对齐即可别单独升容易和 Compose 的协程依赖打架。logging-interceptor只在 debug 构建里加流式响应体很大全量打日志会拖慢调试。3. 流式链路拆解从发请求到 UI 吐字的完整代码3.1 构造请求把 stream 参数打开KIMI 对话接口的流式开关是一个请求体字段常见做法是stream: true。请求体结构大致如下data class ChatRequest( val model: String kimi-latest, // 模型标识按实际可用模型填 val messages: ListMessage, val stream: Boolean true, // 关键开关 val temperature: Double 0.7 // 采样温度0~1 之间 ) data class Message(val role: String, val content: String) fun buildRequestBody(messages: ListMessage): RequestBody { val req ChatRequest(messages messages) val json Gson().toJson(req) return json.toRequestBody(application/json.toMediaType()) }stream true是整条链路的前提漏了这个字段服务端会按非流式返回一个完整 JSON客户端按 SSE 解析就会一行都读不到表现为“请求成功但界面没反应”。temperature控制随机性做客服类应用建议调低到 0.3 左右做创意类可以到 0.8。messages里role取值通常是system、user、assistant多轮对话要把历史消息按顺序带上否则模型没有上下文。请求头里必须带鉴权信息常见是Authorization: Bearer token以及Accept: text/event-stream告诉服务端期望流式响应。token 不要硬编码在代码里放local.properties或构建配置注入这是血泪经验——硬编码的 token 进了 Git 历史清理起来很麻烦。3.2 建立连接并逐行读取核心读取逻辑用 OkHttp 的同步调用配合协程调度到 IO 线程suspend fun streamChat( messages: ListMessage, onDelta: (String) - Unit, // 每收到一段增量文本回调 onComplete: () - Unit, // 流正常结束 onError: (Throwable) - Unit // 异常回调 ) withContext(Dispatchers.IO) { val request Request.Builder() .url(https://api.example.com/v1/chat/completions) // 替换为实际接口地址 .addHeader(Authorization, Bearer $token) .addHeader(Accept, text/event-stream) .post(buildRequestBody(messages)) .build() try { client.newCall(request).execute().use { response - if (!response.isSuccessful) { onError(IOException(HTTP ${response.code})) returnuse } val source response.body?.source() ?: run { onError(IOException(empty body)) returnuse } // 按行阻塞读取直到流结束 while (!source.exhausted()) { val line source.readUtf8Line() ?: break StreamParser.parse(line)?.let { delta - withContext(Dispatchers.Main) { onDelta(delta) } } } withContext(Dispatchers.Main) { onComplete() } } } catch (e: Exception) { withContext(Dispatchers.Main) { onError(e) } } }几个关键点。execute()是同步阻塞调用必须放在Dispatchers.IO放主线程直接 ANR。use {}保证ResponseBody被关闭不关的话连接池会被占满后续请求全部超时——这是流式场景最常见的泄漏点。source.readUtf8Line()每次读一行SSE 的格式是每行以\n结尾空行表示一个事件结束所以按行读是正确姿势。source.exhausted()判断流是否读完配合readUtf8Line()返回 null 时 break双保险。onDelta回调切回主线程再更新 UI因为 OkHttp 的读取在 IO 线程直接改 UI 会崩。这里用withContext(Dispatchers.Main)逐段切换如果增量很密集每秒几十段可以考虑用Channel或Flow做背压避免主线程消息队列堆积。3.3 SSE 行解析data 前缀与 [DONE] 标记服务端推下来的每一行长这样data: {choices:[{delta:{content:你}}]}解析器要做三件事去掉data:前缀、跳过空行和注释行、识别[DONE]结束标记。object StreamParser { private const val PREFIX data: private const val DONE [DONE] fun parse(line: String): String? { val trimmed line.trim() if (trimmed.isEmpty()) return null // 空行是事件分隔跳过 if (trimmed.startsWith(:)) return null // 注释行心跳跳过 if (!trimmed.startsWith(PREFIX)) return null val payload trimmed.removePrefix(PREFIX).trim() if (payload DONE) return null // 结束标记由外层循环自然退出 return try { val obj Gson().fromJson(payload, JsonObject::class.java) obj.getAsJsonArray(choices) ?.firstOrNull() ?.asJsonObject ?.getAsJsonObject(delta) ?.get(content) ?.asString } catch (e: Exception) { null // 单行解析失败不中断整条流 } } }data:后面可能有一个空格removePrefix后要trim()。[DONE]是 OpenAI 兼容格式的结束约定KIMI 接口同样遵循遇到它直接返回 null外层循环读到流末尾自然结束。注释行以:开头是服务端发的心跳保活不处理会导致解析报错。单行 JSON 解析失败返回 null 而不是抛异常因为流式场景下偶发的半包、粘包不该让整个对话崩掉丢一段比全丢好。注意有些实现会在delta里同时带role字段第一段content可能为空。取值时判空别直接asString拿到null字符串塞进 UI。3.4 UI 层消费增量追加与状态机ViewModel 里维护一个消息列表流式过程中不断更新最后一条 assistant 消息的内容class ChatViewModel : ViewModel() { private val _messages MutableStateFlowListMessage(emptyList()) val messages: StateFlowListMessage _messages fun send(text: String) { val history _messages.value Message(user, text) _messages.value history Message(assistant, ) // 先占位 viewModelScope.launch { KimiClient.streamChat( messages history, onDelta { delta - val list _messages.value.toMutableList() val last list.last() list[list.lastIndex] last.copy(content last.content delta) _messages.value list }, onComplete { /* 可在此落库、打点 */ }, onError { e - /* 标记最后一条为失败态 */ } ) } } }先插入一条空的 assistant 消息占位再逐段追加UI 上就是打字机效果。用StateFlow而不是LiveData因为 Compose 直接collectAsState就能驱动重组。每次onDelta都复制整个列表消息多时有性能开销优化方向是用SnapshotStateList或只更新单条消息的MutableState这个在改造章节展开。状态机要覆盖四种态Idle、Streaming、Completed、Failed。Streaming时禁用发送按钮防止用户连点导致多条流并发写同一个列表。Failed时保留已收到的部分文本给一个“重试”入口别把半截回答清空——用户已经读了一半清掉等于白等。4. 跑起来与联调从零到看到第一个字4.1 环境准备与配置注入先把项目 clone 下来用 Android Studio 打开等待 Gradle sync 完成。需要准备的东西不多JDK 17AGP 8.x 要求、Android SDK 对应版本、一个可用的 API 凭证。凭证注入走local.properties不提交到版本库# local.properties kimi.api.tokenyour_token_here kimi.api.baseUrlhttps://api.example.com/v1/chat/completions然后在build.gradle里读取并写入BuildConfigandroid { defaultConfig { buildConfigField String, API_TOKEN, \${localProperties.getProperty(kimi.api.token)}\ buildConfigField String, BASE_URL, \${localProperties.getProperty(kimi.api.baseUrl)}\ } buildFeatures { buildConfig true } }代码里用BuildConfig.API_TOKEN取。这样换环境只改local.properties不用动源码。buildConfig特性在 AGP 8.0 之后默认关闭必须显式打开否则BuildConfig类不生成编译报“找不到符号”——这个坑很多人第一次踩。4.2 最小可运行验证跑通的标准不是“App 能启动”而是“输入一句话能看到字一个个蹦出来”。验证步骤启动 App进入对话页。输入“你好”点发送。观察日志StreamParser每解析出一段应打印delta你、delta好这样的片段。观察界面assistant 气泡内容逐字增长而不是一次性出现。流结束后发送按钮恢复可用。如果第 3 步日志有输出但界面不动问题在 UI 线程切换检查onDelta是否切回了主线程。如果日志一行都没有先看 HTTP 状态码401 是 token 问题404 是 URL 路径问题200 但无数据则大概率是请求体里stream没打开。联调阶段建议开logging-interceptor的BODY级别但只对非流式请求开流式响应体全量打印会刷屏且拖慢读取。更实用的做法是在StreamParser里加一行条件日志只在 debug 构建打印每段 delta 的长度和首字符。4.3 用 curl 先验接口再写代码写客户端之前先用命令行确认接口本身是通的能省掉一半排查时间curl -N -X POST $BASE_URL \ -H Authorization: Bearer $TOKEN \ -H Content-Type: application/json \ -H Accept: text/event-stream \ -d {model:kimi-latest,messages:[{role:user,content:你好}],stream:true}-N关闭 curl 的缓冲否则你会看到命令卡住然后一次性输出误以为服务端没流式。正常表现是data:行一条条往下滚。如果 curl 能看到流式、App 看不到问题一定在客户端解析或线程调度范围立刻缩小。这个习惯我每次接新接口都保留比在 IDE 里打断点快得多。5. 避坑与排查流式场景下最容易翻车的五件事5.1 现象字吐到一半卡住不动也不报错原因通常是连接被中间层缓冲了。某些网络环境或反向代理会对响应做缓冲攒够一定大小才下发流式就变成了“伪流式”。另一个可能是服务端发了心跳注释行客户端解析器没跳过卡在异常分支里静默吞掉。解决请求头加Cache-Control: no-cache服务端侧确认关闭了代理缓冲常见配置是X-Accel-Buffering: no。客户端解析器显式跳过:开头的行并且给整个流加一个读超时比如 60 秒无新数据就主动断开并报STREAM_INTERRUPTED别无限等。5.2 现象连续对话几次后新请求全部超时原因是ResponseBody没关闭连接池被占满。流式读取时如果中途抛异常或提前 returnuse {}块外的路径可能漏关。血泪经验是只要拿到ResponseBody无论走哪条分支都必须保证close()被调用。解决统一用response.use { }包住整个读取逻辑异常也在块内捕获。另外检查是否有地方对同一个Response读了两次 body第二次必然抛IllegalStateException。5.3 现象界面偶尔闪一下已显示的内容被清空原因是并发写。用户快速连点发送两条流同时往同一个消息列表追加后完成的流把列表覆盖了。或者onDelta和onComplete的线程切换顺序错乱onComplete先到把占位消息重置了。解决Streaming状态下禁用发送按钮这是最简单有效的。ViewModel 里加一个isStreaming标志send()入口先判断。另外onComplete里不要重置消息内容只改状态位。5.4 现象中文被截断成乱码或半个字原因是按字节读而不是按行读或者用了固定长度 buffer 切分 UTF-8 多字节字符。中文一个字符占 3 字节按字节边界切必然出现半个字符。解决坚持用readUtf8Line()按行读OkHttp 内部会处理 UTF-8 解码。如果自己实现 buffer 读取用BufferedReader的readLine()别手动read(byte[])再拼字符串。5.5 现象debug 包正常release 包流式失效原因是混淆把 JSON 数据类的字段名改了Gson 反序列化拿不到choices、delta、content解析全返回 null。debug 不混淆所以看不出来。解决给所有网络数据类加Keep注解或在proguard-rules.pro里保留对应包名-keep class com.example.corenetwork.model.** { *; } -keepclassmembers class com.example.corenetwork.model.** { fields; }发版前务必用 release 包实测一次流式别只信 debug。6. 二次开发把流式链路改成可复用组件接手这类项目后我做的第一件事通常不是加功能而是把streamChat从“回调三件套”改成Flow因为回调在复杂页面里会嵌套到没法读。改造后的签名fun streamChat(messages: ListMessage): FlowStreamEvent flow { // ... 建立连接、逐行读取 emit(StreamEvent.Delta(text)) emit(StreamEvent.Done) }.catch { e - emit(StreamEvent.Error(e)) }.flowOn(Dispatchers.IO)StreamEvent用密封类定义Delta、Done、Error三种UI 层collect时when分支处理取消收集即取消请求配合callbackFlow或ensureActive()检查。这样 ViewModel 里一行collect搞定测试也好写——用runTest加一个假的 Flow 就能验证状态流转不用起真网络。第二个改造点是增量渲染的性能。消息很长时每来一个 delta 就复制整个列表GC 压力大。换成SnapshotStateList直接list[lastIndex] list[lastIndex].copy(...)Compose 只重组变化的那一项。再进一步把 delta 先攒 50 毫秒再批量刷 UI肉眼几乎无感但重组次数降一个量级。第三个点是错误恢复。流中断后把已收到的部分文本和原始messages一起存下来重试时带上“请从断点继续”的 system 提示或者干脆重新生成。我一般选后者因为断点续传的提示词工程不稳定重新生成虽然费 token 但结果更可控。改造项改造前改造后收益接口形态三回调Flow 密封类可取消、可测试列表更新全量复制SnapshotStateList 单点更新重组次数下降UI 刷新每 delta 一次50ms 批量主线程压力降低错误恢复清空重来保留半截 重试入口用户感知更好改造完记得用 release 包再跑一遍第 5.5 条的混淆检查我吃过一次亏debug 下 Flow 改造一切正常release 包因为数据类字段被混淆Delta永远是空字符串排查了半天才想起看混淆规则。从那以后我每次改完网络层都强制走一遍“release 包 真机 完整对话”的验证流程不再只信 debug 的表现。希望帮到你。本文还有配套的精品资源点击获取
