问题陈述如何使用Firebase Messaging与Android / iOS应用程序设计基于实时位置的通知系统？
场景
- 用户A创建报告
- 如果用户B位于用户A报告位置的5 km半径内，则用户B应收到通知（即：所有附近的用户得到通知）
该应用程序可以有1000个并发用户，经常发布报告。
通知应尽可能真实的发送。
通知应发送给5公里半径内使用该应用程序的任何人。使用GeoFencing选项，设备在某个区域唤醒不是一个选项，因为当他们附近发生报告时，用户应该始终得到通知。
考虑的方法
- 答：*
- 上传用户位置到服务器每隔一段时间，并存储在数据库中
- 当新报告时，查找半径内的用户，并向每个单独的设备/FCM令牌发送通知
缺点：
- 必须不断上传用户位置到服务器（服务器负载，可扩展性，隐私）
- B：*
- 每个客户端应用程序订阅FCM主题，例如“new-reports”
- 新建报告时，服务器将“仅数据”FCM事件发布到“新建报告”主题
- FCM向所有设备发送消息，设备唤醒并检查用户是否在报告半径内
- 如果是，应用程序将创建通知
优点：
- 减少服务器处理
缺点：
- 不适用于iOS，因为只有后台数据的消息并不总是发送到iOS客户端
- 事件发送到应用程序的每个用户-无论他们是否在该区域
方法B对我来说似乎是两害相权取其轻，但是由于只有数据的消息在后台没有在iOS上传递，因此不适用于iOS。方法A听起来像是电池耗尽，如果必须继续向服务器发送位置，则可能存在隐私问题。
有什么好的方法可以用在这里吗？
1条答案
按热度按时间tcomlyy61#
B不会扩展到成千上万的用户。假设您有N个用户，每个用户每小时有R个报告。这意味着您每小时总共有NR个报告。您需要将其发送给N个用户，这意味着每小时发送N^2R条消息。您的负载按用户数量的平方进行扩展。你会在服务器和处理上花一大笔钱。更不用说你会很快达到消息限制（省电模式每小时只允许这么多的消息，然后就不再允许高优先级的推送通知）。虽然A是更好的隐私，但它不能扩展。实际上，无论如何，你都没有隐私，无论何时你向服务器发送报告，你都必须发送位置。
如果你想模糊一点位置，把Map分成几个区域，只报告你在哪个区域（整个5公里的圆圈永远不会工作得很好，因为它是如此有效，只是做不太准确，但更快的lat/lng查找，而不计算精确的圆圈）。那么你只能在25平方公里的街区内将他们的位置发送到服务器。