投票 vs 推送 - 有什么理由避免推送通知？

Question

作为技术产品经理，我继承了一个Android应用项目，它使用5秒的定时器轮询远程URL以查看应用程序启动的工作是否已完成。我的初始反应当然是建议使用推送/通知机制来替换它，最好使用Android内置的GCM，这样工作就从手机上的应用程序中移除并放在服务器端。

令人惊讶的是，开发团队对此表示了抵制。我的一位前任产品经理似乎已经明确要求实现这种方式。不幸的是，他不善于记录他的决策，因此我现在必须尝试追溯哪些原因可能导致了这个决策，以证明对实现进行更改的合理性。我列出了以下正负面清单：

反对推送/支持轮询

1. -
2. -
3. 需要在服务器端执行推送通知的工作
4. -
5. 没有直接的方法知道推送通知是否成功传递
6. 扩展推送通知传递可能会很麻烦

支持推送/反对轮询

1. 将工作从设备中移除
   • 较低的带宽使用率
   • 更低的电池使用率
   • 响应更快的应用程序和设备
2. 降低服务器负载，因为设备即使没有任何变化也不会每x秒轮询（DDOS）
3. -
4. 推送比5秒（当前定时器）更快（更响应）
5. 使用远程URL的轮询来实现推送通知的投递证明是微不足道的（在这里有意义）
6. 使用消息队列，扩展推送通知传递是一个已解决的问题，并且有很多开源项目和微不足道的实现方法

---

• 还有其他避免使用推送通知并使用轮询的理由吗？
• 还有其他避免使用轮询并使用推送通知的理由吗？
• 我忘记了其他重要事项吗？

- janpio

Answer 1

无法知晓推送通知是否成功发送

当设备收到推送消息时，让设备与你的服务器通信以确认消息是否已被接收即可。如果负载超过4K，则可能需要这样做。

推送通知传递的扩展性可能很难处理

它适用于相当大的用户基础（例如RememberTheMilk），甚至是在XMPP基于持久套接字解决方案出现之前。

还有其他原因避免使用Push Notifications并使用Polling来实现吗？

GCM没有服务水平保证。GCM仅适用于Android；如果你正在寻找可以处理其他客户端操作系统的解决方案，则可以考虑像Amazon SNS这样的包装器。涉及第三方（如Google）的推送解决方案意味着这些第三方的服务器将看到你的原始推送消息负载；如果这是一个问题，请使用适当的应用级加密来加以防护（并且应该这样做）。

还有其他原因避免使用Polling并使用Push Notifications来实现吗？

5秒轮询会让$BABY_DEITY哭泣。

（注意：$BABY_DEITY是一个虚构的代称）

- CommonsWare

---

谢谢，我之前不知道XMPP连接服务器和SNS，现在会去了解一下。另外，你写的其他内容也非常有道理。 - janpio