我刚刚作为（技术）产品经理继承了一个 Android 应用程序项目，该项目使用5 秒计时器轮询远程 URL查看应用程序启动的某些工作是否已完成。我最初的反应当然是建议用推送/通知机制替换它，最好是Android内置的GCM，这样工作就从手机上的app中移除，放到了服务器端。
令人惊讶的是，我遇到了开发团队的阻力。一位前产品经理（我的前任）似乎明确要求实施以这种方式进行。不幸的是，他不太愿意记录他的决定，所以我现在必须尝试追溯哪些原因可能导致这个决定，以证明实施中的改变是合理的。我列出了以下赞成和反对的清单：
Contra Push / 专业民意调查
- -
- -
- 实现推送通知所需的服务器端工作
- -
- 无法直接知道推送通知是否已成功发送
- 扩展推送通知传递可能会很痛苦
赞成推动/反对民意调查
- Work is removed from device
- 较低的带宽使用率
- 降低电池使用量
- 响应速度更快的应用程序和设备
- 服务器负载降低，因为即使没有任何更改，设备也不会每 x 秒轮询一次 (DDOS)
- -
- 推送速度比 5 秒（当前计时器）更快（响应更快）
- 通过远程 URL 的轮询来实现推送通知的传递证明很简单（在这里它是有意义的）
- 扩展推送通知交付是一个已解决的问题，有许多开源项目和消息队列的简单实现
- 对于此用例，还有其他原因避免推送通知并使用轮询吗？
- 对于此用例，还有其他原因避免轮询并使用推送通知吗？
- 还有其他重要的事情我忘记了吗？
无法知道推送通知是否已成功发送
当然有：让设备在收到推送消息后访问您的服务器。如果有效负载大于 4K，您可能无论如何都需要这样做。
扩展推送通知传递可能会很痛苦
它适用于相当大的用户群（例如，RememberTheMilk），甚至在基于 XMPP 的持久套接字解决方案之前。
对于此用例，还有其他原因避免推送通知并使用轮询吗？
GCM 没有服务水平保证。 GCM 是 Android 特定的；如果您正在寻找能够处理其他客户端操作系统的东西，您可能会考虑对其进行包装，例如 Amazon SNS。涉及第三方（例如 Google）的推送解决方案意味着您的原始推送消息负载将对这些第三方的服务器可见；如果这是一个问题（而且应该是），请使用合适的应用程序级加密。
对于此用例，还有其他原因避免轮询并使用推送通知吗？
五秒钟的民意调查让$BABY_DEITY cry.
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
