Hxqing

1. 不会耗电，几十秒才发一个 ping 包，消耗微乎其微（长连接断了就再连嘛，重连很方便， sdk 也会自动重连）；
2. 如上，一个 ping 包的大小估计在几十个字节，一整天可能才几个 KB 。

云巴就有 Socket.IO 相关的解决方案，包括 Socket.IO API 使用等，操作十分便捷，不需要自己造轮子，
详情可看： https://yunba.io/docs/socketio_api_api_manual

@dellch 第三方推送也可选择云巴，快速集成的入门操作仅有 5 步，并且每一步都非常简便，包括注册账号、创建新应用、下载 SDK 、集成 SDK 、开始通信。
详细的内容建议查看云巴的文档，讲得非常详细清晰，链接： https://yunba.io/docs/product_kb_yunba_quick_start
希望对你有所帮助！

推荐使用云巴（ Yunba.io ）。
云巴具有推送到达率高，实时性最长不超过 200 ms ，技术支持响应非常迅速，服务门槛低等优势。
了解更多： https://yunba.io/docs/product_faq

类似题主提到的问题，国内第三方推送服务商的策略貌似是去集成华为、小米推送。
以云巴为例，云巴 Android SDK 从 v1.8.0-beta 起支持小米、华为推送，通过在这两类机型上的小米、华为推送进程来拉起云巴进程，从而实现杀掉 App 也收到推送的效果。集成上述 SDK 后，云巴可以保证将消息送达小米和华为网关，但是小米和华为自身推送链路的稳定性依赖于小米和华为，集成第三方推送更多是作为一个保活的策略。
关于第三方推送的谈论，建议关注这篇文章《第三方推送已死》： http://www.leiphone.com/news/201611/Ulxs4d7GRdXRIFJ0.html

不合理。
首先，“客户端带上上次拉取的消息 ID ，主动去自己的服务器拉取。”这个是不支持的。
其次，这个需求并不是推送的需求，这个是后端云储存。客户端每次都验证自己本地的内容是不是和服务器的一致，不一致就同步，这是典型的云储存的需求。
还有一点，这样实现的话，服务器就要代客户端收取消息，这个是不科学的。
最后，你要解决这个问题的话，可以掏钱让第三方推送服务商，例如，云巴（ Yunba.io ）给你定制服务。当然，要是想免费的话，可以自己搭 firebase 服务器。

国内的 Android 推送多数是靠第三方推送实现的。
以云巴（ Yunba.io ）为例，客户端集成了云巴的 Android SDK ，服务端可通过云巴的 SDK 或使用 RESTful API ，向 Android 客户端发消息。
1.后台保持长连接。 Android SDK 会启动一个后台的 Service ，创建并保持到云巴服务器的长连接，从而保证了消息推送的实时性。
2.确保消息的送达。云巴 SDK 支持 离线消息 的功能，可保证消息送达客户端。

楼主上述的问题，或许下个 Demo 试试看就能解决~
Android ： https://yunba.io/docs/android_demo_quick_start
iOS ： https://yunba.io/docs/ios_demo_quick_start

这里推荐一下 云巴 （ Yunba.io ）吧~
云巴的服务对初创团队的门槛很低，初创团队可以享有每月 100 万次 免费 API 调用和每月 100 万次 免费推送。
此外，云巴的技术服务响应也很迅速及时。
而且，云巴 Android SDK 从 v1.8.0-beta 起支持小米、华为推送，通过在这两类机型上的小米、华为推送进程来拉起云巴进程，从而实现杀掉 App 也收到推送的效果。云巴为了极大地提高集成效率，推出了“自动创建应用”的功能，免去了注册小米、华为账号的繁琐步骤。
详情可以查看《第三方推送集成指南》： https://yunba.io/docs/android_sdk_third_part_push