【听见课堂 HarmonyOS NEXT 实战系列 24】640 字节音频帧背后的工程细节：实时传输、节流与内存边界

实时语音链路里，AUDIO_FRAME_BYTES = 640 看起来只是一个常量，实际上同时约束延迟、调用频率、缓冲策略和错误恢复。帧太小会增加函数调用和调度开销，帧太大又会推高端到端延迟；如果直接在采集回调里做切片、日志、持久化和页面刷新，长课堂还会逐步积累卡顿与内存压力。

听见课堂当前把 AudioCapturer 的缓冲区切成 640 或 1280 字节，再调用 Core Speech Kit 的 writeAudio()。本文从 16 kHz 单声道 16 bit PCM 的数据率开始，分析现有实现做对了什么、还存在哪些边界，以及如何为 45 分钟以上课堂设计可观测的送帧与字幕分层。

一、先把 640 字节换算成时间

当前音频格式是：

采样率：16000 samples/s
声道：1
位深：16 bit = 2 byte

所以每秒原始 PCM 数据量为：

16000 × 1 × 2 = 32000 byte/s

据此可得：

• 640 字节约为 640 / 32000 = 0.02s，即 20 ms；
• 1280 字节约为 40 ms；
• 1 分钟原始流量约 1.92 MB；
• 45 分钟原始流量约 86.4 MB。

项目不保存原始音频，所以 86.4 MB 不是磁盘占用；但这些字节仍会持续经过回调、切片和识别引擎，运行时吞吐不能忽略。

二、为什么只能写 640 或 1280 字节

华为 Core Speech Kit 语音识别指南明确说明，writeAudio() 接收的音频流长度只支持 640 或 1280 字节。项目的常量直接来自这个输入契约：

const AUDIO_FRAME_BYTES: number = 640;

这意味着不能把 AudioCapturer 回调拿到的任意长度 ArrayBuffer 原样写入。适配层必须重新分帧，并确保每次送入的长度合法。

三、当前分帧逻辑做了什么

项目的核心循环如下：

const bytes: Uint8Array = new Uint8Array(buffer);
let offset: number = 0;

while (bytes.byteLength - offset >= AUDIO_FRAME_BYTES) {
  const remaining: number = bytes.byteLength - offset;
  const frameSize: number = remaining >= 1280 ? 1280 : 640;
  this.engine.writeAudio(
    this.sessionId,
    bytes.slice(offset, offset + frameSize)
  );
  offset += frameSize;
}

如果剩余至少 1280 字节，就优先送 1280；最后还剩 640—1279 字节时送 640；不足 640 字节则退出。本轮实现保证了交给引擎的帧长合法。

四、640 与 1280 的主要权衡

按 32 KB/s 计算，纯 640 字节帧约每秒调用 50 次，纯 1280 字节帧约每秒调用 25 次。

帧大小	对应时长	理论调用频率	主要特点
640 B	20 ms	约 50 次/s	更低分帧等待，更高调用与切片开销
1280 B	40 ms	约 25 次/s	更少调用，额外等待最多约 20 ms

实际延迟还包括系统采集缓冲、线程调度、VAD、识别引擎和回调，因此不能只看这 20 ms 差异。最稳妥的策略是遵守引擎契约，再通过真机监控选择，而不是凭感觉把帧做得越小越好。

五、当前实现有一个需要真机确认的尾帧问题

当某次 readData 回调返回的缓冲区不是 640 的整数倍时，循环结束后不足 640 字节的尾部会被丢弃。若系统始终返回 640/1280 对齐缓冲，这不会触发；若回调大小可变，持续丢尾会造成音频缺口。

更稳健的适配层应保留跨回调 remainder：

上次不足 640 的尾部
  + 本次新 buffer
  -> 尽可能切出 1280/640
  -> 再把不足 640 的尾部留到下一次

这项优化不能只写代码后宣称完成，需要在真机记录回调长度分布、尾部累计量和实际识别质量。当前项目没有这个跨回调 remainder，因此文章把它列为风险，而不是把规划包装成已实现能力。

六、slice 会产生分配，长课堂要看分配速率

Uint8Array.slice() 会生成新的数组。若每秒送 25—50 帧，就意味着每分钟约 1500—3000 次小对象分配。单个对象很小，但长时间运行可能增加 GC 压力。

可以评估的方向包括：

• 复用固定大小缓冲池；
• 如果 API 接受目标视图，使用不复制的视图并确认生命周期安全；
• 记录每分钟帧数、字节数与丢弃尾部；
• 避免在每帧路径拼接字符串或序列化日志；
• 在真机用性能工具观察 GC、CPU 与内存趋势。

优化前要先量化。为了减少一次 640 字节复制而引入复杂锁或共享缓冲，可能比现状更危险。

七、采集回调里不要做重活

当前 handleAudioData() 只做状态门禁、切片和 writeAudio()，没有数据库写入、网络请求、字幕渲染或大段日志，这个方向是正确的。

华为低时延录音文档也强调，音频数据回调中不应执行耗时操作，否则延迟读取可能造成噪声或卡顿。虽然该建议页面以 OHAudio C/C++ 回调为例，原则同样适用于实时采集链：回调要尽快交付数据，控制操作和慢任务应在回调外处理。

八、当前实现还没有显式背压队列

代码直接调用 engine.writeAudio()，没有队列长度、写入耗时或丢帧策略。如果 writeAudio() 在某些设备上变慢，采集回调可能堆积；如果它快速同步接收，则直接调用反而最简单。

是否需要队列必须用数据决定。若实测出现回调延迟，可设计有界队列：

AudioCapturer callback
  -> 有界 PCM 队列
  -> 单消费者按序 writeAudio
  -> 记录 queueDepth / droppedFrames / maxLagMs

队列必须有上限。无限队列只是把实时延迟变成不断增长的内存占用。丢帧策略也要可观测，不能静默吞掉音频再把低准确率归咎于模型。

九、页面为什么不能跟着每个音频帧重绘

每秒 25—50 个音频帧没有任何用户可读价值。页面需要的是识别文本、状态变化和低频计时，不应订阅 PCM 帧。

听见课堂当前只在以下时机发快照：

• 状态改变；
• 识别结果更新；
• 计时器每秒一次；
• 用户标记重点或没听清。

音频帧路径没有 emitSnapshot()，这把实时采集频率与 ArkUI 渲染频率隔离开。即使未来识别引擎产生高频 token，也应先在 Service 合并为可展示行，再节流通知 UI。

十、识别回调也需要合并，而不是每个 token 新增一行

项目用 currentCaptionId 把临时结果更新在同一个 LiveCaptionItem 上，只有 isFinal 后才关闭当前行。这能避免一句话被拆成许多短 token，减少列表节点和自动滚动次数。

页面的 ForEach key 包含文本和状态，临时结果变化仍会重建对应项。长句高频回调时可以进一步做 50—100 ms 的 UI 合并，但不能延迟最终结果或让字幕明显落后。节流参数必须用真机观感和无障碍需求校准。

十一、MAX_VISIBLE_CAPTIONS 只解决了显示上限的一半

当前 Service 在字幕超过 100 条后执行：

if (this.captions.length > MAX_VISIBLE_CAPTIONS) {
  this.captions = this.captions.slice(
    this.captions.length - MAX_VISIBLE_CAPTIONS
  );
}

这能限制页面列表和快照复制的规模，但项目结束保存时直接把 liveCaptions 转为 Repository 记录。也就是说，当前实现不仅限制“可见 100 条”，还可能只保存最后 100 条。

真正的分层应是：

全量会话字幕（分批持久化或受控内存）
  -> 最近 100 条展示窗口
  -> 当前行与自动滚动状态

当前源码尚未完成这层全量/可见分离。因此 100 条上限是防止 UI 无限增长的临时边界，不应宣传为长课堂完整存储方案。

十二、长课堂应分批落库而不是结束时一次替换

目前字幕在结束时通过 replaceTranscript() 一次写入。短演示可行，45 分钟课堂则应评估：

• 每 N 条或每 N 秒事务追加/更新；
• 临时结果只在内存，最终结果才入库；
• 写入失败保留可重试批次，不阻塞采集回调；
• 页面分页或窗口化读取；
• 会话结束时只收口未提交批次；
• 清晰区分“已显示”“已识别”“已持久化”计数。

批量策略要保证顺序、幂等和课程隔离。不要从页面层逐条写库，也不要在每个 onResult 里开启事务。

十三、应该记录哪些运行指标

长课堂验收至少需要以下非敏感指标：

指标	目的
capturedBytes	确认采集吞吐符合音频格式
frames640/frames1280	了解真实分帧分布
remainderBytes	发现尾帧丢弃风险
writeAudioDurationP95	判断是否需要背压队列
queueDepth/maxLagMs	队列方案的健康度
partial/final callback count	估算字幕合并频率
visible/full/persisted count	防止 100 条窗口误当全量
CPU、内存、GC、耗电	判断长时间稳定性

日志只记录计数和耗时，不记录原始 PCM、完整字幕、教师姓名或课程隐私内容。

十四、当前证据与待验证项

项目静态合约已确认 readData、writeAudio、监听解绑和资源释放路径存在；历史模拟器运行观察到监听计时、暂停与继续。官方指南当前注明 Core Speech 识别不支持模拟器，因此真实帧吞吐、回调长度分布、尾帧问题、识别延迟、长课堂资源曲线都必须在物理真机补验。

现有报告也把真机真实语音和长课堂资源释放列为 not run。文章中的 20/40 ms 是由格式计算出的理论值，不是已经测得的端到端字幕延迟。

十五、总结

640 字节不是一个孤立魔数，而是 Core Speech Kit 输入契约与 16 kHz PCM 数据率共同决定的 20 ms 音频单位。当前实现已经做到合法分帧、不落盘、音频热路径不触发 UI，但仍需要补上跨回调尾部、写入背压指标、全量字幕与 100 条显示窗口分离，以及长课堂分批持久化。

下一篇将转向识别输出：临时结果如何更新同一字幕，最终结果如何固化，current、final、keyPoint 和 uncertain 又怎样组成可展示的课堂信息。

参考：Core Speech Kit 语音识别指南；低时延音频录制。