这两年做跨平台桌面我越来越觉得路径规划这类功能被很多人默认归到了Web GIS那一边打开浏览器、拖个Leaflet、加个路径规划API好像就完事了。但在真实项目里离线环境、内网部署、Linux工控机、甚至车载触屏上跑一套C#桌面应用的情况其实比想象中多得多。Avalonia这个框架我用到现在已经是系列第七十九篇的内容积累这一篇专门记录一下我是怎么把GIS路径规划从数据处理、算法选型到跨平台渲染完整搬到Avalonia上的适合有C#基础、熟悉Avalonia基本控件但还没真正处理过GIS数据管线和路径规划算法的同学参考。1. 这个系列做到第七十九篇为什么还在用Avalonia做GIS先说结论不是Web GIS不行而是桌面端GIS在某些场景下绕不开。我手头这个项目客户要求应用同时跑在Windows办公电脑、Linux工控机、安卓平板这三类设备上数据要能离线使用地图和路径规划计算必须在本地完成。用Electron套一个Web地图方案当然也行但内存占用和启动速度在工控机上实在不理想而且团队主力是C#维护C/Qt的人力成本也不允许。这时候Avalonia就成了顺理成章的选择。1.1 桌面GIS框架选型对比我把当时考虑的几套方案摊开对比过最后才锁定Avalonia。方案跨平台能力矢量绘图能力团队上手成本离线运行发布体积WPF仅Windows强但被Win绑定C#团队极低支持小MAUIWin/Mac/Android/iOSLinux缺失中等C#团队中等支持中Electron全平台靠Canvas/WebGLWeb团队极低C#团队高支持大Qt/C全平台强需另配C团队支持中AvaloniaWin/Linux/macOS/Android强Skia自绘C#团队低支持小Avalonia最吸引我的不是“跨平台”这个标签本身而是它的渲染机制。GIS应用本质上是个高频绘图应用地图瓦片、路网线、路径高亮、标记点都是矢量图形。Avalonia底层用Skia自绘不依赖操作系统控件这让我可以完全掌控绘制管线不需要像WPF那样在那个老旧的RenderTarget上反复调优也不存在Electron那种DOM树和Canvas来回同步的性能损耗。1.2 为什么我不推荐“先做个Web再套壳”很多人会问地图这东西Web端生态那么成熟为什么非要自研桌面渲染我个人的实操体会是一旦涉及离线地图和本地路网数据Web方案的优势会被削弱一大截。你要么开发一套离线缓存机制要么每台机器上跑一个本地服务都要自己处理。而在Avalonia里坐标转换、地图绘制、路径规划全是本地代码数据直接读本地文件不过网络、不依赖后台服务对很多政企客户来说这才是他们要的“安分”形态。再补一句市面上确实有一些Avalonia第三方地图控件但多数停留在“显示标记点”的层面路径规划这种需要自己维护路网Graph、自己做拓扑搜索的场景还是自己动手更可控。这个系列做到第七十九篇很多读者其实是在等一篇能把控件、数据、算法串起来的完整案例这篇就是。2. GIS数据进Avalonia之前先把坐标系和路网模型理顺路径规划做不好八成不是算法问题而是数据问题。我在第一次接入数据时就被坐标系坑过直接从OpenStreetMap导出的路网是WGS84经纬度按经纬度当平面坐标去算欧氏距离结果路径完全偏掉。这个问题在Web GIS里被各种库屏蔽了在Avalonia里你得自己处理。2.1 坐标系的两种形态GIS数据里最常见的两类坐标系WGS84地理坐标系经纬度单位是度适合全球定位但不适合直接做距离计算。Web Mercator投影坐标系把经纬度投影成以米为单位的平面坐标地图瓦片就是这个坐标系的基础。路径规划里的“距离”和“启发函数”都必须在投影坐标下计算否则一纬度差对应的物理距离在不同纬度差异很大算出来的都是错的。我在项目里的做法是载入路网数据时统一转成Web Mercator平面坐标所有计算都在这个坐标系里完成最后输出路径时再转回纬经度给地图瓦片层使用。2.2 用GeoJSON构建路网Graph项目里的路网数据是GeoJSON格式每一条道路是一根LineString。我使用NetTopologySuite这个库做几何解析它的成熟度比自己在Avalonia里手写解析器要可靠得多。核心流程分三步第一步读取GeoJSON并解析出所有LineString几何对象using NetTopologySuite.IO; var json File.ReadAllText(road_network.geojson); var reader new GeoJsonReader(); var geometry reader.ReadNetTopologySuite.Geometries.Geometry(json);第二步把每条LineString抽成RoadNode和RoadEdge。这里有个容易忽略的细节道路是带节点的折线路径规划的Graph需要把折线的每个坐标点都作为一个节点相邻点之间构成一条边。不能把一条道路整段当成一条边否则在交叉口没法转弯。public class RoadNode { public long Id { get; set; } public double X { get; set; } public double Y { get; set; } public ListRoadEdge Edges { get; set; } new(); } public class RoadEdge { public long AId { get; set; } public long BId { get; set; } public double Weight { get; set; } public string RoadName { get; set; } }第三步做节点合并。真实路网数据里两条道路在交叉口往往并没有完全共用一个节点坐标可能差了几厘米。这种情况会导致路径规划找不到“转弯”的路明明十字路口就在那里算法却认为路是不连通的。我的处理方式是建立一个字典key是坐标取整后的哈希值差值在两米以内的点合并成同一个节点。这一步看起来粗暴但在城市路网数据里非常有效。var tolerance 0.00001; // 投影坐标系下约1米 var key ${Math.Round(x / tolerance)}-{Math.Round(y / tolerance)};2.3 大区域数据的边界过滤如果一次性把整个城市的路网加载进Graph内存和初始化耗时都扛不住。我的办法是先根据客户使用的区域范围做一次边界框裁剪只加载业务范围内的道路。用户漫游到其他区域时再按需加载。这个按需加载机制放到后文性能优化部分再细说但数据进内存之前先做裁剪是这个GIS项目的第一个性能关键点。3. A*路径规划的实现细节启发函数、权重设计与拓扑法误区路网Graph就绪之后路径规划就是一个标准的最短路径问题。选Dijkstra还是A*取决于你在地图里有多少节点。对于几万节点的城市路网Dijkstra的搜索范围会呈圆形扩散平均要多遍历好几倍节点A*靠启发函数把搜索方向往目标点引导工程上提升非常明显。3.1 A*的核心公式与启发函数设计A*的核心是每个节点维护两个分数g(n)从起点到当前节点的实际代价。h(n)从当前节点到终点的估计代价。f(n) g(n) h(n)每次从优先队列里取f值最小的节点扩展。启发函数h(n)的设计决定了A*的效率和正确性的平衡。我用的是投影坐标下的欧氏距离static double Heuristic(RoadNode a, RoadNode b) { var dx a.X - b.X; var dy a.Y - b.Y; return Math.Sqrt(dx * dx dy * dy); }之所以用欧氏距离而不是曼哈顿距离是因为路网里的道路不都是横平竖直的欧氏距离对实际距离的估计更紧搜索效率更高。只要h(n)不大于真实剩余代价A*就一定能找到最短路径。欧氏距离显然是真实路径代价的下界所以正确性有保证。3.2 一个可直接落地的A*实现.NET 6之后自带PriorityQueue写A*比以前省事很多。我给出一段简化但完整的核心代码可以直接抄进项目public static Listlong FindPath( Dictionarylong, RoadNode graph, RoadNode start, RoadNode goal) { var open new PriorityQueueRoadNode, double(); var cameFrom new Dictionarylong, long(); var gScore new Dictionarylong, double(); var fScore new Dictionarylong, double(); open.Enqueue(start, 0); gScore[start.Id] 0; fScore[start.Id] Heuristic(start, goal); while (open.Count 0) { var current open.Dequeue(); if (current.Id goal.Id) return ReconstructPath(cameFrom, current.Id); foreach (var edge in current.Edges) { var tentativeG gScore[current.Id] edge.Weight; if (tentativeG gScore.GetValueOrDefault(edge.BId, double.MaxValue)) { cameFrom[edge.BId] current.Id; gScore[edge.BId] tentativeG; fScore[edge.BId] tentativeG Heuristic(graph[edge.BId], goal); open.Enqueue(graph[edge.BId], fScore[edge.BId]); } } } return null; } static Listlong ReconstructPath(Dictionarylong, long cameFrom, long currentId) { var path new Listlong(); while (cameFrom.ContainsKey(currentId)) { path.Add(currentId); currentId cameFrom[currentId]; } path.Add(currentId); path.Reverse(); return path; }3.3 边权重的设计从长度到通行时间入门版本先用道路长度作为边权重但实际项目里很快会遇到两个问题一是相同长度的两条路一条是主干道一条是拥堵小路选哪条二是单行道怎么办解决办法是把边权重从“长度”改成“通行时间”。每条边除了长度还要存道路等级和方向限制。通行时间等于长度除以该道路等级的平均速度。方向限制则用两个布尔值表示A到B是否允许通行、B到A是否允许通行。双向交通的道路两个都为true单行道只有一个为true。这样A*天然不会规划出逆行的路径而且用户比较两条路线时也更贴近真实驾驶感受。3.4 关于拓扑法和近似单元分解法的常见混淆网上搜索“路径规划拓扑法”时经常会看到“拓扑法是近似单元分解的方法吗”这种问题。这里我想专门解释一下因为涉及到环境建模的概念区分。我的理解是拓扑法是可视图法、Voronoi图法这一类思路的总称核心是把环境抽象成一张拓扑图节点代表关键位置边代表可通行关系然后在拓扑图上搜索路径。近似单元分解法则属于栅格法或单元分解法的分支把连续空间切成近似单元通常是栅格来做规划。两者不是同一种东西拓扑法更强调“关系”单元分解法更强调“空间划分”。本文的路网路径规划本质上是把真实道路网络直接当成一张拓扑图这是拓扑法的应用形态和栅格路径规划的近似单元分解不是一回事。区分清楚这一点后续写避障路径和栅格地图时就不会概念打架。4. 从世界坐标到屏幕像素地图平移缩放与路径绘制的渲染管线路径规划算完只是一堆节点ID真正让用户觉得“好用”的是把路径和地图清晰地画出来并且支持缩放、平移、点选起点终点。Avalonia里没有现成的MapControl我选择自定义控件重写OnRender这是效率最高、可控性最强的做法。4.1 自定义地图控件的核心矩阵变换地图渲染的本质是把世界坐标映射到屏幕坐标。我在控件里维护三个量缩放级别zoom、平移偏移量offsetX和offsetY。每一帧渲染时构建一个变换矩阵protected override void OnRender(DrawingContext context) { var m Matrix.CreateScale(_zoom, _zoom) * Matrix.CreateTranslation(_offsetX, _offsetY); // 绘制底图瓦片 DrawMapTiles(context, m); // 绘制路网 context.DrawGeometry(null, _roadPen, _roadGeometry.Transform(m)); // 绘制路径 if (_pathGeometry ! null) { context.DrawGeometry(null, _pathPen, _pathGeometry.Transform(m)); } }Avalonia的Matrix用法和WPF很像熟悉WPF的人几乎没有学习成本。这里有个关键点不要把每个点单独做坐标转换再画线那样性能会差一个数量级。正确做法是把Geometry整体TransformSkia会在一次绘制调用里完成所有顶点的变换。4.2 瓦片底图的加载与缓存底图我用的是OSM标准瓦片瓦片URL规则是常规的{z}/{x}/{y}格式。为了满足离线和内网部署要求我实现了一个两级缓存内存缓存一个LRU字典磁盘缓存一个按缩放级别分层的目录。用户第一次浏览某块区域时从网络拉取瓦片后续直接从本地磁盘读取。var url $https://tile.openstreetmap.org/{zoom}/{tileX}/{tileY}.png;瓦片调度要放在后台线程做UI线程只负责绘制已经就绪的瓦片。每下载完一张瓦片调用控件的InvalidateVisual触发重绘。这个模型和Web GIS的瓦片加载思路是一致的只是从JS换成了C#这套逻辑我用了很久稳定可靠。4.3 手势交互鼠标和触屏的差异化处理桌面端和安卓端的手势逻辑差异很大。桌面端主要是鼠标滚轮缩放、左键拖拽平移。安卓端则是单指拖拽、双指捏合缩放。Avalonia的Pointer事件在不同平台上有统一抽象但触点的数量需要自己判断。鼠标滚轮缩放我固定在鼠标位置为中心缩放实现方式是缩放后调整平移偏移量保证鼠标下的点不漂移private void OnPointerWheelChanged(object? sender, PointerWheelEventArgs e) { var oldZoom _zoom; var newZoom Math.Clamp(oldZoom * (e.Delta.Y 0 ? 1.2 : 1 / 1.2), 0.5, 20); var mouseX e.GetPosition(this).X; var mouseY e.GetPosition(this).Y; _offsetX mouseX - (mouseX - _offsetX) * (newZoom / oldZoom); _offsetY mouseY - (mouseY - _offsetY) * (newZoom / oldZoom); _zoom newZoom; InvalidateVisual(); }安卓端的双指缩放不能依赖滚轮事件我在OnPointerMoved里同时跟踪两个Pointer的位置变化计算两指间距的比例来更新缩放值。实测下来只要加上一点阻尼效果手感不会比原生地图差太多。4.4 路径和起终点的渲染层级渲染顺序我会严格控制成三层从下往上分别是瓦片底图、路网灰色线、高亮路径和起终点标记。高亮路径用蓝色粗笔线宽固定为3像素不随缩放变化这样缩放时路径始终清晰。起终点用两个圆形标记终点用蓝底白团起点用绿底白团避免用户分不清方向。这里有一个框架细节随缩放保持线宽不变通过DrawGeometry的Pen是无法直接做到的因为Pen会跟着变换矩阵一起缩放。我的处理是每次渲染时根据当前zoom重新创建Pen把线宽除以zoom。这个坑我在最初版本踩过画出来的路径一放大就发虚。5. 三端编译实测Windows、Linux、Android上的踩坑记录框架层面讲完真正让我觉得Avalonia跨平台“没那么简单”的是编译和部署阶段。Windows上跑通后我原以为Linux和Android只是发布目标不同而已结果遇到了好几个平台差异问题这里挑几个印象最深的记录一下。5.1 字体问题中文标签在不同平台的呈现路径规划界面里要显示道路名称和起终点标签。Windows上字体是Microsoft YaHeiLinux上是Noto Sans CJKAndroid上又是系统默认字体。如果只写死一种字体另外两端的文字要么变成方块要么直接不显示。我最终的方案是定义一组字体回退列表通过一个公共类管理public static class FontFamilies { public static readonly string[] MapText { Noto Sans CJK SC, Microsoft YaHei, PingFang SC, sans-serif }; }Avalonia渲染文本时逐个尝试字体族找不到就换下一个。这个回退机制在三种平台下都比较稳妥。5.2 路径规划计算和UI线程地图控件绘制瓦片、路网时如果同时在UI线程跑A算法界面会卡顿到用户以为程序死了。A本身虽然只有几十毫秒但构建Graph和解析GeoJSON却可能要几秒。所以数据加载和路径规划全部放到Task.Run后台线程执行算完再回到UI线程更新控件。var path await Task.Run(() { var graph BuildGraphFromGeoJson(_dataLoader); return PathFinder.FindPath(graph, startNode, goalNode); }); ApplyPathToMap(path);这里特别提醒Avalonia的Dispatcher和WPF类似线程更新控件必须通过Dispatcher.UIThread。在Android上忘记这一步会直接抛异常在Windows上则表现为诡异的渲染错乱。5.3 文件路径和反斜杠的坑跨平台最常见的坑之一就是路径分隔符。Windows用反斜杠Linux和Android用正斜杠。在Android上我曾经直接写“files/road_data/roads.geojson”这个相对路径结果不同平台解析出来的位置完全不一样。我后来统一用环境的专用目录来存放数据不直接写死相对路径var baseDir Environment.GetFolderPath( Environment.SpecialFolder.LocalApplicationData); var dataFile Path.Combine(baseDir, gisdata, road_network.geojson);这样Windows、Linux、Android各自都会解析到合理的用户数据目录也避免了在Linux上写C盘路径的尴尬。5.4 发布裁剪导致GeoJSON解析库失效Android项目为了控制包体积往往开启ILLink裁剪。NetTopologySuite内部用了不少反射默认裁剪模式下会被当成无用代码删掉运行到解析GeoJSON时直接抛MissingMethodException。这个问题在真机崩溃日志里很难找因为异常发生在加载阶段。解决办法是给程序集打上跳过裁剪标记ItemGroup TrimmerRootAssembly IncludeNetTopologySuite / /ItemGroup或者直接在csproj里把整个NetTopologySuite设为TrimmerRootAssembly。这个坑没有在真机上跑过根本发现不了写在这里希望后面的人少走弯路。5.5 三端实测数据我在三台设备上做了基础性能测试路网规模为约6000个节点、8000条边测试路径距离约5公里。设备系统Graph构建耗时A*路径计算耗时帧率拖动地图i5台式机Windows 11约320ms3ms稳定60fpsARM工控机Linux约610ms5ms约40fps中端安卓平板Android 13约720ms6ms约35fpsGraph构建耗时主要花在坐标系转换和节点合并上A*本身在几万节点以下都很快。这个成绩对这个规模的应用完全够用后续如果要接入更大路网就需要做性能优化了。6. 性能优化与方向扩展路网大起来之后怎么办目前的实现能满足中小规模路网的路径规划但GIS项目最怕的就是“数据范围突然变大了”。一旦客户要求全省路网甚至全国路网这套直接加载全量Graph的做法就会触到天花板。这里列几个我已经在规划和验证的优化方向也算给这个系列后续内容埋个伏笔。6.1 路网分块加载与LOD分层和瓦片地图一样路网也可以切成区块。我的思路是把路网按经纬度网格切块每一块单独构建一个小Graph加载时只加载当前视口范围内的块路径规划时把跨块路径拼接起来。这个方案难点在于跨块路径的衔接但收益很大内存占用从全量几个GB降到几百MB。同时可以做LOD分层低缩放级别只显示主干道高缩放级别才显示小路。这不只是减少绘制量也直接减少了参与路径规划的节点数规划速度会快好几倍。6.2 骑乘逻辑预处理加速A*当路网规模达到几十万节点后A即使有启发函数每次规划也要几十甚至上百毫秒。这时可以考虑把A升级为ALT或CH算法。CH的核心思想是预处理阶段给关键节点建立层级关系查询阶段只在子图里搜索查询时间能压到几毫秒以内。代价是预处理时间较长、内存占用更大适合“路网变化不频繁、查询频繁”的业务场景。我个人的建议是不要过早优化。数据量没到阈值前A*完全够用。等真的到了卡顿的地步再上CH改动不会伤筋动骨。6.3 动态避障与实时路径更新热词里还经常看到“动态避障小车路径规划”这和桌面GIS的静态路径规划是两种思路。静态路径规划基于路网Graph动态避障通常基于栅格地图或局部代价地图每帧需要感知障碍物并重新规划。如果要把这套Avalonia应用延伸到机器人或小车方向我的建议是保留现有的图搜索能力做全局路径叠加一个局部动态规划器做避障。两者不是一个算法能覆盖的。这个扩展方向我在后续文章里会单独拆开讲这里先立个flag。6.4 我的实践体会最后分享一点经验GIS路径规划这类项目最难的部分不是Avalonia也不是算法而是如何把坐标系、路网数据、路径算法、地图渲染这四块整合成一个可维护的整体。数据规范化如果做不好算法再优化都白搭。而Avalonia在整个链条里提供的价值是让C#团队能在一个熟悉的语法体系里把这四块逻辑统一打包成三端可运行的产品。这个框架到现在第七十九篇我依然觉得它在跨平台桌面GIS上的潜力被大大低估了。