这两天借着排查“添加的Local Notification到点没有提醒”的机会，对Local Notification, Remote Notification以及相关API做了一个梳理，发现“别有洞天”。

在iOS 8以前，苹果只提供了一个API来获取关于通知相关的东东，[[UIApplication sharedApplication] enabledRemoteNotificationTypes]，

The values in the returned bit mask indicate the types of notifications currently enabled for the app. These types are first set when the app calls the registerForRemoteNotificationTypes: method to register itself with Apple Push Notification service. Thereafter, the user may modify these accepted notification types in the Notifications preference of the Settings app. This method returns those initial or modified values.

官方文档中说，它的值取决于之前用registerForRemoteNotificationTypes注册Remote Notification时所设定的types，同时也会根据用户通知中心中的设定而变更，也就是说，enabledRemoteNotificationTypes同时会反映这两种情况。但在实际测试中，发现只要registerForRemoteNotificationTypes注册成功并生成用于发送PUSH的token，不论通知中心中app的设置如何变化（开启通知、关闭通知、单独开启声音、单独关闭提醒等），enabledRemoteNotificationTypes的值都不会改变，严格等同于之前调用registerForRemoteNotificationTypes时设定的入参。这就意味着，只要注册成功过Remote Notification一次，后续无论用户如何调整app的通知设定，enabledRemoteNotificationTypes的返回值都是一样的。

这个“特性”，对于Remote Notification可能还好，因为毕竟触发PUSH是在服务端，在发送的时候，也无法得知本地客户端的用户设置，但对于Local Notification来说，这就是“致命”的，因为根据它开发者无法判断用户是否允许Local Notification，这也就是文章开头“添加的Local Notification到点没有提醒”的原因，因为现有的判断是根据enabledRemoteNotificationTypes，而它又返回了全部3个type，但其实这时用户已经关闭了app的通知。

幸好苹果在iOS 8上解决了这个问题，引入了新的机制，把用户授权App使用本地/远程通知与Remote Notification成功注册并生成token分离开来，前者用[[UIApplication sharedApplication] registerUserNotificationSettings:]来实现，后者通过[[UIApplication sharedApplication] registerForRemoteNotifications]与AppDelegate的[application:didRegisterUserNotificationSettings:]回调来达到，并引入了[[UIApplication sharedApplication] currentUserNotificationSettings]，来同步返回用户在通知中心中的设定状态。

最后，很有意思的是，在两个版本中，当App在后台时，通知中心中此App的设定值都会影响到Local Notification是否以及如何被显示，而当在App在前台时，无论通知中心中的设置如何，Local Notification总是同样地进行显示。