首先要感谢大家一直以来对于GGTalk即时通讯系统的关注和支持！GGTalk即时通讯系统的不断完善与大家的支持分不开！ 从2013年最初的GG1.0开放源码以来，到后来陆续增加了网盘功能、远程协助功能、离线文件功能、群聊功能、语音聊天功能、视频聊天功能、以及视讯录制功能、和增加了数据库——一路走来，结识许多朋友，大家不仅对GGTalk即时通讯系统的源码提了许多宝贵的建议，我还有幸与某些朋友取得了项目上的合作，这一切都是美妙的缘分！
一直以来，GGTalk即时通讯系统的移动端始终是一个缺憾。前段时间刚好结识了一位做android开发的朋友，他也很有兴趣参与，于是GGTalk即时通讯系统的移动端也借此契机而诞生了！
本文我主要是想为大家介绍一下打通PC端和移动端背后的基本原理，并以GGTalk即时通讯系统的android版作为示例demo供大家参考。当然，这个demo只是完成了GGTalk客户端全部功能的一小部分，以后我们会陆续将更完善的版本分享给大家。
想要直接下载体验的朋友请点击：“下载中心”
一.先睹为快
本次的GGTalk即时通讯系统安卓demo已实现如下功能：
（1）登录服务端
（2）文字聊天，表情图片,消息提醒
（3）好友列表
（4）显示好友在线状态
（5）文件传输
二.基本原理
打通不同平台的客户端中间相互通信，需要满足以下几个条件：
1. 使用同一个公共的服务器进行数据中转。
在GG中，我们.NET的PC端和android移动端都是使用基于.NET开发的GG服务端作为服务器。
2. 通信消息的格式必须达成一致。
一般来说，使用文本协议（比如xml）是非常方便的，但是文本协议有两个主要缺陷：
（1）消息个头大，浪费带宽。
（2）传递二进制数据不方便。比如，传文件这样的功能，文件的本质是byte[]，文本消息表达byte[]就很麻烦。
GG使用的不是文本协议，而是二进制协议，这样，在开发android端时，就需要遵循GG现有的消息格式，才能与GG进行正常的通信。
3. 注意不同平台上的字节序的转换。
比如，android / Java 采用的是big endian，而windows /.NET采用的是little endian。
三.协议格式
二进制协议，又叫“流协议”，流协议规定网络上传递的任何一个消息必须符合以下规则：
（1） 消息由“消息头”（Message Header）和“消息体”（Message Body）构成，消息体可以为空。
（2） 消息头的长度是固定的。
（3） 消息头中至少直接或间接包含了一个信息，那就是消息体的长度。
（4） 如果有消息体，则消息体必须紧接在消息头的尾部。
GG使用紧凑的二进制序列化器，来完成流（byte[]）与协议对象（Contract object）之间的相互转换。在开发GG移动端的某个功能时，首先得实现将这个功能对应的协议对象按照紧凑的二进制协议格式串行化到流中。比如，在GG移动端登录时，会从服务器获取当前登录用户的基本信息，这些信息在GG中使用GGUser类封装，服务器会把GGUser对象采用紧凑的二进制序列化器进行序列化得到byte[]，传递给移动端，移动端就需要按协议格式来解析这个byte[]，将其还原成GGUser对象。GGUser类的结构如下：
其对应的协议格式如下所示：
这个协议格式可以使用协议格式工具ContractFormatGenerator自动生成。协议格式中各个列的含义解释如下：
（1）FieldName：字段的名称。字段名称一般与协议类的属性名是对应的，如果某个属性的类型的长度是可变的（比如string），那么就要先加一个Field，来描述这个属性值转换给字节后的长度。
（2）Type：Field的类型。
（3）StartOffset：当前Field在byte[]中的起始偏移。
（4）Length：当前Field的值的长度。
要注意，协议格式中，第一个int是一个长度（GGUserLen），用来记录当前协议类序列化后的总长度（这个int的4个字节也包含在内） 。
至于协议类与流之间的相互转换细节，大家可以下载GG安卓版的源码详细研究，在此就不赘述了。
四.GGTalk即时通讯系统源码放送
下载最新版本，请转到这里。
大家有什么问题和建议，敬请留言，也可以发送email到我邮箱：2027224508@qq.com。
如果大家觉得还不错，请粉我，顺便再顶一下啊！
版权声明：本文为博主原创文章，未经博主允许不得随意转载。
来源：https://www.cnblogs.com/justnow/p/4836636.html