google的protocol buffer学习

Protocol Buffers是由Google提出的一种高效、灵活且自动化的数据序列化格式。它不仅比XML更小、更快、更简单,还支持多种语言。本文详细介绍了Protocol Buffers的工作原理、优势及应用场景。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Protocol Buffers是Google提出的新的数据交换格式.
关于它的英文定义是: a language-neutral, platform-neutral, extensible way of serializing structured data for use in communications protocols, data storage, and more.
关于Protocol Buffer开发文档的说明:
This documentation is aimed at Java, C++, or Python developers who want to use protocol buffers in their applications. 
This overview introduces protocol buffers and tells you what you need to do to get started 
– you can then go on to follow the tutorials or delve deeper into protocol buffer encoding. 
API reference documentation is also provided for all three languages, as well as language and style guides for writing .proto files.
 

What are protocol buffers?

Protocol buffers are a flexible, efficient, automated mechanism for serializing structured data – 
think XML, but smaller, faster, and simpler. You define how you want your data to be structured once, 
then you can use special generated source code to easily write and read your structured data to and from a variety of data streams 
and using a variety of languages. You can even update your data structure without breaking deployed programs that are compiled against the "old" format. 

How do they work?

You specify how you want the information you're serializing to be structured by defining protocol buffer message types in .proto files. 
Each protocol buffer message is a small logical record of information, containing a series of name-value pairs. 
Here's a very basic example of a .proto file that defines a message contai
ning information about a person:
 message Person {
  required string name = 1;
  required int32 id = 2;
  optional string email = 3;

  enum PhoneType {
    MOBILE = 0;
    HOME = 1;
    WORK = 2;
  }

  message PhoneNumber {
    required string number = 1;
    optional PhoneType type = 2 [default = HOME];
  }

  repeated PhoneNumber phone = 4;
}

As you can see, the message format is simple – each message type has one or more uniquely numbered fields, 
and each field has a name and a value type, where value types can be numbers (integer or floating-point), booleans, strings, raw bytes, 
or even (as in the example above) other protocol buffer message types, allowing you to structure your data hierarchically. 
You can specify optional fields, required fields, and repeated fields. 
You can find more information about writing .proto files in the Protocol Buffer Language Guide. 

象你看到的一样,消息格式很简单:每个消息类型有一个或者多个数据项,每个数据项有一个名字和一个数据类型。数据类型可以是数值(整形或者浮点型),
布尔型,字符串,字节流或者自定义的buffer类型,允许你子架构造数据体系。
你可以指定可选的数据项,必选数据项和重复数据项。关于如何写.proto文件,可以从protocol buffer language指南中得到更多信息。
Once you've defined your messages, you run the protocol buffer compiler for your application's language on your .proto file to generate data access classes. 
These provide simple accessors for each field (like query() and set_query()) as well as methods to serialize/parse the whole structure to/from raw bytes – 
so, for instance, if your chosen language is C++, running the compiler on the above example will generate a class called Person. 
You can then use this class in your application to populate, serialize, and retrieve Person protocol buffer messages. 
You might then write some code like this: 

定义了消息后,就可以protocol buffer编译器编译,从.proto文件生成数据访问类。(与corba idl类似)
这些类提供了简单的访问数据项的方法,类似query(),set_query()
你可以在你的应用中使用这些类来构造、序列化和取回Person这个protocol buffer消息。你可以写如下代码:
Person person;
person.set_name("John Doe");
person.set_id(1234);
person.set_email("jdoe@example.com");
fstream output("myfile", ios::out | ios::binary);
person.SerializeToOstream(&output);

then, later on, you could read your message back in: 
然后,从文件中读回信息

fstream input("myfile", ios::in | ios::binary);
Person person;
person.ParseFromIstream(&input);
cout << "Name: " << person.name() << endl;
cout << "E-mail: " << person.email() << endl;

You can add new fields to your message formats without breaking backwards-compatibility; 
old binaries simply ignore the new field when parsing. So if you have a communications protocol that uses protocol buffers as its data format,
 you can extend your protocol without having to worry about breaking existing code. 
 
 你可以增加数据项,不用考虑前向兼容;旧的代码仅仅是简单的忽略新增的项。
 如果你使用protocol buffer作为你的通讯协议,你能够扩展你的协议,不用担心影响已经存在的代码。
 
You'll find a complete reference for using generated protocol buffer code in the API Reference section, 
and you can find out more about how protocol buffer messages are encoded in Protocol Buffer Encoding. 

你可在API文档中找到完整的参考资料,并能够了解协议是如何编解码的。

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

For example, let's say you want to model a person with a name and an email. In XML, you need to do: 
为什么不使用XML?
protocol buffer有很多XML不具备的优点:
1.简单;
2.小巧:3-10倍
3.效率高:20-100倍
4.无二义性
5.有自动工具生成访问类;(其实ASN.1, CORBA都有类似工具)

例如,Person模型使用xml表示
 <person>
    <name>John Doe</name>
    <email>jdoe@example.com</email>
  </person>
 
while the corresponding protocol buffer message (in protocol buffer text format) is:
对应的protocol文本格式

# Textual representation of a protocol buffer.
# This is *not* the binary format used on the wire.
person {
  name: "John Doe"
  email: "jdoe@example.com"
}

When this message is encoded to the protocol buffer binary format (the text format above is just a convenient 
human-readable representation for debugging and editing), it would probably be 28 bytes long and take around 100-200 nanoseconds to parse. 
The XML version is at least 69 bytes if you remove whitespace, and would take around 5,000-10,000 nanoseconds to parse. 

当消息编码成二进制格式(上面的说明只是为了编译阅读的表示方式),protocol buffer将差不多28个子节长,用100-200ns时间解析。
而XML文件有69字节长,还要去掉空白符,使用5000-10000ns来解析

Also, manipulating a protocol buffer is much easier:
维护以很容易:

  cout << "Name: " << person.name() << endl;
  cout << "E-mail: " << person.email() << endl;

Whereas with XML you would have to do something like:
而XML要做如下的事情:

  cout << "Name: "
       << person.getElementsByTagName("name")->item(0)->innerText()
       << endl;
  cout << "E-mail: "
       << person.getElementsByTagName("email")->item(0)->innerText()
       << endl;

However, protocol buffers are not always a better solution than XML – 
for instance, protocol buffers would not be a good way to model a text-based document with markup (e.g. HTML), 
since you cannot easily interleave structure with text. In addition, XML is human-readable and human-editable; protocol buffers, 
at least in their native format, are not. XML is also – to some extent – 
self-describing. A protocol buffer is only meaningful if you have the message definition (the .proto file). 

可是,protocol buffers并不是一直都比XML好-例如,protocol buffers不适合描述符号文本,如HTML,因为你不能很好的组织文本。
另外,XML更易于阅读和编辑。protocols buffers也不是自描述的(不知什么意思?)

并且,protocol buffers在google内部已经广泛使用。
内容概要:本文档详细介绍了Analog Devices公司生产的AD8436真均方根-直流(RMS-to-DC)转换器的技术细节及其应用场景。AD8436由三个独立模块构成:轨到轨FET输入放大器、高动态范围均方根计算内核和精密轨到轨输出放大器。该器件不仅体积小巧、功耗低,而且具有广泛的输入电压范围和快速响应特性。文档涵盖了AD8436的工作原理、配置选项、外部组件选择(如电容)、增益调节、单电源供电、电流互感器配置、接地故障检测、三相电源监测等方面的内容。此外,还特别强调了PCB设计注意事项和误差源分析,旨在帮助工程师更好地理解和应用这款高性能的RMS-DC转换器。 适合人群:从事模拟电路设计的专业工程师和技术人员,尤其是那些需要精确测量交流电信号均方根值的应用开发者。 使用场景及目标:①用于工业自动化、医疗设备、电力监控等领域,实现对交流电压或电流的精准测量;②适用于手持式数字万用表及其他便携式仪器仪表,提供高效的单电源解决方案;③在电流互感器配置中,用于检测微小的电流变化,保障电气安全;④应用于三相电力系统监控,优化建立时间和转换精度。 其他说明:为了确保最佳性能,文档推荐使用高质量的电容器件,并给出了详细的PCB布局指导。同时提醒用户关注电介质吸收和泄漏电流等因素对测量准确性的影响。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值