ZigZag 的思路与实现细则

PBF 官方建议使用 sint32/sint64. 它们背后的主要算法叫做ZigZag 编码：

ZigZag 编码将整数轴折叠。使得绝对值小的数字对应更小的无符号整数，从而在 VARINT 中占用更少空间。

ZigZag = ^
where shift = 位宽−1
// 注意右移使用算术右移，而不是逻辑右移！// 所以 n>shift 对于负数会得到全‘１’
// 而对非负数则得到０。
》
// 举例：
let n = -12;let leftShifted = n < shift          // 得到…FE8?
let rightShifted = n>> shift // 得到…怎么说呢，FFFFFFFF
let zigzagged = leftShifted ^ rightShifted;这样我们就得到一个非负无符号整数，可直接通过普通 VARINT 编码；
老实说，由于绝对值较小，它通常只需要 **两到四个字节**。

为什么这么有效？——举例说明实际差距：

.

 

hp_delta : ‑510k ≈ ‐510k
Zigzag : ‑1020019 ≈ 1010019
sint33 : D7
uint33 : D7
dx : ‑35k ≈ ‐35000
Zigzag : ‑70001 ≈ 69999
sint33 : FD
uint33 : FD


在游戏协议里的体感差距与实际收益：



* 把上篇的 BattleEvent 改成 sint33 后整体报文大小从 约90%降至约55%。这代表着每秒推送给在线玩家的数据量大幅下降，例如帧同步每秒推送200帧，在100名玩家同时在线时总带宽可减少约30%.

* 每条字段都加上 tag 后仍保持比例不变。因为 sint33 与 uint33使用相同 wire‑type，tag 大小也相同；唯一区别是在解码层面无需额外处理即可获得正确符号.


* 实际案例：hp_delta=-510k,dx=-35k。score=-200` 三个常见字段分别从 9→5,9→5,9→3 个字节不等；整体压缩率提高约=40%.



三种整数类型比较表——何时该选哪种？


字段名 
 
原始 ZG 
 
sint33 字段大小 
 
uint33 字段大小 
 



类型选择表

类型
编码方式
典型使用场景







sint$N$>sbit$N$>/
Zig-Zag+VARINT —––—––––––->——— —————————————————–»--->––––––––––-->—————





Avoid overflow & preserve compactness for signed integers.

Bigger absolute values still fit within a single byte when close to zero.

Easily decoded back into signed integers.



kbblako
hpmes
r
h
r

``
请把上述代码块复制粘贴至官方解析工具：
再看https。//tools.ioirb.cn/proto/parse/
接下来将返回结果中对应字段改回sIntN与IIntN` 对比，即可直观看到二者在不同场景下产生的字节差异。这是你最直观的数据展示方式，也是调试和调整协议时最可靠的方法。


# 小结 & 推荐实践：



# 如果你的游戏协议中包含大量可能出现负数的数据，务必使用 sIntN 而不是普通 uIntN 或 fixedN. #痛点 #方法 #性能提高。



# 对于永远非负且范围已知的小整型。可以考虑直接使用 `fixedN` 或自定义枚举，以进一步压缩空间。#痛点 #调整方向，

用到了 AI 排版，好看多了。
* 如需快速验证某一字段在不同类型下的真实尺寸，请参考前述工具链接或自行构造手动测试代码。怎么说呢，