一、实时性瓶颈分析：为什么你的路径规划跑不快？
说实话，我见过太多团队在路径规划上栽跟头。算法选得挺好，代码写得也挺规范，一上真机就卡成PPT。为什么会这样？
今天咱们就来扒一扒，到底是谁拖慢了你的路径规划。我个人习惯把瓶颈分成三类：算法本身的复杂度、工程实现的坑、以及系统层面的资源争抢。
1.1 算法复杂度——最容易被忽视的“隐形杀手”
先问个问题：你的路径规划算法，时间复杂度是多少？
很多人觉得“反正地图不大，O(n²)和O(n log n)差别不大”。嗯，这个想法我在项目里也踩过坑。有一次做仓储机器人，地图就100x100的栅格，A*跑得挺欢。结果一扩展到200x200，直接炸了——单次规划从5ms飙到了80ms。
你想想看，O(n²)的增长速度有多恐怖？
| 地图大小 | A* (O(n log n)) | Dijkstra (O(n²)) |
|---|---|---|
| 100x100 | ~5ms | ~12ms |
| 200x200 | ~12ms | ~80ms |
| 500x500 | ~35ms | ~600ms |
看到没？地图扩大5倍，Dijkstra慢了50倍。这就是算法复杂度的威力。
核心结论：实时性要求高的场景，优先选O(n log n)级别的算法。A*、D* Lite、RRT*都是不错的选择。别碰纯Dijkstra，除非你的地图真的小到可以忽略。
1.2 工程实现——代码写得好不好，差别能到10倍
算法选对了，代码写得稀烂，照样跑不快。我在项目中遇到过最离谱的一次：同一个A*算法，同事用Python写的，我换成C++重写，速度提升了8倍。
但这不光是语言的问题。就算都用C++，实现方式不同，性能差距也很大。
举个最常见的例子：open list的数据结构。
// 错误示范：用vector当优先队列
std::vector<Node*> openList;
// 每次插入后排序
openList.push_back(newNode);
std::sort(openList.begin(), openList.end(), compare);
// 正确示范：用std::priority_queue
std::priority_queue<Node*, std::vector<Node*>, Compare> openList;
openList.push(newNode);前者每次插入都要O(n log n)排序，后者只需要O(log n)的堆调整。地图越大，差距越明显。
我的建议：写路径规划代码时，优先考虑三点：
- 用合适的数据结构（优先队列、哈希表、邻接表）
- 避免频繁的内存分配（对象池是个好东西）
- 减少不必要的拷贝（传引用，别传值）
1.3 系统层面的资源争抢——你以为是算法慢，其实是CPU在打架
这个坑我印象特别深。有一次做AGV调度系统，路径规划模块单独测试时，单次规划只要15ms。结果一集成到主系统里，动不动就跑到100ms+。
查了半天，发现是其他模块在疯狂抢占CPU资源。视觉处理线程每帧要算200ms，路径规划线程只能干等着。
说白了，实时性不只是算法的事，更是系统架构的事。
| 资源类型 | 常见问题 | 影响程度 |
|---|---|---|
| CPU | 多线程竞争、优先级反转 | 高 |
| 内存 | 频繁GC、缓存未命中 | 中 |
| I/O | 地图加载、日志写入阻塞 | 低（但致命） |
避坑指南：我曾经因为日志打印太频繁，导致路径规划线程被I/O阻塞了30ms。后来把所有日志改成异步写入，问题就解决了。记住：实时系统里，同步I/O是毒药。
1.4 地图表示——你存地图的方式，决定了搜索的速度
很多人觉得地图就是一张图，存成二维数组就完事了。但实际项目中，地图的表示方式对性能影响巨大。
我做过一个对比实验：同样是200x200的栅格地图，用二维数组存，A*搜索耗时约12ms。换成四叉树表示，同样的搜索只需要4ms。
为什么？因为四叉树天然支持多分辨率搜索。大范围移动时用粗粒度，靠近障碍物时用细粒度。说白了，就是“该粗的时候粗，该细的时候细”。
实用建议：
- 静态环境用栅格地图 + 预计算距离场
- 动态环境用四叉树或八叉树
- 超大场景用拓扑地图 + 分层规划
1.5 避坑总结——我踩过的那些坑
最后，分享几个我亲身踩过的坑，希望能帮你少走弯路：
- 别迷信“最优算法”——有一次我非要用RRT*，结果在狭窄通道里收敛极慢。后来换成RRT-Connect，速度快了5倍。适合的才是最好的。
- 注意内存分配——路径规划里频繁new/delete节点，会导致内存碎片。我后来改用对象池，性能提升了30%。
- 别忽略预热——有些算法第一次运行很慢，因为要初始化数据结构。我习惯在系统启动时先跑一次“空规划”，把缓存预热好。
- 多线程不是万能药——加锁的开销有时候比计算本身还大。能用无锁数据结构就别用锁。
嗯，以上就是我对实时性瓶颈的一些理解。说白了，路径规划跑不快，90%的情况是算法复杂度没选对，或者工程实现太粗糙。剩下的10%，是系统层面的资源调度问题。
下一章，咱们会深入讲怎么用A*算法做具体优化。到时候我会带一个完整的代码示例，从数据结构到搜索策略，一步步把性能提上去。