Android 正确使用Firebase连接构建聊天应用程序

我正在评估Firebase构建聊天应用程序的能力。它的计划让我担心：10000个并发连接/1499美元/月

在我看来，聊天应用程序将始终连接到Firebase，以便立即接收传入的消息。这意味着，如果我的应用程序在Android上获得10000个活动安装，那么无论他们是否打开该应用程序，我都必须每月支付1499美元

有人知道一种在不影响聊天应用程序感知质量的情况下减少与Firebase的并发连接的解决方案吗？谢谢

注

---

这是一个聊天应用程序，聊天应用程序的感知质量很重要。因此，如果设备已连接互联网，Android上的连接将永远不会被释放。

拥有10k用户或10k下载您的应用程序并不等于拥有10k并发用户同时登录并查看您的聊天应用程序

更准确的经验法则是，对于典型的网站或应用程序，每月并发访问量大于1200次（应用程序实际平均访问量甚至更高）。例如，50个并发连接大约相当于每月50000次访问，其中750次将接近一百万次访问

大多数开发人员高估了他们将拥有的并发用户数量。作为一个数据点，大多数网站在大多数情况下都是按照“免费”的Firebase计划运行的。事实上，超过99.5%的火基从未达到50%的并发限制

---

因此，长话短说，10k concurrents对于我们的自助服务客户来说已经足够了，一旦您接近1200万用户，那么，希望届时企业选项会很有吸引力。

您可以恢复投票，但这将从根本上否定使用Firebase的优势。您对达到该并发用户数的把握有多大？如果这只是一个恐惧/风险，我建议等待它成为一个真正的问题。拥有10000个并发聊天用户是一个很好的问题。：-）对于web应用程序场景来说也是如此。但我说的是Android应用程序。这是一个聊天应用程序。我们公司只有25人（只有5人是开发者），虽然这个应用程序还没有发布，但峰值是20人。在这种情况下，如果50个并发连接可以处理50000次访问，我不同意。对于android和iOS应用程序，它实际上更自由，接近1400个并发连接。人们使用应用程序的时间比坐在公司的时间短。当然，也有例外，你的应用可能是一个例外，但20个concurrents并不重要——这可能完全是伪造连接、后端服务和开发者用户。请确保您有一些可靠的指标，以免在这里过于担心。如果用户不在线，Firebase是否可以向他们发送推送通知？如果没有，您对此有什么建议吗？这些计算对于请求/响应场景（如HTTP）是有效的。但不适用于持久连接场景（如Websocket或普通TCP，通常用于聊天应用程序）。我不知道确切的数字，但它们没有典型的req/res场景（网站）的月访问量大。对于req/res场景，如果用户每天使用一个应用程序30分钟，那么该应用程序发送请求或等待响应的总时间大约为10秒（这就是为什么每月访问量与并发连接量的比率如此之大），但对于聊天应用程序来说，这将是。。好。。30分钟。。。所以这个比例要小得多。