为了账号安全,请及时绑定邮箱和手机立即绑定

开源一个自用的Android IM库,基于Netty+TCP+Protobuf实现。

欢迎转载,转载请注明出处:https://www.imooc.com/article/285006

写在前面

一直想写一篇关于im即时通讯分享的文章,无奈工作太忙,很难抽出时间。今天终于从公司离职了,打算好好休息几天再重新找工作,趁时间空闲,决定静下心来写一篇文章,毕竟从前辈那里学到了很多东西。工作了五年半,这三四年来一直在做社交相关的项目,有
直播
即时通讯
短视频分享
社区论坛
等产品,深知即时通讯技术在一个项目中的重要性,本着开源分享的精神,也趁这机会总结一下,所以写下这篇文章,文中有不对之处欢迎批评与指正。

本文将介绍:

  • Protobuf序列化
  • TCP拆包与粘包
  • 长连接握手认证
  • 心跳机制
  • 重连机制
  • 消息重发机制
  • 读写超时机制
  • 离线消息
  • 线程池
  • AIDL跨进程通信

本想花一部分时间介绍一下利用AIDL实现多进程通信,提升应用保活率,无奈这种方法在目前大部分Android新版本上已失效,而且也比较复杂,所以考虑再三,把AIDL这一部分去掉,需要了解的童鞋可以私信我。

先来看看效果:
最终运行效果

不想看文章的同学可以直接移步到Github fork源码:github地址

接下来,让我们进入正题。


为什么使用TCP?

这里需要简单解释一下,TCP/UDP/WebSocket的区别。
这里就很好地解释了TCP/UDP的优缺点和区别,以及适用场景,简单地总结一下:

  • 优点:

    • TCP的优点体现在稳定可靠上,在传输数据之前,会有三次握手来建立连接,而且在数据传递时,有确认、窗口、重传、拥塞控制机制,在数据传完之后,还会断开连接用来节约系统资源。
    • UDP的优点体现在比TCP稍安全,UDP没有TCP拥有的各种机制,是一个无状态的传输协议,所以传递数据非常快,没有TCP的这些机制,被攻击利用的机制就少一些,但是也无法避免被攻击。
  • 缺点:

    • TCP缺点就是效率低占用系统资源高易被攻击,TCP在传递数据之前要先建立连接,这会消耗时间,而且在数据传递时,确认机制、重传机制、拥塞机制等都会消耗大量时间,而且要在每台设备上维护所有的传输连接。
    • UDP缺点就是不可靠不稳定,因为没有TCP的那些机制,UDP在传输数据时,如果网络质量不好,就会很容易丢包,造成数据的缺失。
  • 适用场景:

    • TCP:当对网络通讯质量有要求时,比如HTTP、HTTPS、FTP等传输文件的协议, POP、SMTP等邮件传输的协议。
    • UDP:对网络通讯质量要求不高时,要求网络通讯速度要快的场景。

至于WebSocket,后续可能会专门写一篇文章来介绍。
综上所述,决定采用TCP协议。


为什么使用Protobuf?

对于App网络传输协议,我们比较常见的、可选的,有三种,分别是json/xml/protobuf,老规矩,我们先分别来看看这三种格式的优缺点:

  • 优点:

    • json优点就是较XML格式更加小巧,传输效率较xml提高了很多,可读性还不错。
    • xml优点就是可读性强,解析方便。
    • protobuf优点就是传输效率快(据说在数据量大的时候,传输效率比xml和json快10-20倍),序列化后体积相比Json和XML很小,支持跨平台多语言,消息格式升级和兼容性还不错,序列化反序列化速度很快。
  • 缺点:

    • json缺点就是传输效率也不是特别高(比xml快,但比protobuf要慢很多)。
    • xml缺点就是效率不高,资源消耗过大。
    • protobuf缺点就是使用不太方便。

在一个需要大量的数据传输的场景中,如果数据量很大,那么选择protobuf可以明显的减少数据量,减少网络IO,从而减少网络传输所消耗的时间。考虑到作为一个主打社交的产品,消息数据量会非常大,同时为了节约流量,所以采用protobuf是一个不错的选择。


为什么使用Netty?

首先,我们来了解一下,Netty到底是个什么东西。网络上找到的介绍:Netty是由JBOSS提供的基于Java NIO的开源框架,Netty提供异步非阻塞、事件驱动、高性能、高可靠、高可定制性的网络应用程序和工具,可用于开发服务端和客户端。

  • 为什么不用Java BIO?

    • 一连接一线程,由于线程数是有限的,所以这样非常消耗资源,最终也导致它不能承受高并发连接的需求。
    • 性能低,因为频繁的进行上下文切换,导致CUP利用率低。
    • 可靠性差,由于所有的IO操作都是同步的,即使是业务线程也如此,所以业务线程的IO操作也有可能被阻塞,这将导致系统过分依赖网络的实时情况和外部组件的处理能力,可靠性大大降低。
  • 为什么不用Java NIO?

    • NIO的类库和API相当复杂,使用它来开发,需要非常熟练地掌握Selector、ByteBuffer、ServerSocketChannel、SocketChannel等。
    • 需要很多额外的编程技能来辅助使用NIO,例如,因为NIO涉及了Reactor线程模型,所以必须必须对多线程和网络编程非常熟悉才能写出高质量的NIO程序。
    • 想要有高可靠性,工作量和难度都非常的大,因为服务端需要面临客户端频繁的接入和断开、网络闪断、半包读写、失败缓存、网络阻塞的问题,这些将严重影响我们的可靠性,而使用原生NIO解决它们的难度相当大。
    • JDK NIO中著名的BUG–epoll空轮询,当select返回0时,会导致Selector空轮询而导致CUP100%,官方表示JDK1.6之后修复了这个问题,其实只是发生的概率降低了,没有根本上解决。
  • 为什么用Netty?

    • API使用简单,更容易上手,开发门槛低
    • 功能强大,预置了多种编解码功能,支持多种主流协议
    • 定制能力高,可以通过ChannelHandler对通信框架进行灵活地拓展
    • 高性能,与目前多种NIO主流框架相比,Netty综合性能最高
    • 高稳定性,解决了JDK NIO的BUG
    • 经历了大规模的商业应用考验,质量和可靠性都有很好的验证。
  • 为什么不用第三方SDK,如:融云、环信、腾讯TIM?
    这个就见仁见智了,有的时候,是因为公司的技术选型问题,因为用第三方的SDK,意味着消息数据需要存储到第三方的服务器上,再者,可扩展性、灵活性肯定没有自己开发的要好,还有一个小问题,就是收费。比如,融云免费版只支持100个注册用户,超过100就要收费,群聊支持人数有限制等等…
    融云收费

Mina其实跟Netty很像,大部分API都相同,因为是同一个作者开发的。但感觉Mina没有Netty成熟,在使用Netty的过程中,出了问题很轻易地可以找到解决方案,所以,Netty是一个不错的选择。

好了,废话不多说,直接开始吧。


准备工作

  • 首先,我们新建一个Project,在Project里面再新建一个Android Library,Module名称暂且叫做im_lib,如图所示:
    新建项目

  • 然后,分析一下我们的消息结构,每条消息应该会有一个消息唯一id,发送者id,接收者id,消息类型,发送时间等,经过分析,整理出一个通用的消息类型,如下:

    • msgId 消息id
    • fromId 发送者id
    • toId 接收者id
    • msgType 消息类型
    • msgContentType 消息内容类型
    • timestamp 消息时间戳
    • statusReport 状态报告
    • extend 扩展字段

    根据上述所示,我整理了一个思维导图,方便大家参考:
    消息结构
    这是基础部分,当然,大家也可以根据自己需要自定义比较适合自己的消息结构。

    我们根据自定义的消息类型来编写proto文件。
    编写proto文件
    然后执行命令(我用的mac,windows命令应该也差不多):
    执行protoc命令
    然后就会看到,在和proto文件同级目录下,会生成一个java类,这个就是我们需要用到的东东:
    生成的protobuf java类文件
    我们打开瞄一眼:
    打开的protobuf java类文件
    东西比较多,不用去管,这是google为我们生成的protobuf类,直接用就行,怎么用呢?直接用这个类文件,拷到我们开始指定的项目包路径下就可以啦:
    导入protobuf java类文件到项目中
    添加依赖后,可以看到,MessageProtobuf类文件已经没有报错了,顺便把netty的jar包也导进来一下,还有fastjson的:
    导入protobuf以及netty的依赖
    建议用netty-all-x.x.xx.Final的jar包,后续熟悉了,可以用精简的jar包。

    至此,准备工作已结束,下面,我们来编写java代码,实现即时通讯的功能。


封装

为什么需要封装呢?说白了,就是为了解耦,为了方便日后切换到不同框架实现,而无需到处修改调用的地方。举个栗子,比如Android早期比较流行的图片加载框架是Universal ImageLoader,后期因为某些原因,原作者停止了维护该项目,目前比较流行的图片加载框架是Picasso或Glide,因为图片加载功能可能调用的地方非常多,如果不作一些封装,早期使用了Universal ImageLoader的话,现在需要切换到Glide,那改动量将非常非常大,而且还很有可能会有遗漏,风险度非常高。

那么,有什么解决方案呢?

很简单,我们可以用工厂设计模式进行一些封装,工厂模式有三种:简单工厂模式、抽象工厂模式、工厂方法模式。在这里,我采用工厂方法模式进行封装,具体区别,可以参见:通俗讲讲我对简单工厂、工厂方法、抽象工厂三种设计模式的理解

我们分析一下,ims(IM Service,下文简称ims)应该是有初始化建立连接重连关闭连接释放资源判断长连接是否关闭发送消息等功能,基于上述分析,我们可以进行一个接口抽象:
抽象的ims接口1
抽象的ims接口2
OnEventListener是与应用层交互的listener:
OnEventListener
IMConnectStatusCallback是ims连接状态回调监听器:
IMConnectStatusCallback

然后写一个Netty tcp实现类:
Netty tcp ims1
Netty tcp ims2

接下来,写一个工厂方法:
ims实例工厂方法

封装部分到此结束,接下来,就是实现了。


初始化

我们先实现init(Vector serverUrlList, OnEventListener listener, IMSConnectStatusCallback callback)方法,初始化一些参数,以及进行第一次连接等:
初始化参数

其中,MsgDispatcher是消息转发器,负责将接收到的消息转发到应用层:
MsgDispatcher

ExecutorServiceFactory是线程池工厂,负责调度重连及心跳线程:
ExecutorServiceFactory1
ExecutorServiceFactory2
ExecutorServiceFactory3


连接及重连

resetConnect()方法作为连接的起点,首次连接以及重连逻辑,都是在resetConnect()方法进行逻辑处理,我们来瞄一眼:
resetConnect
可以看到,非首次进行连接,也就是连接一个周期失败后,进行重连时,会先让线程休眠一段时间,因为这个时候也许网络状况不太好,接着,判断ims是否已关闭或者是否正在进行重连操作,由于重连操作是在子线程执行,为了避免重复重连,需要进行一些并发处理。开始重连任务后,分四个步骤执行:

  • 改变重连状态标识
  • 回调连接状态到应用层
  • 关闭之前打开的连接channel
  • 利用线程池执行一个新的重连任务

ResetConnectRunnable是重连任务,核心的重连逻辑都放到这里执行:
ResetConnectRunnable1
ResetConnectRunnable2
ResetConnectRunnable3

toServer()是真正连接服务器的地方:
toServer

initBootstrap()是初始化Netty Bootstrap:
initBootstrap
注:NioEventLoopGroup线程数设置为4,可以满足QPS是一百多万的情况了,至于应用如果需要承受上千万上亿流量的,需要另外调整线程数。参考自:netty实战之百万级流量NioEventLoopGroup线程数配置

接着,我们来看看TCPChannelInitializerHanlder
TCPChannelInitializerHandler
其中,ProtobufEncoderProtobufDecoder是添加对protobuf的支持,LoginAuthRespHandler是接收到服务端握手认证消息响应的处理handler,HeartbeatRespHandler是接收到服务端心跳消息响应的处理handler,TCPReadHandler是接收到服务端其它消息后的处理handler,先不去管,我们重点来分析下LengthFieldPrependerLengthFieldBasedFrameDecoder,这就需要引申到TCP的拆包与粘包啦。


TCP的拆包与粘包

  • 什么是TCP拆包?为什么会出现TCP拆包?

    简单地说,我们都知道TCP是以“流”的形式进行数据传输的,而且TCP为提高性能,发送端会将需要发送的数据刷入缓冲区,等待缓冲区满了之后,再将缓冲区中的数据发送给接收方,同理,接收方也会有缓冲区这样的机制,来接收数据。
    拆包就是在socket读取时,没有完整地读取一个数据包,只读取一部分。

  • 什么是TCP粘包?为什么会出现TCP粘包?

    同上。
    粘包就是在socket读取时,读到了实际意义上的两个或多个数据包的内容,同时将其作为一个数据包进行处理。

引用网上一张图片来解释一下在TCP出现拆包、粘包以及正常状态下的三种情况,如侵请联系我删除:
TCP拆包、粘包、正常状态
了解了TCP出现拆包/粘包的原因,那么,如何解决呢?通常来说,有以下四种解决方式:

  • 消息定长
  • 用回车换行符作为消息结束标志
  • 用特殊分隔符作为消息结束标志,如\t、\n等,回车换行符其实就是特殊分隔符的一种。
  • 将消息分为消息头和消息体,在消息头中用字段标识消息总长度。

netty针对以上四种场景,给我们封装了以下四种对应的解码器:

  • FixedLengthFrameDecoder,定长消息解码器
  • LineBasedFrameDecoder,回车换行符消息解码器
  • DelimiterBasedFrameDecoder,特殊分隔符消息解码器
  • LengthFieldBasedFrameDecoder,自定义长度消息解码器。

我们用到的就是LengthFieldBasedFrameDecoder自定义长度消息解码器,同时配合LengthFieldPrepender编码器使用,关于参数配置,建议参考netty–最通用TCP黏包解决方案:LengthFieldBasedFrameDecoder和LengthFieldPrepender这篇文章,讲解得比较细致。我们配置的是消息头长度为2个字节,所以消息包的最大长度需要小于65536个字节,netty会把消息内容长度存放消息头的字段里,接收方可以根据消息头的字段拿到此条消息总长度,当然,netty提供的LengthFieldBasedFrameDecoder已经封装好了处理逻辑,我们只需要配置lengthFieldOffset、lengthFieldLength、lengthAdjustment、initialBytesToStrip即可,这样就可以解决TCP的拆包与粘包,这也就是netty相较于原生nio的便捷性,原生nio需要自己处理拆包/粘包等问题。


长连接握手认证

接着,我们来看看LoginAuthHandlerHeartbeatRespHandler

  • LoginAuthRespHandler是当客户端与服务端长连接建立成功后,客户端主动向服务端发送一条登录认证消息,带入与当前用户相关的参数,比如token,服务端收到此消息后,到数据库查询该用户信息,如果是合法有效的用户,则返回一条登录成功消息给该客户端,反之,返回一条登录失败消息给该客户端,这里,就是在接收到服务端返回的登录状态后的处理handler,比如:LoginAuthRespHandler
    可以看到,当接收到服务端握手消息响应后,会从扩展字段取出status,如果status=1,则代表握手成功,这个时候就先主动向服务端发送一条心跳消息,然后利用Netty的IdleStateHandler读写超时机制,定期向服务端发送心跳消息,维持长连接,以及检测长连接是否还存在等。

  • HeartbeatRespHandler是当客户端接收到服务端登录成功的消息后,主动向服务端发送一条心跳消息,心跳消息可以是一个空包,消息包体越小越好,服务端收到客户端的心跳包后,原样返回给客户端,这里,就是收到服务端返回的心跳消息响应的处理handler,比如:HeartbeatRespHandler
    这个就比较简单,收到心跳消息响应,无需任务处理,直接打印一下方便我们分析即可。


心跳机制及读写超时机制

心跳包是定期发送,也可以自己定义一个周期,比如Android微信智能心跳方案,为了简单,此处规定应用在前台时,8秒发送一个心跳包,切换到后台时,30秒发送一次,根据自己的实际情况修改一下即可。心跳包用于维持长连接以及检测长连接是否断开等。

接着,我们利用Netty的读写超时机制,来实现一个心跳消息管理handler:
HeartbeatHandler
可以看到,利用userEventTriggered()方法回调,通过IdleState类型,可以判断读超时/写超时/读写超时,这个在添加IdleStateHandler时可以配置,下面会贴上代码。首先我们可以在READER_IDLE事件里,检测是否在规定时间内没有收到服务端心跳包响应,如果是,那就触发重连操作。在WRITER_IDEL事件可以检测客户端是否在规定时间内没有向服务端发送心跳包,如果是,那就主动发送一个心跳包。发送心跳包是在子线程中执行,我们可以利用之前写的work线程池进行线程管理。
addHeartbeatHandler()代码如下:
addHeartbeatHandler
从图上可看到,在IdleStateHandler里,配置的读超时为心跳间隔时长的3倍,也就是3次心跳没有响应时,则认为长连接已断开,触发重连操作。写超时则为心跳间隔时长,意味着每隔heartbeatInterval会发送一个心跳包。读写超时没用到,所以配置为0。

onConnectStatusCallback(int connectStatus)为连接状态回调,以及一些公共逻辑处理:
onConnectStatusCallback
连接成功后,立即发送一条握手消息,再次梳理一下整体流程:

  • 客户端根据服务端返回的host及port,进行第一次连接。
  • 连接成功后,客户端向服务端发送一条握手认证消息(1001)
  • 服务端在收到客户端的握手认证消息后,从扩展字段里取出用户token,到本地数据库校验合法性。
  • 校验完成后,服务端把校验结果通过1001消息返回给客户端,也就是握手消息响应。
  • 客户端收到服务端的握手消息响应后,从扩展字段取出校验结果。若校验成功,客户端向服务端发送一条心跳消息(1002),然后进入心跳发送周期,定期间隔向服务端发送心跳消息,维持长连接以及实时检测链路可用性,若发现链路不可用,等待一段时间触发重连操作,重连成功后,重新开始握手/心跳的逻辑。

看看TCPReadHandler收到消息是怎么处理的:
TCPReadHandler1
TCPReadHandler2
可以看到,在channelInactive()及exceptionCaught()方法都触发了重连,channelInactive()方法在当链路断开时会调用,exceptionCaught()方法在当出现异常时会触发,另外,还有诸如channelUnregistered()、channelReadComplete()等方法可以重写,在这里就不贴了,相信聪明的你一眼就能看出方法的作用。
我们仔细看一下channelRead()方法的逻辑,在if判断里,先判断消息类型,如果是服务端返回的消息发送状态报告类型,则判断消息是否发送成功,如果发送成功,从超时管理器中移除,这个超时管理器是干嘛的呢?下面讲到消息重发机制的时候会详细地讲。在else里,收到其他消息后,会立马给服务端返回一个消息接收状态报告,告诉服务端,这条消息我已经收到了,这个动作,对于后续需要做的离线消息会有作用。如果不需要支持离线消息功能,这一步可以省略。最后,调用消息转发器,把接收到的消息转发到应用层即可。

代码写了这么多,我们先来看看运行后的效果,先贴上缺失的消息发送代码及ims关闭代码以及一些默认配置项的代码。
发送消息:发送消息
关闭ims:关闭ims
ims默认配置:ims默认配置
还有,应用层实现的ims client启动器:
IMSClientBootstrap
由于代码有点多,不太方便全部贴上,如果有兴趣可以下载demo体验。
额,对了,还有一个简易的服务端代码,如下:
NettyServerDemo1
NettyServerDemo2
NettyServerDemo3


调试

我们先来看看连接及重连部分(由于录制gif比较麻烦,体积较大,所以我先把重连间隔调小成3秒,方便看效果)。

  • 启动服务端:启动服务端
  • 启动客户端:启动客户端
    可以看到,正常的情况下已经连接成功了,接下来,我们来试一下异常情况,比如服务端没启动,看看客户端的重连情况:
    调试重连
    这次我们先启动的是客户端,可以看到连接失败后一直在进行重连,由于录制gif比较麻烦,在第三次连接失败后,我启动了服务端,这个时候客户端就会重连成功。

然后,我们再来调试一下握手认证消息即心跳消息:
握手消息及心跳消息测试
可以看到,长连接建立成功后,客户端会给服务端发送一条握手认证消息(1001),服务端收到握手认证消息会,给客户端返回了一条握手认证状态消息,客户端收到握手认证状态消息后,即启动心跳机制。gif不太好演示,下载demo就可以直观地看到。

接下来,在讲完消息重发机制及离线消息后,我会在应用层做一些简单的封装,以及在模拟器上运行,这样就可以很直观地看到运行效果。


消息重发机制

消息重发,顾名思义,即使对发送失败的消息进行重发。考虑到网络环境的不稳定性、多变性(比如从进入电梯、进入地铁、移动网络切换到wifi等),在消息发送的时候,发送失败的概率其实不小,这时消息重发机制就很有必要了。
我们先来看看实现的代码逻辑。
MsgTimeoutTimer:
MsgTimeoutTimer1
MsgTimeoutTimer2
MsgTimeoutTimerManager:
MsgTimeoutTimerManager1
MsgTimeoutTimerManager2
然后,我们看看收消息的TCPReadHandler的改造:
加入消息重发机制的TCPReadHandler
最后,看看发送消息的改造:
加入消息重发机制的发送消息

说一下逻辑吧:发送消息时,除了心跳消息、握手消息、状态报告消息外,消息都加入消息发送超时管理器,立马开启一个定时器,比如每隔5秒执行一次,共执行3次,在这个周期内,如果消息没有发送成功,会进行3次重发,达到3次重发后如果还是没有发送成功,那就放弃重发,移除该消息,同时通过消息转发器通知应用层,由应用层决定是否再次重发。如果消息发送成功,服务端会返回一个消息发送状态报告,客户端收到该状态报告后,从消息发送超时管理器移除该消息,同时停止该消息对应的定时器即可。
另外,在用户握手认证成功时,应该检查消息发送超时管理器里是否有发送超时的消息,如果有,则全部重发:
握手认证成功检查是否有发送超时的消息


离线消息

由于离线消息机制,需要服务端数据库及缓存上的配合,代码就不贴了,太多太多,我简单说一下实现思路吧:
客户端A发送消息到客户端B,消息会先到服务端,由服务端进行中转。这个时候,客户端B存在两种情况:

  • 1.长连接正常,就是客户端网络环境良好,手机有电,应用处在打开的情况。
  • 2.废话,那肯定就是长连接不正常咯。这种情况有很多种原因,比如wifi不可用、用户进入了地铁或电梯等网络不好的场所、应用没打开或已退出登录等,总的来说,就是没有办法正常接收消息。

如果是长连接正常,那没什么可说的,服务端直接转发即可。
如果长连接不正常,需要这样处理:服务端接收到客户端A发送给客户端B的消息后,先给客户端A回复一条状态报告,告诉客户端A,我已经收到消息,这个时候,客户端A就不用管了,消息只要到达服务端即可。然后,服务端先尝试把消息转发到客户端B,如果这个时候客户端B收到服务端转发过来的消息,需要立马给服务端回一条状态报告,告诉服务端,我已经收到消息,服务端在收到客户端B返回的消息接收状态报告后,即认为此消息已经正常发送,不需要再存库。如果客户端B不在线,服务端在做转发的时候,并没有收到客户端B返回的消息接收状态报告,那么,这条消息就应该存到数据库,直到客户端B上线后,也就是长连接建立成功后,客户端B主动向服务端发送一条离线消息询问,服务端在收到离线消息询问后,到数据库或缓存去查客户端B的所有离线消息,并分批次返回,客户端B在收到服务端的离线消息返回后,取出消息id(若有多条就取id集合),通过离线消息应答把消息id返回到服务端,服务端收到后,根据消息id从数据库把对应的消息删除即可。
以上是单聊离线消息处理的情况,群聊有点不同,群聊的话,是需要服务端确认群组内所有用户都收到此消息后,才能从数据库删除消息,就说这么多,如果需要细节的话,可以私信我。


不知不觉,NettyTcpClient中定义了很多变量,为了防止大家不明白变量的定义,还是贴上代码吧:
定义了很多变量的NettyTcpClient

应用层封装

这个就见仁见智啦,每个人代码风格不同,我把自己简单封装的代码贴上来吧:
MessageProcessor消息处理器:
MessageProcessor1
MessageProcessor2
IMSEventListener与ims交互的listener:
IMSEventListener1
IMSEventListener2
IMSEventListener3
MessageBuilder消息转换器:
MessageBuilder1
MessageBuilder2
MessageBuilder3
AbstractMessageHandler抽象的消息处理handler,每个消息类型对应不同的messageHandler:
AbstractMessageHandler
SingleChatMessageHandler单聊消息处理handler:
SingleChatMessageHandler
GroupChatMessageHandler群聊消息处理handler:
GroupChatMessageHandler
MessageHandlerFactory消息handler工厂:
MessageHandlerFactory
MessageType消息类型枚举:
MessageType
IMSConnectStatusListenerIMS连接状态监听器:
IMSConnectStatusListener
由于每个人代码风格不同,封装代码都有自己的思路,所以,在此就不过多讲解,只是把自己简单封装的代码全部贴上来,作一个参考即可。只需要知道,接收到消息时,会回调OnEventListener的dispatchMsg(MessageProtobuf.Msg msg)方法:
应用层接收ims消息入口
发送消息需要调用imsClient的sendMsg(MessageProtobuf.Msg msg)方法:
应用层调用ims发送消息入口
即可,至于怎样去封装得更好,大家自由发挥吧。


最后,为了测试消息收发是否正常,我们需要改动一下服务端:
改动后的服务端1
改动后的服务端2
改动后的服务端3
改动后的服务端4
改动后的服务端5
可以看到,当有用户握手成功后,会保存该用户对应的channel到容器里,给用户发送消息时,根据用户id从容器里取出对应的channel,利用该channel发送消息。当用户断开连接后,会把该用户对应的channel从容器里移除掉。

运行一下,看看效果吧:
最终运行效果

  • 首先,启动服务端。
  • 然后,修改客户端连接的ip地址为192.168.0.105(这是我本机的ip地址),端口号为8855,fromId,也就是userId,定义成100001,toId为100002,启动客户端A。
  • 再然后,fromId,也就是userId,定义成100002,toId为100001,启动客户端B。
  • 客户端A给客户端B发送消息,可以看到在客户端B的下面,已经接收到了消息。
  • 用客户端B给客户端A发送消息,也可以看到在客户端A的下面,也已经接收到了消息。
    至于,消息收发测试成功。至于群聊或重连等功能,就不一一演示了,还是那句话,下载demo体验一下吧。。。

由于gif录制体积较大,所以只能简单演示一下消息收发,具体下载demo体验吧。。。

如果有需要应用层UI实现(就是聊天页及会话页的封装)的话,我再分享出来吧。


发现的bug

  1. MsgTimeoutTimer
    MsgTimeoutTimer bug1
    这个bug是自己在检查代码时发现的,可能是连续熬几天夜写文章魔怔了。。。
    修改如下:
    MsgTimeoutTimer bug1 fix

一个人精力有限,大家在使用过程中,如果发现其它bug,烦请告诉我,反正我是会虚心接受,坚决不改,呸,一定改,一定改。另外,欢迎fork,期待大家与我一起完善。。。


写在最后

终于写完了,这篇文章大概写了10天左右,有很大部分的原因是自己有拖延症,每次写完一小段,总静不下心来写下去,导致一直拖到现在,以后得改改。第一次写技术分享文章,有很多地方也许逻辑不太清晰,由于篇幅有限,也只是贴了部分代码,建议大家把源码下载下来看看。一直想写这篇文章,以前在网上也尝试过找过很多im方面的文章,都找不到一篇比较完善的,本文谈不上完善,但包含的模块很多,希望起到一个抛砖引玉的作用,也期待着大家跟我一起发现更多的问题并完善,最后,如果这篇文章对你有用,希望在github上给我一个star哈。。。

应大家要求,精简了netty-all-4.1.33.Final.jar包。原netty-all-4.1.33.Final.jar包大小为3.9M,经测试发现目前im_lib库只需要用到以下jar包:

  • netty-buffer-4.1.33.Final.jar
  • netty-codec-4.1.33.Final.jar
  • netty-common-4.1.33.Final.jar
  • netty-handler-4.1.33.Final.jar
  • netty-resolver-4.1.33.Final.jar
  • netty-transport-4.1.33.Final.jar

所以,抽取以上jar包,重新打成了netty-tcp-4.1.33-1.0.jar,目前自测没有问题,如果发现bug,请告诉我,谢谢。

附上原jar及裁剪后jar包的大小对比:
原netty-all-4.1.33.Final.jar大小
裁剪后netty-tcp-4.1.33-1.0.jar大小
代码已更新到Github.


接下来,会抽时间把下图想写的文章都写了,没有先后顺序,想到哪就写到哪吧。。。
想写的文章

The end.

点击查看更多内容
4人点赞

若觉得本文不错,就分享一下吧!

评论

作者其他优质文章

正在加载中
移动开发工程师
手记
粉丝
1
获赞与收藏
9

关注作者,订阅最新文章

阅读免费教程

感谢您的支持,我会继续努力的~
扫码打赏,你说多少就多少
赞赏金额会直接到老师账户
支付方式
打开微信扫一扫,即可进行扫码打赏哦
今天注册有机会得

100积分直接送

付费专栏免费学

大额优惠券免费领

立即参与 放弃机会
意见反馈 帮助中心 APP下载
官方微信

举报

0/150
提交
取消