极光推送升级总结

公司之前用的百度推送，经常出现推送丢失的情况。发现推送经常会收不到，而且经常是推送接口没有返回错误。之前一直不想换，因为觉得成本有点高。后来实在受不了了就决定研究当下有哪些推送比较好。最后比较后，业界当然口碑最好的是极光推送。就觉得换极光了。事实上推送的确比百度好多了。
要平滑升级极光推送，其实并没有之前想的那么高成本。不过升级过程也遇了问题，现在就来讲升级的过程。

之前我们系统有一个Push接口，主要是推送的涉及的方法，单点推送，分组推送，类型推送，广播推送等。有一个Push4BaiduYun的类实现了该接口。具体就是把用百度的推送api实现了。在系统中用到推送的地方用spring的配置Push4BaiduYun。

现在要平滑升级极光推送，要考虑的就是实现和极光推送的对接，和同时兼容之前没有升级用户的推送和新用户的推送，就是根据用户当然的版本采用不同的推送方式。

推送标示一个用户，都有自己的id，原系统设计的时候用户信息里面存储了mid来标示，同时有一个mt标示用户设备类型。支持ios 4，android 3。在这样的基础上，升级后的前端需要更换极光推送的包，同时在更新mid的时候用极光产生的regid。那怎么最小改动，最好的判断用户用的是什么版本呢，用mt。之前的ios 是 4，android 是3。新版本在生产mt时，ios 用 14，android用13。这样就可以标识出用户当然的设备是什么版本了。同时，只需要修改mt使用时判断，然后选择就好了。

为了实现这个，新建了两个类实现Push接口，Push4Jiguang,PushManager。其中Push4Jiguang用极光的包实现了基础的推送功能，PushManager，包含了Push4BaiduYun和Push4Jiguang，同时可以通过Spring配置各自的key和secret。在PushManager实现各个Push的推送接口时，都可以根据mt的类型选择不同的推送方式。

在使用Push的地方，只需要在Spring配置改为PushManager就好了，更本不感知推送方式的升级。

另外，升级极光推送的时候有一个问题困扰了个多小时，极光推送在执行sendPush方法的时候，好像是抛出final类不能继承的错误，莫名其妙啊。在例程中没有问题，在系统中跑就不行。一直怀疑是系统什么包错误了，没有找到。最后把极光的功能导入，跟踪才发现是gson出问题了，一查发现，系统中有一个gson1.4的包，而极光用的是gson2.4的包，好吧，替换下包就好了。至于为什么gson1.4的包不能，没有仔细去研究。

还有一个问题，在看极光推送官方文档发现，极光对于免费推送有一些限制。一些限制对我们影响还比较大。我们替换极光推送当然是因为它稳定，推送不丢失。但是极光推送的两个限制可能会影响这个成功率。
1、全部免费用户共享20W/s的推送通道。
2、API调用频率最多600次/s。

这意味这，对于第一条限制，我们除了升级VIP用户，没有其他办法。推送在高峰时期丢失无法避免。对于第二条限制，我实际测试了，如果一直推送，消息不仅会丢失，还会导致极光把我们拉入黑名单一段时间。也就是说如果，要在第二条限制的基础上做到不丢失推送，不能多于600次/s的推送，因为免费用户没有进行分组推送，所以，除广播，我们一条推送只能到一个用户。那一秒钟最多可以推送10条，那推送一条sleep(100)就可以保障不会受限制。为了避免出问题，这里每推送一条都sleep(200)。如果这样做，那我们每天可以推送的消息数是56060*24=43200条。当然最好的还是直接升级VIP，不受这个限制好了。

可以想象，百度可能也有类似的限制。根据我们的业务特点，推送都是集中一次性一起发送很多条，但是对时间的延迟要求基本没什么要求，就算晚了一个小时，也没有什么影响。所以之前消息丢失可能有很多都是我们一次性调用太多次数，导致消息丢失了。