作为技术产品经理,我继承了一个Android应用项目,它使用5秒的定时器轮询远程URL以查看应用程序启动的工作是否已完成。我的初始反应当然是建议使用推送/通知机制来替换它,最好使用Android内置的GCM,这样工作就从手机上的应用程序中移除并放在服务器端。
令人惊讶的是,开发团队对此表示了抵制。我的一位前任产品经理似乎已经明确要求实现这种方式。不幸的是,他不善于记录他的决策,因此我现在必须尝试追溯哪些原因可能导致了这个决策,以证明对实现进行更改的合理性。我列出了以下正负面清单:
令人惊讶的是,开发团队对此表示了抵制。我的一位前任产品经理似乎已经明确要求实现这种方式。不幸的是,他不善于记录他的决策,因此我现在必须尝试追溯哪些原因可能导致了这个决策,以证明对实现进行更改的合理性。我列出了以下正负面清单:
反对推送/支持轮询
- -
- -
- 需要在服务器端执行推送通知的工作
- -
- 没有直接的方法知道推送通知是否成功传递
- 扩展推送通知传递可能会很麻烦
支持推送/反对轮询
- 将工作从设备中移除
- 较低的带宽使用率
- 更低的电池使用率
- 响应更快的应用程序和设备
- 降低服务器负载,因为设备即使没有任何变化也不会每x秒轮询(DDOS)
- -
- 推送比5秒(当前定时器)更快(更响应)
- 使用远程URL的轮询来实现推送通知的投递证明是微不足道的(在这里有意义)
- 使用消息队列,扩展推送通知传递是一个已解决的问题,并且有很多开源项目和微不足道的实现方法
- 还有其他避免使用推送通知并使用轮询的理由吗?
- 还有其他避免使用轮询并使用推送通知的理由吗?
- 我忘记了其他重要事项吗?