结合公司业务后，对极光推送的进一步思考

公司决定启用推送技术。目前来说，用的是极光推送。免费版。

主要目标为ios + android。不排除未来有JS上实现的需求。

极光推送的文档只看到ANDROID、ios、winPhone，就是不支持js。
从这点看，技术选型的拓展性不强。

回到现状

因为手机本身的电量、网络的限制，我们必须要根据手机本身的特点，尽量节省电量和流量，同时要保证数据到达客户端的及时性。
为了解决数据同步，两个方式：
一、从服务器拉取。
二、手机跟服务器端维持长连接，进行推送。
很多情况下，我们会选择推拉结合的方式。

移动网络的特点

先来了解下IPv4的短缺问题 NAT-IPv4

换言之，运营商的网关需要维护一个外网的IP、端口到内网IP、端口的对应关系，来保证客户端跟服务器端的通信。
但是，客户端在一段时间内没有通信，则会淘汰NAT表中的对应项，通信中断。

大致讲下移动端的情况

Android手机：

平台多，ROM差异化大。要想实现及时性，必须要有取舍。经常说要接入各平台的推送服务，才能使用平台级的推送唤醒功能。华为的、小米的、魅族的、fire的，一来二去apk的包Size就变大了。这是我们不愿意看到的。

IOS手机：

依赖系统级的推送。不存在多家的问题。到时简化了。也没有推送无法唤醒手机的问题。

这次重点讲解android的方案。

IOS的推送是通过ios的框架实现的。问题会少。不存在因为轮训唤醒的电量，及时性问题。
极光推送在Android上的长连接(IOS可以利用系统服务推送哟)
要维持长连接，需要心跳机制。所以，心跳的频率很重要，直接影响到了电量，及时性。
保持Android长期唤醒Timer、AlarmManager。

极光推送是用AlarmManager实现的。这个消息，一定不可能及时。RTC唤醒你频率不可能高，频繁唤醒你的电量会激增，感受一下：一次网络请求40ma。休眠3ma。简单来说，你待机时间会大幅压缩。而且，每次唤醒，你难保其他app不会做网络请求。那就可能导致电量很不经用。

极光推送的服务器设计

大量的客户端连接，对服务器的压力会非常巨大。极光号称有C2000K项目。但是从来没有数据表示，他们到底活跃链接的处理量有多少？现在他们官网直说 10亿并发，这个完全不同的概念。天。并发数不说了吗？
另外通信量也会有不同的影响。这个需要结合起来看。

网络，有评论描述。同一个推送，有10分钟到的。也有1小时到了。

解决方案：自己做，便宜又好用。MQTT XMPP搞起来。

这里更多的是产品逻辑配合技术实现。这避免了很多问题。好用不贵。

首先

用一套成熟的协议来简化，其实，MQTT\XMPP都是可以的

其次

AlarmManager、Timer去掉。那么这里怎么处理呢。
我认为，但是需要AlarmManager、Timer的时候，手机是一定休眠了的。既然如此。你何必强制唤醒一次。这里改拉的方式，监听锁屏点亮、切换到当前应用的时候，进行Router拦截进行网络请求，切他。拉取你需要的信息。

再者

一般的互联网App，用户量1KK其实也还行，日活有多少，低频还是高频的用户操作，我们公司是低频的用户操作。其实，cover 1kk的用户量，估计同时在线率很低很低。保持10K的连接数就可以cover住。后续，可以考虑优化链接方式，LRU之类的处理优化长连接。这是完全可以做到的。

在电量、及时性、并发链接数解决后，你还有什么问题呢？
其实费用还好的，部署一台靠谱的阿里云上就好。