NotificationServiceExtension
文档对此没有任何说明。在我的测试中它不起作用。所有通知都通过一个NotificationServiceExtension 处理。
通知内容扩展
对于NotificationContentExtension,文档说:
您可以将多个通知内容应用扩展添加到您的
项目,但每个都必须支持一组唯一的通知
类别。您在其指定应用程序扩展的类别
Info.plist 文件,如声明支持的通知中所述
类型。
Customizing the Appearance of Notifications
docs
我验证了☝️并且成功了! FWIW,您可以将单个通知内容扩展用于多个类别。
UNNotificationExtensionCategory(必填)
一个字符串或一个字符串数组。每个字符串都包含标识符
应用程序使用 UNNotificationCategory 声明的类别
类。
还值得一提的是NotificationServiceExtension 的默认 plist 设置如下所示:
它不与任何给定的类别相关联。我尝试添加NSExtensionAttributes,以及UNNotificationCategoryExtension 键值。但即使它编译,它也没有工作!我认为 Apple 决定如何使用通知服务扩展的方式是基于以下两个字段:
- 其 bundleID 前缀为
apns-topic 的目标
-
NSExtensionPointIdentifer 字段必须始终设置为 com.apple.usernotifications.service。 this 的值对于今天的扩展或内容通知扩展等是不同的。
因此,如果您有两个服务扩展,那么系统无法决定应该显示哪一个
但是,NotificationContentExtension 的默认 plist 设置确实有 UNNotificationCategoryExtension 键,包括值:
另外考虑这一点,如果一个应用程序有 5 个不同的类别,并且每个类别都有一个服务扩展并一次接收它们,那么它将启动 5 个不同的进程(想想 5 个并行的didFinishLaunchingWithOptions 回调. 每个类别和进程一个),这对操作系统不利。
虽然不确定,但documentation on Signal's NotificationService class 支持这一理论。
// Note that the NSE does *not* always spawn a new process to
// handle a new notification and will also try and process notifications
// in parallel. `didReceive` could be called twice for the same process,
// but will always be called on different threads. To deal with this we
// ensure that we only do setup *once* per process and we dispatch to
// the main queue to make sure the calls to the message fetcher job
// run serially.
NotificationContentExtension 并非如此。它不能一次处理 5 个 contentExtensions。因为它是一个由主线程控制的 UI。