用 Flutter 构建 OpenHarmony 井盖巡检地图与排班系统-北京尧图网络

最近一段时间我一直在折腾一个挺有意思的项目用 Flutter 给 OpenHarmony 做一套城市井盖地图管理 App顺带把巡检人员的日程排班功能也塞了进去。项目整体跑通之后回头看踩过的坑和做过的取舍我觉得很值得拿出来聊聊。先说这个 App 是干嘛的。市政道路上有大量井盖雨水、污水、电力、通信、燃气各路井盖归属不同部门巡检频率也各不相同。传统的纸质巡检记录效率低、反馈慢井盖丢了破了也很难快速定位责任人。这个 App 要做的就是在地图上把所有井盖的位置、状态、权属信息直观展示出来然后给巡检人员自动排班派单每个人登录后看到自己今天要去哪个网格、检查哪些井盖完成任务就拍照上报状态。这个项目听起来不大但真做起来涉及的细节很碎地图组件在鸿蒙上的适配、大量井盖点位的聚合展示、排班算法的公平性约束、排班结果怎么推送到地图上变成巡检任务。这篇文章会把整个项目的来龙去脉、技术选型、核心实现和踩坑记录完整过一遍。想用 Flutter 切 OpenHarmony 的、想做地图类巡检 App 的、或者只想搞一个能落地的排班引擎的都可以参考着看。1. 项目拆解井盖地图和排班到底在解决什么事1.1 井盖管理的真实痛点城市井盖看起来只是路上的一个圆铁盖实际管理起来非常麻烦。首先是数量大一个小县城都有几万个井盖大城市几十万个靠人工记忆位置根本不现实。其次是权属混乱同一条路上的井盖可能分属几个不同的管线单位出了问题居民举报后台得先查半天这口井归谁管。第三是巡检效率低传统模式是拿着纸质表格一条街一条街排查回來再手工录入系统信息滞后严重。我们把这些问题拆成两个核心功能闭环一是井盖地图解决“这些井盖在哪、什么状态、归谁管”的空间信息问题二是日程排班解决“每天谁去巡哪些区域、按什么周期巡、异常如何快速上报”的任务调度问题。地图是眼睛排班是大脑两个功能配合起来巡检链条就完整了。1.2 为什么用 Flutter 做 OpenHarmony 应用这个项目选型的时候团队内部有过一番讨论。OpenHarmony 生态还在成长期原生应用一般用 ArkTS 开发但项目里大部分同事的技术栈都是前端和 Flutter重新学一整门原生语言成本高而且后面还有可能同步发布 Android 版本。如果两边各维护一套代码地图逻辑、表单逻辑、列表逻辑都要写两遍想想就头大。Flutter 在这类场景下的价值就很明显了一套 Dart 代码UI 层、状态管理、业务逻辑完全复用底部对接的平台引擎负责调用 OpenHarmony 的原生能力。具体到井盖地图这种应用大部分页面其实都是列表、地图标点、表单、状态标签Flutter 画这些东西非常顺手。OpenHarmony 侧目前可以跑社区维护的 Flutter SDK 分支虽然版本更新不是特别快但只要构建流程走通日常开发几乎没有障碍。1.3 排班和地图怎么串成一条线很多类似项目会把排班做成一个独立的考勤工具地图做成一个独立的数据展示工具这是不对的。真正的业务场景里排班的输出必须直接驱动地图上的巡检任务。完整的流转过程是这样的管理员在后台设置排班规则比如每个网格每天需要几个白班巡检员、几个夜班值班员系统自动生成未来一周或一个月的排班表。巡检员登录 App 之后服务端按“人员日期”查到当天的排班任务再把任务关联的井盖点位列表下发到客户端。地图页面收到点位根据状态用不同颜色标注绿色的正常黄色的疑似松动红色的破损或缺失夜班任务还会额外显示照明和路线提醒。巡检员挨个点过去看到异常就拍照上报服务端更新井盖状态同时回写工单。这套链路跑通之后管理者不再需要每天人工问“今天谁值班、巡哪条街、有没有发现异常”打开后台页一眼就能看清当天所有任务的执行情况这个才是排班和地图联动真正的价值。2. 技术选型地图、状态管理、排班引擎怎么配合2.1 地图能力的三条路线怎么选涉及地图的 Flutter 项目第一步一定是决定地图能力从哪来。我们在 OpenHarmony 上对比了三条路线。第一条是直接用 OpenHarmony 系统自带的地图能力通过 PlatformView 把原生地图组件嵌到 Flutter 页面里。优点是和系统结合稳定定位、手势、缩放都是原生体验缺点是要写不少平台桥接代码而且不同设备上原生地图组件和 Flutter 的纹理渲染偶尔有兼容性问题排查起来比较费劲。第二条是接入国内某主流商业地图 SDK 的鸿蒙版本。正常的 Android/iOS 项目用这种 SDK 很方便但鸿蒙版的支持时间普遍不长功能可能缺斤短两。我们在评估阶段发现如果要用商业 SDK光权限适配和隐私合规声明就要处理一大堆而且井盖巡检这种应用主要跑在市政内网环境里对方服务端的地图和定位接口能不能通都是问题。第三条是完全自绘轻量地图层。底图用符合规范的瓦片服务客户端按瓦片行列号拉图并渲染井盖点位直接叠加在 Flutter 的 CustomPaint 或 Stack 上。坐标转换用常见 Web Mercator 公式缩放和拖动自己处理。缺点是工作量多一些但换来的好处是跨端行为完全一致不依赖任何平台组件OpenHarmony、Android、桌面端通吃。我们最后选了第三条自绘轻量地图。原因是井盖巡检场景关注的范围基本集中在城区网格内不需要特别精细的街道级底图用瓦片或简化矢量图完全够用。而且这个选择让排班和地图的联动逻辑可以完全跑在 Dart 层避免过多平台桥接引入的不确定性。注意如果后续预算和团队精力允许可以把地图层抽象成接口内部先接自绘实现之后再切系统地图能力业务层不用改动。2.2 状态管理与数据流设计这个 App 的数据流比较清晰页面之间没有特别复杂的横跳但有两个地方容易乱地图点位状态和排班任务的执行状态。如果不在架构层面约束一下写到最后一定是一堆 setState 和回调满天飞。我采用的是 Riverpod 做状态管理。地图页维护一个“视野内井盖点位”的异步状态排班页维护“当日任务”和“任务执行进度”两个状态。所有服务端数据统一走 Repository 层页面不直接调 ApiClient。比如地图页刷新区块时触发一个 loadManholes(gridId) 异步动作内部按需请求服务端把结果缓存在本地数据库里UI 只监听状态变化。排班引擎生成的结果不放在客户端状态里它属于后台配置数据客户端只拿到“某个人在某天某班次要巡哪些网格”的投影结果。这样做的好处是排班规则怎么调、怎么重新生成客户端完全不需要感知避免把规则逻辑复制到多端。2.3 排班引擎放在哪个环节排班引擎理论上可以放在客户端、服务端甚至放在一个独立工具里。我建议放在服务端客户端只负责展示和执行结果。原因有两点。第一排班是全局优化问题需要看全部人员的连续工作状态、夜班次数、请假记录这些数据只在服务端有完整视图第二排班结果会被多个客户端同时读取如果每个客户端各自生成很容易出现版本不一致。服务端排完班推送下来同一账号在任何设备上看到的任务都一样这个体验很重要。不过排班引擎的核心算法我用纯 Dart 做了原型验证跑通之后再用其他语言搬到服务端或者直接在服务端用对应语言重写。算法逻辑本身不依赖具体平台写文章下面的代码示例我就用 Dart 来讲方便有 Flutter 背景的人直接理解。2.4 数据存储与接口约定客户端本地存储用了 Hive主要缓存两类数据井盖点位的静态信息和已经拉下来的排班任务。因为巡检员经常要跑地下车库、桥洞、城市边角地带网络信号不稳定没有缓存的话地图页会频繁转圈体验很难受。服务端接口按 RESTful JSON 约定核心接口就三个接口方法作用/manholes?gridIdoffsetlimitGET分页获取指定网格的井盖点位/reportPOST上报井盖异常包含状态、照片、位置/tasks/{workerId}?dateGET获取某人某天的排班巡检任务这几个接口能覆盖 90% 的业务场景。更多复杂的统计报表接口可以在后续迭代里再加初期不要急着把接口设计得太花哨跑通闭环比面面俱到重要。3. 核心实现数据模型、地图聚合和排班算法3.1 井盖数据模型要预留多少字段井盖这个对象表面看就是一个经纬度加一个状态但真落库的时候字段比想象的多。我设计了这样一个 Dart 数据模型enum ManholeType { rain, sewage, power, communication, gas } enum ManholeStatus { normal, // 正常 loose, // 松动 damaged, // 破损 missing, // 缺失 underRepair, // 维修中 pending, // 待确认 } class ManholeInfo { final String id; final double latitude; final double longitude; final String address; final ManholeType type; final ManholeStatus status; final String gridId; // 所属管理网格 final String ownerCompany; // 权属单位 final String manager; // 具体责任人 final DateTime lastCheckTime; final int checkCycleDays; // 巡检周期单位天 final String coverModel; // 井盖规格型号 }之所以要把权属单位、责任人和巡检周期都塞进来是因为实际管理时经常要根据“类型权属”过滤点位。比如电力井盖出问题后台要先定位到电力管线单位的区域负责人而不是让市政养护队白跑一趟。这些字段早点设计好后面接管理报表的时候就从容得多。3.2 地图点标和聚合展示策略城市级井盖点位数量是万级别的如果地图初始化时把所有标记点全部画上去Flutter 渲染必然卡顿。最常用的解决方式是视口按需加载加聚合展示聚合的基本逻辑是用 GeoHash 对点位分组。GeoHash 的原理说起来并不复杂把经纬度编码成一串字符串字符串前缀相同的点在地理位置上比较接近。比如取前 4 位作为分组 key地图缩放到城市级时一片区域内几十个井盖会聚成一个簇渲染时只画一个带数字的圆形标记。用户放大两级再把 GeoHash 精度从 4 提升到 6同一个簇里的点就会被进一步拆分直到缩放到街道路口级别时每个井盖都单独显示。class PointAggregator { static MapString, ListManholeInfo groupByGeoHash( ListManholeInfo points, int precision, ) { final result String, ListManholeInfo{}; for (final item in points) { final hash geoHashEncode( item.latitude, item.longitude, precision, ); result.putIfAbsent(hash, () []).add(item); } return result; } }实际渲染时对于分组后数量小于 3 的簇就直接展开成单点标记大于等于 3 的显示聚合圆点。这样既不丢信息也不会出现地图上密密麻麻挤成一团的情况。放大手势结束后重新计算一次分组的耗时很短我在真机上实测过万级点位从原始数据到聚合结果单帧内基本能算完。3.3 日程排班核心算法怎么实现排班这个话题网上能找到的大部分文章都在讲动态规划、整数规划、遗传算法听着很高端但真放到市政巡检这种场景里大部分时候用不到那么重的解法。我们需要处理的约束条件其实很实际每天每个网格需要固定数量的白班和夜班巡检员。每个人不能无限连轴转连续上班上限一般是 5 天。夜班不能让人连续值太多天否则身体扛不住。每个人每周的班次数尽量均衡不能出现有人天天白班、有人全是夜班的情况。我用的方案可以叫“轮转加打分修正”。先生成一个基础轮转表然后逐日检查每组班次的需求名额给候选人员打分优先选择当前约束下得分最高的人选。打分的时候主要看这几个负向指标昨天刚值过夜班且今天又排夜班扣 30 分连续工作已经达到 5 天扣 50 分这周累计夜班次数偏多扣 20 分。从候选池里选得分最高的填进槽位同时把选中人员的连续工作计数加一。double scoreCandidate( String worker, bool isNightShift, MapString, int workStreak, MapString, int nightCount, ) { var score 100.0; if (isNightShift) { final count nightCount[worker] ?? 0; score - count * 12; if (workStreak[worker] previousNightWorker) { score - 30; } } if ((workStreak[worker] ?? 0) 5) { score - 50; } return score; }这个方案不是数学上最优但工程上非常稳。排班结果生成之后我再跑一遍全量校验函数检查同一个人是否在同一时间段被分配了两个任务、每天人数是否达标、连续工作是否超限任何一个校验失败就自动触发局部规则调整。生产中我建议你也别省掉这一步因为人工微调排班表之后非常容易引入冲突光靠生成器保证是不够的。排班规则的配置参数做成模板下发比如白班人数、夜班人数、周期天数、连续上班上限管理员在后台改完重新生成即可客户端完全不用发版。3.4 排班结果与地图任务的联动展示排班表和井盖地图之间需要一个中间结构来串联这就是巡检任务。排班引擎生成的是“谁在哪天值什么班”业务侧把它加工成“这个班次要巡哪些网格、哪些井盖”然后下发给客户端。服务端联动的伪逻辑大概是先取某网格下所有井盖点位按巡检周期过滤出当天需要检查的井盖列表以网格为单位生成初始任务模板再根据排班表把模板分配给具体人员。比如一个网格有 300 个井盖其中 60 个处于“近期需要检查”状态当天排到这个网格的白班巡检员就会被分配到覆盖这些点位的任务。客户端收到任务列表后在地图上把任务关联的井盖点高亮显示同时显示一个简短的统计条本网格任务井盖 60 个已检查 23 个异常上报 2 个。巡检员每点开一个井盖打卡一次状态同步更新到任务进度里。这个联动设计让排班不再是后台的一张死表格而是真正驱动现场作业的可视化任务流。4. 实操记录环境搭建到关键代码落地4.1 OpenHarmony 环境准备与工程初始化在 OpenHarmony 上跑 Flutter第一步就是安装鸿蒙应用开发所需的 IDE 和 SDK然后配置 Flutter 的 OpenHarmony 适配分支。这里最容易踩的坑是版本匹配适配分支的版本号要跟 IDE 工具链版本对得上否则编译时刻会报一堆原生代码错误。建议先用一个空工程把构建链路跑通再开始往里填业务代码。初始化工程的时候Flutter 工具链会生成标准的 lib 目录同时生成一个鸿蒙侧的原生工程目录这个目录里包含了应用安装所需的打包配置。日常开发主要还是在 lib 下写 Dart只有需要调用原生定位、相机等能力时才去动原生目录。权限配置是绕不开的一步。井盖地图至少要两个权限网络权限和定位权限。在鸿蒙侧需要在模块配置里声明对应的权限条目否则运行时申请会被直接拒绝。定位权限尤其要注意鸿蒙的定位权限分模糊定位和精确定位巡检场景必须申请精确定位否则井盖经纬度偏差过大地图标点会飘。4.2 地图页面搭建与定位接入自绘地图页面的核心是一个可拖拽缩放的视口容器。底图用瓦片图片铺满井盖点位根据当前视觉坐标换算成屏幕坐标再渲染成标记组件。核心换算逻辑是标准 Web Mercator 公式Offset latLngToScreenPoint( double latitude, double longitude, double zoom, Offset viewportCenter, double tileSize, ) { final x (longitude 180) / 360; final sinLat sin(latitude * pi / 180); final y 0.5 - log((1 sinLat) / (1 - sinLat)) / (4 * pi); final scale tileSize * pow(2, zoom); return Offset(x * scale - viewportCenter.dx, y * scale - viewportCenter.dy); }这个过程不需要额外引入地图 SDK只要拿到瓦片数据源就行。瓦片数据如果来自商业服务注意看授权范围是不是允许在政务内网使用如果是内部自建的瓦片服务直接把服务地址配到环境变量里就可以。定位能力我建议通过 MethodChannel 调用鸿蒙原生定位因为不是所有 Flutter 定位插件都针对 OpenHarmony 做了适配。Flutter 侧只维护一个统一的定位接口App 启动时检查权限权限通过后调用原生方法拿坐标再把坐标放到地图视口正中。4.3 排班引擎关键代码示例排班引擎不建议写成一个巨大无比的类我习惯把它拆成三块模板配置、生成器、校验器。下面是一个简化但能体现完整思路的生成器结构class ShiftAssignment { final String date; final String shiftName; final ListString workerIds; const ShiftAssignment(this.date, this.shiftName, this.workerIds); } class RotationScheduler { final ListString workers; final MapString, int dailyShiftConfig; // shiftName - requiredCount final int cycleDays; ListShiftAssignment generate() { final assignments ShiftAssignment[]; for (var day 0; day cycleDays; day) { // 用日期偏移做基础轮转保证同一个人不会连续多天卡在深夜班 final baseOffset day % workers.length; for (final entry in dailyShiftConfig.entries) { assignments.add(ShiftAssignment( day$day, entry.key, picksByScoring(day, baseOffset, entry.key, entry.value), )); } } return assignments; } ListString picksByScoring( int day, int baseOffset, String shiftName, int requiredCount, ) { // 按打分规则挑选 requiredCount 个人 // 细节略核心是通过约束参数调整每个人的优先级 return []; } }生成器跑完校验器马上跟进。校验器里至少要有这几个检查项同一班次人数是否满足、同一时间段同一人员是否重复、连续工作天数是否超过上限、夜班组是否连续排了太多次。校验不通过就局部重排重排次数限制在 3 次以内如果仍然冲突再抛出一个明确的异常让管理员去人工调整不要让系统悄悄生成一份有问题的排班表。void validateSchedule(ListShiftAssignment assignments) { final workerTimeMap String, ListString{}; for (final assignment in assignments) { for (final worker in assignment.workerIds) { workerTimeMap.putIfAbsent(worker, () []).add( ${assignment.date}-${assignment.shiftName}, ); } } for (final entry in workerTimeMap.entries) { if (entry.value.length ! entry.value.toSet().length) { throw StateError(排班冲突${entry.key} 在同一时间段被分配了多次); } } }排班结果存储和服务端同步就简单了直接按人员 ID 加日期维度生成任务索引。客户端每天第一次打开 App 时拉取一次当日任务后续刷新依赖下拉手势和进入地图页的路径刷新即可。5. 踩坑实录地图适配、排班冲突和性能优化5.1 鸿蒙适配类问题这个项目里最折磨人的适配问题出现在地图图层和 Flutter 页面叠加的阶段。最开始我想用原生地图组件通过 PlatformView 嵌套结果在 OpenHarmony 真机上出现两种现象一种是地图区域黑屏组件加载不出来另一种是地图能显示但 Flutter 侧弹出的浮层会被原生地图盖住遮挡非常严重。后来换回自绘方案之后这类问题再也没出现因为所有内容都是 Flutter 自身绘制的不存在原生 View 和 Flutter View 的层级竞争。如果你坚持要用系统地图能力我的建议是少做复杂的图层叠加地图尽量铺满整个页面操作按钮放在地图之外避开层级冲突。定位权限在鸿蒙上也容易出问题。有的设备系统版本对权限管理更严格用户在设置里如果只给了模糊定位授权App 拿到的坐标精度会明显下降地图标点和真实位置能偏出去几百米。上线前一定要把“模糊定位”和“精确定位”这两种授权状态分开测试我在测试阶段就被这种偏移坑过好几次。5.2 排班冲突与数据同步问题排班冲突最常见的情况是人工调班之后没有重新跑校验。管理员想把周一的夜班从老张换成小李直接改数据库记录但是小李周一原本已经有一个白班任务系统没有任何提示。客户端把两个任务都拉了下来排班引擎在对账检查时才暴露冲突这时候已经影响到当天巡检了。解决办法很简单所有排班修改必须走同一个带有校验逻辑的接口禁止直接改库。夜班跨天问题也容易被忽略。夜班如果从晚上 17 点到凌晨 1 点跨过了自然日不能直接按排班日期判断任务归属。我的做法是任务模型里用两个时间字段来标记实际起止时间而“排班日期”只作为业务归属维度这样统计月度工时时能算准确同时客户端也不会出现凌晨任务消失的情况。5.3 性能与发布注意事项地图页面性能优化主要做三件事按视口加载、点位聚合、瓦片缓存。按视口加载就是只请求当前屏幕矩形范围内的井盖点位拖动结束再补数据点位聚合前面已经讲过瓦片缓存则是把下载过的瓦片存入本地下次打开直接走磁盘缓存离线也能看到基础底图。HAP 包体积也是一个值得关注的发布问题。Flutter 引擎本身会给包体增加不少体积如果再把瓦片包、离线数据塞进去HAP 很容易变得非常臃肿。我建议离线瓦片按网格按需下载不要试图把所有城区的瓦片都打进安装包。初次启动引导用户下载所在城区的离线包之后增量更新安装包能控制在合理范围内。还有一个发布细节OpenHarmony 的签名和权限声明比传统 Android 要严谨一些。打包之前把所有权限的使用场景写清楚尤其是定位权限、网络权限和相机权限不然审核和真机安装阶段容易被拦下来。我在第一次打正式包的时候因为相机权限声明不合规导致安装后上报功能不可用排查了半天才发现是声明问题。写在项目结束后这个项目做完我个人的体会是用 Flutter 切入 OpenHarmony 生态是完全可行的前提是不要把平台能力绑定得太死。地图这个大块头对于市政巡检这类场景自绘轻量地图反而是更稳的选择跨端一致性强、不依赖第三方服务、离线好做唯一的成本是需要投入时间处理瓦片计算和手势。日程排班这块别一开始就上复杂优化算法先明确业务约束用轮转加打分把流程跑通再加上全量校验兜底比任何花哨的模型都实在。最后再分享一个小技巧在鸿蒙上调试这类带定位和网络请求的 App尽量别在模拟器上验证很多传感器行为和真机差异很大。有条件直接上真机一次性能暴露一半以上的兼容性问题能省下大量排查时间。如果你也正在做 OpenHarmony 上的 Flutter 地图或排班类项目希望这篇记录能帮你少走几步弯路。

用 Flutter 构建 OpenHarmony 井盖巡检地图与排班系统

相关推荐

生产级大模型私有化部署全链路指南：从显存规划到高可用架构

Docker部署phpipam：开源IPAM工具实现高效IP地址管理

JS逆向实战：破解VMP保护的Sign参数生成逻辑

更多资讯

Drummond Group AS2认证EDI产品选型避坑指南

链表合并：非递减有序链表的原地归并实现

Spring Boot 3.x 整合 Elasticsearch 8.x：客户端迁移与搜索实践

AI越聪明，人类越忙？被忽视的“验证税”正在吞噬效率

MATLAB逆傅里叶变换ifft实战：归一化、频率排列与单双边谱处理

SpringBoot+Vue实验报告管理系统：从部署到二次开发全流程实战

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？