iOS实现自定义铃声（从VoIP到NSE）

一、背景

2018年，受通信监管要求，苹果国区AppStore不允许app支持CallKit。
2019年，随着iOS 13正式开放， Xcode11随之发布，苹果已不再允许将PushKit应用在非VoIP语音通话的场景上，开发者必须在接入CallKit的情况下才能使用PushKit。也就是说，通过 Xcode 11 编译的 iOS 13 系统 App，如果使用 PushKit 则必须依赖苹果 CallKit 才能正常接收VoIP推送。
结论：使用VoIP功能则无法在中国区App Store上架。

二、技术方案

VoIP

以微聊音视频铃声播放为例，在之前的方案中，微聊音视频消息会使用VoIP Push Notification，客户端在被唤醒之后将获得30s的后台运行时间，在这30s内，微聊被唤醒调起音视频页面，并播放定制铃声音频。

Notification Service Extension

新的方案是主要是利用了苹果在iOS10中推出的Notification Service Extension(以下简称NSE)，当apns的payload上带上"mutable-content"的值为1时，就会进入NSE的代码中。与Voip方案最大的不同之处是，NSE不能唤醒主应用，也不能访问主应用的文件空间，只能在Extension进程中处理相应的逻辑。在NSE中，开发者可以更改通知的内容，利用离线合成或者从后台下载的方式，生成需要播报的内容，通过自定义通知铃声的方式，达到语音播报提醒的目的。NSE方案也是苹果在WWDC2019的Session707上推荐的解决方式。

消息推送流程

UNNotificationSound

在NSE中，可以通过给UNNotificationContent中的Sound属性赋值来达到在通知弹出时播放一段自定义音频的目的。

// The sound file to be played for the notification. The sound must be in the Library/Sounds folder of the app's data container or the Library/Sounds folder of an app group data container. If the file is not found in a container, the system will look in the app's bundle.
文档中明确描述了音频文件的存储路径，以及读取的优先级：

1.主应用中的Library/Sounds文件夹中
2.AppGroups共享目录中的Library/Sounds文件夹中
3.main bundle中

自定义铃声支持的声音格式包括，aiff、wav以及caf格式，铃声的长度必须小于30s，否则系统会播放默认的铃声。
锁屏情况下，铃声可以持续30s（与NES强制结束时间一致）在亮屏情况下铃声只能持续5s，是系统行为限制。
而且由于是通知铃声，声音是默认跟静音开关的。

AppGroups

由于我们是在NSE中自定义铃声，所以1和3这两个文件路径我们是无法访问的。只能将合成好或者下载到语音音频文件存储到AppGroups下的Library/Sounds文件夹中，需要在Capablities中打开这个AppGroups的能力，即可通过NSFileManager的containerURLForSecurityApplicationGroupIdentifier:方法访问AppGroups的根目录。

示例代码：

    NSFileManager *fileManager = [NSFileManager defaultManager];
    NSURL *containerUrl = [fileManager containerURLForSecurityApplicationGroupIdentifier:@"group.com.wchat.share"];
    
    NSString *newPath = [containerUrl.path stringByAppendingPathComponent:@"Library/Sounds"];
    // 清理本地缓存，删除sounds文件夹（可选）
    [fileManager removeItemAtPath:newPath error:nil];
    
    if (![fileManager fileExistsAtPath:newPath]) {
        [fileManager createDirectoryAtPath:newPath withIntermediateDirectories:NO attributes:nil error:nil];
    }
    NSURL *localURL = [NSURL fileURLWithPath:[newPath stringByAppendingPathComponent:[NSString stringWithFormat:@"/%@.%@", identifier, fileType]]];
    [fileManager moveItemAtURL:temporaryFileLocation toURL:localURL error:&error];

    //设置播发音频 文件名sname.sfileType
    self.bestAttemptContent.sound = [UNNotificationSound soundNamed:[NSString stringWithFormat:@"%@.%@", sname, sfileType]];

三、开发过程中遇到的问题

消息播放队列

NSE方案有个问题是：当客户端短时间内收到多条播报通知时，后面的通知会顶掉前面的通知，导致前面的通知播报不完整。所以需要增加一个消息队列，将所有需要播报的通知都添加到队列中，当前面的消息播放完毕后，再播放后面的消息。

多线程问题

要注意的是，NSE的代码逻辑并不是在主App工程中执行的。一方面避免了开发者在NSE由于代码设计失误导致前台的其他应用界面卡住的问题，另一方面是主工程此时已被挂起或者已被kill掉，NSE本质是push部分而不是调起主App。
所以我们在处理上面提到的消息播放队列，以及涉及到文件读写的逻辑上，需要给相应的代码逻辑加锁，否则会出现多线程问题。

四、NSE扩展

iOS Notification Service Extension 共享空间数据互通测试

五、相关资料

Advances in App Background Execution - 2019
UNNotificationServiceExtension