何时使用定值protobuf类型？还是在什么情况下？

我想通过TCP传输序列化的protobuf消息，我尝试使用第一个字段来指示序列化消息的总长度。

我知道int32会在编码后更改长度。因此，也许fixed32是一个不错的选择。

但是在“编码”一章的最后，我发现即使我在field_num＃1中使用了fixed32，也无法依靠它。因为Field Order说顺序可能会改变。

我的问题是何时使用固定值类型？有示例场景吗？

  

“我的问题是何时使用固定值类型？”

在序列化值时，总会有一个权衡。如果我们查看Protobuf-documentation，那么对于32位整数，我们会看到一些选择：

  

int32 ：使用可变长度编码。负数编码效率低下–如果您的字段可能具有负值，请改用sint32。

  
  

uint32 ：使用可变长度编码。

  
  

sint32 ：使用可变长度编码。有符号的int值。与常规的int32相比，它们更有效地编码负数。

  
  

fixed32 ：始终为四个字节。如果值通常大于2 ^ 28，则效率比uint32高。

  
  

sfixed32 ：始终为四个字节。

int32是一种可变长度的数据类型。类型本身未指定的任何信息都需要以某种方式表示。要反序列化一个可变长度的数字，我们需要知道长度是多少。该消息也包含在序列化消息中，这需要额外的存储空间。可选的负号也是如此。因此，生成的消息可能较小，但也可能较大。

假设我们有很多0到255之间的整数要编码。以两个字节（一个字节的实际值，一个字节表示我们只有一个字节）的形式发送此信息，要比发送完整的32位（4个字节）的整数 [虚构的值，实际实现可能会有所不同] 。另一方面，如果我们要序列化一个较大的值（只能容纳4个字节），则结果可能会更大（4个字节和一个额外的字节来表示值是4个字节；总共5个字节）。在这种情况下，使用fixed32会更有效。我们只知道fixed32是4个字节；我们不需要序列化fixed32是一个4字节的数字。

如果我们查看fixed32，它实际上提到的折衷点大约是2 ^ 28（对于无符号整数）。

因此，对于大值，某些类型是好的 [例如，在存储空间方面更有效] ；对于小值，某些类型对于正/负值。这完全取决于实际值代表什么。

  

“有示例场景吗？”

32位哈希（即CRC-32），IPv4地址/掩码。可预测的邮件大小可能是相关的。