iOS平台Firebase Crashlytics中AudioOut.cpp线程TTS相关崩溃求助

崩溃发生在AudioOut.cpp第XXX行的wordpos_thread(void*)函数，关联线程为com.google.firebase.crashlytics.MachExceptionServer，前序线程调用栈指向AXSpeech/TextToSpeech模块，推测是传入无效文本导致但无法复现，且调用栈中无自身代码痕迹，以下是具体解决思路：

1. 给TextToSpeech输入加防御性校验 #

• 过滤无效文本：直接移除空字符串、仅含不可见/控制字符的内容，只保留可打印的Unicode字符（比如常规中文、英文、常用符号，排除\0、连续换行这类异常字符）。
• 统一TTS调用入口：把所有AVSpeechSynthesizer相关调用收敛到一个工具类，在入口处强制做文本校验，避免分散调用遗漏校验步骤。

2. 捕获TTS相关的异常与上下文日志 #

• 实现AVSpeechSynthesizerDelegate代理，在完成/取消朗读的回调里记录完整的朗读文本、语音配置（语言、语速）；用@try/@catch包裹TTS调用代码，捕获异常后写入自定义日志（同步到Crashlytics的自定义日志中）。
• 开启Crashlytics自定义日志，每次调用TTS前，记录当前输入的文本、调用场景（比如用户点击朗读按钮、推送触发朗读），后续崩溃时就能关联到具体的输入内容。

3. 构造边缘场景尝试复现 #

• 测试各种异常文本：空字符串、超长文本、混合乱码+Emoji、大量控制字符（比如连续\n或\t），在崩溃高发的iOS版本上反复测试TTS调用。
• 模拟后台场景：调用栈显示NSRunLoop在运行，可能是后台触发TTS导致的问题，测试APP进入后台后触发朗读的场景，看是否能复现崩溃。

4. 排查版本与设备的相关性 #

• 查看Crashlytics崩溃数据的设备和iOS版本分布，确认是否集中在特定版本（比如iOS 15.x）或设备型号。如果是版本相关问题，可针对性查找苹果官方的已知问题，或测试对应版本的API替代方案。

5. 明确MachExceptionServer线程的作用 #

• com.google.firebase.crashlytics.MachExceptionServer只是Crashlytics捕获崩溃的线程，真正触发崩溃的是前序的AXSpeech线程。即使调用栈里没有你的代码，也说明是TTS内部处理输入时出了问题，所以输入校验是核心修复方向。

内容的提问来源于stack exchange，提问作者Paul Mitchell