本地通知ios开发的简单介绍

iOS本地通知的实现

通知的原理，在这里就不做过多的解释了，不懂的朋友可以自行Google

这里我们主要说下本地推送。

目前来说本地通知主要分为iOS 10 及 iOS 10以下两种不同方式

在iOS 10上 我们可以定义对于推送的各种快捷操作，那么我们的如何实现操作方法呢？

答案就是代理，苹果官方的API几乎都是如此！

首先 遵循 代理 UNUserNotificationCenterDelegate

实现代理方法,在实际开发中，注意对应的 categoryid

iOS 10上 还有很多操作性的API，修改通知的内容或移除通知等

上篇:iOS推送权限开发判断

下篇:iOS通知消息的处理

如有瑕疵之处，望大家不吝指教

相关问答

Q1: iOS 本地消息通知

通过调用 requestAuthorization 这个方法，通知中心会向用户发送通知许可请求。用户在弹出的Alert中心点击“同意”按钮，即可完成注册。

首先设置信息内容 UNMutableNotificationContent 和触发机制 UNNotificationTrigger ；然后用这两个值来创建 UNNotificationRequest ；最后将request加入当前通知中心 UNUserNotificationCenter.current() 中

这一步就是系统或者远程服务器推送通知的过程。伴随着一声清脆的响声（或自定义的声音），通知对应的UI会显示在手机界面中。

当用户看到通知后，点击通知后会看到相应的响应选项。 UNNotificationAction 和 UNNotificationCategory 用于设置响应选项。

AppDelegate.m

添加通知

取消通知

Q2: iOS 必知必会 - APNs篇

导语：

由于移动设备内存、CPU、电量的局限性，iOS 不允许 APP 的进程常驻后台（事实上可以申请后台运行一段时间，最长约 10 分钟），这样当用户主动杀掉 APP，或者 APP 进入后台超过约定时长时，就意味着该 APP 进程的结束。这在很大程度上保障了前台 APP 的流畅性，也延长了手机的使用时长，获得了较好的用户体验。但是这也意味着，服务器无法主动和用户交互（如推送实时消息等）。为了解决这个限制，苹果推出了 APNs，允许设备和服务器分别与苹果的推送通知服务器保持长连接状态。

iOS 的通知分为本地通知和远程通知。本地通知是由本地应用触发的，一般是基于时间的一种通知形式，如闹钟、待办事件等的提醒。远程通知是由开发商通过自己的服务器推送的一种通知形式，而 APNs 就是远程通知功能的核心。

关于远程推送，记住以下两点就够了：

这里就很清楚了，其实 APNs 的本质就是 服务器和客户端之间的中介 。当服务器需要给客户端推送消息时，先将消息发送给苹果服务器，再由苹果服务器找到对应设备推送下去。

那为什么还要走中介，不直接发送呢？因为这样做一个设备（即所有 APP ）只需要和苹果的服务器建立一条长连接，而不需要每个 APP 都和服务器建立一条长连接。

可能有些人还是不太明白 APNs 的意义，觉得也只是将多个长连接变成了统一的一个长连接而已，有必要那么做吗？

很有必要！

我们来看下 Android 的推送现状就明白了。

Android 事实上也有类似于 APNs 的一套用于推送的服务，简称 GCM，即 Google Cloud Messaging。但由于 GCM 需要谷歌服务器的支持，在国内由于「墙」的原因基本不能使用。这下就热闹了，国内出现了一大堆第三方推送服务商，如华为推送、小米推送、极光推送等。APP 通过集成这些推送服务来实现推送功能，而这些推送服务为了保持自己的长连接不被杀死，采用了各种保活、唤醒手段，这也是 Android 手机使用不流畅的真凶。之前也有看到「 工信部要求国内安卓统一消息推送标准 」的新闻，工信部都这么重视，可见统一推送的意义非凡。

想要了解具体区别，可以参考这篇文章 「 国内 90%以上的 iOS 开发者，对 APNs 的认识都是错的 」。

不言而喻，当然是尽早升级 HTTP/2 协议了。

参考:

（完）

Q3: iOS 本地推送(Local Push)

本文主要介绍了本地通知的用法，将iOS8.0和10.0以上都进行了区分，具体的使用还需要大家根据具体情况而定，希望对大家有所帮助。

最后，附上 Demo-传送门