【原创】轻量级移动设备即时通信技术MobileIMSDK的常见问题解答

 

---

申明：MobileIMSDK 目前为我的原创开源工程且已发布，现整理了一些有关MobileIMSDK的常见的问题，但愿对须要的人有用，谢谢。如需与做者交流，见文章底部我的签名处，互相学习。 

---

MobileIMSDK工程的代码托管地址请进入 Git@OSC：点击进入 

学习交流

• 讨论学习和资料区：点此进入 ^推荐
• 移动端即时通信交流群： 215891622 ^推荐
• bug/建议发送至：jb2011@163.com
• 技术支持/合做/咨询请联系做者QQ：413980957

 

【问题1】：MobileIMSDK究竟是什么？有何价值？解决了哪些问题？

① 究竟是什么？
纯技术角度讲：它是一整套基于UDP协议的客户端A、服务端、客户端B的3方全向即时通信算法实现，超轻量级、高度提炼。
应用层角度讲：它是一组包含了Android客户端库、iOS客户端库、Java跨平台客户端库和服务端库的即时通信SDK框架集。
更通俗一点讲：它是一个专为移动设备设计的跨设备、跨平台、跨网络的即时通信开发框架，可用于（包含但不限于）开发聊天APP、企业OA、消息推送应用等。

②  有何价值？
有过即时通信应用开发经验的人都有体会，即时通信应用开发的难点不只在于应用层的业务逻辑实现，更重的要是须要稳定、可靠、对应用层友好的即时通信核心层框架，不然应用层的复杂逻辑再掺杂进即时通信通讯技术自己的复杂性（在无线网络普及的时代，问题更为突出），会让经验不足的开发团队陷入混乱。MobileIMSDK的价值在于：让开发者专一于应用逻辑的开发，底层复杂的即时通信算法交由SDK开发人员，从而解偶即时通信应用开发的复杂性。

③  解决了哪些问题？

• UDP协议实现，更符合现今的复杂移动端网络通讯环境；
• 完善的QoS消息送达保证机制，解决了UDP通讯时的消息黑洞问题；
• 解决了高延迟网络环境下的2G、3G、4G、WiFi以及传统宽带的多端、多网混合通讯可靠性和稳定性问题；
• 拥有通讯自动治愈算法，不管无线信号多么恶劣，只要恢复通讯，将自动实现链接自我修复；
• 预约义多种耗电模式，在应对不一样通讯场景的状况下，自主决定电量、网络流量的消耗等；
• 易拆装的协议封装，可针对不一样应用场景，选择适合的协议压缩方案；
• 历经多个版本的锤炼，API高度封装，在解决应用层与即时通信层代码偶合的同时，能适应更多应用场景。

 

【问题2】：相似于MobileIMSDK的框架好开发吗，有何难度？

老实讲，想要开发出稳定可靠且可用于生产环境的完整算法，并不容易（固然，这只是我的观点，若是你不这么认为，至少说明你比本文做者强多了，呵呵），比较明显的难点以下所述：

难点①：算法偶合性大、整合有难度
算法自己并没有开创性，但杂合无线网络的复杂性（不一样制式、易受干扰等）、跨设备、跨平台、跨网络类型的混合通讯， 这些要素和条件下，要实现的算法偶合性较大，加大了整合的难度。

难点②：算法需多平台无差异精确实现、人员配备省不了
因须要支持不一样平台、多种要素和条件，要实现的算法不可谓不吹毛求疵，要求不算过高，但显然没有些许功底是不太容易搞定的，因此人员配备是个问题。

难点③：框架的提炼和把握需精准、对上层友好是关键
能较高质量地实现所谓“框架”的价值已然超越了算法自己，不然再牛逼的东西也只能孤芳自赏，因此对上层友好也很关键，简单的代码堆砌显然不可能达到目的。

难点④：时间上很难一蹴而就
在众多要素和条件存在的前提下，未经长期的测试和针对性调优，很难知足实际应用的品质要求，时间上也是省不了的。

 

【问题3】：使用MobileIMSDK时如何得到帮助？

• 讨论学习和资料区：点击进入；
• 移动端即时通信学习交流群：215891622 （更多QQ群点此进入）；
• bug和建议请发送至：jack.jiang@openmob.net 或 jb2011@163.com；
• 技术支持、技术合做或咨询请联系做者QQ：413980957。

 

【问题4】：MobileIMSDK定义了具体的聊天APP协议吗？

没有。MobileIMSDK有明确的设计目标：即实现一个”专为移动端开发，可应用于跨设备的聊天APP、企业OA、消息推送等各类场景的高可重用即时通信框架。“，因此为了提高MobileIMSDK的可重用性和灵活性，设计之初就特别回避了这一点。

这么设计带来的好处是，好比当MobileIMSDK应用于企业OA时，因传统企业应用系统中，一般都有自已的用户关系管理模型和实现，于是只须要将MobileIMSDK做为即时通信消息路由子系统来使用便可，这样的场景下事情原本就该这么简单。

固然，您能够自已定义您的聊天APP协议细节，这也意味着您在开发时能拥有更高的灵活性。一个典型的基于MobileIMSDK的全功能聊天应用APP案例：点此查看和试用。

 

【问题5】：MobileIMSDK为什么是基于UDP协议实现？有何好处？

众所周之，由于UDP协议的无链接特性，比较明显的好处有如下两点：

好处①：同等服务器软硬件条件下的更高效费比
相比TCP协议，因UDP协议的无链接特性，可灵活调整即时通信算法，从而达成在有限的软硬件条件下能支持更多的同时在线数。

好处②：很是适合于网络延迟较大、网络环境复杂的场景
某款基于MobileIMSDK的应用（点此查看它的非敏感运营数据）曾运营于高延迟、复杂的跨国、跨洲际网络环境下（统计代表，此应用的典型网络环境里访问一个http应用的单向网络平均延迟高达300ms以上，而同时段访问国内的主流门户延迟约为30ms左右），应用仍能正常保持较好的用户体验。这也必定程度证实了MobileIMSDK在此场景下的稳定性和可靠性。但假设此种状况下使用TCP协议，则协议层丢包和重传状况会很是多，根据TCP协议的重传算法指数退避原则，在某些状况下，所以而带来的用户体验灾难是没法控制的。

 

【问题6】：MobileIMSDK支持集群吗？

MobileIMSDK暂不支持集群（后绪版本有支持集群的计划）。理论上，MobileIMSDK应用于聊天APP时单机可负载的同时在线数可数十万，应用于推送场景下可达千万级别，若是您的应用能达到这样的负载极限，总用户数至少是百万甚至千万级别，相信一切技术问题都再也不会是问题了。不管如何，任何同类技术的单机容量都会有颈，为了更高的负载和更好的伸缩性，大型应用里集群固然是必须的选择。MobileIMSDK的压力测试报告：点此查看。

 

【问题7】：MobileIMSDK支持TCP协议吗？

目前不支持。MobileIMSDK设计之初，充分考虑了移动互联网的网络复杂性和不可靠特性，最终选择以UDP协议实现之，目前尚未特别须要支持TCP协议的理由出现，固然如您有好的建议和想法，欢迎交流和讨论。

 

【问题8】：MobileIMSDK支持同一用户名的多设备登录吗？

理论上MobileIMSDK的通信不依赖于用户名（服务端会为每个登录的客户端分配一个惟一ID），于是同一用户名在不一样客户端登录时，通信不受影响，但具体实现还依赖于应用层是若是处理的。

 

【问题9】：客户端后台有心跳机制吗？为什么须要心跳机制？

MobileIMSDK的客户端后台有健壮的心跳机制，使用心跳机制的主要目的有3个：

目的①：刷新NAT路由的UDP端口老化时间
典型状况下厂商的NAT路由算法中UDP的端口老化时间约为300秒（固然，具体数值由无线ISP或您的家用路由器厂商定义，不少状况下此时间可能会更短），若是没有心跳机制，则您的客户端将会因UDP端口老化而再也收不到消息。这显然不是MobileIMSDK的问题，它是由网关设备的NAT路由算法所决定。

目的②：告诉服务端您的客户端还“活着”
由于UDP的无链接特性，心跳机制对于刷新服务端的在线列表是直接而有效的方案。

目的③：让客户端知道自已经是否还处于“正常通讯”状态致使客户端与服务端没法通讯的因素有不少，很难用有限且简单的代码来判断之。举个例子：当您的手机正常链接于您的家庭WiFi时，WiFi链接是正常的，但此时您的宽带因为欠费或其它缘由根本就没法上网，此时若是没有心跳机制，您的APP会认为网络正常，但却没法完成数据的收发，由于根本就上不了网。