protobuf

1.pb编码方法

varient 变长编码，对于tag和value的编码。

根据tag中包含了编码类型和字段的序号

整数：

正数和负数：绝对值小于2^28，使用变长编码，负数使用zigzag编码映射

(n << 1) ^ (n >> 31)

对于负数int32，结果表示为2n+（符号位可能存在的1），按照无符号数的计算：即 2^32 -1 -(n-1)*2 ,

绝对值大于2^28，使用固定长度的编码

浮点数：固定长度编码

tag-length-value的编码，适用于string, bytes, embedded messages, packed repeated fields

tag中对应的位表示为0b010，会有表示length的位，之后的编码方式

string 为utf8编码

byte 的编码

嵌套message根据field的内容编码

2.序列化

2.1序列化长度

调用bytesizelong函数

1.首先计算requeired字段

计算长度时候，首先通过位运算判定是否所有的required字段存在，若存在，调用函数，若位判定失败，逐个检查对应的required字段并进行序列化长度计算

首先计算string和bytes，二者计算长度时候调用的函数是一样的。

计算整型int32，int64，sint时候，使用的是自带plusone的函数，转换为无符号整数调用计算长度的函数，但是这个长度会多1（这个长度多了1是包含了tag的长度，如果要计算tag的单独的长度，需要调用TagSize(),在调用repeated成员时候哦，不需要额外的tag长度）

使用fixed32或者fixed64时候，直接返回1+byte长度

计算bool长度时候，proto2中直接长度加一，proto3中也是直接+1

计算enum的长度时候，未调用plusone的函数，但是在调用前已经自加一。

2.其次计算repeated字段

repeated 中stacked在proto3中是默认开启的，对于基本类型采取的是tagvaluevalue的模式，对于string则是tag length value ，proto2中是关闭的，直接为tag value tag value

3.计算optional字段

optional计算时候，首先根据位运算判断是否存在optional字段（proto3中），若存在，计算长度，否则逐个计算相应的值

4.计算unknown的字段长度

2.2序列化

调用SerializeToString 函数

序列化前检查相应的string的长度，确保分配足够的大小，将所确定长度的字符串数据传入SerializeToArrayImpl。

根据字段号，将序列化的内容写入stream中。初始化的steam中写入时候，逐字节写入。

对于optional，写入过程为：tag ，value

疑问：为什么在proto3中序列化optional之前要调用 EnsureSapce，proto2中所有的序列化之前都要调用该函数

对于repeat：

在proto3中，提前缓存了repeat的大小，默认开启了packed，调用函数时候调用的是WriteXXPacked

在proto2中，不开启packed，会通过一个循环对repeated的元素进行序列化。

2.2.2string和bytes

string和byte的区别

protobuf里的string/bytes在C++接口里实现上都是std::string。

两者序列化、反序列化格式上一致，不过对于string格式，会有一个utf-8格式的检查。

会调用WriteStringMaybeAliased，判断宏：

(__builtin_expect(false || (size >= 128 || end_ - ptr + 16 - TagSize(num << 3) - 1 < size), false))

为真的时候，会调用函数WriteStringMaybeAliasedOutline，其中：

左移三位是为了将其恢复为无符号数，判断tag所占据的大小，第三个异或中，若字符串的size小于剩余的尺寸，那说明不会溢出（等于呢？），也就是说，任意异或为真时候，可能会存在分配字符串空间不足的问题，这件事发生概率较小。若发生，需要重新分配内存

正常流程为通过memcpy分配对应的字节到stream中

2.3 嵌套message，使用的是TLV的格式

tag 长度+ 序列化长度+ 

2.4 union

使用switch，tag+ 根据类型判断是否需要length，+ 序列化的长度

2.5 map 对于map中的元素遍历进行序列化

2.6bool  tag-value序列化

2.3 反序列化

反序列化，调用 ParseFromString， 反序列化时候，会有不同的ParseFlags作为函数模板的参数

反序列化时候，根据tag中定义的field顺序进行生成代码，解析顺序取决于当前指针的tag的值。

1.首先分配要读的string范围，（根据是否小于16个字节返回合适的地址，若小于，返回的是内建buffer的地址，否则返回的还是string的地址）

2.根据地址，获取tag的地址，读取对应的tag值（不超过5个字节的长度）

3.根据tag值，跳转到读取变量的值，

optional

整型：

repeat

requeired

1.整数读取的整数值最多占用10个字节，否则会报错。

对于sint，正常的反序列化，最后解码后再转换为负数  (n >> 1) ^ (~(n & 1) + 1)

对于repeated，会调用readPackedVarient,

2.string  

读取string的长度，最多为5个字节

读取具体的字符串，无溢出时候，调用assign，若有溢出，需要额外调用函数（需要仔细看，buffer_end, ptr,kslopBytes）

检查是否满足UTF8 编码

对于string，若其字段序号大于2个字节，repeat的生成代码会改变

3.bool

4.union

5.mao

反序列化的函数调用：MergeFromImpl函数中进行反序列化，构造对象ParseContext ctx, 最终调用虚函数实现在生成代码中的调用，ctx会将序列化字符串的首地址返回。函数的返回值为序列化结束后的ptr的地址，最后检查函数的地址，判断是否出现error。

判断error的方法，解析成功后指针ptr非空且last_tag_minus_1_为0（在string 和stream的解析中，条件不一致，具体见下方：）并进入函数判断保证所有的required字段存在（但是proto3中没有required字段）。

  // This variable is used to communicate how the parse ended, in order to

  // completely verify the parsed data. A wire-format parse can end because of

  // one of the following conditions:

  // 1) A parse can end on a pushed limit.

  // 2) A parse can end on End Of Stream (EOS).

  // 3) A parse can end on 0 tag (only valid for toplevel message).

  // 4) A parse can end on an end-group tag.

  // This variable should always be set to 0, which indicates case 1. If the

  // parse terminated due to EOS (case 2), it's set to 1. In case the parse

  // ended due to a terminating tag (case 3 and 4) it's set to (tag - 1).

  // This var doesn't really belong in EpsCopyInputStream and should be part of

  // the ParseContext, but case 2 is most easily and optimally implemented in

  // DoneFallback.

  uint32_t last_tag_minus_1_ = 0;

出现了stringpiece作为参数

几个需要记录的函数：

// ParseFromCodedStream() is implemented as Clear() followed by

// MergeFromCodedStream().

//解析器设计的基本抽象是对ZeroCopyInputStream（ZCIS）抽象的轻微修改。ZCIS将序列化流表示为连接到完整流的一系列缓冲区。

//从图像上看，ZCI以这样的方式将流分块呈现

//其中“-”表示与流的字节垂直排列的字节。原型解析器要求其输入以类似的方式呈现额外属性，即每个块的末尾都有kSlopBytes，与下一个块的第一个kSlopBytes重叠，或者如果没有下一个块，至少它仍然可以读取这些字节。同样，从图像上看，我们现在有了----

//这里的“-”表示流或块的字节和“.”表示与下一个块的开头匹配的块之后的字节。每个区块上方有4个“.”在大块之后。如果这些“溢出”字节表示流过去的字节（上面用“*”表示），则它们的值未指定。阅读它们仍然是合法的。用户应检测到超过末端的读数，并将其指示为错误。

//不可否认，这种非常规不变量的原因是无情地优化protobuf解析器。重叠有两个重要的帮助。

//首先，如果一段代码保证读取的字节数不超过k字节，那么它就不必执行边界检查。第二，也是更重要的一点，protobuf wireformat使得读取密钥/值对的长度始终小于16字节。这样就不需要在读取原语值的过程中更改到下一个缓冲区。因此，无需存储和加载当前位置。

// The basic abstraction the parser is designed for is a slight modification

// of the ZeroCopyInputStream (ZCIS) abstraction. A ZCIS presents a serialized

// stream as a series of buffers that concatenate to the full stream.

// Pictorially a ZCIS presents a stream in chunks like so

// [---------------------------------------------------------------]

// [---------------------] chunk 1

//                      [----------------------------] chunk 2

//                                          chunk 3 [--------------]

//

// Where the '-' represent the bytes which are vertically lined up with the

// bytes of the stream. The proto parser requires its input to be presented

// similarly with the extra

// property that each chunk has kSlopBytes past its end that overlaps with the

// first kSlopBytes of the next chunk, or if there is no next chunk at least its

// still valid to read those bytes. Again, pictorially, we now have

//

// [---------------------------------------------------------------]

// [-------------------....] chunk 1

//                    [------------------------....] chunk 2

//                                    chunk 3 [------------------..**]

//                                                      chunk 4 [--****]

// Here '-' mean the bytes of the stream or chunk and '.' means bytes past the

// chunk that match up with the start of the next chunk. Above each chunk has

// 4 '.' after the chunk. In the case these 'overflow' bytes represents bytes

// past the stream, indicated by '*' above, their values are unspecified. It is

// still legal to read them (ie. should not segfault). Reading past the

// end should be detected by the user and indicated as an error.

//

// The reason for this, admittedly, unconventional invariant is to ruthlessly

// optimize the protobuf parser. Having an overlap helps in two important ways.

// Firstly it alleviates having to performing bounds checks if a piece of code

// is guaranteed to not read more than kSlopBytes. Secondly, and more

// importantly, the protobuf wireformat is such that reading a key/value pair is

// always less than 16 bytes. This removes the need to change to next buffer in

// the middle of reading primitive values. Hence there is no need to store and

// load the current position.

//前进到下一个缓冲区块返回一个指针，指向由Overflow设置的流中相同的逻辑位置。溢出表示在slop区域中解析留下的位置（0<=溢出<=kSlopBytes）。如果处于限制，则返回true，如果出现错误，此时返回的指针可能为null。该函数的不变之处在于，它保证可以从返回的ptr访问kSlopBytes字节。此函数可能会在底层ZeroCopyInputStream中推进多个缓冲区。

// Advances to next buffer chunk returns a pointer to the same logical place

  // in the stream as set by overrun. Overrun indicates the position in the slop

  // region the parse was left (0 <= overrun <= kSlopBytes). Returns true if at

  // limit, at which point the returned pointer maybe null if there was an

  // error. The invariant of this function is that it's guaranteed that

  // kSlopBytes bytes can be accessed from the returned ptr. This function might

  // advance more buffers than one in the underlying ZeroCopyInputStream.

  std::pair<const char*, bool> DoneFallback(int overrun, int depth);

  // Advances to the next buffer, at most one call to Next() on the underlying

  // ZeroCopyInputStream is made. This function DOES NOT match the returned

  // pointer to where in the slop region the parse ends, hence no overrun

  // parameter. This is useful for string operations where you always copy

  // to the end of the buffer (including the slop region).

  const char* Next();

//前进到下一个缓冲区时，对底层ZeroCopyInputStream最多调用一次next（）。此函数与返回的指针不匹配，该指针指向解析在slop区域中的结束位置，因此没有溢出参数。这对于总是复制到缓冲区末尾（包括slop区域）的字符串操作非常有用。

//溢出是流当前所在的斜坡区域中的位置（0<=溢出<=kSlopBytes）。为了防止在解析将在当前缓冲区的最后kSlopBytes中结束的情况下翻转到ZeroCopyInputStream的下一个缓冲区。深度是嵌套组的当前深度（如果用例不需要仔细跟踪，则为负值）。

inline const char* NextBuffer(int overrun, int depth);

1.pb中使用arena分配大块内存，将mutable等需要分配内存的地方，分配到一块指定的空间，减少内存碎片，对于string，设置了TaggedStringPtr，用于将内存的分配位置做区分，