（2020.05.13 GGTalk 安卓版源碼全面更新！並提供apk直接安裝測試。）
首先要感謝大家一直以來對於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。
如果大家覺得還不錯，請粉我，順便再頂一下啊！
版權聲明：本文為博主原創文章，未經博主允許不得隨意轉載。