当可以接受较大的延迟（小时）时进行“推送与轮询”

如今看来，轮询是一种不好的做法，而在开发需要不断从远程服务器接收数据的移动应用程序时，推送是必须走的路。

所有主要的移动商店都提供其推送通知服务的版本：

• 苹果推送通知服务
• 适用于Android的Google Cloud Messaging
• Microsoft推送通知服务

但是我想知道这个假设在多大程度上是正确的。我的意思是，如果我有一个应用程序一天只轮询几次远程服务器，并且不需要立即向其发送“通知”（可以接受较大的延迟），那么这将是一个不错的决定轮询而不是推送数据？

提前致谢！

当不需要实时时，轮询总是可以接受的。您需要问自己的是，为什么要使用一个而不是另一个？

推送服务的目的是几件事情；如果您的推送是广播，而由第三方提供者进行广播，则处理的流量可能会大大减少-这使您可以发送一条消息，成千上万条消息被接收。但是，正如您所注意到的，推送服务的最大好处是实时性，它允许立即更新到达您的消费者。但是，在进行推送时，您实际上根本不想在广播时推送大数据集，而且您还受制于使用的第三方推送服务（如果您使用的话）。

轮询的目的是定期检查数据差异，其中更新时间段可以在一定时间段内具有可接受的SLA不准确性。轮询将要求您的所有客户端定期请求数据，这意味着将为每个正在运行的客户端请求连接，并且实时服务必须能够准确监控该数据以将其提供给轮询器。要提供准确的数据，就意味着某些数据持久性将占用磁盘和维护时间。

因此，从中我们可以看到，如果您担心网络流量或服务的维护（这可能意味着对请求进行身份验证/授权，记录占用磁盘空间的日志以及维护服务的所有正常要求），那么您不必不想强迫客户进行投票。但是，如果用例需要传输特别大的数据集，或者您无法绑定到可能随时间变化的第三方API，以及他们的SLA或费用，那么尽管维护维护，也可以使用本地种植的轮询系统开销可能会更多。或者，您可能已经在运行服务并保留了数据，以使轮询是对已经就位的基础架构的轻松补充，这使轮询更加可取。

尽管您认为自己是正确的，如果实时是必要的，轮询不会做。如果不是，那么您只需要算一下如何检查数据的周期性乘以客户群乘以数据集大小就可以算出网络成本是否值得，或者是否需要推送服务最好是始终可以推送一个更改事件，让他们在第二步骤中请求大数据集（尽管这些步骤的原子性可能取决于数据的关键性，因此您需要小心一些）。

在您的情况下，轮询应该可以。而且您不必与另一个系统（或用于多个平台的多个系统）集成。

但是，设备详细信息可能是一个问题。当应用程序不在设备的正面和中心位置时，您能否可靠地轮询？（可能对您来说不是问题）。您这样做的能力可能取决于您开发应用程序所使用的技术。

当然。它也更容易（如果每个人都遵循相同的时间表，只需提防峰值）。

也就是说，考虑到移动用户的期望，我将挑战“可以接受大的延迟”这一假设。（“地图无法实时更新！不可接受！”-或-“我知道这是气象服务，但我将每五秒钟不断按一次刷新按钮，直到明天的天气预报变得晴朗！”）