这是一篇在新公司写的博客( ´ ▽ ` )ﾉ
iOS10新增的UserNotifications框架，可以应对remote notification和local notification。这两者在用户的感知上十分类似，但是实现上却几乎是两回事。所以为了思路清晰，这篇博客打算专注于介绍remote notification。
功能更新
iOS10新增的UserNotifications框架，主要有了这样几方面的更新：
- 用
UserNotifications框架替换了原先与通知相关的接口，通知文字可分为title、subtitle和body三部分，通知可携带附件 - 系统在展示通知之前，可以唤起app附带的service extension，并且允许它改动通知的内容
- 用户在对通知右滑查看、下拉或者3d touch的时候，通知会展开，展开后页面的布局可以由app附带的content extension来决定
UserNotifications框架
在iOS10中，UserNotifications框架替换了大部分原先与通知相关的接口。
注册通知
在iOS10中，想要发送通知（不管是local还是remote），首先得经过用户的许可。使用新的接口来向用户申请允许通知：
UNUserNotificationCenter *un = [UNUserNotificationCenter currentNotificationCenter];
[un requestAuthorizationWithOptions:UNAuthorizationOptionAlert | UNAuthorizationOptionSound | UNAuthorizationOptionBadge
completionHandler:^(BOOL granted, NSError * _Nullable error) {
}];
要进行remote notification，我们还需要得到用户的device token。获取device token的过程和先前一致：
[application registerForRemoteNotifications];
然后在
- (void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken;
方法中获取device token。
支持title、subtitle和body
如果要让通知支持title、subtitle和body，服务端在给出通知时，只要将payload中alert字段由字符串改为一个字典就行了。
原来的payload：
{
"apns" : {
"alert" : "This is my body",
...
}
}
推送给iOS10设备的payload：
{
"apns" : {
"alert" : {
"title" : "This is my title",
"subtitle" : "This is my subtitle",
"body" : "This is my body",
}
...
}
}
携带action的通知
其实从iOS8开始，通知已经可以携带action了。而在iOS10中，通知的action被放在了更明显的位置，与action相关的接口也有了很大变化。
如何确定决定一个通知应该有哪些action呢？在payload中，这是由category字段决定的。
{
"apns" : {
"alert" : "This is my body",
"category" : "my_category",
...
}
}
如果我们希望一个通知能携带若干个action，我们就需要将若干个action和一个category绑定起来。通知到达前端后，系统会根据category的名字来决定要给这个通知展示哪些action：
UNNotificationAction *dislikeAction = [UNNotificationAction actionWithIdentifier:@"dislike"
title:@"It's boring"
options:UNNotificationActionOptionAuthenticationRequired | UNNotificationActionOptionDestructive];
UNNotificationAction *favoriteAction = [UNNotificationAction actionWithIdentifier:@"favorite"
title:@"I like it"
options:UNNotificationActionOptionAuthenticationRequired];
UNNotificationAction *launchAction = [UNNotificationAction actionWithIdentifier:@"launch"
title:@"Launch my app"
options:UNNotificationActionOptionAuthenticationRequired | UNNotificationActionOptionForeground];
UNNotificationCategory *category = [UNNotificationCategory categoryWithIdentifier:@"my_category"
actions:@[dislikeAction, favoriteAction, launchAction]
intentIdentifiers:@[]
options:UNNotificationCategoryOptionNone];
[[UNUserNotificationCenter currentNotificationCenter] setNotificationCategories:[NSSet setWithObject:category]];
怎么得知用户选了哪个action并做出相应操作呢？这需要给UNUserNotificationCenter指定一个delegate：
[UNUserNotificationCenter currentNotificationCenter].delegate = myNotificationDelegate;
按照UNUserNotificationCenter.h中的注释，这个delegate必须在app中被注册（应该意思是不能在extension中注册），并且要在applicationDidFinishLaunching:返回之前完成：
// The delegate can only be set from an application
// The delegate must be set before the application returns from applicationDidFinishLaunching:.
然后在delegate的类中实现
// The method will be called on the delegate when the user responded to the notification by opening the application, dismissing the notification or choosing a UNNotificationAction. The delegate must be set before the application returns from applicationDidFinishLaunching:.
- (void)userNotificationCenter:(UNUserNotificationCenter *)center didReceiveNotificationResponse:(UNNotificationResponse *)response withCompletionHandler:(void(^)())completionHandler;
方法，通过response.notification.request.content.categoryIdentifier和response.actionIdentifier就可以得知用户选择的action了。
即便app已经被系统杀死，但只要用户操作了通知，这个方法就会被调用。
除了我们自定义的actionIdentifier，其实iOS还为我们定义了两个actionIdentifier，分别是
UNNotificationDefaultActionIdentifier
和
UNNotificationDismissActionIdentifier
分别表示用户点击通知唤起app，和用户清除掉了通知。
但是这里有个坑，用户点击通知本身唤起app，和用户点击某个标记了UNNotificationActionOptionForeground的action唤起app，看似是类似的操作，但在
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions;
中，前者唤起的app会携带合理的launchOption，而后者唤起的app，launchOption却为空。ʕ •ᴥ•ʔ
app在前台时展示通知
在iOS10以前，当app在前台时，通知是不会被展示在通知中心的，只能通过
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo;
方法收获到通知，然后在app内通过弹窗等方式自行展示。
但是iOS10支持当app在前台时，也在通知中心展示通知。
上一段中我们已经为UNUserNotificationCenter注册了一个delegate，在这个delegate中，实现方法：
- (void)userNotificationCenter:(UNUserNotificationCenter *)center willPresentNotification:(UNNotification *)notification withCompletionHandler:(void (^)(UNNotificationPresentationOptions options))completionHandler;
这个方法只有当app在前台收到通知时才会被调用。当这个方法实现之后，app在前台时收到通知时，通知中心也可以弹出了。同时
- (void)application:(UIApplication *)application didReceiveRemoteNotification:(NSDictionary *)userInfo;
便不会被调用了。
notification service extension
给app添加service extension后，系统会在收到通知后唤醒它，并允许它修改通知的内容，之后再展示这个通知。
service extension只对remote notification起作用，local notification是无法唤起它的。
改变通知内容
如果想要让系统唤起service extension的话，payload必须符合这样几个条件：
- 必须增加
mutable-content字段并为1，这表示允许客户端修改这个通知：
{
"apns" : {
"alert" : "This is my body",
"mutable-content" : 1,
...
}
}
- 这个通知必须展示一个alert，如果只是一个修改badge的通知的话，是不会唤起service extension的
- 静默推送是不能唤起service extension的，所以payload中不能有
"content-available" : 1字段。
在Xcode8中创建一个service extension，Xcode会自动填充模板代码，其中我们可以看到在
- (void)didReceiveNotificationRequest:(UNNotificationRequest *)request withContentHandler:(void (^)(UNNotificationContent * _Nonnull))contentHandler;
方法中，第三方程序员可以修改即将展示的通知内容。
如果这是一个带附件的通知的话，这个方法内需要启动附件的下载。
当通知的内容被更改完毕后，需要调用contentHandler()代码块，并把修改完成后的通知内容作为参数传入。
如果在指定的时间内，contentHandler()代码块都没能被调用的话，系统会调用serviceExtensionTimeWillExpire方法。
比如一个通知想要修改标题，也想下载附件，但是网络状况导致附件下载超时，serviceExtensionTimeWillExpire就回被调用。在这个方法中，程序员可以让系统展示仅修改了标题而没有附件的通知。
实践中发现的几个问题（使用Xcode8-beta6）：
- 如果
didReceiveNotificationRequest:withContentHandler:方法在执行中途crash了，那么系统会展示原始的通知； -
UNMutableNotificationContent中的title，subtitle等字段都是用copy修饰的，如果给它们赋值为nil的话，系统会展示原始的通知；
让通知携带附件
因为payload有大小限制，所以如果remote notification想要携带附件，那么payload上只能带上如附件下载地址之类的信息，等通知到达客户端后由service extension下载附件到本地，然后在初始化UNNotificationAttachment对象时传入附件在本地的URL。
NSError *error = nil;
UNNotificationAttachment *attachment = [UNNotificationAttachment attachmentWithIdentifier:@"my_identifier"
URL:localURL
options:nil
error:&error];
if (attachment) {
myUNNotificationContent.attachments = @[attachment];
}
初始化UNNotificationAttachment对象时，可以传入option参数。这里的option参数可以强制指定附件的类型，可以选择是否展示缩略图，以及缩略图截取自附件的哪一帧、哪一部分。
目前iOS10通知只将几种格式的图片、音频和视频作为附件，附件的大小也有一定限制，具体可以看官方文档中的限制说明。
notification content extension
利用content extension，用户可以自定义通知展开后的视图。
比如：
在新建了一个content extension之后，我们首先需要关注它的info.plist，其中的NSExtensionAttributes中有这样几个键值对：
- UNNotificationExtensionCategory
一个app其实可以携带多个content extension，系统通过一个叫做category的字段来区分当用户展开一个通知时，应该唤起哪一个content extension。这和action是类似的。
所以，如果想要使用content extension的话，需要在payload中增加一个category字段：
{
"apns" : {
"alert" : "This is my body",
"category" : "my_category",
...
}
}
然后在info.plist的UNNotificationExtensionCategory中填上和payload的category相同的字符串。这样，当用户展开一个通知时，这个content extension也会被系统唤起了。
category还有制作带action的通知的作用，在下文会讲到。
- UNNotificationExtensionDefaultContentHidden
如果把这个字段设为YES，那么当用户展开一个通知时，上下的通知界面就能被隐藏。
- UNNoficicationExtensionInitialContentSizeRatio
当用户展开通知时，content extension可能没能立刻加载完成，在这段短暂的时间内，界面应该有多高，就依靠这个字段来指定。
试验了一下，这个字段如果设为0是不起作用的，如果想要让通知界面尽可能小，只能设置为0.00001了。
参考
UserNotifications
Local and Remote Notifications in Depth
The Remote Notification Payload
活久见的重构 - iOS 10 UserNotifications 框架解析
