之前的項目大多使用GSON，理由是序列化和反序列化非常方便，又是使用廣泛的多平臺JSON格式，尤其爲第三方應用提供aidl接口的時候，如果有些數據不方便傳遞給第三方，而平臺又一股腦的用經典的JSON格式都返回了（有些字段只有應用內部才需要用到），此時通過序列化和反序列化對JSON數據的過濾篩選有奇效。當然這些都考慮到了開發的便利性，用親兒子GSON而不用其他的fastjson等則是考慮到兼容性。不過谷歌又生了個兒子叫protobuf，據說在序列化和反序列化上有非凡的造詣：
Why not just use XML?
Protocol buffers have many advantages over XML for serializing structured data. Protocol buffers:
- are simpler
- are 3 to 10 times smaller
- are 20 to 100 times faster
- are less ambiguous
- generate data access classes that are easier to use programmatically
來源：谷歌開發者網站
因而想起來比較一下常用的GSON，原生的JSON，以及新兒子protocol buffers
當然這裏有一點必須指出，這裏多次測試都是使用特定的生產報文進行的，之後條目不變，內容相差不大。另外因爲發送網絡請求的時候，都會轉化爲byte數組，所以序列化的標誌是生成byte數組，反序列化的標誌則是從byte數組生成對象並取出一個二級值。得出結論如下：
結論：不考慮服務端的情況下，性能較差的設備建議使用JSON，性能較強的設備建議使用PB。
整體上（序列化和反序列化綜合考慮），當性能足夠強的時候（如當前的主流旗艦手機），PB具有極致的性能表現，其相比JSON速度快了五倍，相比GSON則快了一個數量級，隨着設備性能逐漸下降，JSON的表現會更加突出，逐漸縮小和PB之間的性能差距，當性能降低到新大陸X5和聯迪C10時，JSON的性能已經反超PB，快三倍左右，在這樣的情況下PB的性能甚至不如GSON；
對於PB而言，當性能足夠強的時候，其序列化和反序列化差距很小，隨着設備性能的降低，PB的序列化會變得喫力，反序列化則依然非常快速，當性能降低到聯迪C10等級別時，序列化的速度已經和反序列化的速度差了兩個數量級，大約有四五十倍的區別。同樣的，單從反序列化來看，無論設備性能如何，PB大部分時間都比JSON和GSON有數量級上的優勢。
對於JSON而言，無論性能如何，其序列化和反序列化的速度都非常接近。其反序列化一直不如PB，但是其序列化可以在性能差的機器上佔據數量級優勢，比PB和GSON都快三倍左右。
對於GSON，其序列化和反序列的性能穩定接近，當設備性能足夠強的時候，其序列化和反序列化比JSON慢三倍左右，和PB則有着數量級上的差距，但是隨着設備性能的降低，PB序列化會逐漸喫力，直到最後GSON的序列化會和PB達到同一水平並穩定佔據一些優勢。總體上GSON沒有亮點。
另外對於報文大小，當報文條目結構一定時， PB相對JSON壓縮60%左右。
舊機寶常常處於這樣的狀態：舊手機接受新手機發送過來的指令，大部分情況下，性能較差的舊手機要實現新手機發送過來的指令的反序列化，而性能較強的新手機作爲控制者，常常需要實現指令的序列化。這樣可以把protobuf在性能差設備上的反序列化優勢和性能強設備上的序列化優勢全都發揮出來，簡直不能更適合了，再加上需求記錄的需要，舊機寶決定採用protobuf作爲報文序列化和反序列化工具。