首先要感謝大家一直以來對於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到我郵箱：[email protected]。 

如果大家覺得還不錯，請粉我，順便再頂一下啊！