Hiyaa.AI Android 项目深挖面试知识点整理

整理自项目模拟面试，覆盖流式消息处理、HTTP streaming、Markdown 渲染、角色配置、FCM 拉活、模型微调与评估

一、项目里核心的 AI 问答消息是如何处理的

一句话

整体链路是 本地会话组装 -> HTTP 流式请求 -> chunk 增量回调 -> UI 边收边展示 -> 结束后统一落库。

发送侧做了什么

用户发送消息后，不是只把当前一句话直接发给服务端
会先从本地会话库里取最近一段上下文消息
再拼上当前用户输入、角色对应的 system prompt、roleId、modelId
最后带上 stream=1 发到聊天接口

为什么这样做

保留上下文，避免模型只看最后一句
把角色设定和用户当前会话一起带给服务端
明确告诉服务端走流式返回，而不是整包返回

接收侧做了什么

底层不是普通 Retrofit 一次性读完整 JSON
而是用 OkHttp 持续读取 ResponseBody 的流
每读到一段新内容，就通过 onReceiving(chunk, received, beforeLength, afterLength) 往上层回调
UI 层直接用累计好的 received 更新当前 assistant 消息，实现边生成边展示

状态管理

WAITING：已创建占位消息，等待服务端返回
GENERATING：已经收到 chunk，正在持续生成
SUCCEEDED：流正常结束
FAILED：网络异常、次数不足、内容违规、token 超限等
INTERRUPT：用户主动点击 Stop

落库策略

生成过程中主要更新内存模型和界面
不在每个 chunk 到来时都频繁写数据库
结束后再统一把最终内容写回会话表

这样设计的价值

首字延迟更低
用户体感更像“实时对话”
状态收口清晰，便于做停止生成、重试、埋点和错误兜底

二、HTTP streaming、SSE、WebSocket 的区别与取舍

先说结论

这个项目最终选择的是 HTTP POST + 流式响应读取，本质上属于 HTTP streaming，不是 WebSocket。

三者区别

方案	通信模型	适用场景	特点
HTTP streaming	单次 HTTP 请求，服务端持续写响应体	AI 问答、长文本生成	接入成本低，和现有 HTTP 体系兼容
SSE	基于 HTTP 的单向事件流	服务端持续推文本/事件	比较标准化，适合单向流式输出
WebSocket	双向长连接	IM、协同编辑、强实时双向交互	更灵活，但连接管理复杂

为什么项目里优先选 HTTP streaming

业务模型是“用户发一问，服务端流式回一答”，天然是请求-响应增强版
可以复用现有 HTTP 网关、鉴权、签名、埋点体系
客户端和服务端改造成本更低
已经足够满足边生成边展示、Stop、中断、异常处理这些核心需求

trade-off

相比 WebSocket，不适合高频双向主动推送
相比标准 SSE，协议约定更偏自定义
但在当时业务形态下，复杂度、上线速度、可维护性更平衡

三、OkHttp 为什么能持续读取流，readTimeout 有什么影响

原理

HTTP 响应体本身就是一个可持续消费的字节流
只要服务端持续往连接里写数据、连接没断，客户端就可以一直读
OkHttp 拿到 response.body().source() 后，可以在循环里持续 read(...)
每拿到一段新数据，就可以立刻交给上层做 UI 刷新

readTimeout 的含义

readTimeout 控制的是“两次成功读取数据之间，最多允许等多久”
如果在这个时间里一直没读到新字节，OkHttp 就会判定读超时

在流式 AI 场景里的影响

设得太短：
模型中途生成慢一点就可能被误判超时
用户看到的现象是回答到一半停掉
设得太长：
真正的死连接暴露太慢
用户等待时间会被拉长

更合理的做法

connectTimeout 按普通接口设置
readTimeout 比普通接口更保守
同时配合主动 Stop，而不是完全依赖超时兜底

四、用户点击 Stop 之后会发生什么

客户端侧

通过 requestId 找到当前流式请求
将请求标记为 interrupted
回调 onEnd(INTERRUPT)
停止继续向 UI 分发后续 chunk
已经收到的文本会保留下来

服务端侧

如果当前实现没有显式 cancel call
那么服务端不一定在用户点击的瞬间就知道请求被停止
它往往是在下一次写响应体时，才发现对端已经不再消费或连接已断

为什么没有直接 `cancel OkHttp Call`

为了把“用户主动停止”和“网络失败”区分开
避免 Stop 被打进异常链路
更稳定地保留部分已生成结果
当前实现更偏客户端软中断，而不是强一致的服务端取消

五、HTTP/1.1 chunked transfer 和 HTTP/2 streaming 的区别

HTTP/1.1

常见做法是 Transfer-Encoding: chunked
服务端按块写响应体，每块前有长度信息
一个流式响应通常长时间占用一个 TCP 连接

HTTP/2

不再使用 chunked transfer
底层通过二进制 frame + stream 传输
一个 TCP 连接里可以并发多个 stream
中断时也通常可以只中断当前 stream，而不必关整个连接

对业务层的意义

两者都能支持 AI 流式输出
对上层业务来说，重点不是死扣协议细节
更关键的是：
服务端能否持续 flush
客户端能否持续读取
超时和中断策略是否合理

六、Markdown 渲染是如何做的

一句话

不是走 WebView，也不是服务端先转 HTML，而是客户端本地用 Markwon 把 Markdown 解析成 Spanned，再交给 TextView 原生渲染。

基本链路

parse(md) 把 Markdown 解析成 AST
render(node) 把 AST 转成 Spanned
setParsedMarkdown(...) 设置到 TextView

为什么选这条路线

比 WebView 更轻，适合聊天列表高频刷新
仍然保留原生 TextView 的选择、复制、点击能力
方便和现有消息 item、长按菜单、播放按钮做原生交互集成

做了哪些增强

代码块高亮：接了 Prism4j
代码块样式：加背景、圆角、主题色
代码块复制：通过 span 做可点击复制区域
表格兼容：自定义 FixTablePlugin
数学公式：接 JLatexMathPlugin
部分 HTML 标签支持：补充 tag handler

设计模式角度可以怎么讲

Visitor：遍历 Markdown AST
Factory：不同节点生成不同 span
Plugin：功能插件化拼装
Decorator：通过 span 给文本附着样式和行为
Strategy：不同节点用不同渲染策略

Spanned 能不能做复杂 Markdown

能覆盖大部分聊天场景常见富文本
但它本质上是“文本 + span”的原生富文本体系，不是浏览器排版引擎
像复杂表格、复杂块布局往往要额外做插件和 layout 适配

七、角色配置是怎么实现的

设计思路

角色配置拆成两层：
角色公共配置
用户个性化配置

角色公共配置

统一抽象成 RoleInfo
包含：
名字
头像 / 背景图
简介
首条消息
标签
权限
模型信息

数据来源

本地 assets/config.json 做冷启动和离线兜底
服务端接口拉角色分类、列表、详情
自定义角色从单独接口和本地缓存补充

为什么要本地预置 + 远端拉取

提高冷启动可用性
弱网或接口异常时有兜底
兼顾动态配置能力

用户个性化配置

按 roleId 存 memory、persona 等信息
同一个官方角色，不同用户可以配置不同关系和人设
这层配置不改角色公共定义，只影响当前用户体验

聊天时如何消费

UI 展示会用到：
briefIntro
firstMessage
角色图片和标签
发送请求会注入：
roleId
modelId
systemPrompt
memory
persona

八、FCM 拉活推送是怎么做的

链路拆分

应用初始化时获取 fcmToken
把 token 同步给业务服务端
订阅拉活 topic
Firebase 收到消息后回调 FirebaseMessagingService
按 action 分发到不同推送处理器
组装通知内容并展示
用户点击通知后跳转到目标角色聊天页

为什么 FCM 能做拉活

真正长期在线的是系统侧的 Google Play Services/FCM 通道
即使 App 不在前台，消息也可以先到系统侧
系统再把消息分发给应用，或者展示通知
用户点击通知后就能把访问重新拉回 App

data message 在应用死掉后还能不能收到

理论上可以，因为系统可能会临时拉起 FirebaseMessagingService
但不是绝对可靠
会受以下因素影响：
是否 force stop
省电模式 / Doze
厂商后台限制
消息优先级
Google 服务可用性

拉活推送里的客户端策略

命中实验组才允许发
注册当天用户不打扰
结合本地会话数据，优先挑“还没聊过”的角色
从本地 push_role_config.json 里选角色和文案

这样做的价值

推送协议可扩展
能做 AB 实验和人群过滤
能结合本地行为数据做更细的角色选择

九、微调模型的数据怎么来，怎么做，怎么评估

数据来源

真实业务里的高质量对话样本
人工整理过的角色设定、首句、system prompt 等配置数据
AI 辅助生成的对话初稿，再做人工筛选和清洗
安全和负向样本，例如 NSFW、拒答、越界约束数据

为什么要准备训练集和验证集

训练集负责让模型学习
验证集不参与参数更新，只用来判断模型有没有学偏、有没有过拟合
如果训练效果越来越好，但验证效果变差，通常说明开始过拟合

微调方式上怎么讲更稳妥

重点是 SFT/继续微调的工程落地
我的主要工作不是底层训练框架开发
而是：
数据清洗
格式转换
部署
批量对话测试

数据处理会做什么

去重、去异常、去明显 OOC 样本
统一成多轮对话格式
按角色风格、通用闲聊、安全约束等维度分层
控制不同数据类型的配比

怎么判断微调效果

离线

固定一批 benchmark 问题
同时跑基线模型和微调模型
看：
角色一致性
回复自然度
上下文承接
OOC 率
安全违规率
再做人工抽样 review

在线

看业务指标是否变好：
会话轮次
留存
用户反馈
举报 / 安全问题率
结合 AB 实验验证是否值得上线

面试里怎么收口

微调成功不等于回答更长
更重要的是角色更稳定、互动更自然、越界更少，且线上核心指标不回退

十、一句话速记

知识点	速记
AI 流式消息	本地组装上下文，HTTP 流式接收，chunk 增量渲染，结束统一落库
HTTP streaming	仍然是 HTTP，不是 WebSocket；请求一次，响应持续写
OkHttp 读流	`ResponseBody` 是可持续消费的字节流，持续 `read()` 即可
Stop 处理	当前实现更偏客户端软中断，保留部分结果，不等于服务端瞬时停算
Markdown 渲染	Markwon 把 Markdown AST 转成 `Spanned`，原生 TextView 渲染
角色配置	公共角色配置 + 用户个性化配置，两层解耦
FCM 拉活	借系统推送通道触达用户，再通过通知点击把访问拉回 App
模型微调	重点是数据处理、格式转换、部署和批量效果评估