ProtoBuf既然比json和纯二进制文件都要好，那项目里是不是应该打消这两种数据的序列化方式？

dxking

比来同事筹备用ProtoBuf措置项目中的地图数据，稍微查询拜访了一下，发现基本都是说ProtoBuf性能措置最优，那其它的序列化方式是不是就没有价值了。

ioness

类似json这种定位的协议, 就不该仅仅绑定到结构体这种数据集合, 表现出来应该是事件或元素构成的流.
元素包括原子类型, 和结构的声明, 比如一个数组头部; 或者一对 "开始, 结束"事件(对应花括号).
不能把结构信息放在解码的程序内部, 一定要写在数据里.
比如序列化一个 struct{int a; struct b{float c;}};
要存储就是 {1{0.0}}, 而不能是 1,0.0

ytfjeom

根据具体应用场景来看吧，比如在游戏开发中，会有以下情况需要做技术选择：
如果某个模块，需要序列化后的配置文件，可以提供给非技术人员，比如策划，去阅读或修改，最好是文本的方式去序列化比较好，比如xml、json，甚至csv。
如果某个模块，涉及到多人协作，且对内存和性能要求不高，也适合用文本的方式序列化，因为很多版本管理工具并不适合解决二进制文件的冲突。
如果某个模块，要求加载速度快，对内存要求没那么极致，也不考虑兼容性，也可以考虑用二进制的方式序列化。
PB优势在于序列化的产物占用空间小，反序列化速度较文本更高。缺点就是可阅读性差。
游戏开发中，还要注意PB的GC等问题，使用PB最好掌握了Google提供的运行时源码和protoc源码再用，对序列化这块儿的掌控力会更强一些。

bluestardm

protobuf有几个优点：
1，二进制格式编码，variant int格式尤为突出，哪怕是8字节的int64，只要值够小，最终编码后也只需要1字节。
2，自带DSL（也就是proto文件），定义message的时候会要求写上tag，也就是说不用像json那样把字段名字编码进去，而是编码tag数字，减少了序列化的数据量。
3，有代码生成，对每个结构都会生成其对应的序列化/反序列化方法。对于Java/C#这样的语言，如果没有代码生成那就只能走反射，反射很显然会慢一截。如果你在线上有服务遇到序列化耗时比较高的问题，最终可能也会速途同归的走上了代码生成这条路。
protobuf是为网络传输设计优化的，并且跟静态类型语言搭配更佳，如果不是这种场景，你很难享受到它的优点。
比如，在动态语言里，很显然json更适合，尤其是js里一个JSON.stringfy就完成了的事情，没有必要再去写proto又编译成对应的js源码来执行。而且类似json的二进制格式（msgpack,CBOR）也很流行。
再比如，除了网络传输，还有数据存储需要序列化（比如bson格式），而数据存储跟网络传输要考量的点是不一样的，像bson存一个int64就是直接写满8个字节，没有用variant int来减少容量，因为固定长度利于从磁盘快速寻址。

wanpin

pb啊，这个话题真的一言难尽。
首先是他的二进制格式确实设计得非常精巧。甚至作为通信协议，不能自解释也不是大问题：tcp/ip/udp/icmp之类的协议又有哪个自解释了？你说你http/json可以抓了包就可以直接看，tcp/udp照样大把人可以抓了包直接看的。

pb最关键的麻烦地方在于：他的生成代码直接嵌入了工程代码之内。

• 每次变更这些文件，都要触发大面积的重编译。更雪上加霜的是，他的代码编得还特别慢——最起码，各种的getter/setter，而且还不是一层，还动辄套两三层调用。我从来就没明白这么脱裤子放屁的原因是什么：代码都是你生成的，也不大可能有人动手改（毕竟改了之后，每变一次proto就要手动merge一次，谁会费那劲？），那你叠这么一套套，除了折腾编译器外，有什么实际效果？
  
• 如果一份代码用了两个pb库，或者两个静态库各自独立用了pb，那就有相当概率导致各种符号冲突。
  
• 如果你说要做个动态库，这货又是个c++的，abi的问题嘛，说大不大说小也不小。
  

当然，上面这些问题，不是没有办法解决。但你说用起来很方便顺心，那只能说你没深入的做过相关的工程问题。

总之，pb作为一种编码协议，确实很轻量。但是它的代码实现，却偏偏很重量。尤其是很多时候你只想用来做个数据编码，没打算整个rpc框架都用它的话，它的不少做法都非常不合时宜。
所以，有些时候，用json，反而更轻量。

zmy609

第一，纯二进制文件性能必然最优，不是最优说明你做的垃圾。
第二，protobuf的理念之一是做数据的虚拟机，为了解决跨平台问题，很遗憾，这个问题他没有解决，在各个平台上经常会有问题。