ZIM 最佳实践：用信令消息实现“正在输入”状态提示
内容提要
“正在输入”提示是即时通讯提升实时感的关键。ZIM方案用信令消息（type=2）承载，因其不可存储、无留痕、支持高频发送。发送端首条立即发、每3秒保活、停止后发stop；接收端展示并10秒超时兜底。该方案不污染历史消息和会话列表，离线用户不收过期提示，群聊建议小群启用并降频。
延伸解读
消息类型选型：为何信令消息是唯一正解
文章对比了四种消息类型：信令消息（type=2）不可存储、限频30次/秒；弹幕消息（type=20）不可存储但仅限房间；文本消息（type=1）和自定义消息（type=200）可存储、限频10次/秒。Typing作为瞬时状态，必须避免进入历史消息和会话列表，因此只有信令消息满足“无留痕”要求。自定义消息虽灵活，但可存储特性会导致污染，接入时务必确认type=2。
保活与超时：弱网下的体验保障机制
信令消息不保证送达与顺序，因此方案采用3秒保活心跳对抗丢包，即使丢失1~2条也能被后续心跳补上。接收端设置10秒超时兜底，当stop信号丢失时自动隐藏提示，避免残留。发送端在停止输入1秒后发送stop，确保及时隐藏。这种“保活+超时”组合是弱网环境下维持状态可靠性的关键，也是自测时需重点验证的环节。
群聊扩展：规模控制与降频策略
群聊中多位成员可分别展示输入状态，但文章建议仅在成员≤50的小群启用，大群应关闭或仅对最近活跃成员展示。实现时需按senderUserID维护多份状态，并注意信令限频额度共享。多人高频输入时，建议将保活频率从3秒降至5秒，或设置独立降级开关，以平衡实时性与系统负载。
接入自测：三个关键验证项
文章强调接入后需逐项自测：一是stop信号丢失后，接收端是否在10秒超时后自动隐藏提示；二是双方翻看历史消息，是否完全看不到Typing记录；三是会话列表的最新消息是否未被Typing污染。这三项直接验证了方案是否真正实现了“瞬时状态”的语义，避免因消息类型误用导致数据留痕。
Q&A
ZIM 实现“正在输入”状态提示为什么选择信令消息而不是普通文本消息？
因为“正在输入”是瞬时状态而非消息，不应进入历史消息、产生数据留痕或出现在会话列表最新消息中。信令消息（ZIMCommandMessage，type=2）不可存储、天然无留痕，且支持 30 次/秒的高发送频率，与 Typing 的语义完全匹配。
ZIM 的“正在输入”提示发送端有哪些发送策略？
发送端策略包括：用户输入第一个字符时立即发送首条 typing 信号；持续输入期间每 3 秒发送一次保活心跳以对抗丢包；停止输入 1 秒后、输入框失焦或清空时发送 stop 信号通知对端隐藏。两次发送间隔需 ≥34ms 以满足 30 次/秒限频，但 3 秒保活节奏远低于限频，无需额外处理。
接收端如何处理“正在输入”信令并防止提示残留？
接收端收到 action 为 typing 的信令时展示“对方正在输入…”，收到 action 为 stop 时隐藏提示。同时设置 10 秒超时兜底：若距最后一条 typing 信号超过 10 秒未收到新信号，则自动隐藏提示，防止因 stop 丢失导致提示残留。
ZIM 的“正在输入”信令消息格式是怎样的？
信令消息的 message 字段为二进制数据，业务侧需自行序列化。通常用 JSON 表示，例如正在输入：{"bizType":"typing","action":"typing","ts":1725000000000}；停止输入：{"bizType":"typing","action":"stop","ts":1725000005000}。其中 bizType 固定为 "typing"，action 为 typing 或 stop，ts 为时间戳用于防乱序。
在群聊场景中使用“正在输入”提示需要注意什么？
群聊场景建议：规模控制在群成员 ≤50 的小群启用，大群建议关闭或仅对最近活跃成员展示；按 senderUserID 维护多份状态以展示多人输入；多人高频输入时建议降低保活频率（如 3s 改为 5s）或设置独立降级开关，因为 Typing 会占用共享的信令限频额度。
如何验证 ZIM“正在输入”功能实现是否正确？
关键验证项包括：stop 信号丢失后接收端是否在 10 秒超时后自动隐藏提示；双方翻看历史消息是否看不到任何 Typing 记录；会话列表最新消息是否不被 Typing 污染；离线用户上线后是否不会收到过期 Typing。
