3. 开发环境搭建
Cyber RT 的性能与可靠性工程，第一步不是写代码，而是把“可复现的运行环境”搭起来。Apollo 是一个由 Bazel 驱动、依赖大量第三方库、并强依赖 Docker 镜像的大型工程；如果环境不一致，后续所有性能数据、时延曲线、丢包统计都会失去可比性。本章围绕源码编译、Cyber RT 运行环境、Docker 与 Bazel 工具链、以及调试与性能观测工具四条主线展开，目标是让你得到一套“可编译、可运行、可观测、可复现”的本地开发环境。
一、核心原理：为什么 Apollo 必须用 Docker + Bazel
Apollo 的依赖包括 Protobuf、gRPC、Fast DDS、Eigen、PCL、OpenCV、CUDA 等，版本敏感且互相耦合。Docker 解决的是“操作系统级依赖一致性”，Bazel 解决的是“构建过程可复现与增量构建”。两者叠加，才能保证同一份源码在不同机器上产出行为一致的二进制。
Cyber RT 作为 Apollo 的运行时框架，其核心是“组件（Component）+ 通道（Channel）+ 调度器（Scheduler）”。它依赖共享内存、DDS 通信、协程调度等系统能力，因此运行环境必须满足：内核共享内存参数合理、CPU 亲和性可配置、时钟源稳定。这些都属于“环境即性能”的范畴。
二、方法流程：从源码到可运行环境
推荐流程为：拉取源码 → 启动 Docker 开发容器 → 容器内 Bazel 编译 → 运行 Cyber RT 示例 → 接入调试与观测工具。下面给出关键命令。
# 1. 拉取 Apollo 源码
git clone https://github.com/ApolloAuto/apollo.git
cd apollo
git checkout v9.0.0
# 2. 启动开发容器（首次会自动拉取镜像）
bash docker/scripts/dev_start.sh
# 3. 进入容器
bash docker/scripts/dev_into.sh
# 4. 容器内编译 Cyber RT 示例
bazel build //cyber/examples/...
# 5. 运行 talker / listener 验证通信
bazel run //cyber/examples/talker
bazel run //cyber/examples/listener
Bazel 编译时建议关注以下参数：--config=opt 开启优化，--jobs 控制并行度避免内存溢出，--copt=-g 保留调试符号以便 perf/gdb 使用。若机器内存较小，可先编译单个 target 而非全量。
三、Docker 与 Bazel 工具链要点
Docker 侧要理解三个脚本：dev_start.sh 负责启动容器并挂载源码目录，dev_into.sh 进入容器，dev_stop.sh 停止容器。容器内已预装 Bazel、CUDA、依赖库，因此不要在宿主机直接编译，否则极易出现版本冲突。
Bazel 侧要理解 WORKSPACE 与 BUILD 文件：WORKSPACE 声明外部依赖，BUILD 定义 target 与依赖关系。Cyber RT 的组件通常以 cc_binary 或 cc_library 形式声明。增量编译是 Bazel 的核心优势，修改单个文件后只重建受影响 target。
| 工具 | 作用 | 典型命令/文件 | 常见误区 |
|---|---|---|---|
| Docker | 统一系统与依赖环境 | dev_start.sh / dev_into.sh | 在宿主机直接编译 |
| Bazel | 可复现增量构建 | bazel build //cyber/... | 忽略 --jobs 导致 OOM |
| Cyber RT | 组件与通道运行时 | cyber_monitor / cyber_recorder | 未配置共享内存 |
| perf / gdb | 性能与崩溃调试 | perf top / gdb --args | 无调试符号 |
| top / htop | 资源占用观测 | top -H -p PID | 只看进程不看线程 |
四、调试与性能观测工具入门
Cyber RT 自带一批观测工具，是性能工程的“第一双眼睛”：
cyber_monitor：实时查看通道频率、时延、消息量，是判断通信是否正常的首选工具。cyber_recorder：录制与回放通道数据，用于离线复现性能问题。cyber_launch：按 launch 文件启动多个组件，便于构造真实场景。perf：采样 CPU 热点，定位计算瓶颈。gdb：定位崩溃与死锁，配合 core dump 使用。
下面这张图展示了从源码到可观测运行环境的完整链路，以及各工具在链路中的位置。
五、案例与场景：一次“时延异常”的排查
某团队在容器内运行 Cyber RT 组件，发现端到端时延从 5ms 抖动到 40ms。排查路径如下：先用 cyber_monitor 确认通道频率正常，排除消息积压；再用 top -H -p PID 发现某线程 CPU 占用周期性飙高；接着用 perf top 定位到 DDS 序列化热点；最终发现容器 CPU 配额被限制为 1 核，导致调度抖动。调整容器资源后时延恢复稳定。这个案例说明：观测工具的价值在于把“感觉慢”变成“可定位的指标”。
六、误区与复盘
- 误区一：宿主机直接编译。依赖版本冲突几乎必然发生，应始终在 Docker 容器内构建。
- 误区二：忽略 Bazel 缓存。合理使用
--jobs与远程缓存可大幅缩短构建时间，但不要盲目全量编译。 - 误区三：只看进程不看线程。Cyber RT 是线程/协程模型，必须用
top -H或perf观察线程级行为。 - 误区四：没有调试符号。编译时加
-g，否则 perf 与 gdb 只能看到地址，无法定位函数。 - 误区五：环境参数随意。共享内存大小、CPU 亲和性、时钟源都会影响时延，应记录并固化到启动脚本。
复盘来看，开发环境搭建不是“一次性任务”，而是性能与可靠性工程的基线工程。建议把 Docker 启动、Bazel 编译、Cyber RT 运行、观测工具调用固化为脚本，并纳入版本管理。这样，任何一次性能回归都能在相同环境下被复现和验证。