主要目标为ios + android。不排除未来有JS上实现的需求。
极光推送的文档只看到ANDROID、ios、winPhone，就是不支持js。 从这点看，技术选型的拓展性不强。
因为手机本身的电量、网络的限制，我们必须要根据手机本身的特点，尽量节省电量和流量，同时要保证数据到达客户端的及时性。 为了解决数据同步，两个方式： 一、从服务器拉取。 二、手机跟服务器端维持长连接，进行推送。 很多情况下，我们会选择推拉结合的方式。
换言之，运营商的网关需要维护一个外网的IP、端口到内网IP、端口的对应关系，来保证客户端跟服务器端的通信。 但是，客户端在一段时间内没有通信，则会淘汰NAT表中的对应项，通信中断。
平台多，ROM差异化大。要想实现及时性，必须要有取舍。经常说要接入各平台的推送服务，才能使用平台级的推送唤醒功能。华为的、小米的、魅族的、fire的，一来二去apk的包Size就变大了。这是我们不愿意看到的。
依赖系统级的推送。不存在多家的问题。到时简化了。也没有推送无法唤醒手机的问题。
IOS的推送是通过ios的框架实现的。问题会少。不存在因为轮训唤醒的电量，及时性问题。 极光推送在Android上的长连接(IOS可以利用系统服务推送哟) 要维持长连接，需要心跳机制。所以，心跳的频率很重要，直接影响到了电量，及时性。 保持Android长期唤醒Timer、AlarmManager。
极光推送是用AlarmManager实现的。这个消息，一定不可能及时。RTC唤醒你频率不可能高，频繁唤醒你的电量会激增，感受一下：一次网络请求40ma。休眠3ma。简单来说，你待机时间会大幅压缩。而且，每次唤醒，你难保其他app不会做网络请求。那就可能导致电量很不经用。
大量的客户端连接，对服务器的压力会非常巨大。极光号称有C2000K项目。但是从来没有数据表示，他们到底活跃链接的处理量有多少？现在他们官网直说 10亿并发，这个完全不同的概念。天。并发数不说了吗？ 另外通信量也会有不同的影响。这个需要结合起来看。
网络，有评论描述。同一个推送，有10分钟到的。也有1小时到了。
这里更多的是 产品逻辑配合技术实现。这避免了很多问题。好用不贵。
用一套成熟的协议来简化，其实，MQTT\XMPP都是可以的
AlarmManager、Timer去掉。那么这里怎么处理呢。 我认为，但是需要AlarmManager、Timer的时候，手机是一定休眠了的。既然如此。你何必强制唤醒一次。这里改 拉的方式，监听锁屏点亮、切换到当前应用的时候，进行Router拦截进行网络请求，切他。拉取你需要的信息。
一般的互联网App，用户量1KK其实也还行，日活有多少，低频还是高频的用户操作，我们公司是低频的用户操作。其实，cover 1kk的用户量，估计同时在线率很低很低。保持10K的连接数就可以cover住。后续，可以考虑优化链接方式，LRU之类的处理优化长连接。这是完全可以做到的。
在电量、及时性、并发链接数解决后，你还有什么问题呢？ 其实费用还好的，部署一台靠谱的阿里云上就好。
