默认
发表评论 7
想开发IM:买成品怕坑?租第3方怕贵?找开源自已撸?尽量别走弯路了... 找站长给点建议
[已回复] 求助使用MobileIMSDK开发位置共享App的技术方案探讨
阅读(37733) | 评论(7 收藏 淘帖
首先感谢大佬JackJiang提供宝地,让我学到了很多网络方面的知识。

我是一个小白独立开发者,自己有开发一个地图类app,一直想把位置共享功能加入其中,一直也在努力,由于环境比较封闭所以只能依赖网络上学习,导致进度缓慢,填坑不少,方案定了又推,难定取舍,耗费了不少精力,现在通过在这个网站不断的学习,已经基本完成了“队伍建立”“队伍修改”“队伍申请”这几个基本功能,其中也是按照大神的指导,udp短指令加http请求来完成的,现在遇到核心的位置队伍共享功能,方案不能取舍,想在这里让大神JackJiang给点指导。

方案一

用户定位成功,然后通过udp上传到服务器,服务器取对应队伍所有成员的列表,循环判断是否在线,如果在线则分发给每个用户,用户端收到后做相应的处理即完成一次定位操作
优势:实时
劣势:
  • 1.当用户所在的组群过多时,需要向每个组群发送位置,这样以来,服务器同时接收转发的指令的量可能会非常的大,后期业务量上来后可能会有一定的压力
  • 2.需要向用户所有的组的成员推送当前位置,这个任务量较大 实现起来不够优雅

方案二

修改IMservice源码,在onlineProcessor中添加一个ConcurrentHashMap(String,String) 来存在在线用户的位置信息(userId,locationString)

用户定位成功,通过udp上传服务器,然后服务器存入ConcurrentHashMap中,位置分发则采取用户端定时任务通过http循环请求的方式,例如如果当前用户选择队伍A来加载在地图上,则后台locaitonShareService启动一个循环任务 http请求server,然后service获取队伍A所有成员username,然后从ConcurrentHashMap中把位置取出来生成json返回用户端
优势:简单优雅
劣势:不够实时

以上是我想到的两个方案,望大神给点指导,该选哪个方案进行哪些优化,或者还有更好的方案
功能实时性要求其实不高,5秒一个位置更新已足够
其实前面由提过这个问题,大神进行过回复,不过现在我对MobileIm的理解更深了,所以想提出来再探讨一下,希望大佬指导指导!




即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:[已回复] 求教MobileIMSDK中登陆连接超时,该怎么实现下一篇:开源轻量级IM框架 MobileIMSDK v6.1.1 已发布!
推荐方案
评论 7
你这个是用在什么场景下的?实时性不需要要求这么高吧。

如果是像微信里的那种:“共享位置”功能,通常也只是选择某个或某几个人进行实时共享,而不是你说的一个群、甚至会有很多群同时共享。微信这种是在有限用户间的实时共享,而且这种功能本身是冷门功能不常用,所以各方面的资源消耗上也能接受
就是户外工作, 一个队伍 一起行动,需要彼此知道位置,或者是上级需要知道下级一个队伍的位置等等,其实位置共享在大多数情况下实时性不需要那么高,2秒到5秒一次刷新就可以满足了
组群现在只用于位置共享,还不涉及组群聊天,起被也不想放开每个队伍的人数限制,可能每个队伍也只能加入10个人
不知道回复成功没,再回复一次
这个功能一般用在户外,大家一个小队 出去工作 ,彼此需要知道对方的位置 ,或者是上级需要知道下级一个小队的位置信息等等,个人认为一般情况位置共享的场景对实时性要求都没有那么高
我的app中的这个队伍功能暂时只用于位置共享,不用于组群聊天
引用:jayhuang 发表于 2021-08-10 22:13
不知道回复成功没,再回复一次
这个功能一般用在户外,大家一个小队 出去工作 ,彼此需要知道对方的位置  ...

如果实时性要求不高,你就别用MobileIMSDK这种长连接框架,直接http定时上传和下拉,这样的技术实现成本小多了。长连接的优势就是实时性,抛去实时性的话,长连接代价太大了
引用:JackJiang 发表于 2021-08-11 13:57
如果实时性要求不高,你就别用MobileIMSDK这种长连接框架,直接http定时上传和下拉,这样的技术实现成本 ...

这几天我也研究过其它类型软件的实现方法,其实都是http上传和下拉,但考虑到以后可能会涉及聊天等实时性功能,包括现有功能中也有“申请加入队伍”等有实时性需求的功能,所以决定还是保留mobileim然后采用上面的第二种方法来
引用:jayhuang 发表于 2021-08-11 14:53
这几天我也研究过其它类型软件的实现方法,其实都是http上传和下拉,但考虑到以后可能会涉及聊天等实时性 ...

可以。后期根据生产环境下的具体情况,再进行调整就好了,留好优化空间。
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部