本帖最后由 茜茜asa 于 2015-12-14 17:50 编辑
申明:MobileIMSDK 目前为个人原创开源工程且已发布,现整理了一些有关MobileIMSDK的常见的问题,希望对需要的人有用,谢谢。
MobileIMSDK开源工程的代码托管地址请进入 Git@OSC:点击进入
MobileIMSDK的Android端SDK文档:点此进入
【问题1】:MobileIMSDK到底是什么?有何价值?解决了哪些问题?
① 到底是什么?
纯技术角度讲:它是一整套基于UDP协议的客户端A、服务端、客户端B的3方全向即时通讯算法实现,超轻量级、高度提炼。 应用层角度讲:它是一组包含了Android客户端库、iOS客户端库、Java跨平台客户端库和服务端库的即时通讯SDK框架集。 更通俗一点讲:它是一个专为移动设备设计的跨设备、跨平台、跨网络的即时通讯开发框架,可用于(包含但不限于)开发聊天APP、企业OA、消息推送应用等。 ② 有何价值? ③ 解决了哪些问题?
【问题2】:类似于MobileIMSDK的框架好开发吗,有何难度? 老实讲,想要开发出稳定可靠且可用于生产环境的完整算法,并不容易(当然,这只是个人观点,如果你不这么认为,至少说明你比本文作者强多了,呵呵),比较明显的难点如下所述:
难点①:算法偶合性大、整合有难度
算法本身并无开创性,但杂合无线网络的复杂性(不同制式、易受干扰等)、跨设备、跨平台、跨网络类型的混合通信, 这些要素和条件下,要实现的算法偶合性较大,加大了整合的难度。 难点②:算法需多平台无差别精确实现、人员配备省不了 难点③:框架的提炼和把握需精准、对上层友好是关键 难点④:时间上很难一蹴而就 【问题3】:使用MobileIMSDK时如何获得帮助?
【问题4】:MobileIMSDK定义了具体的聊天APP协议吗? 没有。MobileIMSDK有明确的设计目标:即实现一个”专为移动端开发,可应用于跨设备的聊天APP、企业OA、消息推送等各种场景的高可重用即时通讯框架。“,所以为了提升MobileIMSDK的可重用性和灵活性,设计之初就特别回避了这一点。
这么设计带来的好处是,比如当MobileIMSDK应用于企业OA时,因传统企业应用系统中,通常都有自已的用户关系管理模型和实现,因而只需要将MobileIMSDK作为即时通讯消息路由子系统来使用即可,这样的场景下事情本来就该这么简单。 当然,您可以自已定义您的聊天APP协议细节,这也意味着您在开发时能拥有更高的灵活性。一个典型的基于MobileIMSDK的全功能聊天应用APP案例:点此查看和试用。 【问题5】:MobileIMSDK为何是基于UDP协议实现?有何好处?
众所周之,因为UDP协议的无连接特性,比较明显的好处有以下两点:
好处①:同等服务器软硬件条件下的更高效费比 好处②:非常适合于网络延迟较大、网络环境复杂的场景 【问题6】:MobileIMSDK支持集群吗? MobileIMSDK暂不支持集群(后绪版本有支持集群的计划)。理论上,MobileIMSDK应用于聊天APP时单机可负载的同时在线数可数十万,应用于推送场景下可达千万级别,如果您的应用能达到这样的负载极限,总用户数至少是百万甚至千万级别,相信一切技术问题都不再会是问题了。无论如何,任何同类技术的单机容量都会有颈,为了更高的负载和更好的伸缩性,大型应用里集群当然是必须的选择。MobileIMSDK的压力测试报告:点此查看。
【问题7】:MobileIMSDK支持TCP协议吗? 目前不支持。MobileIMSDK设计之初,充分考虑了移动互联网的网络复杂性和不可靠特性,最终选择以UDP协议实现之,目前还没有特别需要支持TCP协议的理由出现,当然如您有好的建议和想法,欢迎交流和讨论。
【问题8】:MobileIMSDK支持同一用户名的多设备登陆吗? 理论上MobileIMSDK的通讯不依赖于用户名(服务端会为每一个登陆的客户端分配一个唯一ID),因而同一用户名在不同客户端登陆时,通讯不受影响,但具体实现还依赖于应用层是如果处理的。
【问题9】:客户端后台有心跳机制吗?为何需要心跳机制?
MobileIMSDK的客户端后台有健壮的心跳机制,使用心跳机制的主要目的有3个:
目的①:刷新NAT路由的UDP端口老化时间 目的②:告诉服务端您的客户端还“活着” 目的③:让客户端知道自已是否还处于“正常通信”状态 |