背景痛点

在移动端实现实时语音转文字功能时，开发者通常会遇到几个核心挑战：

1. 延迟问题：用户说话后需要快速看到文字反馈，理想延迟应控制在1秒内
2. 内存占用：大型AI模型在移动设备上容易导致OOM（内存溢出）
3. 功耗控制：持续录音和推理会显著增加电池消耗
4. 设备兼容性：Android设备的硬件差异导致性能表现不一

技术选型对比

| 方案 | 优点 | 缺点 | |---------------------|--------------------------|-----------------------------| | 云端Speech-to-Text API | 准确率高，无需维护模型 | 依赖网络，隐私性差，成本高 | | TensorFlow Lite | 本地运行，支持自定义模型 | 需要自己优化模型和前后处理 | | Whisper.cpp | 超强准确率，开源可量化 | 需要处理C++跨平台集成 |

最终选择Whisper.cpp方案，因其： - 支持模型量化到INT8（大小缩减至~100MB） - 在Pixel 6上单句推理仅需300-500ms - 支持多语言和口音识别

核心实现

1. 音频流捕获

使用MediaRecorder配合环形缓冲区实现低延迟采集：

val bufferSize = AudioRecord.getMinBufferSize(
    SAMPLE_RATE,
    AudioFormat.CHANNEL_IN_MONO,
    AudioFormat.ENCODING_PCM_16BIT
) * 2

val audioRecord = AudioRecord(
    MediaRecorder.AudioSource.MIC,
    SAMPLE_RATE,
    AudioFormat.CHANNEL_IN_MONO,
    AudioFormat.ENCODING_PCM_16BIT,
    bufferSize
)

// 环形缓冲区实现
val ringBuffer = CircularBuffer(capacity = 10 * bufferSize)

audioRecord.startRecording()
thread {
    val tempBuffer = ByteArray(bufferSize)
    while (isRecording) {
        val read = audioRecord.read(tempBuffer, 0, bufferSize)
        ringBuffer.write(tempBuffer, 0, read)
    }
}

2. JNI集成

关键native方法声明：

external fun initModel(modelPath: String, threads: Int): Long
external fun processAudio(
    ctx: Long, 
    audioData: ShortArray, 
    sampleRate: Int
): String

对应的C++实现需处理： - 加载量化模型 - 音频重采样到16kHz - Mel频谱计算

3. 线程安全管道

// 使用协程通道处理音频块
val audioChannel = Channel<ShortArray>(capacity = 10)

// 生产者：从环形缓冲区提取数据
launch {
    while (isActive) {
        val pcm = ringBuffer.readChunk(CHUNK_SIZE)
        audioChannel.send(pcm)
    }
}

// 消费者：推理线程
launch {
    for (pcm in audioChannel) {
        val text = processAudio(nativeCtx, pcm, SAMPLE_RATE)
        withContext(Dispatchers.Main) {
            updateUI(text)
        }
    }
}

性能优化

量化效果对比（Pixel 6）

| 模型类型 | 大小 | 单句延迟 | 内存占用 | |---------|-------|---------|---------| | FP32 | 1.4GB | 1200ms | 2.1GB | | INT8 | 410MB | 480ms | 600MB |

内存泄漏预防

1. 使用Android Profiler监控native内存
2. 确保JNI全局引用及时释放
3. 实现Closeable接口管理模型生命周期

class WhisperRecognizer : Closeable {
    private var ctxPtr: Long = 0

    init {
        ctxPtr = initModel("quantized.bin", 4)
    }

    override fun close() {
        if (ctxPtr != 0L) {
            releaseModel(ctxPtr)
            ctxPtr = 0
        }
    }
}

避坑指南

1. 采样率问题：
2. 检测设备支持的最高采样率

3. 统一重采样到Whisper需要的16kHz

4. UI卡顿：

5. 使用Choreographer控制UI刷新频率

6. 结果聚合：每3-5个语音片段更新一次UI

7. 模型热更新：

8. 通过ContentProvider分发新模型
9. 使用FileObserver监控模型变化

延伸思考

对于更高要求的场景，可以考虑：

1. 端云协同：
2. 本地快速响应+云端二次校验

3. 根据网络条件动态切换

4. 动态量化：

5. 设备性能检测自动选择模型精度

6. 骁龙8系启用FP16加速

7. 预加载策略：

8. 用户打开麦克风时预加载模型
9. 空闲时释放资源

完整项目示例见：GitHub示例仓库