日志系统在游戏项目里往往是最不起眼、但一出问题就要命的基础设施。王者荣耀这种量级的实时对战游戏，单局产生的日志量非常可观，如果日志组件本身开销大、写盘慢、占用内存高，轻则拖累帧率，重则在对局关键时刻引发卡顿。BqLog 作为王者荣耀内部使用的日志组件，被反复提到的一个特点就是"快"，而它快的核心手段之一，就是高性能实时压缩日志。这篇就围绕这个点，把 BqLog 在实时压缩这条路上做的取舍、原理和实操细节拆开讲清楚，适合做客户端性能优化、基础组件开发，或者单纯对高性能日志实现感兴趣的同学参考。
1. 为什么日志组件必须把"实时压缩"当成一等公民
1.1 移动端日志的真实开销到底在哪
很多人对日志开销的第一反应是"写文件慢"，但实际压测下来，写文件往往不是最大头。真正吃性能的是三块：字符串格式化、内存分配、以及 I/O 等待。格式化阶段要把各种类型转成文本，涉及大量临时字符串；内存分配阶段如果每条日志都 new 一块 buffer，GC 压力会非常明显；I/O 阶段如果直接同步写盘，主线程被阻塞的风险极高。
在王者荣耀这种帧率敏感的场景里，一帧只有 16.6ms（60帧）甚至 8.3ms（120帧）的预算。如果日志组件在某一帧里集中写入几十 KB 的文本，光是格式化加写盘就可能吃掉好几毫秒。所以日志组件的设计目标从来不是"能写就行"，而是"在几乎不影响主流程的前提下把该记的都记下来"。
压缩在这里的价值就体现出来了：它把"写盘的数据量"直接降下来。文本日志的压缩比通常很可观，重复的字段名、时间戳格式、模块前缀，这些在压缩算法眼里都是高度冗余的内容。数据量降下来，I/O 时间、磁盘占用、后续上传带宽全都跟着降。这就是为什么 BqLog 把实时压缩放在这么核心的位置。
1.2 "实时"两个字才是真正的难点
压缩本身不难，zlib、zstd、lz4 这些库都很成熟。难的是"实时"——日志是边产生边写的，你不能等攒够一大块再压缩，那样内存占用高、崩溃时还会丢数据。实时压缩意味着：日志产生后很快就要进入压缩流程，压缩过程不能长时间持有大 buffer，也不能阻塞产生日志的线程。
这就带来一系列约束。压缩算法不能太重，否则 CPU 占用飙升；压缩块不能太大，否则延迟高；压缩不能在主线程做，否则一样卡帧。BqLog 的实时压缩本质上是在"压缩比、CPU 开销、内存占用、延迟"这四个维度上找平衡点，而不是单纯追求压缩比最高。
提示：评估一个日志组件的压缩方案，不要只看压缩比。要看它在目标设备上的 CPU 占用、单条日志的端到端延迟、以及峰值内存。压缩比高但 CPU 打满的方案，在移动端是灾难。
1.3 不压缩的日志在线上会付出什么代价
举个量化的例子。假设某局游戏产生了 2MB 的原始文本日志，不压缩直接落盘，磁盘写入 2MB。如果开启压缩，文本日志压缩到 20% 到 30% 是很常见的，也就是 400KB 到 600KB。写入量直接降到四分之一左右。对于每天海量对局的线上环境，这个差距在存储成本和上传流量上是数量级的。
更关键的是崩溃场景。玩家反馈卡顿或闪退时，日志是排查的第一手资料。如果日志因为写盘太慢被丢弃，或者因为占用内存太大被系统杀掉，那排查就无从谈起。实时压缩让"完整记录"和"低开销"这两个原本矛盾的目标变得可以同时成立。
2. BqLog 实时压缩的底层思路拆解
2.1 分块压缩：把连续日志流切成可独立处理的单元
BqLog 的实时压缩不是把整个日志文件当成一个流去压，而是把日志流切成一个个块（block），每块独立压缩。这样做有几个直接好处：第一，压缩可以在后台线程按块处理，主线程只管往队列里塞；第二，每块压缩完就能立刻落盘，不需要等整个文件结束；第三，崩溃时已经压缩落盘的块是完整的，最多丢最后一块。
块的大小选择是个关键参数。块太小，压缩算法发挥不出效果，因为每个块都要重新建立压缩上下文，头部开销占比高；块太大，内存占用高，延迟也大。实践中常见的做法是把块大小控制在几十 KB 到几百 KB 之间。这个区间既能保证压缩算法有足够的冗余可利用，又不会让单块处理时间过长。
这里有个容易被忽略的点：块边界怎么切。如果按固定字节数切，可能把一条日志从中间截断，解压后拼起来虽然能还原，但可读性差。更稳妥的做法是按日志条目的边界切，攒够一定条数或一定字节数就封一个块。BqLog 这类组件通常会维护一个写入缓冲区，达到阈值就触发一次块提交。
2.2 压缩算法的选型逻辑：为什么不是无脑上 zstd
压缩算法选型要看场景。zstd 压缩比好、速度也不错，但它的高压缩级别在移动端 CPU 上依然偏重；lz4 速度极快，压缩比一般；zlib 是老牌方案，压缩比中等、速度中等。BqLog 面向的是实时场景，所以更偏向"速度优先、压缩比够用"的算法。
实际选型时通常会把压缩级别调低。比如 zstd 用最低级别，或者 lz4 直接用默认级别。低级别下压缩比可能从 25% 变成 35%，但 CPU 开销能降一大截。对于日志这种"能还原就行、不需要极致压缩"的数据，这个取舍非常划算。
还有一个常被忽视的维度是解压速度。日志压缩后是要给人看的，排查问题时需要解压。如果压缩算法解压很慢，排查效率就低。lz4 在这点上优势明显，解压速度极快，适合"压缩时省 CPU、解压时也要快"的双向需求。
| 算法 | 压缩速度 | 解压速度 | 压缩比 | 适用场景 |
|---|---|---|---|---|
| lz4 | 极快 | 极快 | 一般 | 实时日志、低延迟优先 |
| zstd（低级别） | 快 | 快 | 较好 | 通用日志、平衡型 |
| zstd（高级别） | 慢 | 快 | 很好 | 归档日志、离线压缩 |
| zlib | 中等 | 中等 | 中等 | 兼容性优先 |
2.3 压缩与写入的流水线设计
BqLog 快的另一个原因是把压缩和写入做成了流水线。日志产生线程只负责把格式化好的数据放进一个无锁或低锁的队列，然后立刻返回。后台有专门的压缩线程从队列取数据、组块、压缩，压缩完再交给写入线程落盘。三个阶段各司其职，互不阻塞。
这种流水线设计的关键在于队列的实现。如果用普通的互斥锁队列，高并发写日志时锁竞争会很严重。所以高性能日志组件通常会用无锁队列或者每线程独立缓冲（thread-local buffer）的方式，减少竞争。每线程独立缓冲的好处是写入几乎无锁，缺点是内存占用会随线程数增长，需要控制线程数量或缓冲大小。
流水线还有一个好处是能利用多核。移动端虽然核心数不如桌面，但现代手机普遍有 6 到 8 个核，把压缩放到单独的核心上，对主线程的影响就很小。当然，这也要看系统的调度策略，不能假设后台线程一定能拿到独立核心。
3. 把实时压缩落地时要盯住的几个硬指标
3.1 单条日志的端到端延迟怎么测
延迟是实时压缩最核心的指标。测法很简单：在日志产生处打一个时间戳，在数据真正落盘后打一个时间戳，两者之差就是端到端延迟。但要注意，这个延迟在流水线架构下是异步的，日志产生线程感知到的延迟（入队延迟）和实际落盘延迟是两回事。
对游戏来说，真正影响帧率的是"日志产生线程被阻塞的时间"，也就是入队延迟。这个值应该控制在微秒级。而落盘延迟可以放宽到毫秒甚至几十毫秒，只要不无限堆积就行。所以测延迟要分开测：入队延迟看主线程影响，落盘延迟看数据完整性风险。
实测中常见的坑是：队列满了之后，日志产生线程被迫等待，入队延迟突然飙升。所以队列容量和丢弃策略要设计好。BqLog 这类组件通常会设置队列上限，满了之后要么丢弃低级别日志，要么阻塞等待，具体策略要看业务对日志完整性的要求。
3.2 压缩线程的 CPU 占用如何压住
压缩线程再独立，也是要抢 CPU 的。如果压缩线程优先级设得太高，会跟渲染线程抢资源；设得太低，又可能压缩跟不上产生速度，导致队列堆积。合理的做法是给压缩线程设一个中等偏低的优先级，并且在队列积压时动态调整压缩级别——积压多就用更快的低级别压缩，积压少就用稍高的级别。
另一个手段是限制压缩线程的处理节奏。比如每处理完一个块就主动让出一次 CPU，避免长时间占用。这在移动端尤其重要，因为移动端的调度器对长时间占用 CPU 的线程不太友好。
注意：不要在主线程做任何压缩相关的同步等待。哪怕只是等一个压缩块完成，都可能造成掉帧。所有压缩必须异步化。
3.3 内存峰值与崩溃安全
实时压缩会引入额外的内存占用：写入缓冲、压缩输入缓冲、压缩输出缓冲、队列里的待处理数据。这些加起来可能比不压缩时高不少。移动端内存紧张，必须控制峰值。
控制手段包括：限制队列长度、复用缓冲（避免频繁分配释放）、压缩完立刻释放输入缓冲。复用缓冲这点很关键，如果每个块都 new 一块内存，GC 压力会很大。用对象池或者固定大小的环形缓冲能显著降低分配次数。
崩溃安全方面，因为日志是分块压缩落盘的，崩溃时最多丢最后一个未完成的块。为了进一步降低丢失风险，可以缩短块提交的阈值，让块更频繁地落盘。但块太小又影响压缩比，所以还是要平衡。有些实现会在崩溃信号处理里做一次强制 flush，把当前缓冲刷出去，但这要求 flush 过程本身足够快且信号安全。
4. 实操中容易踩的坑与排查思路
4.1 压缩后日志不可读，排查反而变慢
这是最常见的抱怨。日志压缩了，出问题时得先解压才能看，如果解压工具不顺手，排查效率反而下降。解决办法是提供配套的解压/查看工具，最好能支持流式解压，边解压边看，不用等整个文件解完。
另一个做法是分级压缩：低级别日志（如 verbose）压缩存储，高级别日志（如 error）不压缩或轻压缩，保证关键日志随时可读。BqLog 这类组件通常会支持按日志级别配置不同的处理策略。
4.2 压缩线程把主线程的 CPU 抢了
前面提过优先级问题，但实际排查时往往不容易定位。表现是：开启日志压缩后，帧率下降，但 profiling 又看不出明显的热点。这时候要看线程调度情况，确认压缩线程是不是在某些时段占用了大量 CPU。
排查方法：用系统的性能分析工具看各线程的 CPU 占用时间线，对比开启和关闭压缩两种情况。如果发现压缩线程在帧渲染期间活跃，就要调整它的调度策略，比如让它更倾向于在空闲时段工作。
4.3 队列堆积导致日志延迟越来越大
队列堆积的典型表现是：日志文件里时间戳和实际发生时间对不上，越到后面差得越多。原因是产生速度长期大于压缩+写入速度。这时候要么提高压缩/写入吞吐，要么降低日志产生量（比如提高日志级别门槛）。
排查时先确认是压缩慢还是写入慢。可以分别统计压缩线程的处理速率和写入线程的落盘速率。如果是压缩慢，考虑降压缩级别或换更快的算法；如果是写入慢，考虑批量写入或换更高效的 I/O 方式。
4.4 不同机型表现差异巨大
移动端机型差异是绕不开的。低端机 CPU 弱、内存小，压缩方案要更保守；高端机可以适当激进。BqLog 这类组件通常会提供配置项，让业务根据机型档位调整压缩级别、块大小、队列长度等参数。
实操建议是准备几档预设配置，按机型性能分级下发。不要指望一套参数打天下，低端机上跑高端机参数，很可能直接卡死。
5. 从 BqLog 的设计里能抄走哪些通用经验
5.1 异步化是一切高性能日志的前提
不管压不压缩，日志写入必须异步。同步写日志在主线程上是性能杀手。异步化的核心是队列加后台线程，队列要尽量无锁，后台线程要能批量处理。这个模式适用于几乎所有高性能日志场景，不只是 BqLog。
5.2 压缩是手段不是目的，别为了压缩比牺牲实时性
很多人一上来就想用最高压缩比，结果 CPU 打满。日志压缩的目标是"降低 I/O 和存储开销，同时不影响主流程"，压缩比只是其中一个维度。低级别压缩往往才是实时场景的正解。
5.3 可观测性要覆盖日志组件自身
日志组件自己也需要被监控：队列长度、压缩速率、落盘速率、丢弃条数、端到端延迟。这些指标能帮你在出问题前就发现异常。很多团队只顾着用日志排查业务问题，却忘了日志组件本身也需要排查。
5.4 配置化让不同场景各取所需
不同业务、不同机型、不同调试阶段对日志的需求不一样。把压缩级别、块大小、队列长度、日志级别门槛都做成可配置的，能让组件适应更多场景。硬编码参数是维护噩梦。
我在实际做客户端性能优化时的一个体会是：日志组件的优化收益往往被低估。大家更关注渲染、网络、内存这些显性指标，但日志这种"基础设施"一旦设计不好，会在各种意想不到的地方拖后腿。BqLog 把实时压缩做扎实，本质上是在为整个游戏的稳定性兜底——平时感觉不到它的存在，出问题时它能把现场完整保留下来，这才是日志组件最大的价值。
