前言部分
说到长链接的技术，我们首先都会想到netty这个框架，也是目前使用最广泛的长链接框架，由于该框架使用简单性能稳定，自然也是项目的首先，一般来说长链接的话，可能是做即时通讯会用到的比较多，因为要随时监控是否有新的信息发送过来。其实长链接的应用范围是很广泛的，我们平时也是一直都在使用，不过我们没有很留意而已。常见的推送就是通过长链接来实现实时的接受后台的消息。起初我的项目中也是使用的推送来完成和客户端的即时通讯的，后期由于对消息的实时性要求提高，和消息种类的增多，所以决定自己集成长链接进来，并且自己封装了协议来处理不同类型的通知。
我们的项目长链接作用是通知同步消息、订单信息、商品信息，还有一个重要的功能是将同账号下其他设备上的产生的数据变化，实时的同步到其他的同账号的设备上。当然也不是全部的同步，同步一些共享的消息，比如我说的商品信息，但是订单的信息都是根据机械走的，这也我们做连锁设备的必要需求。
内容部分
其实内容没有多少，网上的实例也很多了，我这里只是将以前写的demo做一个整理出来。最后我会把demo上传，供大家参考。
主要步骤，分为服务端喝客户端两部分。
-
首先我们实现长链接通讯，需要两个端即客户端和服务端，然后这需要两个handle来接受对方发过来消息。
-
下面先看客户端的代码，下面代码主要配置引导程序，编码，解码器，接受消息的处理器。如下：
mWorkerGroup = new NioEventLoopGroup(); mBootstrap = new Bootstrap(); mDispatcher = new Dispatcher(); mBootstrap.group(mWorkerGroup) .channel(NioSocketChannel.class) .handler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel socketChannel) throws Exception { ChannelPipeline pipeline = socketChannel.pipeline(); pipeline.addLast(new IdleStateHandler(readerIdleTimeSeconds, writerIdleTimeSeconds, allIdleTimeSeconds)); pipeline.addLast("decoder", new StringDecoder()); pipeline.addLast("encoder", new StringEncoder()); pipeline.addLast("handler", mDispatcher); } }); } future = mBootstrap.connect(mServerAddress);几个比较核心的类，NioEventLoopGroup内部线程池初始化；Bootstrap引导程序；Dispatcher就是接受消息返回的handler了。这里的编解码器我只是使用了简单的string。实际上多数是会使用protobuf的，因为这种协议的优势比一半的json和xml更有优势。占用更小的体积，更安全的数据传输。上面初始化客户端的代码很简单了，深入内容并没有去探究，因为主要还是实现目前的需求为主。
-
然后是客户端的另一个关键的类handler，这里我起的名字是Dispatcher，不过该类还是继承自SimpleChannelInboundHandler。我们主要关注两个方法一个是userEventTriggered，一个是channelRead0。
初始化的时候添加IdleStateHandler是为了监听通道的状态，主要分为三种状态，WRITER_IDLE：写超时；READER_IDLE：读超时；ALL_IDLE：读写超时。不同的状态会回调到userEventTriggered方法中，我们可以根据不同的状态进行不同的操作，比如读超时（很久没收到服务端的联系）的时候可能是客户端掉线了，这时候客户端可以主动去连接服务端。很久没写入数据的时候，我们也可以发个心跳到服务端，告诉一下客户端还在线。
代码也差不多吧，这里我没有写入业务代码，只是做了一下演示，如下：
@Override public void channelRead0(ChannelHandlerContext cxt, String msg) throws Exception { Log.d("Dispatcher收到服务端的消息", msg); } @Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (evt instanceof IdleStateEvent) { IdleStateEvent e = (IdleStateEvent) evt; switch (e.state()) { case WRITER_IDLE: Log.d("Dispatcher", "client WRITER_IDLE over."); //发送心跳 sendHeart(); break; case READER_IDLE: //重连 Log.d("Dispatcher", "client READER_IDLE over."); NettyClient.getInstance().reConnect(); break; case ALL_IDLE: Log.d("Dispatcher", "client ALL_IDLE over."); //发送心跳 sendHeart(); break; default: break; } } } -
下面看一下服务端的代码，其实很客户端类似一致，也是一个service里面做初始化，然后在用一个handler来接受来自客户端的消息就可以了。这里要注意一下handler和childHandler的区别，我在网上搜索了一下，都是如下解释。
handler()和childHandler()的主要区别是，handler()是发生在初始化的时候，childHandler()是发生在客户端连接之后，我简单的验证了。
其他的区别并不明显，这里我们业务上是，如果后台数据变化，服务端主动发送更新数据的消息到客户端，来保证多端和前后端数据统一。
//创建worker线程池，这里只创建了一个线程池，使用的是netty的多线程模型 mWorkerGroup = new NioEventLoopGroup(); //服务端启动引导类，负责配置服务端信息 mServerBootstrap = new ServerBootstrap(); mServerBootstrap.group(mWorkerGroup) .channel(NioServerSocketChannel.class) .handler(new ChannelInitializer<NioServerSocketChannel>() { @Override protected void initChannel(NioServerSocketChannel nioServerSocketChannel) throws Exception { ChannelPipeline pipeline = nioServerSocketChannel.pipeline(); pipeline.addLast("ServerSocketChannel out", new OutBoundHandler()); pipeline.addLast("ServerSocketChannel in", new InBoundHandler()); } }) .childHandler(new ChannelInitializer<SocketChannel>() { @Override protected void initChannel(SocketChannel socketChannel) throws Exception { //为连接上来的客户端设置pipeline ChannelPipeline pipeline = socketChannel.pipeline(); pipeline.addLast(new IdleStateHandler(10,0,0)); pipeline.addLast("decoder", new StringDecoder()); pipeline.addLast("encoder", new StringEncoder()); pipeline.addLast("handler", new ServerChannelHandler()); } }); channelFuture = mServerBootstrap.bind(PORT_NUMBER); -
上面介绍完初始化服务端的代码，这里来介绍ServerChannelHandler这个类，看这个里面其实和客户端的handler保持高度一致的。代码基本一致，我也不解释了。但是这个只是我本地的测试demo，实际的后台服务应该更复杂。下面贴个代码：
public class ServerChannelHandler extends SimpleChannelInboundHandler<String> { private static final String TAG = "ServerChannelHandler"; @Override public void channelRead0(ChannelHandlerContext cxt, String protoTests) throws Exception { Log.d(TAG, "收到客户端消息: " + protoTests); NettyMessageBean nettyMessageBean = JsonUtils.fromJsonToBean(protoTests, NettyMessageBean.class); int command = nettyMessageBean.getCommand(); switch (command) { case 1: //心跳 cxt.writeAndFlush("心跳"); break; case 2: //登陆 cxt.writeAndFlush("登陆成功"); break; default: break; } } @Override public void userEventTriggered(ChannelHandlerContext ctx, Object evt) throws Exception { if (evt instanceof IdleStateEvent) { IdleStateEvent e = (IdleStateEvent) evt; switch (e.state()) { case WRITER_IDLE: System.err.println("writer_idle over."); break; case READER_IDLE: System.err.println("reader_idle over."); break; case ALL_IDLE: System.err.println("all_idle over."); default: break; } } } @Override public void channelInactive(ChannelHandlerContext ctx) throws Exception { Log.d(TAG, "client inactive: " + ctx.channel().remoteAddress()); super.channelInactive(ctx); } @Override public void channelActive(ChannelHandlerContext ctx) throws Exception { Log.d(TAG, "client active: " + ctx.channel().remoteAddress()); super.channelActive(ctx); } }
上面基本完成，但是其实我们还有一个问题没有处理，那就算关于netty的拆包和粘包问题。
-
网上一般把这个分为几类，我项目中通过特殊的分隔符来进行处理（就是在消息的结尾加入\r\n），其实我们在处理扫码枪的时候也是这么处理的，并且扫码枪和这个netty情况很类似，也会出现上个码和这个码连到一起，或者条码出现不完整的问题。
-
还有一种是通过消息定长来处理的。推荐链接
// netty提供的自定义长度解码器，解决TCP拆包/粘包问题 pipeline.addLast("frameEncoder", new LengthFieldPrepender(2)); pipeline.addLast("frameDecoder", new LengthFieldBasedFrameDecoder(65535,0, 2, 0, 2));
结束啦
上面的内容就是这样了啊，算是对长连接进行了入门了，后续只要结合业务需求，进行深度的code就可以了。因为以前项目中使用也只是通知一些消息类型，然后本地做一些操作，实际上是不传输内容，所以并没有使用protobuf协议来处理，但是阅读了很多的博客，大家还是统一推荐使用。毕竟长连接的数据交互频率 比较高，也要考虑用户流量的问题。
项目中使用度不高，所以也没有太多比较深入使用。
如果没积分的同学，就留言邮箱吧
扫一扫
320
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
