关于本地通知：
- 在使用通知之前必须注册通知类型，如果用户不允许应用程序发送通知，则以后就无法发送通知，除非用户手动到iOS设置中打开通知。
- 本地通知是有操作系统统一调度的，只有在应用退出到后台或者关闭才能收到通知。(注意：这一点对于后面的推送通知也是完全适用的。 ）
- 通知的声音是由iOS系统播放的，格式必须是Linear PCM、MA4（IMA/ADPCM）、µLaw、aLaw中的一种，并且播放时间必须在30s内，否则将被系统声音替换，同时自定义声音文件必须放到main boundle中。
- 本地通知的数量是有限制的，最近的本地通知最多只能有64个，超过这个数量将被系统忽略。
- 如果想要移除本地通知可以调用UIApplication的cancelLocalNotification:或cancelAllLocalNotifications移除指定通知或所有通知。
在iOS中如果点击一个弹出通知（或者锁屏界面滑动查看通知），默认会自动打开当前应用。
由于通知由系统调度那么此时进入应用有两种情况：
①如果应用程序已经完全退出那么此时会调用- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions方法；
②如果此时应用程序还在运行（无论是在前台还是在后台）则会调用-(void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification方法接收消息参数。
当然如果是后者自然不必多说，因为参数中已经可以拿到notification对象，只要读取userInfo属性即可。如果是前者的话则可以访问launchOptions中键为UIApplicationLaunchOptionsLocalNotificationKey的对象，这个对象就是发送的通知，由此对象再去访问userInfo。
关于推送通知：
和本地通知不同，推送通知是由应用服务提供商发起的，通过苹果的APNs（Apple Push Notification Server）发送到应用客户端。下面是苹果官方关于推送通知的过程示意图：
推送通知的过程可以分为以下几步：
- 应用服务提供商从服务器端把要发送的消息和设备令牌（device token）发送给苹果的消息推送服务器APNs。
- APNs根据设备令牌在已注册的设备（iPhone、iPad、iTouch、mac等）查找对应的设备，将消息发送给相应的设备。
- 客户端设备将接收到的消息传递给相应的应用程序，应用程序根据用户设置弹出通知消息。
1.应用程序注册APNs推送消息。
说明：
a.只有注册过的应用才有可能接收到消息，程序中通常通过UIApplication的registerUserNotificationSettings:方法注册，iOS8中通知注册的方法发生了改变，如果是iOS7及之前版本的iOS请参考其他代码。
b.注册之前有两个前提条件必须准备好：开发配置文件（provisioning profile，也就是.mobileprovision后缀的文件）的App ID不能使用通配ID必须使用指定APP ID并且生成配置文件中选择Push Notifications服务，一般的开发配置文件无法完成注册；应用程序的Bundle Identifier必须和生成配置文件使用的APP ID完全一致。
2.iOS从APNs接收device token，在应用程序获取device token。
说明：
a.在UIApplication的-(void)application:(UIApplication *)application didRegisterForRemoteNotificationsWithDeviceToken:(NSData *)deviceToken代理方法中获取令牌，此方法发生在注册之后。
b.如果无法正确获得device token可以在UIApplication的-(void)application:(UIApplication *)application didFailToRegisterForRemoteNotificationsWithError:(NSError *)error代理方法中查看详细错误信息，此方法发生在获取device token失败之后。
c.必须真机调试，模拟器无法获取device token。
3.iOS应用将device token发送给应用程序提供商，告诉服务器端当前设备允许接收消息。
说明：
a.device token的生成算法只有Apple掌握，为了确保算法发生变化后仍然能够正常接收服务器端发送的通知，每次应用程序启动都重新获得device token（注意：device token的获取不会造成性能问题，苹果官方已经做过优化）。
b.通常可以创建一个网络连接发送给应用程序提供商的服务器端， 在这个过程中最好将上一次获得的device token存储起来，避免重复发送，一旦发现device token发生了变化最好将原有的device token一块发送给服务器端，服务器端删除原有令牌存储新令牌避免服务器端发送无效消息。
4.应用程序提供商在服务器端根据前面发送过来的device token组织信息发送给APNs。
说明：
a.发送时指定device token和消息内容，并且完全按照苹果官方的消息格式组织消息内容，通常情况下可以借助其他第三方消息推送框架来完成。
5.APNs根据消息中的device token查找已注册的设备推送消息。
说明：
a.正常情况下可以根据device token将消息成功推送到客户端设备中，但是也不排除用户卸载程序的情况，此时推送消息失败，APNs会将这个错误消息通知服务器端以避免资源浪费（服务器端此时可以根据错误删除已经存储的device token，下次不再发送）。