民意调查与推送 - 避免推送通知的任何理由？

Question

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

令人惊讶的是,我遇到了开发团队的阻力.一位前产品经理(我的前任)似乎明确要求实施以这种方式运作.不幸的是,他在记录他的决定方面并不是很重要,因此我现在必须试图回顾哪些原因可能导致这一决定证明改变实施的合理性.我提出了以下专业和反对清单:

Contra Push/Pro民意调查

1. -
2. -
3. 实现推送通知所需的服务器端工作
4. -
5. 无法直接了解推送通知是否已成功传递
6. 扩展推送通知传递可能很痛苦

Pro Push/Contra民意调查

1. 工作已从设备中删除
   • 降低带宽使用率
   • 降低电池使用量
   • 更灵敏的应用程序和设备
2. 服务器负载降低,因为即使没有任何更改,设备也不会每x秒轮询一次(DDOS)
3. -
4. 推送比5秒更快(响应更快)(当前计时器)
5. 推送通知的交付证明通过远程URL的轮询实现是微不足道的(这里有意义)
6. 扩展推送通知传递是许多开源项目和带有消息队列的简单实现的解决问题

---

• 是否还有其他原因可以避免使用推送通知并对此用例使用轮询？
• 是否还有其他原因可以避免轮询并对此用例使用推送通知？
• 我忘了还有其他重要的事吗？

Answer 1

无法知道推送通知是否已成功传递

当然有:在收到推送消息后,设备会命中您的服务器.如果有效载荷大于4K,您可能还需要这样做.

扩展推送通知传递可能很痛苦

它适用于相当大的用户群(例如,RememberTheMilk),甚至在基于XMPP的持久套接字解决方案之前.

是否还有其他原因可以避免使用推送通知并对此用例使用轮询？

GCM没有服务级别保证.GCM是特定于Android的; 如果你正在寻找能够处理其他客户端操作系统的东西,你可以考虑使用它的包装器,如Amazon SNS.涉及第三方(如Google)的推送解决方案意味着您的原始推送消息有效负载将对这些第三方的服务器可见; 如果这是一个问题,请使用合适的应用级加密(它应该是).

是否还有其他原因可以避免轮询并对此用例使用推送通知？

五秒钟的民意调查让人$BABY_DEITY大哭.