tracy攻略：和Profiler们怎么选
tracy攻略别一上来就装工具，先看你到底卡在哪里。它适合追帧抖动、线程等待、函数区间耗时；perf、VTune、VS Profiler、RenderDoc各有强项。按下面这套步骤走，少走弯路，也不容易被一堆漂亮图表带偏。
第1步：先判定问题类型
做tracy攻略，第一步不是下载，而是把问题说清楚：你是平均帧率低，还是偶尔掉一帧？是CPU忙，GPU忙，还是两个线程互相等？Tracy最顺手的场景，是“我知道大概有一段流程不稳，但不知道哪一小段抖”的情况。它把一帧里的函数区间、线程活动、锁等待摊在时间线上看，适合游戏、实时渲染、仿真、音视频这类对延迟敏感的项目。
横向看，perf更像免费听诊器，适合Linux下先扫热点；VTune更像医院精密仪器，能看微架构、缓存、指令层面的事；Visual Studio Profiler对Windows/C#或MSVC项目很省心；RenderDoc主要看图形渲染帧，不是拿来查普通CPU业务逻辑的。别把工具拿反了。
第2步：选采样还是埋点
Tracy不是纯采样工具，它更偏“你主动标出来，我帮你按时间线还原”。官方介绍里也说，它能做采样统计，但重点在手动标记源码，从而逐帧检查程序执行过程。([wolf.nereid.pl](https://wolf.nereid.pl/projects/tracy-profiler/)) 这就决定了它的优缺点：优点是定位偶发卡顿很直观，缺点是你得愿意在关键路径上加Zone、FrameMark这类标记。
如果你连卡在哪个模块都没谱，先用perf、VS Profiler这类低侵入工具粗扫一遍；如果你已经怀疑“资源加载”“脚本回调”“物理同步”这几块，Tracy就能把锅分得很细。我的经验是，第一轮埋点别超过20处，先围住主循环、渲染提交、资源IO、任务系统这四块。
第3步：小范围接入验证
别一口气把全项目都改了。靠谱做法是开一个profiling分支，只接入最小闭环：编译Tracy客户端，工程里接入头文件和客户端源文件，主循环末尾打FrameMark，几个疑似函数加Zone。跑30秒到2分钟就够，先看能不能稳定抓到问题。
和VS Profiler相比，Tracy前期多一步接入；和VTune相比，它少了不少环境负担；和自己打日志相比，它不用你盯着一屏时间戳猜调用顺序。只要项目能重新编译，Tracy的试用成本通常不高，真正费时间的是你给哪些代码段起清楚名字。
第4步：按证据缩小范围
看Tracy结果时，别只盯最长条。先找坏帧，再看坏帧和正常帧差在哪：多了哪个Zone？哪个线程空等？锁是不是集中在同一段？内存分配是不是突然冒尖？如果每次卡顿都落在同一个任务队列附近，那比“某函数平均耗时高”更有价值。
火焰图擅长告诉你总体热在哪里，Tracy的时间线擅长告诉你“为什么这一帧突然坏了”。这也是它和传统采样工具最大的区别。遇到每隔几秒才抖一次的毛病，平均值经常会把真相抹平。
第5步：决定长期留还是临时用
Tracy官方仓库说明它支持CPU、GPU、内存分配、锁、上下文切换等多类数据，也提供文档和发布包。([github.com](https://github.com/wolfpld/tracy)) 但这不代表每个项目都要常驻。小工具、一次性脚本、纯后端批处理，未必需要长期带着它；多人游戏客户端、引擎、渲染器、实时音频项目，建议保留一套可开关的Profiling构建。
最后给个土办法：如果一次性能问题能让团队浪费半天以上，Tracy就值得装；如果只是偶尔看一个函数慢不慢，系统自带采样工具更省事。工具别供起来，用完能解决问题才算值。
常见问题
tracy适合新手用吗？
适合，但别从全功能学起。先会FrameMark、Zone标记、时间线查看这三件事，就能解决大多数入门性能问题。
tracy会不会明显拖慢程序？
会有额外开销，尤其埋点过密、字符串命名太多、采集时间太长时。建议只在profiling构建里开启，先少量埋点再扩展。
tracy和RenderDoc怎么选？
查CPU流程、线程等待、帧时间波动，选Tracy；查某一帧的draw call、纹理、shader、渲染状态，选RenderDoc。