gamexg
2019-02-18 17:01:09 +08:00
推送问题不是常识吗？
苹果系统本身有统一的推送机制，android 也有系统级别的统一推送机制。
但是国内墙的问题使得这个机制无法工作，然后各个应用就使用各种手段常驻后台维持自己的长连接推送。各个程序都在台运行会造成严重的耗电问题，厂家为了解决这个问题各种杀后台进程，进程被杀后程序自己的推送机制当然挂了。
几年前曾经实现过 android 推送，算是明白 app 和厂家之间的相爱相杀。
android 锁屏一段时间后，cpu 会关闭，这时候即使 app 没被杀死也无法工作。虽然 app 可以强制 cpu 不关闭，但是耗电会很高，除了极少数特殊用途 app，其他 app 敢这么干是等着被卸载。
那么只能选择定时唤醒 cpu 去维持自己的推送通道，不过 google android api 文档上面写的很清楚的定时器 api 实际工作并不是那么可靠。
厂家为了解决各个 app 为了维持自己的推送通道不断唤醒 cpu 造成耗电加剧问题，当检测到 app 执行太多的唤醒操作后就不会在唤醒 app 了，app 无法唤醒会造成长连接被关闭当然会造成推送失败。
即使手机提供了白名单等功能，实际测试看起来也是无效，当执行太多唤醒时 app 会进入黑名单，定时器完全不工作了。
当时围绕着能够唤醒关闭 cpu 的各个功能查了一遍，最终找到了一个网络唤醒 cpu 的方式。即服务器发包，基带收到数据后会唤醒 cpu，android 系统会将数据传输给 app，这样就避开了定时器不允许运行太多的问题。
但是如果这个长连接因为各种意外断开，那么 app 就无法被服务器数据唤醒了，只能等到下次屏幕开启等广播或超长定时器唤醒后重建长连接了，这就是推送延迟。