第1章课程导学与工具概览

1、课程导学与工具概览：ADAS系统性能瓶颈分析、Perf与Trace工具介绍、课程目标与学习路径

说实话，我入行ADAS那会儿，大家对性能的理解还停留在「能跑就行」。直到有一次，我们团队在高速测试时，系统突然延迟了200毫秒——嗯，200毫秒在普通应用里不算啥，但在时速120公里的车上，那就是6.7米的制动距离。那次之后，我再也不敢轻视性能分析了。

ADAS系统跟普通嵌入式系统不一样。你想想看，它要同时处理摄像头、雷达、激光雷达的数据，还要跑目标检测、路径规划、控制输出。任何一个环节卡顿，都可能造成严重后果。我见过太多团队，算法模型跑得飞快，但一上实车就各种问题——说白了，就是没做好系统级的性能分析。

常见的性能瓶颈有哪些？我列几个典型的：

这些瓶颈，光靠看代码是看不出来的。你得用工具去「摸」系统的脉搏。这就是Perf和Trace的价值所在。

Perf是Linux内核自带的性能分析工具。我第一次用Perf时，觉得它就是个计数器——后来才发现，它远比我想象的强大。

Perf能做什么？简单说：

举个例子，你想知道目标检测算法里哪个函数最耗CPU：

# 采样30秒，记录调用栈
perf record -g -p <pid> -- sleep 30
perf report

输出结果会告诉你，哪个函数占用了最多的CPU时间。我在项目中遇到过，一个看起来不起眼的图像预处理函数，居然占了40%的CPU——优化后，整个系统的帧率提升了30%。

我的习惯：每次做性能优化前，先用Perf做一次全量采样。这就像医生看病先做CT，能快速定位问题区域。

Perf擅长告诉你「哪里慢」，但Trace工具擅长告诉你「为什么慢」。Trace记录的是系统事件的时间序列——比如任务什么时候开始执行、什么时候被抢占、中断什么时候触发。

常用的Trace工具有：

我个人的经验是：Ftrace适合日常调试，LTTng适合深度分析。比如你想排查一个任务为什么延迟了：

# 开启调度器跟踪
echo 1 > /sys/kernel/debug/tracing/events/sched/sched_switch/enable
cat /sys/kernel/debug/tracing/trace_pipe

输出会显示每个任务的切换时间、运行时长、被谁抢占。我曾经用这个方法，发现一个高优先级的中断处理函数，每次执行都要花5毫秒——导致低优先级的控制任务频繁被延迟。优化中断处理逻辑后，系统响应时间从15ms降到了3ms。

注意：Trace工具会引入一定的性能开销。在生产环境中使用时，要控制跟踪的事件数量，避免影响系统行为。我一般先在测试环境复现问题，再用Trace做详细分析。

这门课的目标不是让你成为Perf或Trace的「说明书读者」，而是让你真正能用它们解决实际问题。具体来说：

我见过太多工程师，工具用得贼溜，但优化效果一般。为什么？因为他们只看到了「现象」，没看到「本质」。比如CPU利用率高，可能是算法效率低，也可能是内存带宽不够导致CPU空转。你得结合多个指标，才能做出正确判断。

这门课我设计了四个阶段：

每个阶段我都会结合真实项目案例来讲。比如第三阶段，我会分享一个我在ADAS项目中遇到的「内存带宽瓶颈」案例——当时我们用了三路摄像头，结果系统帧率从30fps掉到了15fps。用Perf和Trace一步步排查，最后发现是DDR带宽被图像数据吃满了。优化方案是调整数据流水线，减少不必要的内存拷贝。

一句话总结：性能分析不是玄学，是科学。工具是手段，理解系统才是根本。这门课，我会带你从「会用工具」到「会优化系统」。

好了，课程导学就到这里。下一章，我们正式开始Perf的实战操作。记住，工具是练出来的，不是看出来的。建议你边学边动手，在自己的开发板上跑一跑。遇到问题，随时在课程群里交流——我看到了会回复。