Profiling、火焰图与热点分析
Category
operation / observability 子树。节点定位：把性能讨论从猜测推进到证据——症状定义、火焰图读法、采样/插桩取舍、热点归因与预算治理。
Definition
性能优化最大的浪费，是把精力花在不存在或者不重要的瓶颈上。“感觉这里慢”和“数据显示这里最贵”之间，隔着一条完整的取证链路。Profiling 和火焰图的价值不在于画出一张 impressive 的图，而在于把性能讨论从猜测推进到证据：哪段路径在哪种负载下确实最贵、贵得有没有道理、优化它能换来多少玩家可感知的收益。
Problem
性能优化最大的浪费是优化不存在或不重要的瓶颈：「感觉这里慢」和「数据显示这里最贵」之间隔着完整取证链路。没有性能预算约束，优化收益会随版本迭代持续漏掉，性能退化是常态而非意外。
从症状定义开始，而不是从工具开始
采样之前先回答四个问题：什么负载下、什么场景里、慢多少、影响谁。症状定义清楚了，profile 结果才有解读的坐标系；定义含糊时，同一张火焰图可以有无数种读法，每种读法都像有道理。常见的症状定义包括“某个玩法团战时帧耗时翻倍”“活动开启后逻辑线程 CPU 抬升三成”“某档设备上加载耗时超预算”。
症状定义还有一个附带作用：它决定了采样的时机和范围。间歇性抖动要在抖动发生的时间窗内采样，负载相关的热点要压到对应负载再采，设备相关的客户端问题要换到目标设备上采。先有症状再采样，工具才会指向答案。
火焰图到底在表达什么
火焰图的读法有几条基本规则：
- 横向宽度表示时间占比，不代表调用次数。
- 纵向是调用栈，越往下越是调用链的起点。
- 宽块的“平顶”往往意味着热点：这个函数本身在消耗时间，而不是仅仅转调别人。
- 全图总宽度对应采样期间的总 CPU 时间。
读图的常见判断是：宽而且平顶、又属于业务代码的块值得优先看；属于运行时底层的宽块，例如内存分配、序列化原语、锁操作，先问“是谁调用得这么多”，答案通常在上面几层。火焰图指出的是“时间去哪了”，而“为什么去那里”经常要沿着栈往上找业务成因。
采样型与插桩型的取舍
性能采集有两类基本手段，各有明确的适用边界：
- 采样型：周期性抓取调用栈，开销低、可以常驻线上，但极短的函数可能被低估，采样边界附近的调用存在归因误差。
- 插桩型：在函数边界埋点计数计时，边界精确、能量化调用次数，但开销大且会改变程序时序，只适合离线或复现环境。
线上常态只能依赖采样，插桩适合在复现环境里对已经锁定的路径做精确测量。两种手段经常配合使用：线上采样指出方向，插桩验证细节。把插桩直接铺到线上，观测本身就会扭曲被观测的系统。
线上持续 profiling 的代价与收益
低开销采样器可以常驻生产环境，换来两个平时拿不到的能力：一是与历史基线对比，这次版本的热点分布和上个版本差在哪里，退化会在数据上直接显形；二是异常时刻的现场留存，抖动发生时恰好有采样数据可查，而不是事后空手复原。
代价同样具体：持续的 CPU 占用、采样数据的存储、以及符号还原的成本。发布版本通常裁掉符号信息，如果不同时归档符号表与版本号，抓到的栈就无法对应到源码，图等于白抓。持续 profiling 的常见配置是低频率常驻加异常时提高采样率，用很小的稳定开销换取随时可比的基线。
热点归因的几条常见路径
火焰图指到具体函数之后，归因通常落在几类常见成因上，每类的处理方向完全不同：
- 分配频繁：短命对象大量创建，代价不在分配本身，而在回收压力和缓存失效，方向是复用与对象池。
- 序列化与拷贝：广播路径上同一份数据反复编码复制，方向是共享与按需序列化。
- 锁竞争：栈上显示在等锁，真实热点在持锁的那段代码，方向是缩小临界区或改无锁结构。
- 定时器与遍历：每帧全量遍历的对象集合随规模增长，方向是分帧、增量与脏标记。
- 意外路径：本该缓存的查询落在慢路径，本该批量的写被逐条提交，方向是修正调用方式。
归因错了，优化就会做成反方向——例如把锁粒度改细却引入更多开销，或者给一个调用频率极低的函数做对象池。这也是插桩数据（调用次数）有独立价值的原因：它回答“这个函数被调用了多少次”，是判断优化方向的关键输入。
采样窗口与统计稳定性
单次短时间采样得出的火焰图可能有偶然性：恰好采到一次活动开启、一次落盘高峰，热点分布与常态相差很远。对比两次采样时，窗口长度和负载条件不同，结论就不可比。常见的做法是固定采样时长、避开特殊时段、对同一症状多次采样确认形态稳定，再下优化结论。数据量不足时宁可多采几轮，也不要从一张孤立的图上确定优化清单。
同一个函数在不同玩法、不同地图、不同对象规模下的开销可能差一个数量级。所以 profile 数据最好能和业务维度关联：采样时记录当前玩法类型、在线规模、对象数量、活动状态。没有这层关联，优化结论只能停留在函数级别，无法回答“玩家在什么时候、什么场景下会受影响”，也就无法估计优化的实际收益。
上下文关联对客户端尤其重要：同一段逻辑在主城和在战场、在低端机和高档机上的表现可能完全不同，脱离负载谈热点很容易得出以偏概全的结论。
客户端与渲染链路的特殊性
客户端性能问题经常不在纯逻辑代码上：CPU 与 GPU 的边界、合批与 draw call、资源加载与实例化、GC 停顿、热更新与解压，每一类都有自己的观测手段。逻辑层的火焰图看不出 GPU 瓶颈，帧率问题要先分清是 CPU 准备不及还是 GPU 渲染不及，两者对应完全不同的优化方向。
设备分档是客户端 profiling 绕不开的维度。低端机上的热点在高端机上可能完全不可见，所以客户端采样通常按设备分档进行，并且要在真实目标设备上做——开发机的结论外推价值有限。
服务端与客户端各有优先观测点
服务端 profiling 的优先对象相对集中：逻辑帧主循环、广播与序列化、数据库访问路径、定时任务。这些路径的负载与在线规模直接相关，也最容易在容量增长时先暴露。客户端的优先对象则分散在帧预算的各个组成部分：逻辑更新、渲染提交、资源加载、UI 重建、GC。两边经常需要配合定位——服务端帧耗时正常而客户端表现卡顿时，问题往往在同步量、插值和渲染压力的交界处，任何一侧单独看都容易误判。
优化要闭环验证
优化前建立基准、优化后用同一基准复测，听起来是常识，实际经常被跳过——赶工时“改完感觉快了”就提交。没有复测的优化有两个常见结局：效果被高估，或者优化点在真实负载里根本不在主路径上，玩家毫无感知。
基准要尽量接近真实负载形态。只测单个函数的微型基准容易把优化引向一条真实场景里根本不会出现的路径，数据好看但对玩家无意义。完整闭环通常是：真实负载基准、优化、复测、再观察线上指标确认玩家侧真的有变化。
什么时候值得做专项优化
粗略的优先级判断是单次代价乘以触发频率：一条很贵但一年触发一次的路径，往往不如一条便宜但每帧执行几千次的路径值得优化。经验上，玩家可感知的性能收益大多来自主循环、广播、序列化、视野计算这类高频路径，而不是最显眼的复杂算法。
这个判断反过来也解释了一个常见挫败：团队做了技术含量很高的优化，玩家却没感觉——大概率是优化点频率不够高。先看频率再看单次开销，顺序反了就容易做出收益接近零的工作。
用预算约束性能退化
比事后 profiling 更靠前的机制是性能预算：逻辑帧各阶段、单帧广播包量、关键加载耗时，各自有明确的预算值，新功能接入时对照检查。预算值不需要精确，它的作用是让“这个功能会不会拖慢主循环”变成一个可讨论、可测量的量，而不是上线后才发现。预算超了怎么办，可以是优化实现、可以是降低表现、也可以是有意识地调高预算——重要的是这个决定是被做出的，而不是默认发生的。
性能数据的记录与对比
热点分析的纵向价值依赖历史留存：采样结果按版本归档，关键场景的火焰图和基准数字留档，跨版本对比才有依据。很多团队 profiling 做了、数据没留，每次都从零开始，性能退化因此长期不可见。归档的成本很低，通常就是带版本号和场景说明的采样文件，加上几行基准数字。
持续治理比一次性突击更有效
性能会随版本腐化：新功能引入新的每帧开销，旧的热点被遗忘，退化是渐进的。把 profiling 纳入常规流程——版本前后跑一次热点对比、主干常驻低开销采样、发布检查里加一条性能基线核对——往往比一年一次的性能专项周更能防住退化。专项突击适合处理已知的重大热点，但防不住渐进式劣化，而玩家对渐进式劣化的感知同样明显。
常见误区
- 拿一张火焰图直接下结论，不看采样环境、负载形态和业务上下文。
- 优化显眼而不关键的地方，投入很大、玩家无感。
- profiling 只在性能专项时开启，平时没有基线，异常时无数据可比。
- 发布版本不归档符号信息，抓到调用栈却无法还原到源码。
- 用开发机或微型基准的结论代表生产负载和真实设备。
- 优化后不做基准复测，效果全凭感觉，甚至引入新的退化而不自知。
热点分析的价值不在于工具的先进程度，而在于症状定义、上下文关联和闭环验证这三个环节是否完整。环节齐了，普通的采样工具就能支撑可靠的性能决策；环节缺失，再好的火焰图也只是装饰。
Used By
性能专项的取证流程（症状→采样→归因→闭环验证）；线上持续 profiling 的成本评估；性能预算与回归防退化。
Related
关系链：症状定义 → 火焰图证据 → 采样取舍 → 热点归因 → 预算治理。上游：observability/02（哪些指标异常该触发 profiling）。下游：client 树（渲染链路 profiling，见 client/web）。
Reference
本页为工程经验归纳。