我想在我的Android应用中添加用户之间的聊天。
我读到了Firebase Cloud Messaging，除了Firebase，我了解到must implement an app server（后端）。
另一方面，我发现了一些使用其他方法的来源：他们使用Firebase实时数据库本身作为后端（例如MChat-master）。通过代码查看似乎根本没有使用FirebaseMessaging。他们向Firebase发送聊天消息并侦听数据中的更改。当消息上传到服务器时，数据会被更改，调用侦听器并在接收电话上提取消息。
我的问题是：首选哪种方式？
第一种方法对我来说听起来更真实，而第二种方法看起来像是一种无需处理后端服务器的解决方法。
第一种方法（使用FCM）：
优点：
在客户端使用服务和广播接收器（简易前端）
消息会发送到客户端，只要应用程序启动就会收到消息（不用担心应用程序关闭时会传递消息）
缺点：
第二种方法（使用Firebase作为后端）：
优点：
无需处理后端服务器
我已经在使用Firebase实时数据库，因此我熟悉其查询
缺点：
必须在我的所有活动中添加侦听器以侦听服务器上的数据更改并决定是否提取新消息
当应用未运行时（听众没有醒来），我没有看到处理传入消息的简单方法
使用Firebase作为标准方式的聊天后端是什么？如果是这样，你对我所列出的不良行为的看法是什么？
答案 0 :(得分：1)
恕我直言，没有一种标准方法可以构建聊天模块（或其他任何真正的方法），而是实现特定功能集的有效方法..
在这种情况下，我会说这取决于你是否想要通知你的用户有关应用程序外的传入消息...如果你不这样做，那么使用Firebase w / oa应该没有任何问题后端服务，只是听取变化..
但是，如果您确实需要有关新消息的通知，即使应用程序未运行，那么基于纯粹的基于更改的侦听也不是最佳解决方案。您应该能够设置一个服务，该服务将尝试侦听更改时应用程序也出来了..但谷歌（以及苹果公司）已经 高度 优化了处理推送通知的流程，这些推送通知不能快速打开天线并节省成本宝贵的电池寿命和其他资源...
尽管如此，如果你的目标是尽可能快地制作MVP或原型，那么在没有后端的情况下进行开发肯定会降低成本，而不是过早优化会带来更多弊大于利......
考虑到所有因素，不要寻找标准方式.. 没有一个 ...整理出您的解决方案所需的优先级和功能有你想要投资的容量/成本，然后做出决定..