Flutter中基于距离的类Tinder搜索最优实现方案咨询

1. geolocator是否为当前场景的最优插件？有没有更适配的方案？ #

geolocator是Flutter生态里非常成熟的跨平台定位插件，不管是获取用户经纬度，还是客户端计算两点距离，API都直观易用，而且稳定性、iOS/Android双平台兼容性拉满，完全能覆盖你的场景。

如果说替代方案：

• 要是你的应用已经集成了Google Maps SDK，也可以用SDK内置的距离计算方法，但没必要额外引入，geolocator足够轻量，不需要依赖Maps的庞大SDK。
• 若你更倾向于后端处理距离计算，客户端只用geolocator拿定位数据就行，不过这属于架构调整，不是插件层面的替代。

总的来说，geolocator就是当前场景的最优选择，没有必要换其他插件。

2. 用户量较大时原方案是否可行？是否需要geohashing？geoflutterfire受Google Maps API限制吗？Firestore局限是否必须迁Back4App？ #

原方案的可行性 #

原方案（每次查前10个用户再客户端算距离）在用户量小的时候凑合用，但用户量上来后完全不可行：

• Firestore的“前10个用户”是按你设置的排序规则返回的，大概率大部分都不在目标半径内，纯纯浪费带宽和客户端计算资源。
• 要是为了凑够10个符合条件的用户，你可能得查几十上百个数据，客户端逐个算距离会明显拖慢加载速度。

是否需要geohashing？ #

必须用。Firestore本身不支持原生的半径查询，geohashing可以把经纬度转换成一段哈希字符串，通过查询相邻的哈希值范围，就能把候选用户的范围大幅缩小到目标半径附近，之后再用geolocator做精确距离筛选，效率会提升几个量级。

geoflutterfire是否受Google Maps API调用限制？ #

不会。geoflutterfire的核心是给Firestore文档生成geohash字段，以及基于geohash做范围查询，它本身不需要调用Google Maps的API——除非你主动用它结合Maps API做额外操作，否则完全不用担心调用限制和费用问题。

是否必须迁移到Back4App？ #

没必要。如果你的应用已经基于Firestore开发了大部分功能，迁移到Back4App的成本太高（数据迁移、代码适配、学习新平台）。用geoflutterfire+geohashing的方案，完全可以在Firestore上实现高效的地理范围查询，再结合兴趣标签的过滤，完全能满足你的需求。只有当你有Firestore完全无法满足的其他核心需求时，再考虑迁移不迟。

额外优化建议 #

• 用户的经纬度不要只在App启动时存一次，应该设置位置变化阈值（比如移动超过50米），自动更新Firestore里的坐标和对应的geohash字段，保证查询的准确性。
• 查询时先通过geohash筛选候选集，再筛选兴趣匹配的用户，最后计算精确距离并排序，取前10个返回，这样能把性能损耗降到最低。

内容的提问来源于stack exchange，提问作者Big_Chair