寻路表现和性能优化

寻路表现和性能优化

A-Star
1，预处理，绝对不可达的cell不会被纳入寻路搜寻结点，而不是寻路时再判断一次。

2，结点每次被加入和移出openlist,有一次堆排序，改为每个结点对象持有一个int计数，每个寻路任务赋予一个count(递增)，则只需判断结点的计数器是否小于当前任务的count，小于则未加入openlist，设置为当前任务count则表示加入了openlist。加入closelist同理。对堆的排序操作优化为一次整数比较大小和一次赋值。

3，启动新线程寻路不考虑
缺点：
a,地图状态实时变化影响寻路，需要跨线程维护地图状态。
b,对确定性有要求(帧同步)，多线程寻路会因为寻路时间的不确定性导致游戏结果不确定。

4，路径优化。a*寻路结果不自然，路线曲折，即使两点目视可达，轨迹也可能多次拐弯。对结果做处理，两点直线可达时，中间路径点舍弃。

5，稳定帧率，量化寻路所有消耗，包括寻路搜寻的结点数，处理结果时判断两点是否可达的计算。将所有这些消耗量化为cost。每一帧的寻路计算设置cost上限，即任务slice，保证无论任务计算量多大，帧率不会被拖累。

6，任务快速失败。每个任务设置消耗上限，到达上限即寻路失败，但仍可返回一条已搜出的路径，让目标先行移动。适用于超大地图。

7，任务并行，建立多个PathFinder，单帧驱动多个finder执行。每个finder维护独立的cellRuntime数据，如openlistCount，F,G等。共用是否可达，通过cost等数据。每帧的tick指定单个finder本帧消耗上限和本帧所有finder消耗上限，一个任务结束，消耗配额有富余则从任务队列pick下一个执行。并行化可以解决：单个超大任务一直占用导致后续寻路都要等待的问题。可考虑将消耗上限大的任务交给固定的finder，这样不影响低消耗任务在其它finder的执行。