android 实现本地定时推送(兼容)

首先写几点感悟：

创新互联公司主要从事成都做网站、成都网站建设、网页设计、企业做网站、公司建网站等业务。立足成都服务临汾,10余年网站建设经验,价格优惠、服务专业,欢迎来电咨询建站服务:18980820575

闹钟类，目前只用过 AlarmManager.RTC_WAKEUP 类型，这个是精确定时，很多博客都提到过，不了解的可以自己查查。然后 action 用来启动服务或者广播， alarmId 就是 requestCode ，用来区别不同的闹钟。该工具类不仅仅可以用来定时通知，只要稍加改动，定时广播、定时任务、定时弹窗都是可以做的。

服务和广播配置一个就可以了，目前我才有的是服务的配置方法

服务的配置方法：

广播的配置方法:

由于查看的资料太多了，所以就不一一列举了，然后提供一个测试方法，可以在 MainActivity 的 OnCreate 方法中调用：

Android消息推送：第三方消息推送平台详细解析

其他推送方式还有：C2DM、轮询、SMS、MQTT协议、XMPP协议等等，相对于这些推送方式，第三方推送方式的特点分别是：

请记住一个潜规则：操作系统是不会杀死属于自己品牌的推送服务。

当今市场上的Android手机系统份额最高是MIUI系统，即小米（具体排名请看 ）

因为：免费、到达率高且在Android系统市场份额第一的MIUI系统上不被杀死。所以，如果要选择手机厂商的推送服务， 请选择小米推送作为第三方平台实现推送服务

下面一些应用可以从侧面来证明我的推断：

请记住一个规则：推送系统会共享一条推送渠道

所以说，关于如何选择第三方平台类的推送，推送平台的规模效应就很重要了。

那如何得知他们的规模和市场份额呢？按个人经验，主要看两点：

BAT大厂其实并没有什么优势， 同时谨记：

所以，大家可根据自己的使用场景来进行消息推送平台的选择。

通常第三方推送平台都支持两种推送消息类型：通知栏消息和透传消息。

不定期分享关于 安卓开发 的干货，追求 短、平、快 ，但 却不缺深度 。

Android消息推送原理

产品的角度：功能需要，比如说资讯类产品的新闻推送、工具类产品的公告推送等等

运营的角度：活动运营需要，比如说电商类产品的促销活动；召回用户 / 提高活跃度等等

作为开发者，不要有需求就接，应该多思考、多理解用户 / 功能的使用场景，有助于我们更好地去选择合适的开发方式

系统级别：任何时候都可以推送给用户，且不会被系统杀死

Android的消息推送服务称为：C2DM（Cloudto Device Messaging）

消息推送的本质是：App将服务器更新的信息推送给用户，即App获取服务器信息，再推送给用户

App从服务器获取最新消息的基本方式（原理）有3种：Push、Pull 和 SMS

经总结，Android中实现消息推送的有7种主流解决方案，接下来将一一介绍。

4.1 C2DM

定义：Cloud to Device Messaging，云端推送

Android系统级别的消息推送服务-Google出品

原理：基于Push方式，C2DM服务负责处理诸如消息排队等事务，并向运行于目标设备上的应用程序分发这些消息。如下图：

定义：轻量级的消息发布/订阅协议

原理：基于Push方式，wmqtt.jar 是IBM提供的MQTT协议的实现，原理如下图：

其他三种：

客户端

通信能够在这三者的任意两个之间双向发生。

原理流程

现今主流的推送平台分为

手机厂商类：小米推送、华为推送。

第三方平台类：友盟推送、极光推送、云巴（基于MQTT）

BAT大厂的平台推送：阿里云移动推送、腾讯信鸽推送、百度云推送

android系统的APP消息推送机制

参考文章：

1. 主流的第三方推送平台分类

手机厂商类：小米推送、华为推送。

第三方平台类：友盟推送、极光推送、云巴（基于MQTT）

BAT大厂的平台推送：阿里云移动推送、腾讯信鸽推送、百度云推送

2. 对比其他推送方式的特点

其他推送方式还有：C2DM、轮询、SMS、MQTT协议、XMPP协议等等，相对于这些推送方式，第三方推送方式的特点分别是：

优点：

成本低

上述的推送大多数是免费的，假如自己实现则消耗过多资源（开发成本和后台管理、统计成本）

消息到达率高

如果一个手机里有多个App使用了同一家推送服务，那么这些App将共用一条消息通道，即使你家的App推送服务被杀死了，那么只要用户打开了其他集成该推送服务的App，你家的推送就能到达用户

缺点

安全性低

使用别人的服务器，所以你懂的。

服务会被杀死

由于Android系统的机制，后台推送 Service 会被各种主动的或是被动的行为给杀死，而服务一旦被杀死，意味着就接收不到推送消息。

3. 第三方推送服务方式的特点

第三方服务基本都具备免费、和到达率高的特点

那么应该如何选择呢？我们来分别看一下第三方推送各种方式的优点：

3.1 手机厂商推送

请记住一个潜规则：操作系统是不会杀死属于自己品牌的推送服务。

手机厂商的推送服务在自家的手机上属于系统级别的服务，这意味着系统不会杀死自家的推送服务

比如说，Android原生系统是不会杀死C2DM消息推送服务，MIUI系统是不会杀死小米的推送服务。

当今市场上的Android手机系统份额最高是MIUI系统，即小米（具体排名请看）

因为：免费、到达率高且在Android系统市场份额第一的MIUI系统上不被杀死。所以，如果要选择手机厂商的推送服务，请选择小米推送作为第三方平台实现推送服务

下面一些应用可以从侧面来证明我的推断：

腾讯新闻使用的小米推送，没有使用自己家的信鸽推送

淘宝使用了自家的阿里云推送，同时还集成了小米推送

百度视频和爱奇艺使用的是小米推送，没有用自家的百度推送

官网截图 - 集成应用：

如果希望进一步提高推送的效果，其实可以集成多个手机厂商的推送服务

比如小米渠道用小米推送，华为渠道用华为推送，但这样的实现成本会大一些

3.2 第三方平台类

请记住一个规则：推送系统会共享一条推送渠道

这意味着假设你接入了友盟推送，而恰好今日头条也接入了友盟。

有一天你的App被杀死了，但这时用户启动了今日头条，那么推送系统也就会通过共享的推送通道顺便把你推送消息送达到手机上，然后还可能把你的进程也唤醒（被“保活”了）。

所以说，关于如何选择第三方平台类的推送，推送平台的规模效应就很重要了。

那如何得知他们的规模和市场份额呢？按个人经验，主要看两点：

问内部的朋友。

看推送平台的合作客户里有哪些大的app - 参考对应官网的合作案例

3.3 BAT大厂的推送

BAT大厂其实并没有什么优势，同时谨记：

不要以为用了腾讯信鸽推送，就能占上微信的光保证你的App永远内部被杀死。

说个题外话，手机淘宝除了自家的阿里云的移动推送，同时也使用其它的第三方推送平台啊（比如友盟推送）。

4. 如何选择第三方平台推送服务？

主要从用户类别+实现成本+渠道来选择不同的使用场景

1. 如果用户群体精准（使用小米手机或华为手机居多），可以考虑只集成对应手机厂商的推送；

注意：单一的手机厂商也能工作，比如小米推送在非小米手机上当然也能工作，只不过不是系统级别的服务了，容易被杀死。

如果用户群体广泛、希望实现成本低，可以考虑只使用单一第三方平台类的推送（极光、友盟blabla，选一个规模效应最大的）

如果用户群体广泛、不在意实现成本，个人建议：

对于小米手机，使用小米推送；

对于华为手机，使用华为推送；

对于其他手机，只使用单一第三方平台类的推送（极光、友盟blabla，选一个规模效应最大的）

让不同的推送运行在各自擅长的环境里，最大化实现推送的到达率和产品的存活率

大家可以根据自己的使用场景来进行消息推送平台的选择。

5. 推送消息类别的选择

5.1 推送消息的类别

通常第三方推送平台都支持两种推送消息类型：通知栏消息和透传消息。

通知栏消息：该类消息在被送达用户的设备后，直接以系统通知栏的形式展示给用户

不会继续被传递到App

透传消息：该类消息在被送达用户的设备后，还会继续传递到App

通过回调App的某个BroadcastReceiver的形式将消息传递到App内部。然后由App决定如何处理和显示这个消息。

所以透传消息不一定会以系统通知栏的形式进行推送，由程序猿自定义

5.2 消息类别的区别与特点

二者的区别在于：透传消息在整个消息传递过程中比通知栏消息多了一步-传递到App

通知栏消息的优点：送达率高

因为透传消息在整个消息传递过程中比通知栏消息多了一步-传递到App，因此透传消息就增加一些被系统限制的概率，给系统杀死的概率就高一些，所以说，通知栏消息比透传消息应该能提供更好的送达率。

我们来看下小米推送的官方文档描述：

在一些 Android 系统(如 MIUI)中，受到系统自启动管理设置的限制,应用不能在后台自启动

在这类系统中，如果在发送消息的时候对应的应用没有被启动，透传类消息将不能顺利送达。

因此,对于对送达率要求很高的消息,建议尽量采用通知栏提醒的方式推送消息

透传消息的优点：对消息操作程度高 自定义程度高

提供了对消息数据的更灵活的操纵能力。

App如果仅仅通过通知栏消息，是无法接触到消息数据本身的。

可自定义通知提醒的样式（包括提示样式、提示形式如声音等等）

所以大家可以根据不同的使用场景来对推送消息类别进行选择了。

当前题目：android本地推送,android推送解决方案
URL分享：http://lswzjz.com/article/dsigpii.html