移動端通信協議選擇：json、flatbuf、protobuf、MessagePack

• JSON:

 1、JSON是純文本。
 2、JSON具有良好的自我描述性，便於閱讀。

優點

1 簡單易用開發成本低
2 跨語言
3 輕量級數據交換
4 非冗長性（對比xml標籤簡單括號閉環）

缺點

1 體積大，影響高併發
2 無版本檢查，自己做兼容
3 片段的創建和驗證過程比一般的XML複雜
4 缺乏命名空間導致信息混合

總結：最簡單最通用的應用協議，使用廣泛，開發效率高，性能相對較低，維護成本較高。

如果對性能要求不高，傳輸數據少，優先選擇這個，現在大部分使用的是這個；

• protobuf:

  Protobuf是一種以有效並可擴展的格式編碼結構化數據的方式。

• 語言無關、平臺無關。即 ProtoBuf 支持 Java、C++、Python 等多種語言，支持多個平臺
• 高效。即比 XML 更小（3 ~ 10倍）、更快（20 ~ 100倍）、更爲簡單
• 擴展性、兼容性好。你可以更新數據結構，而不影響和破壞原有的舊程序

 比較強大，如果是大數據，建議使用 protobuf 性比較好，並支持數據流；

缺點：不便於閱讀，庫相對較大，移動端可以使用 protobuf-lite;

 

1 二進制格式，可讀性差（抓包dump後的數據很難看懂）
2 對象冗餘，字段很多，生成的類較大，佔用空間。
3 默認不具備動態特性（可以通過動態定義生成消息類型或者動態編譯支持）

總結：簡單快速上手，高效兼容性強，維護成本較高；不便於閱讀，庫相對較大，移動端可以使用 protobuf-lite;

• flatbuf

FlatBuffers是Google專門爲遊戲開發而創建的跨平臺序列化庫

1. 對序列化數據的訪問不需要打包和拆包——它將序列化數據存儲在緩存中，這些數據既可以存儲在文件中，又可以通過網絡原樣傳輸，而沒有任何解析開銷；
2. 內存效率和速度——訪問數據時的唯一內存需求就是緩衝區，不需要額外的內存分配；
3. 擴展性、靈活性——它支持的可選字段意味着不僅能獲得很好的前向/後向兼容性（對於長生命週期的遊戲來說尤其重要，因爲不需要每個新版本都更新所有數據）；
4. 最小代碼依賴——僅僅需要自動生成的少量代碼和一個單一的頭文件依賴，很容易集成到現有系統中。
5. 強類型設計——儘可能使錯誤出現在編譯期，而不是等到運行期才手動檢查和修正；
6. 使用簡單——生成的C++代碼提供了簡單的訪問和構造接口；而且如果需要，通過一個可選功能可以用來在運行時高效解析Schema和類JSON格式的文本；
7. 跨平臺——支持C++11、Java，而不需要任何依賴庫；在最新的gcc、clang、vs2010等編譯器上工作良好。

編碼性能對比 (S)

Person個數	Protobuf	JSON	FlatBuffers
10	6.000	8.952	12.464
50	26.847	45.782	56.752
100	50.602	73.688	108.426

編碼性能Protobuf相對於JSON有較大幅度的提高，而FlatBuffers則有較大幅度的降低。

解碼性能對比 (S)

Person個數	Protobuf	JSON	FlatBuffers
10	0.255	10.766	0.014
50	0.245	51.134	0.014
100	0.323	101.070	0.006

解碼性能方面，Protobuf相對於JSON，有着驚人的提升。Protobuf的解碼時間幾乎不隨着數據長度的增長而有太大的增長，而JSON則隨着數據長度的增加，解碼所需要的時間也越來越長。而FlatBuffers則由於無需解碼，在性能方面相對於前兩者更有着非常大的提升。

 移動端，可以使用flatbuffers,相對protobuffer  要好一些。

• MessagePack

It's like JSON.but fast and small.

msgpack不是軟件，是一個標準，可以先把它看成二進制的json，“二進制json”容易讓人聯想到一個更流行一點的標準：BSON。如果你不知道bson是啥可以去查一下，總之msgpack和bson是同類型的競爭產品，但是msgpack無論從速度還是體積上都秒殺bson，至少在網絡傳輸上是這樣的。

MessagePack 在移動端表現並不是太好，可能優勢在PC。