本帖最后由 茜茜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、消息推送应用等。

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

③  解决了哪些问题?

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

【问题2】:类似于MobileIMSDK的框架好开发吗,有何难度?

老实讲,想要开发出稳定可靠且可用于生产环境的完整算法,并不容易(当然,这只是个人观点,如果你不这么认为,至少说明你比本文作者强多了,呵呵),比较明显的难点如下所述:
难点①:算法偶合性大、整合有难度
算法本身并无开创性,但杂合无线网络的复杂性(不同制式、易受干扰等)、跨设备、跨平台、跨网络类型的混合通信, 这些要素和条件下,要实现的算法偶合性较大,加大了整合的难度。

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

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

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

【问题3】:使用MobileIMSDK时如何获得帮助?

【问题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会认为网络正常,但却无法完成数据的收发,因为根本就上不了网。

开源轻量级即时通讯技术 MobileIMSDK 的常见问题解答的更多相关文章

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

    申明:MobileIMSDK 目前为个人原创开源工程且已发布,现整理了一些有关MobileIMSDK的常见的问题,希望对需要的人有用,谢谢.如需与作者交流,见文章底部个人签名处,互相学习. Mobil ...

  2. 【原创】轻量级即时通讯技术MobileIMSDK:Android客户端开发指南

    申明:MobileIMSDK 目前为个人维护的原创开源工程,现陆续整理了一些资料,希望对需要的人有用.如需与作者交流,见文章底签名处,互相学习. MobileIMSDK开源工程的代码托管地址请进入 G ...

  3. 【原创】轻量级移动端即时通讯技术 MobileIMSDK 发布了

    申明:MobileIMSDK目前为个人原创开源工程,投入了大量的时间和精力,希望对需要的人有所帮助.如需与作者交流,见文章底部个人签名处,互相学习.Q群:215891622,欢迎共同志趣者学习和交流. ...

  4. Web端即时通讯技术原理详解

    前言 有关IM(InstantMessaging)聊天应用(如:微信,QQ).消息推送技术(如:现今移动端APP标配的消息推送模块)等即时通讯应用场景下,大多数都是桌面应用程序或者native应用较为 ...

  5. Web端即时通讯技术盘点:短轮询、Comet、Websocket、SSE

    1. 前言 Web端即时通讯技术因受限于浏览器的设计限制,一直以来实现起来并不容易,主流的Web端即时通讯方案大致有4种:传统Ajax短轮询.Comet技术.WebSocket技术.SSE(Serve ...

  6. 新手入门:史上最全Web端即时通讯技术原理详解

    前言 有关IM(InstantMessaging)聊天应用(如:微信,QQ).消息推送技术(如:现今移动端APP标配的消息推送模块)等即时通讯应用场景下,大多数都是桌面应用程序或者native应用较为 ...

  7. 国内开源的即时通讯框架 (endv.cn) (前言)

    如题:国内开源类似QQ的即时通讯框架(endv.cn) 出于在企业管理方面遇到的一些瓶颈问题,特别是在数据收集.统计与分析,大数据处理,时时监控跟踪,风险分析.成本控制等方面遇到的很多数据信息问题等, ...

  8. WebRtc(网页即时通讯技术)知识点总结

    前言 WebRTC,名称源自网页实时通信(Web Real-Time Communication)的缩写,简而言之它是一个支持网页浏览器进行实时语音对话或视频对话的技术.并且还支持跨平台:window ...

  9. 新手入门贴:史上最全Web端即时通讯技术原理详解

    关于IM(InstantMessaging)即时通信类软件(如微信,QQ),大多数都是桌面应用程序或者native应用较为流行,而网上关于原生IM或桌面IM软件类的通信原理介绍也较多,此处不再赘述.而 ...

随机推荐

  1. memcached和redis区别

    Memcached:是高性能分布式内存缓存服务器,本质是一个内存 key-value 数据库,但不支持数据持久化,服务器关闭后,数据全丢失.只支持 key-value 结构. Redis:将大部分数据 ...

  2. 比特币编译(Ubuntu 16.04)

    安装比特币需要的所有库 sudo apt-get install build-essential libtool autotools-dev automake pkg-config libssl-de ...

  3. 阿里CDN核心技术解密

    1. 阿里CDN组件分层 其中应用层主要用到的技术有负载均衡和缓存, 负载均衡包括全局负载均衡和本地负载均衡; 缓存通过HTTP缓存服务器Swift做HTTP缓存. 全局负载均衡以DNS服务器Phar ...

  4. Java初次见面

    1.Java语言特点(运行环境JRE[操作系统,api,dll]): a.跨平台:Java自带的虚拟机很好地实现了跨平台性.Java源程序代码经过编译后生成二进制的字节码是与平台无关的,但是可被Jav ...

  5. Github精选 – 适合移动端的HTML5 Datepicker

     2016-01-12 (updated: 2017-01-07) 15731 通过 HTML5 的 <input> 新属性可以简单方便地调用手机的原生 Datepicker,但功能较弱, ...

  6. jstorm系列-2:入门

    有了基本的概念之后,我们用jstorm来做一点小事情吧 做一个很无聊的事情:给定一个时间戳,输出对应的问候语 规则是:时间戳的十位对应的数字对应不同的时间段,0-2代表早上,3代表中午,4-6代表下午 ...

  7. 无锁的对象引用:AtomicReference

    http://www.dewen.net.cn/q/9588 首先volatile是java中关键字用于修饰变量,AtomicReference是并发包java.util.concurrent.ato ...

  8. 关于k8s里的service互访,有说法

    昨天,测试了一个项目的接入.明白了以下几个坑: 1,traefik有可能有性能问题,如果daemonset安装,可重建.也需要通过8580端口查看性能. 2,集群中的service访问自己时,好像性能 ...

  9. Table上下滚动

    <table> <tr> <td> <div id="marquees"> <!-- 这些是字幕的内容,你可以任意定义 --& ...

  10. Linux下使用ssh远程登录服务器

    如果自己的服务器是在内网,想在外网通过ssh在自己的VPS服务器上远程登录自己的内网服务器,可以按照如下操作: 一.在自己的服务器上使用如下命令: #ssh -CfnNT -R 端口A:localho ...