GGTalk即時通信系統（支持廣域網）終於有移動端了！（技術原理、實現、源碼）

時間 2019-11-08

標籤 ggtalk 即時通信系統支持廣域網終於移動技術原理實現源碼欄目無線简体版

原文原文鏈接

首先要感謝你們一直以來對於GGTalk即時通信系統的關注和支持！GGTalk即時通信系統的不斷完善與你們的支持分不開！從2013年最初的GG1.0開放源碼以來，到後來陸續增長了網盤功能、遠程協助功能、離線文件功能、羣聊功能、語音聊天功能、視頻聊天功能、以及視訊錄製功能、和增長了數據庫——一路走來，結識許多朋友，你們不只對GGTalk即時通信系統的源碼提了許多寶貴的建議，我還有幸與某些朋友取得了項目上的合做，這一切都是美妙的緣分！html

一直以來，GGTalk即時通信系統的移動端始終是一個缺憾。前段時間恰好結識了一位作android開發的朋友，他也頗有興趣參與，因而GGTalk即時通信系統的移動端也藉此契機而誕生了！android

本文我主要是想爲你們介紹一下打通PC端和移動端背後的基本原理，並以GGTalk即時通信系統的android版做爲示例demo供你們參考。固然，這個demo只是完成了GGTalk客戶端所有功能的一小部分，之後咱們會陸續將更完善的版本分享給你們。數據庫

想要直接下載體驗的朋友請點擊：「下載中心」 windows

一.先睹爲快

本次的GGTalk即時通信系統安卓demo已實現以下功能：服務器

（1）登陸服務端網絡

（2）文字聊天，表情圖片,消息提醒工具

（3）好友列表spa

（4）顯示好友在線狀態orm

（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安卓版的源碼詳細研究，在此就不贅述了。