背景
在《程序媛的人生观》这篇文章中，在博客园有热心朋友反馈：
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。所以也不存在不支持嵌套这一说。
原文链接：https://mp.weixin.qq.com/s/Ob_caogahB-MxCsYJOWaIw
