背景
在《程序媛的人生觀》這篇文章中，在博客園有熱心朋友反饋：
protosbuff支持的類型少~而且不支持嵌套~性能更沒有json高，如不是外網使用節約流量，沒有用的必要~
我覺得評論說的很好。但是以淘金式思路來看這個問題，需要提出自己的問題，進行批判性吸收。
編碼效率
寫了一段代碼測試使用protostuff和json兩種序列化編碼的執行速度。結果每次protostuff的速度都比json快。下面是其中3次的結果：
（結果1）
（結果2）
（結果3）
結論：protostuff編碼速度快於json。
這個數據讓我非常的自責，因為可以看到編碼的速度在100ms上下，是非常耗時的操作。但是我在編寫我們項目代碼的時候沒有加專門的監控統計。
為了驗證是否和執行順序有關，調換一下執行順序。實際上如果在同一個方法里先后運行兩次序列化，會影響執行結果。但是因為用了兩個獨立的junit test方法，所以影響可忽略不計。來看看效果。
這是修改了順序的代碼。下面是其中3次的結果：
（結果1）
（結果2）
（結果3）
可以看到，protostuff編碼速度仍然快於json。
解碼效率
改造一下代碼，測試一下解碼效率。
（結果1）
（結果2）
（結果3）
結論：protostuff解碼速度遠遠快於json。
編碼后的大小
結果：
結論：protostuff編碼后的數據小於json。
換一個復雜對象驗證效果：
結果：
又換了一個更復雜的，結果：
雖然protostuff編碼后的數據小於json。但是相差不是很大。這是因為剛才所有的測試（包括效率和大小）都是基於我將protostuff編解碼和base64綁定處理了。
這是編碼。
這是解碼。如果不用base64，最后一條的結果是
protostuff的優勢還是很明顯的。
關於支持的類型少和不支持嵌套。看上面我用到的對象Pod，是
io.fabric8.kubernetes.api.model.Pod，有k8s背景的朋友應該知道這個對象有多復雜。測試里面的ResourceMessage對象其實是個泛型對象，里面嵌套了Pod。所以也不存在不支持嵌套這一說。
思考
虞美人
上中學的時候，家里養了一盆花死掉了。花盆放在陽台外面，土里長了草。我心里覺得不公平。為什么花要在花盆里收到精心的呵護，而普通的小草就要被拔掉呢？於是，我每天給小草澆水。
奇跡出現了，花盆里長出花來。大紅色的花，我見過的最完美的花。
之前在媽媽辦公室后面有個小花園，里面長滿了月季花。都是比我還高的月季花樹，不是普通路邊見到的矮矮的。但是我試圖找到一朵完美的花卻找不出來。仔細看花瓣，都是有瑕疵的。
之前我喜歡白色、黃色、粉色這些顏色淡雅的花。但是自從看到這朵花，我甚至喜歡穿紅色的衣服，雖然紅色並不合適我。后來想查查那究竟是什么花。找到長得最像的是虞美人。但是我的花其他部分像草，花要紅的純粹。我的花要美得多。更像是草的精靈。
做自己想做的事情，用心去做。不苛求奇跡，但是有一天奇跡會找到你。
語音版點擊《測試了一下編解碼的執行效果》獲取，用耳朵來聽姿勢~~
推薦閱讀