一、消息推送系统设计需求

1、高性价比，在有限的硬件资源下，尽可能的提高消息系统的性能和可用性。

2、提高数据的一致性。




二、分析

消息推送，按数据量划分，包括两类：

1）持续的大量数据（比如：持续的物联网GPS上报等）推送，单类数据量大于 10 kb 每秒 。

2）低频率、数据量小的偶发事件、通知类的数据推送。




消息重要性和实时性分级：（ “四象限” 划分）

                            不重要                            |                          不重要

                            可延时                            |                          低延时

                            ——————————————————————

                            很重要                            |                          很重要

                            可延时                            |                          低延时

        备注：

                  很重要  =  非常重要，数据不丢、不乱。

                  不重要  =  可接受偶尔出现问题。

                  低延时  =  延时低（平均在3秒以内）。

                  可延时  =  有一定延时（3秒以上）。

 

大部分消息处于 (2) (3) (4) 象限。针对消息的特性，应采用不同性能和稳定级别的推送方案。










根据 CAP 定理：

    Consistency(一致性), 数据一致更新，所有数据变动都是同步的。

    Availability(可用性), 好的响应性能。

    Partition tolerance(分区容错性) 可靠性。

    定理：任何分布式系统只可同时满足二点，没法三者兼顾。

没有一个分布式系统是C、A、P同时都达到完美的，要么损失性能来保障一致性和可用性；要么损失一致性来提高性能。

理想模型如下：

A、牺牲 性能 来提高 可用性和一致性。

B、牺牲 一致性 来提高 性能和可用性。

C、牺牲 可用性 来提高 性能和一致性。

对于上面的 A 模型，用得非常广泛，比如消息的ACK机制，用法比较简单，不多说。

对于上面的 B 模型，经常使用 BASE （牺牲高一致性，保证最终一致性） 方案。

    Basically Available 基本可用。

    Soft state 软状态 状态可以有一段时间不同步，异步。

    Eventually consistent 最终一致，最终数据是一致的就可以了，而不是实时高一致。

对于上面的 C 模型，用得比较少，也不好理解。牺牲可用性，来保证一致性和性能，我的理解是，除非服务不可用，否则服务一定是高性能且高一致性的。

也就是说，当服务不能保证一致性和高性能的时候，就降低可用性，宁愿服务不可用，也不能让服务出现不一致或者性能低的情况。

C模型的关键点在于，C模型的系统，系统自身不保证高可用，出现异常（性能降低或者一致性出现问题）时，它有意降低可用性，来保障服务期间的高性能和数据的强一致性。

所以如果使用C模型，则需要考虑，如何通过外部手段来保证系统的可用性（加强监控，出现不可用时，人工介入恢复，或者启动临时方案）。

延伸知识：分布式系统的容错模式

电路熔断器模式(Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失。在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时，调用方能够主动熔断，以防止服务被进一步拖垮或者导致其他系统故障（雪崩效应）；如果情况又好转了，电路又能自动恢复，这就是所谓的弹性容错，系统有自恢复能力。

参考文章：http://www.infoq.com/cn/articles/basis-frameworkto-implement-micro-service/

 

上面的A、B、C模型对于推送系统来说，

对于上面处于(2) 象限的消息推送，可以考虑 能否采用上面 C模型，如果不能接受C模型的服务（暂时）不可用，则可能会降级为 A、B 模型，A模型牺牲性能，整个系统是否存在性能问题？B模型牺牲一致性，是否能采用软状态、最终一致性方案来弥补？

对于上面处于(3) 象限的消息推送，宜采用 A 模型。

对于上面处于(4) 象限的消息推送，宜采用 B 模型，A模型也可以，具体视情况而定。







A模型数据推送系统设计方案

 

在A模型中，性能不是关键。它的关键词：性能不是瓶颈  数据要准确可靠

 

考虑点：

  1、如何保证数据100%不丢失？

  2、如何保证数据100%不重复？

 

不丢失：数据来后，先以最稳当的方式持久化下来，再推送出去，推送成功后，才删掉持久化的数据，否则数据一直持久化直到超过保存容量或者时间上限。（如果使用数据库，可以考虑事务）

不重复：能够识别每条数据的唯一性（最简单的办法就是每条数据有一个唯一标识），在内存数据库中保存一段时间已推送的数据标识（ID）的列表，当新的数据来了之后，和数据标识列表中的ID进行比较，如果存在则说明之前已经推送过这条数据，直接pass，否则推送数据并加入数据标识列表。

 

技术选型和系统处理数据流程：（纯Java + Redis缓存ID + 本地磁盘缓存数据）

1）收到数据后，先将数据ID取出，去Redis里已推送的数据ID的列表中查找，如果找到这个ID，则说明数据已处理过，重复了，则丢弃该数据。否则继续下面的步骤。

2）将数据和ID用Producer线程尽快写入本地磁盘，以防丢失。

3）然后用Consumer线程将数据从磁盘读取出来，然后尝试推送出去。

4）如果推送成功，则标记该ID的数据为success并保存到磁盘，然后继续处理后面的数据。否则暂停或关闭接收 后续的数据（如果可以），如果不能暂停，则直接进入下面的第(5)步骤），

5）无限尝试推送当前数据，直到故障解除，当前数据推送成功，

7）故障解除时，如果之前暂停或关闭了数据接收，则将其恢复。

8）继续从磁盘取后面未处理的数据。

9）定期触发一个异步线程去清理磁盘上推送成功的数据，保持磁盘空间良好。

其他说明：

1）尽量将多种消息合并在一个线程处理，如果技术或者业务上不能在一个线程去处理，则另起线程（或进程），与其他线程（或进程）隔离、数据完全独立。

2）尽量控制在单机处理，如果一台机器不够，则多加几台机器，但每台机器处理的数据完全独立。

3）数据缓存在本地磁盘上，只是一种简单高效的策略，但使用不够方便，也不便于管理，如果有高可用、高性能的redis，则建议建将数据缓存在redis上。次之，可以换成mysql，如果网络环境稳定，可以连远程mysql，否则可以将mysql和应用安装在同一台服务器上。另外，也可以用sqlite文件数据库。

 

 

B模型数据推送系统设计方案

 

B模型的系统，不保证数据一致性。它的关键词：性能和可用性优先。

 

设想这种场景：

一天有1亿的数据要推送出去，但是在处理某条数据的时候报错了，且重试了3次仍然不成功，后面还有大量数据等着推送，线程不能阻塞，那么只能将推送失败的数据记录下来，继续处理后面来的数据。

 

可以在 数据推送失败或者接收方响应非常缓慢时，将数据记录下来（比如记日志，供人工排查补数据；或者转存kafka，由补偿程序处理），然后继续接收后面的数据继续推送。

 

首先，我们将容易产生故障的业务和数据分类，将容易发生故障的数据与其他数据隔离，以保证发生故障时，不影响其他数据的处理。

 

根据业务场景，按照数据分类，用单独的线程处理，做故障隔离（某个线程发生故障时，不影响其他线程）。

 

其次，在故障发生持续时间长，或者故障发生频繁的场景下，可能不适合用B模型，因为B模型不保证数据一致性，故障发生得越多，数据问题就会越严重，处理起来越麻烦。

 

在推送数据项目里，如果发生故障可能持续时间很长，数据堆积很多，有这种情况下，就不建议使用B方案。

在故障发生率低、故障持续时间短的前提下，可以如下操作：

  如果推送失败，不要阻塞后面的数据，采用将数据记录下来（放内存里面），等后面一批数据来后，同时处理，再次推送，如果这次推送仍然失败，则再重复这个过程，一共重试3~5次，如果都失败则进入C方案的流程（下面会讲）。

上面这个方案，可以在故障持续时间短的情况下，解决推送问题。

 

 

C模型数据推送系统设计方案

 

C模型的系统，不保证系统高可用，换句话说，它宁愿系统不可用，也要保证在系统可用的时间段内系统的高性能和数据的强一致性。它的关键词：牺牲可用性 换一致性和性能。

 

可以在 数据推送失败或者接收方响应非常缓慢时，且在C方案的补偿机制下，系统仍无好转，则关闭该数据的推送，同时触发监控程序，通知人工处理，或者由 故障处理程序 去处理。

 

根据具体的业务场景，如果当某类数据多次无法推送时，主动关闭该数据的推送，同时触发监控程序，通知维护人员，由维护人员决定，是否去处理故障，如果不需要处理，则该数据就一直关闭，如果需要处理，则当故障恢复时，重新启动该数据的推送任务。也可以由monitor主动去监控数据推送是否恢复正常，恢复正常后，自动恢复推送。





一、消息推送系统设计需求

1、高性价比，在有限的硬件资源下，尽可能的提高消息系统的性能和可用性。

2、提高数据的一致性。




二、分析

消息推送，按数据量划分，包括两类：

1）持续的大量数据（比如：持续的物联网GPS上报等）推送，单类数据量大于 10 kb 每秒 。

2）低频率、数据量小的偶发事件、通知类的数据推送。




消息重要性和实时性分级：（ “四象限” 划分）

                            不重要                            |                          不重要

                            可延时                            |                          低延时

                            ——————————————————————

                            很重要                            |                          很重要

                            可延时                            |                          低延时

        备注：

                  很重要  =  非常重要，数据不丢、不乱。

                  不重要  =  可接受偶尔出现问题。

                  低延时  =  延时低（平均在3秒以内）。

                  可延时  =  有一定延时（3秒以上）。

 

大部分消息处于 (2) (3) (4) 象限。针对消息的特性，应采用不同性能和稳定级别的推送方案。










根据 CAP 定理：

    Consistency(一致性), 数据一致更新，所有数据变动都是同步的。

    Availability(可用性), 好的响应性能。

    Partition tolerance(分区容错性) 可靠性。

    定理：任何分布式系统只可同时满足二点，没法三者兼顾。

没有一个分布式系统是C、A、P同时都达到完美的，要么损失性能来保障一致性和可用性；要么损失一致性来提高性能。

理想模型如下：

A、牺牲 性能 来提高 可用性和一致性。

B、牺牲 一致性 来提高 性能和可用性。

C、牺牲 可用性 来提高 性能和一致性。

对于上面的 A 模型，用得非常广泛，比如消息的ACK机制，用法比较简单，不多说。

对于上面的 B 模型，经常使用 BASE （牺牲高一致性，保证最终一致性） 方案。

    Basically Available 基本可用。

    Soft state 软状态 状态可以有一段时间不同步，异步。

    Eventually consistent 最终一致，最终数据是一致的就可以了，而不是实时高一致。

对于上面的 C 模型，用得比较少，也不好理解。牺牲可用性，来保证一致性和性能，我的理解是，除非服务不可用，否则服务一定是高性能且高一致性的。

也就是说，当服务不能保证一致性和高性能的时候，就降低可用性，宁愿服务不可用，也不能让服务出现不一致或者性能低的情况。

C模型的关键点在于，C模型的系统，系统自身不保证高可用，出现异常（性能降低或者一致性出现问题）时，它有意降低可用性，来保障服务期间的高性能和数据的强一致性。

所以如果使用C模型，则需要考虑，如何通过外部手段来保证系统的可用性（加强监控，出现不可用时，人工介入恢复，或者启动临时方案）。

延伸知识：分布式系统的容错模式

电路熔断器模式(Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器，如果家里的电路发生短路，熔断器能够主动熔断电路，以避免灾难性损失。在分布式系统中应用电路熔断器模式后，当目标服务慢或者大量超时，调用方能够主动熔断，以防止服务被进一步拖垮或者导致其他系统故障（雪崩效应）；如果情况又好转了，电路又能自动恢复，这就是所谓的弹性容错，系统有自恢复能力。

参考文章：http://www.infoq.com/cn/articles/basis-frameworkto-implement-micro-service/

 

上面的A、B、C模型对于推送系统来说，

对于上面处于(2) 象限的消息推送，可以考虑 能否采用上面 C模型，如果不能接受C模型的服务（暂时）不可用，则可能会降级为 A、B 模型，A模型牺牲性能，整个系统是否存在性能问题？B模型牺牲一致性，是否能采用软状态、最终一致性方案来弥补？

对于上面处于(3) 象限的消息推送，宜采用 A 模型。

对于上面处于(4) 象限的消息推送，宜采用 B 模型，A模型也可以，具体视情况而定。







A模型数据推送系统设计方案

 

在A模型中，性能不是关键。它的关键词：性能不是瓶颈  数据要准确可靠

 

考虑点：

  1、如何保证数据100%不丢失？

  2、如何保证数据100%不重复？

 

不丢失：数据来后，先以最稳当的方式持久化下来，再推送出去，推送成功后，才删掉持久化的数据，否则数据一直持久化直到超过保存容量或者时间上限。（如果使用数据库，可以考虑事务）

不重复：能够识别每条数据的唯一性（最简单的办法就是每条数据有一个唯一标识），在内存数据库中保存一段时间已推送的数据标识（ID）的列表，当新的数据来了之后，和数据标识列表中的ID进行比较，如果存在则说明之前已经推送过这条数据，直接pass，否则推送数据并加入数据标识列表。

 

技术选型和系统处理数据流程：（纯Java + Redis缓存ID + 本地磁盘缓存数据）

1）收到数据后，先将数据ID取出，去Redis里已推送的数据ID的列表中查找，如果找到这个ID，则说明数据已处理过，重复了，则丢弃该数据。否则继续下面的步骤。

2）将数据和ID用Producer线程尽快写入本地磁盘，以防丢失。

3）然后用Consumer线程将数据从磁盘读取出来，然后尝试推送出去。

4）如果推送成功，则标记该ID的数据为success并保存到磁盘，然后继续处理后面的数据。否则暂停或关闭接收 后续的数据（如果可以），如果不能暂停，则直接进入下面的第(5)步骤），

5）无限尝试推送当前数据，直到故障解除，当前数据推送成功，

7）故障解除时，如果之前暂停或关闭了数据接收，则将其恢复。

8）继续从磁盘取后面未处理的数据。

9）定期触发一个异步线程去清理磁盘上推送成功的数据，保持磁盘空间良好。

其他说明：

1）尽量将多种消息合并在一个线程处理，如果技术或者业务上不能在一个线程去处理，则另起线程（或进程），与其他线程（或进程）隔离、数据完全独立。

2）尽量控制在单机处理，如果一台机器不够，则多加几台机器，但每台机器处理的数据完全独立。

3）数据缓存在本地磁盘上，只是一种简单高效的策略，但使用不够方便，也不便于管理，如果有高可用、高性能的redis，则建议建将数据缓存在redis上。次之，可以换成mysql，如果网络环境稳定，可以连远程mysql，否则可以将mysql和应用安装在同一台服务器上。另外，也可以用sqlite文件数据库。

 

 

B模型数据推送系统设计方案

 

B模型的系统，不保证数据一致性。它的关键词：性能和可用性优先。

 

设想这种场景：

一天有1亿的数据要推送出去，但是在处理某条数据的时候报错了，且重试了3次仍然不成功，后面还有大量数据等着推送，线程不能阻塞，那么只能将推送失败的数据记录下来，继续处理后面来的数据。

 

可以在 数据推送失败或者接收方响应非常缓慢时，将数据记录下来（比如记日志，供人工排查补数据；或者转存kafka，由补偿程序处理），然后继续接收后面的数据继续推送。

 

首先，我们将容易产生故障的业务和数据分类，将容易发生故障的数据与其他数据隔离，以保证发生故障时，不影响其他数据的处理。

 

根据业务场景，按照数据分类，用单独的线程处理，做故障隔离（某个线程发生故障时，不影响其他线程）。

 

其次，在故障发生持续时间长，或者故障发生频繁的场景下，可能不适合用B模型，因为B模型不保证数据一致性，故障发生得越多，数据问题就会越严重，处理起来越麻烦。

 

在推送数据项目里，如果发生故障可能持续时间很长，数据堆积很多，有这种情况下，就不建议使用B方案。

在故障发生率低、故障持续时间短的前提下，可以如下操作：

  如果推送失败，不要阻塞后面的数据，采用将数据记录下来（放内存里面），等后面一批数据来后，同时处理，再次推送，如果这次推送仍然失败，则再重复这个过程，一共重试3~5次，如果都失败则进入C方案的流程（下面会讲）。

上面这个方案，可以在故障持续时间短的情况下，解决推送问题。

 

 

C模型数据推送系统设计方案

 

C模型的系统，不保证系统高可用，换句话说，它宁愿系统不可用，也要保证在系统可用的时间段内系统的高性能和数据的强一致性。它的关键词：牺牲可用性 换一致性和性能。

 

可以在 数据推送失败或者接收方响应非常缓慢时，且在C方案的补偿机制下，系统仍无好转，则关闭该数据的推送，同时触发监控程序，通知人工处理，或者由 故障处理程序 去处理。

 

根据具体的业务场景，如果当某类数据多次无法推送时，主动关闭该数据的推送，同时触发监控程序，通知维护人员，由维护人员决定，是否去处理故障，如果不需要处理，则该数据就一直关闭，如果需要处理，则当故障恢复时，重新启动该数据的推送任务。也可以由monitor主动去监控数据推送是否恢复正常，恢复正常后，自动恢复推送。

zzz~

Android端进程被杀死后，目前自带的保护后台接收消息活跃机制。暂时没有什么好的机制保持任何情况下都活跃
文章参考：http://blog.csdn.net/marswin89/article/details/50917098
android原生系统用home键杀进程可以起来，如果是强行停止就只能用户自己手动开启应用
如果是miui等第三方应用，杀了进程默认无法自启动

如果是root过的原生系统，杀了进程也是没有办法起来的，这个时候推送是收不到的




如果是原生系统，没有root，只要不是强行停止，其他系统自带的停止方式都可以自启动，一般10s内恢复




目前已知以下第三方系统会影响到应用：

小米【MIUI】

        自启动管理：需要把应用加到【自启动管理】列表，否则杀进程或重新开机后进程无法开启

        通知栏设置：应用默认都是显示通知栏通知，如果关闭，则收到通知也不会提示
华为【Emotion】

        自启动管理：需要把应用加到【自启动管理】列表，否则杀进程或重新开机后进程不会开启，只能手动开启应用

        后台应用保护：需要手动把应用加到此列表，否则设备进入睡眠后会自动杀掉应用进程，只有手动开启应用才能恢复运行

        通知管理：应用状态有三种：提示、允许、禁止。禁止应用则通知栏不会有任何提醒
魅族【Flyme】

        自启动管理：需要把应用加到【自启动管理】列表，否则杀进程或重新开机后进程发开启

        通知栏推送：关闭应用通知则收到消息不会有任何展示
VIVO【Funtouch OS】

        内存一键清理：需要将应用加入【白名单】列表，否则系统自带的“一键加速”，会杀掉进程

        自启动管理：需要将应用加入“i管家”中的【自启动管理】列表，否则重启手机后进程不会自启。但强制手动杀进程，即使加了这个列表中，后续进程也无法自启动。
OPPO【ColorOS】

        冻结应用管理：需要将应用加入纯净后台，否则锁屏状态下无法及时收到消息
        自启动管理：将应用加入【自启动管理】列表的同时，还需要到设置-应用程序-正在运行里锁定应用进程，否则杀进程或者开机后进程不会开启，只能手动开启应用




目前推送的保活机制基本上都是
一.依赖于系统广播的接收调用
常用的有：1.锁屏解锁广播2.网络状态改变广播3.安装包广播，卸载包广播4.存储器挂载卸载广播
android.intent.action.USER_PRESENT

android.net.conn.CONNECTIVITY_CHANGE

android.net.wifi.RSSI_CHANGED

android.net.wifi.STATE_CHANGE

android.net.wifi.WIFI_STATE_CHANGED
android.intent.action.MEDIA_UNMOUNTED

android.intent.action.MEDIA_REMOVED

android.intent.action.MEDIA_CHECKING

android.intent.action.MEDIA_EJECT
二.依赖于同一个手机上不同APP使用相同的SDK来相互拉起对方
通过LBE安全大师看QQ能通过个推，JPUSH，小米推送，微信开放平台接口广播，新浪SAE云推送,qq浏览器推送状态广播，手机QQ广播接收等多种推送方式相互唤醒
是否可以尝试按照QQ方式去实现。
尝试用com.tencent.mm包名，在魅族NOTE2上，在另外zzh中创建了个服务，服务里每隔一秒打印test，发现正常通过菜单关闭都可以继续执行，此时例子APP到缓存进程中继续运行，关闭缓存进程才彻底关闭。
QQ当我在魅族NOTE2上，把正在运行和缓存进程中的QQ杀掉后，并且没有其他QQ能唤醒的情况下，QQ也无法收到推送消息。
三.是否可以尝试依赖于某个手机自身的推送服务
逐个判断当前推送方式是否能成功，如果不能成功就换下种推送方式推送
或者在用户登陆APP后反馈登陆信息，根据反馈信息来首先使用当前手机得推送服务。
魅族没有自己的推送服务，此路不通
四.看到360手机助手怎么杀都杀不死
找到一个root的手机，如果不行就找个360一键root，adb shell进入后，执行su命令，当时root权限后，就进入到data/app中，把我需要的com.qihoo.appstore文件中base.apk复制到某个可以用文件夹（例如/mnt/sdcard/tmp）中，然后adb pull /mnt/sdcard/tmp c:\ 中，再通过反编译编译出代码，看看实现。
发现它有个deamon守护进程的库，libCoreDaemon.so看看怎么使用，发现一直无法加载该库，System.loadLibrary(“CoreDaemon”);报错，无法加载






1.尝试在魅族上使用微信的包名，发现通过菜单关闭APP，后台服务依然存在可以执行

2.反编译出360的JAVA代码，查看保活机制，没看懂，尝试使用它的第三方，发现无法加载

3.尝试集成了信鸽和JPUSH两个推送，发现存活率依然不高

4.尝试集成多个手机系统的消息推送，发现VIVO，魅族等没有推送服务

5.尝试闹钟唤醒，闹钟在5.1随着APP关闭也无效

6.GITHUB上找例子  JNI开启服务不行     前台服务也不行    双JAVA服务也不行

7.尝试ROOT后使用系统权限   没有ROOT方式，暂时没尝试

8.两个APP采用不同用户，一个关闭去拉起另外一个     暂时没有尝试

9.尝试微信或者QQ是否有广播，可以唤醒我们APP      没有发现什么广播可以唤醒

10.尝试单独起个接收器，接收所有推送的守护进程广播，来启动我们自己的服务  LBE显示有相互唤醒路径，但是没有唤醒服务   没有唤醒






在上面基本上又做了新的尝试
问题点1.JNI运行在哪里   启动服务  确认下通过任务管理器关闭掉APP后C进程是否存在

动态链接库文件，是一种不可执行的二进制程序文件，它允许程序共享执行特殊任务所必需的代码和其他资源,只是加载到内存一种资源文件,仅测试和java属于同一个进程，不同线程

java虚拟机类似于一个沙箱，应用程序进程共享zygote的同一套JAVA核心库，Android的进程和线程其实是和liunx进程管理保持一致，Android里fork创建进程,clone创建线程

am startservice -n com.uhealth.member/cn.jpush.android.service.DaemonService 包名/类名

推送是通过

am startservice -a cn.jpush.android.intent.DaemonService 相互唤醒

魅族把静态注册广播接收器进程没启动时，不给启动，也就是自启动管理设置的

服务：

packageManagerService解析APK，负责安装，及/data下目录生产，并在内存存储了所有组件的信息（Acitivity,Service），并对外提供数据查询

ActivityManagerService  管理ActivityRecord和TaskRecord，processRecord,并根据uid和processname去看是否需要创建新的进程,创建新进程是发消息给zygote，给新进程绑定Application，然后最后启动Activity或Service

问题点2.自启动试试是否可以

Flyme3.1设置开机自启：可以在设置—应用控制—开机启动进行设置。

Flyme4.0设置开机自启：可以在设置—应用管理—（点击需设置的软件）—权限管理—自启动，点击即可关闭或打开。  打开自启动确实可以重启

所谓的自启动管理，就是把静态注册的广播接收器进程没启动时无法接收广播，当DEMO程序自启动打开时，收到发送广播也会自动启动

对外暴露的服务是可以通过广播启动
问题点3：
尝试生成子进程的子进程，然后把子进程杀掉，看是否可以形成360的依赖于init的子进程特例

360并不是通过生成子进程，然后杀掉父进程来连接上的

通过JAVA层新建2个进程，2个进程里2个JAVA服务，一个java服务service1去唤醒另外一个JAVA服务service2，service2里会启动一个C线程，并创建其子进程，然后通过命令杀掉service2所在的进程，此时子进程就成为了init的子进程，子进程一直在运行，然后通过任务管理器关闭DEMO程序，没有自启动




本文内容转载至 ：https://blog.csdn.net/z157794218/article/details/51657444

消息推送，即时通信，目的：想办法让服务器能够及时的通知客户端

消息推送最简单的方法就是使用第三方的，比如现在使用比较多的是小米推送、极光推送，消息推送的技术原理是：移动无线网络长连接



实现方案



1、轮询

客户端每隔一定的时候就向服务器发出请求，获得最新的信息。特点：

如果用在最新新闻通知上，那么效率就比较低了。
技术简单，好现实。
应用场景：当服务器端的数据以固定的频率更新，比如 股票行情。



2、发短信

特点：效率高，最及时，同时，费用也是最高的。 

应用场景：比较土毫的做法，不差钱。



3、使用第三方的开源项目

AndroidPN ( android push notify) 



4、使用第三方的API实现推送功能

小米推送，百度推送、极光推送、个推、微信推送

实现方式3和4原理上都属于消息推送。

消息推送 的实现原理：Socket长联接 + 心跳桢

XMPP 网络上开源的，用于网络聊天的网络协议

asmack.jar jar包是对xmpp协议的实现



推送原理

xmpp 是一种基于TCP/IP的协议, 这种协议更适合消息发送
socket 套接字, 发送和接收网络请求
长连接 keep-alive, 服务器基于长连接找到设备,发送消息
心跳包 , 客户端会定时(30秒一次)向服务器发送一段极短的数据,作为心跳包, 服务器定时收到心跳,证明客户端或者,才会发消息.否则将消息保存起来,等客户端活了之后(重新连接),重新发送.

  
客户端轮询(客户端定时主动拉取数据), 浪费流量, 浪费性能 

  谷歌推送服务(不能用,被墙了)


移动互联网络的现状

因为手机平台本身、电量、网络流量的限制，移动互联网应用在设计上跟传统PC 上的应用很大不一样，需要根据手机本身的特点，尽量的节省电量和流量，同时又要尽可能的保证数据能及时到达客户端。为了解决数据同步的问题，在手机平台上，常用的方法有2种。

一种是定时去服务器上查询数据，也叫Polling，还有一种手机跟服务器之间维护一个TCP 长连接，当服务器有数据时，实时推送到客户端，也就是我们说的Push。从耗费的电量、流量和数据送达的及时性来说，Push 都会有明显的优势，但Push 的实现和维护成本相对较高。在移动无线网络下维护长连接，相对也有一些技术上的难度



移动无线网络的特点

因为IP v4 的IP 量有限，运营商分配给手机终端的IP 是运营商内网的IP，手机要连接Internet，就需要通过运营商的网关做一个网络地址转换（Network Address Translation，NAT）。简单的说运营商的网关需要维护一个外网IP、端口到内网IP、端口的对应关系，以确保内网的手机可以跟Internet 的服务器通讯。

对于大部分移动无线网络运营商都在链路一段时间没有数据通讯时，会淘汰NAT 表中的对应项，造成链路中断。



Android 平台上长连接的实现

为了不让NAT 表失效，我们需要定时的发心跳，以刷新NAT 表项，避免被淘汰。Android 上定时运行任务常用的方法有2种，一种方法用Timer，另一种是AlarmManager。



Timer

Android 的Timer 类可以用来计划需要循环执行的任务，Timer 的问题是它需要用WakeLock 让CPU 保持唤醒状态，这样会大量消耗手机电量，大大减短手机待机时间。这种方式不能满足我们的需求。



AlarmManager

AlarmManager 是Android 系统封装的用于管理RTC 的模块，RTC (Real Time Clock) 是一个独立的硬件时钟，可以在CPU 休眠时正常运行，在预设的时间到达时，通过中断唤醒CPU。这意味着，如果我们用AlarmManager 来定时执行任务，CPU 可以正常的休眠，只有在需要运行任务时醒来一段很短的时间。极光推送的Android SDK 就是基于这种技术实现的。



服务器设计

当有大量的手机终端需要与服务器维持长连接时，对服务器的设计会是一个很大的挑战。假设一台服务器维护10万个长连接，当有1000万用户量时，需要有多达100台的服务器来维护这些用户的长连接，这里还不算用于做备份的服务器，这将会是一个巨大的成本问题。那就需要我们尽可能提高单台服务器接入用户的量，也就是业界已经讨论很久了的C10K 问题。

上面只是针对极光推送来说，下面是具体的消息推送的一般有的方式：



通过SMS进行服务器端和客户端的交流通信

在Android平台上，你可以通过拦截SMS消息并且解析消息内容来了解服务器的意图，可以实现完全的实时操作。但是问题是这个方案的成本相对比较高，且依赖于运营商



循环主动定时获取

这种方法需要客户端来做一个定时或者周期性的访问服务器端接口，以获得最新的消息。轮询的频率太慢可能导致某些消息的延迟，太快则会大量消耗网络带宽和电池



持久连接

这个方案可以解决由轮询带来的性能问题，但是还是会消耗手机的电池。我们需要开一个服务来保持和服务器端的持久连接（苹果就和谷歌的C2DM是这种机制）。但是对于Android系统，当系统可用资源较低，系统会强制关闭我们的服务或者是应用，这种情况下连接会强制中断。（Apple的推送服务之所以工作的很好，是因为每一台手机仅仅保持一个与服务器之间的连接，事实上C2DM也是这么工作的。即所有的推送服务都是经由一个代理服务器完成的，这种情况下只需要和一台服务器保持持久连接即可。C2DM=Cloud to Device Messaging）。

相比之下第三种还是最可行的。为软件编写系统服务或开机启动功能；或者如果系统资源较低，服务被关闭后可以在onDestroy ()方法里面再重启该服务，进而实现持久连接的方式。

C2DM内置于Android的2.2系统上，无法兼容老的1.6到2.1系统；且依赖于Google官方提供的C2DM服务器，由于国内的网络环境，这个服务经常不可用。

建立在TCP协议之上的XMPP协议，不仅可提供可这种持久连接的功能，能实现服务器和客户机的双工通信，还能不依赖与系统版本和google服务器的限制，提供了比较好的解决方案。



小米消息推送服务

目前用的最多的，也是最稳定消息推送服务，http://dev.xiaomi.com/console/appservice/push.html



极光推送

1.UILocalNotification：调度创建
// 创建一个本地推送
    UILocalNotification *notification = [[UILocalNotification alloc] init];
    //设置10秒之后
    //如果设置为立即推送可以不设置pushdate
    NSDate *pushDate = [NSDate dateWithTimeIntervalSinceNow:10];
    
    if (notification != nil) {
        // 设置推送时间
        notification.fireDate = pushDate;
        // 设置时区
        notification.timeZone = [NSTimeZone defaultTimeZone];
        // 设置重复间隔
        notification.repeatInterval = kCFCalendarUnitDay;
        // 推送声音
        notification.soundName = UILocalNotificationDefaultSoundName;
        // 推送内容
        notification.alertBody = @"推送内容";
        //显示在icon上的红色圈中的数子
        notification.applicationIconBadgeNumber = 1;
        //设置userinfo 方便在之后需要撤销的时候使用
        NSDictionary *info = [NSDictionary dictionaryWithObject:@"name"forKey:@"key"];
        notification.userInfo = info;
        //添加推送到UIApplication
        UIApplication *app = [UIApplication sharedApplication];
        //立即推送用 [app presentLocalNotificationNow:notification];
        [app scheduleLocalNotification:notification];
    }

2.UILocalNotification：获取通知
若果是(远程通知)Remote Notifications需要注册，这里本地通知不需要
获取通知分多种情况
1.通知发送，APP没有在前台运行，这个时候系统会执行该通知（以横幅，警告，声音提醒，标记 的形式）
 a.当用点击通知消息的时候，系统打开运行APP
 这时由方法application:didFinishLaunchingWithOptions:接受通知信息
- (BOOL)application:(UIApplication *)application didFinishLaunchingWithOptions:(NSDictionary *)launchOptions
{
    UILocalNotification *localNotif =
    [launchOptions objectForKey:UIApplicationLaunchOptionsLocalNotificationKey];
    if (localNotif) {
        NSString *itemName = [localNotif.userInfo objectForKey:@"key"];
        UIAlertView *alertView = [[UIAlertView alloc]
                                  initWithTitle:itemName
                                  message:@"推送测试信息－－didFinishLaunchingWithOptions"
                                  delegate:self
                                  cancelButtonTitle:@"关闭"
                                  otherButtonTitles:nil, nil];
        [alertView show];
        [[UIApplication sharedApplication] setApplicationIconBadgeNumber:0];
        [[UIApplication sharedApplication] cancelLocalNotification:localNotif];
    }
    
    /*
    //判断是否由远程消息通知触发应用程序启动
    if ([launchOptions objectForKey:UIApplicationLaunchOptionsRemoteNotificationKey]!=nil) {
        //获取应用程序消息通知标记数（即小红圈中的数字）
        NSInteger badge = [UIApplication sharedApplication].applicationIconBadgeNumber;
        if (badge>0) {
            //如果应用程序消息通知标记数（即小红圈中的数字）大于0，清除标记。
            badge--;
            //清除标记。清除小红圈中数字，小红圈中数字为0，小红圈才会消除。
            [UIApplication sharedApplication].applicationIconBadgeNumber = badge;
        }
    }
    //远程推送注册
    [[UIApplication sharedApplication] registerForRemoteNotificationTypes:UIRemoteNotificationTypeSound|UIRemoteNotificationTypeBadge|UIRemoteNotificationTypeAlert];
    */
    return YES;
}






  b.如果用户不是由点击响应该消息而启动APP（例如直接点击APP图片启动App应用），系统将不会将推送消息提供给APP；[launchOptions
 objectForKey:UIApplicationLaunchOptionsLocalNotificationKey]获取不到，为nil


2.通知到达设备时，应用正在前台运行：
由委托方法application:didReceiveLocalNotification: 接受通知信息
#pragma mark - 本地消息测试
-(void)application:(UIApplication *)application didReceiveLocalNotification:(UILocalNotification *)notification
{
    
    UIAlertView *alertView = [[UIAlertView alloc]
                              initWithTitle:@"51huapao"
                              message:@"推送测试信息－－didReceiveLocalNotification"
                              delegate:self
                              cancelButtonTitle:@"关闭"
                              otherButtonTitles:nil, nil];
    [alertView show];
}







3.其他有关UILocalNotification的介绍：


Notification是智能手机应用编程中非常常用的一种传递信息的机制，而且可以非常好的节省资源，不用消耗资源来不停地检查信息状态（Pooling），在iOS下应用分为两种不同的Notification种类，本地和远程。本地的Notification由iOS下NotificationManager统一管理，只需要将封装好的本地Notification对象加入到系统Notification管理机制队列中，系统会在指定的时间激发将本地Notification，应用只需设计好处理Notification的方法就完成了整个Notification流程了。

本地Notification所使用的对象是UILocalNotification，UILocalNotification的属性涵盖了所有处理Notification需要的内容。UILocalNotification的属性有fireDate、timeZone、repeatInterval、repeatCalendar、alertBody、alertAction、hasAction、alertLaunchImage、applicationIconBadgeNumber、soundName和userInfo。



UILocalNotification的调度

其中fireDate、timeZone、repeatInterval和repeatCalendar是用于UILocalNotification的调度。fireDate是UILocalNotification的激发的确切时间。timeZone是UILocalNotification激发时间是否根据时区改变而改变，如果设置为nil的话，那么UILocalNotification将在一段时候后被激发，而不是某一个确切时间被激发。repeatInterval是UILocalNotification被重复激发之间的时间差，不过时间差是完全根据日历单位（NSCalendarUnit）的，例如每周激发的单位，NSWeekCalendarUnit，如果不设置的话，将不会重复激发。repeatCalendar是UILocalNotification重复激发所使用的日历单位需要参考的日历，如果不设置的话，系统默认的日历将被作为参考日历。
UILocalNotification的提醒内容

alertBody、alertAction、hasAction和alertLaunchImage是当应用不在运行时，系统处理

 

UILocalNotification提醒是需要的内容。alertBody是一串现实提醒内容的字符串（NSString），如果alertBody未设置的话，Notification被激发时将不现实提醒。alertAction也是一串字符（NSString），alertAction的内容将作为提醒中动作按钮上的文字，如果未设置的话，提醒信息中的动作按钮将显示为“View”相对文字形式。alertLaunchImage是在用户点击提醒框中动作按钮（“View”）时，等待应用加载时显示的图片，这个将替代应用原本设置的加载图片。hasAction是一个控制是否在提醒框中显示动作按钮的布尔值，默认值为YES。




 
UILocalNotification的其他部分

applicationIconBadgeNumber、soundName和userInfo将使UILocalNotification更完整。applicationIconBadgeNumber是显示在应用图标右上角的数字，这样让用户直接了解到应用需要处理的Notification。soundName是另一个UILocalNotification用来提醒用户的手段，在Notification被激发之后将播放这段声音来提醒用户有Notification需要处理，如果不设soundName的话，Notification被激发是将不会有声音播放，除去应用特制的声音以外，也可以将soundName设为UILocalNotificationDefaultSoundName来使用系统默认提醒声音。userInfo是Notification用来传递数据的NSDictionary。


登记UILocalNotification

在设置完UILocalNotification对象之后，应用需要在系统Notification处理队列中登记已设置完的UILocalNotification对象。登记UILocalNotification * localNotification的方式为：

   [[UIApplication sharedApplication]  scheduleLocalNotification:localNotification];

在有些时候，应用可能需要直接激发一个Notification而不是等一段时间在激发，应用可以以下的方式直接触发已设好的Notification：

   [[UIApplication sharedApplication] presentLocalNotificationNow:localNotification];
处理UILocalNotification

在提醒框动作按钮被点击后，应用开始运行时，可以在-(BOOL)application:didFinishLaunchingWithOptions:这个Application delegate方法中处理。可以通过以下方式来加载为最近未处理的Notification：

   UILocalNotification * localNotif=[launchOptions objectForKey:UIApplicationLaunchOptionsLocalNotificationKey];

如果应用正在运行时，可以通过覆盖在Application Delegate中的方法-(void)application:didReceiveLocalNotification:来处理Notification。作为方法的第二个参数为UILocalNotification对象，只需处理对象携带的userInfo来处理响应的动作。
取消UILocalNotification

可以使用以下两个方式来取消一个已经登记的Notification，第一个方式可以直接取消一个指定的Notification，第二个方式将会把该应用已登记的Notification一起取消

   [[UIApplication sharedApplication] cancelLocalNotification:localNotification];



   [[UIApplication sharedApplication] cancelAllLocalNotification];
总结

本地Notification的机制在应用开发中非常有效，可以很好的帮助开发者管理一些指定时间需要发生的事件，例如闹钟类的应用。而且因为系统统一对Notification的管理，让同样的任务可以非常简单得被处理，而无需让应用浪费资源去等待事件的触发。