前言

由于项目需求，对基于APNs的语音播报做一个预研探究。如场景：收到转账消息，实时收到推送并播放语音。

历史方案总结, 经过多方尝试验证，以下方式都已过时

以下方案均为调研过程中无法成功的方案一览；

方案一： App收到推送，通过sound指定播放固定音频（“收到一笔转账”）。前提：mp3\caf\m4a音频文件需要内置在bundle中，推送下发时指定文件名称。缺点：无法根据具体金额播报。
方案二： App在前台收到推送时，通过AVAudioSession 或者 AVSpeechSynthesisVoice播报。缺点：1 App在前台播报时，可以通过音量键调整音量。正常的推送抵达时，音量键或者关机键会即刻中断播放推送声音，所以本方案不是真正的推送音。2 App杀死情况下无法播报。
方案三：通过通知扩展（Notification Service）播放音频。App通知扩展收到推送时，调用AVAudioSession 或者 AVSpeechSynthesisVoice 播报。可能在通知扩展刚推出的时是允许这种做法的。但现在苹果已经不支持在通知扩展中播放音频，即使调用相关函数也不会生效。
方案四：通过通知扩展（Notification Service）发送本地通知播报。App通知扩展收到推送时，顺序创建多个本地通知，每个通知都播放内置音频，从而组成一句完整的播报音频。缺点：1 苹果已不支持在通知扩展发送本地通知。2 播放推送音频时，音量键或者关机键会中断当前本地通知的音频播放。
方案五：基于VOIP的语音播报，iOS13之后苹果对VOIP做了很大的限制，必须配合CallKit使用，否则收到VOIP推送后直接中断crash，没有机会再做更多事情了。

现有方案

基于通知扩展（Notification Service）来处理推送，可以保证 App被杀死 或者 App在前后台时 都能够处理推送并实时播报。

也可以通过发送静默通知，来实时播报。收到静默通知时，App会被系统拉活然后然后执行application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable : Any]),可以在内部播放音频播报。但是由于苹果官方文档有说明，静默通知是有限制的：（所以该方式我们放弃了）

APNs若检测到较高频率的静默通知发送请求，可能会终止其发送
静默通知唤醒后台App，最多有30秒的时间处理系统回调
静默推送的优先级低，系统不能保证推送必达，大量的静默推送通知可能被系统将限制。苹果官方建议一个小时不超过2-3条静默推送
静默通知官方文档

准备工作：

需要在Bundle中内置音频文件，如（0-9，元，点）等基础音频。
设置AppGroup

当接收通知时：

读取aps中的播报数据，读取Bundle中音频文件进行合并音频（如"您收到.mp3"+"1.mp3"+"元.mp3"），输出到指定目录。
修改本次推送声音标识sound，指定合并后的音频文件播报。最后达到语音播报目的。

注意点：

需设置AppGroup，通过共享目录创建音频目录和文件。
若有指定sound:"abc.mp3"，系统会逐级查找是否有可用的abc.mp3文件：

查找AppGroup共享目录
查找App NSHomeDirectory()+"/Library/Sounds/"
查找bundle中是否有可用的abc.mp3
查找系统音频库

GitHub Demo

GitHub Demo ApnsDemo 资源文件如有侵权请联系删除。

Test Payload

建议使用SmartPush来测试推送

{
    "aps": {
        "alert": {
            "title": "title",
            "body": "body"
        },
    "transfer":"123",
     "mutable-content":1
    }
}

基于APNS的语音播报实践

前言

历史方案总结, 经过多方尝试验证，以下方式都已过时

现有方案

GitHub Demo

Test Payload