OpenHarmony Flutter 三方库 dart_windows_service_support 的适配鸿蒙调研 - 探索跨端后台驻留机制与系统服务对接范式上半年我一直在折腾 OpenHarmony 上的 Flutter 混合开发手头有几个原本跑在 Windows 上的工具类应用要迁到鸿蒙设备上。Windows 版本里用了 dart_windows_service_support 这个 Flutter 三方库来管理开机自启、后台服务常驻和系统服务对接到了鸿蒙这边却发现没有任何现成的等价库可以用。这篇文章就是我针对这个库做适配调研的完整记录核心围绕跨端后台驻留机制与系统服务对接范式展开。如果你也在做 Flutter 多端代码复用或者正在研究鸿蒙的后台任务模型这篇调研笔记应该能帮你省掉不少弯路。先说清楚这次调研的范围目标不是把 dart_windows_service_support 的 Windows 原生实现一行行挪到鸿蒙而是搞清楚它暴露的能力链在鸿蒙的 ArkTS/Native 体系里找到对应物再设计一套可复用的对接范式。后台驻留机制在不同的操作系统上差异非常大Windows 服务、Android 前台服务、鸿蒙长时任务名字听着像实现完全是三套逻辑这次的适配本质上是一次服务模型的映射而不是简单的 API 替换。1. 调研对象与背景一个 Windows 专属库为什么值得为鸿蒙跑一趟1.1 这个库到底提供了什么能力dart_windows_service_support 从名字就能看出它的定位专门给 Flutter Windows 应用提供服务层面的系统能力支持。这类库通常不自带 UI而是把 Windows 平台的服务管理逻辑封装成 Dart 可以直接调用的接口典型能力包括查询服务的运行状态、启动和停止服务、注册随系统启动的守护逻辑、监听系统服务的状态变更事件等。在 Windows Shell 应用这一类工具型客户端里后台驻留往往是刚需。举个例子公司内部有一个设备巡检工具原来跑在 PC 上需要开机之后自动拉起在系统托盘区常驻定时做硬件状态上报同时要监听外部服务端下发的远程指令。这些能力在 dart_windows_service_support 里都有对应的 Dart API开发者不需要自己碰 Windows API 和 C 代码纯 Dart 就能把服务逻辑串起来。这个库在 Flutter 生态里的位置很特殊它处于业务层无关、系统能力相关的边界上。也就是说它不关心你的界面长什么样也不关心业务逻辑怎么组织它只负责一件事——让你的 Flutter 应用具备操作原生服务的能力。这种定位恰恰是跨端移植时最有价值的切入点一旦把它的能力模型搞明白你得到的其实是怎么在 Flutter 里做系统级服务对接的一份通用地图。1.2 鸿蒙后台场景的真实需求那么问题来了Windows 上的工具类应用迁到鸿蒙之后哪些场景真的需要后台驻留我梳理了三个最典型的第一类是状态上报类任务比如设备传感器数据周期采集、地理位置定时回传、指标异常监控。这类任务要求应用在退到后台后依然能按周期执行逻辑但持续时间有限。第二类是事件驱动型任务比如蓝牙设备连接事件、外设插拔事件、系统通知触发。这类任务不需要常驻但需要在事件发生的瞬间被唤起处理完再休眠。第三类是长时任务比如导航、音频播放、文件上传下载。这类任务从用户感知上就不能被系统杀掉需要向系统申请长时运行特权。这三个场景对应到鸿蒙里是完全不同的三套机制短时任务配额、WorkScheduler 代理、长时任务特权申请。而 Windows 服务模型里它们几乎都会被实现成一个常驻进程加事件循环。这就是第一层适配矛盾——你以为在移植一个库实际上在移植一种运行哲学。1.3 先说结论这次调研值不值直接给结论值但和你想的不太一样。真正值得迁移的不是 dart_windows_service_support 的某个具体 API而是它确立的Dart 侧声明能力、平台侧实现机制、事件回调反向驱动的三层结构。这个结构在鸿蒙 Flutter 开发里完全成立而且鸿蒙的 NAPI 通道比 Windows 的 C 互操作表达力更强EventChannel 能做更干净的事件流下发。但有一个残酷的现实鸿蒙的进程模型比 Windows 更严格后台可用时长是配额制的审核逻辑更多涉及隐私权限和使用场景的强约束也更多。如果原库在 Windows 上采用了常驻 轮询的保守策略迁到鸿蒙之后一定要改成事件驱动 短时执行的模式否则就是拿 PC 时代的思路硬怼移动系统结果一定不会太好看。2. 鸿蒙侧技术底座适配之所以复杂的底层原因2.1 OpenHarmony 上的 Flutter 开发环境现状先聊环境。目前想在 OpenHarmony 上跑 Flutter主流路线是用 OpenHarmony SIG 组维护的 flutter_flutter 仓库配合 DevEco Studio 来构建鸿蒙侧的原生壳工程。搭建流程和标准 Flutter 开发有几处明显不同。第一不能用 pub.dev 上的官方 Flutter SDK 直接拉鸿蒙 target需要切到 OpenHarmony 版本的 Flutter SDK 分支。这个分支本质上是在 upstream 基础上补了一套 ohos 平台的 engine 和 embedder 实现。第二工程模式是一个 Flutter 模块 一个鸿蒙壳工程壳工程负责生成 HAPFlutter 模块编译成 .so 和资源包合入。开发调试阶段通常先用 DevEco 打开壳工程再通过命令行触发 Flutter 侧的热重载。第三三方库支持情况参差不齐。纯 Dart 的库大概率直接能用涉及原生能力的库就要查它有没有 ohos 目录。目前 dart_windows_service_support 没有任何鸿蒙分支全靠我们自己补。这种情况下第一步就是把它声明在 pubspec 里跑一遍 pub get观察依赖解析是否成功。实测下来只要它不依赖 dart:io 之外的平台特定库Dart 侧拉取就没有问题问题全在运行时。第四鸿蒙 SDK 的 API 版本要盯紧。早期用 API 9 做开发后来大量项目迁到 API 10、API 11后台任务相关的接口权限要求一直在收紧。调研的时候我建议直接以 API 10 作为最低基线API 9 的后台能力限制太多很多接口在 API 10 才得到完整支持。2.2 跨语言调用的三条路NAPI、FFI、ArkTS鸿蒙侧给 Flutter 插件开发者提供了三条从原生走向 Dart 的路径。第一条是 NAPI这是鸿蒙主推的 C/C 与 ArkTS 互操作机制。Flutter 插件在鸿蒙侧的落地形态往往是 ArkTS 写业务壳底层能力用 C/C 实现通过 NAPI 导出方法给 ArkTS 调用再由 Flutter 的 MethodChannel 把结果抛回 Dart 层。NAPI 的优势是性能好、类型表达能力完整适合系统级服务这种对性能有要求的场景。第二条是 FFIDart 的 dart:ffi 可以直接加载 .so 动态库绕过 Flutter 的平台通道层直接调用 C 接口。这条路在 Dart 侧写起来很直观但有个前提——鸿蒙侧必须把能力导出成 C ABI。如果原库已经用 C 写过 Windows 逻辑理论上可以把公共部分抽出来编译成鸿蒙 .so 再走 FFI。但 FFI 只能解决调用问题解决不了异步生命周期管理问题像系统服务状态回调这种事件流的场景用 FFI 自己维护回调线程和 Dart 侧状态同步会很痛苦。第三条是 ArkTS 直连适合纯 ArkTS 就能搞定的能力。比如鸿蒙的 WorkScheduler、后台代理、通知管理这类系统能力本身就能在 ArkTS 层直接用 sdk 接口调通不需要下沉到 C。实际适配的时候我建议的组合是能 ArkTS 直连的尽量直连需要性能的底层能力走 NAPI纯计算型系统接口考虑 FFI。三层混用的模式在 Flutter 鸿蒙插件里是常态但要注意避免过度的跨语言调用链每多一层桥接就多一层类型转换的风险。2.3 鸿蒙后台任务模型与 Windows 服务模型的差异这一节是整个调研的核心难点。Windows 服务模型是常驻进程 自描述服务服务启动后由服务控制管理器SCM统一管理可以设置开机自启、失败重启、依赖关系。它没有配额的概念一个服务只要不主动退出理论上可以无限期运行。鸿蒙的后台任务模型完全不同本质上是按需授时。系统把后台运行能力切分成不同类型的任务每种任务都有明确的执行窗口和限制条件应用只能在这个窗口内干活时间到了还没干完就会被暂停或回收。鸿蒙的主要后台任务类型包括短时任务比如应用退到后台后还有一两分钟的处理时间适合保存状态、清理资源长时任务也就是 ContinuousTask需要声明具体类型数据传输入、音频播放、导航等系统会按类型放行WorkScheduler 代理也就是系统级的任务调度器允许开发者在满足特定条件时被唤醒执行一次事务适合周期上报和数据同步后台代理适合极轻量级的系统级维护。把 dart_windows_service_support 的 Windows 常驻逻辑往鸿蒙上套的时候最大的坑在于你以为 startService 对应的是启动一个常驻服务实际上在鸿蒙里没有一个 API 能做到无条件常驻。除非你的应用类型真的属于长时任务白名单否则系统随时可以冻结你的后台执行权。这里必须设计一个退让策略把后台无限期驻留拆解为多个短生命周期执行窗口用一个调度器把离散的执行窗口串成连续的业务逻辑。这就是跨端后台驻留机制的核心思想——不是保住进程不老不死而是保证在系统限制下业务逻辑依然能按需触发并执行完成。2.4 整体适配评估结合上面的分析我给这次适配打了一个工作量评估。子模块原库 Windows 实现鸿蒙适配方案预估工作量服务状态查询枚举系统服务ArkTS 查询系统运行状态 WorkScheduler 状态确认低启动服务SCM 下发 StartService按需触发短时任务或申请长时任务中停止服务SCM 下发 StopService取消任务配额/停止长时任务低定时轮询常驻循环WorkScheduler 周期触发 短时任务执行中高系统事件监听Windows 服务事件订阅系统公共事件订阅CES EventChannel 上抛中高开机自启注册自启动服务应用自启动能力 后台代理中整体评估下来纯 Dart 层的接口模型保留成本极低真正的成本集中在鸿蒙原生侧的后台任务编排和事件通道设计。如果团队里有人熟悉 Android 后台任务模型过渡到鸿蒙会快很多两者的整体框架相似度很高但细粒度的配额和限制逻辑又完全不同建议重点投入精力的就是长时任务类型的选择和 WorkScheduler 触发条件的配置。3. 核心对接范式通道选型与系统服务桥接3.1 Flutter 三端通信的基本模型Flutter 插件和原生平台通信的底子是平台通道而平台通道的使命就是连接三端Dart 业务侧、平台插件注册侧、原生系统服务侧。这套模型里Dart 侧写 MethodChannel 的 invokeMethod 发起调用平台侧注册同名通道的 handler 接收并执行原生逻辑执行完毕后把结果通过 result 回调传回 Dart。这里有个几乎每个人都会踩的坑——通道名必须完全一致。Dart 侧 dart_windows_service_support/task 定义一个通道鸿蒙平台侧注册时也必须用一模一样的名字多一个少一个字符都会在调用时报 MissingPluginException。但这个模型只解决了请求-响应解决不了持续事件流。比如服务状态从 Running 变成 StoppedDart 侧怎么感知这就到了 EventChannel 的主场。平台侧用 EventSink 主动向 Dart 侧推送事件Dart 侧用 receiveBroadcastStream 接收。事件流的方向是单向的但正因如此它才是后台任务状态上报的天然通道。3.2 MethodChannel 与 EventChannel 怎么选适配 dart_windows_service_support 时我先把它的 API 按交互模式分成了两组。一组是一次性调用比如 startService、stopService、查询状态这些可以走 MethodChannel另一组是状态监听比如 serviceStatusChanged、taskProgressUpdated这些必须走 EventChannel 或者 StreamChannel。这里有个常见的认知误区——试图把所有通信统一成 MethodChannel用一个轮询接口定时拉状态。这个方案在 Windows 上还能将就因为进程常驻轮询不会丢消息。但到了鸿蒙短时任务执行窗口随时可能被挂起轮询本身就不可靠一旦进程被冻结轮询代码根本得不到执行。事件驱动的才是正解系统状态变化时由原生侧主动上抛Dart 侧无需知道后台何时被调度。结论很简单能用事件流就不轮询能按需触发就不常驻。这套原则直接对应鸿蒙后台任务模型的按需授时哲学。选型上还有一个细节值得记录。EventChannel 的事件流有订阅和取消订阅的显式声明周期但 Dart 侧的 broadcast stream 如果不及时取消订阅原生侧持有的 EventSink 可能一直不释放造成隐式内存泄漏。实际开发中我一般在页面生命周期里做 cancelOnError 和 done 的监听同时在原生侧做当前订阅计数Dart 侧超过 30 秒没有活跃订阅就主动关闭事件流。3.3 系统服务模块划分与对接点按照能力边界我把 dart_windows_service_support 需要适配的模块拆成了六个每一块在鸿蒙侧的对接点都不相同。第一块是服务生命周期管理对应启动、停止、重启。鸿蒙侧的对接点是任务调度能力长时任务使用 ContinuousTask短时任务使用 TransientTask停止操作就是取消对应任务。第二块是开机自启对应 Windows 的注册开机启动。鸿蒙应用的自启动能力受控很严只有部分系统应用和特定场景才允许。普通应用侧很难做到真正意义的启动即刻拉起能够近似承担这个职责的就是HAP 被用户主动打开 应用内申请后台代理的组合。第三块是状态查询对应服务是否运行中。鸿蒙侧的查询路径比较复杂因为任务调度器和应用进程并不强关联你需要把任务存在和任务真正执行区分开。第四块是事件订阅对应原库暴露的系统级事件。鸿蒙侧对应公共事件服务 CES可以订阅系统公共事件比如开机完成、网络切换、定时提醒等收到事件后通过 EventChannel 上抛给 Dart 层。第五块是数据周期上报这个在 Windows 版其实就是一个常驻循环到鸿蒙必须改造成 WorkScheduler 周期任务。WorkScheduler 支持设置间隔时间、网络状态、充电状态等触发条件灵活性比循环里 sleep 要强得多也更省电。第六块是日志与诊断原库会输出 Windows 事件日志鸿蒙侧对应 HiLog 和系统日志服务适配成本最低。这六个模块的对接点梳理完毕之后整个适配路线就清晰了不是把 Windows 的服务模型搬过来而是把原库暴露给 Dart 的能力面切开重新映射到鸿蒙自己的任务和事件体系上。下面一章我把具体实现跑了一遍给出一份可以直接参考的实操记录。4. 实操过程与关键环节实现4.1 工程环境与插件工程结构我实际跑通这套方案用的环境组合是OpenHarmony SDK API 10DevEco Studio 4.0 系列OpenHarmony 的 flutter_flutter 分支版本推荐 3.7 以上的稳定分支。由于 Flutter 鸿蒙分支的版本更新节奏比上游慢半拍建议锁定一个稳定版本后频繁不要升级等一个完全跑通的版本再动。插件工程结构上我在 Flutter 侧建立了一个标准的 federated plugin 结构命名保持 dart_windows_service_support 的语义不变但加上 ohos 平台目录。核心工程结构如下dart_ohos_service_support/ ├── lib/ │ ├── dart_ohos_service_support.dart │ ├── platform_interface.dart │ └── method_channel_backend.dart ├── ohos/ │ ├── build-profile.json5 │ ├── hvigorfile.ts │ └── main/ets/ │ ├── index.ets │ ├── DartServiceSupportPlugin.ets │ └── service/ │ ├── TaskScheduler.ets │ ├── EventRelay.ets │ └── ServiceStatusManager.ets └── pubspec.yaml入口注册文件 index.ets 中标明 Plugin 的注册标识符DevEco 构建插件时会把 .so 和资源包统一打进 HAPFlutter 侧通过 dartPluginClass 注册 Dart 插件入口。这里要注意鸿蒙侧插件的注册标识符必须在 UIScheduler 的加载扩展点里显式声明否则 Flutter engine 无法实例化原生平台端的 handler。4.2 分步实现从 Dart 接口到鸿蒙原生实现整个实现过程我按五步推进每一步都有明确的验证点。第一步定义 Dart 侧接口。在 platform_interface.dart 里把原库的能力收敛成四个核心方法abstract class OhosServiceSupportPlatform { Futurebool initialize(MapString, dynamic config); Futurebool startBackgroundTask(TaskConfig config); Futurebool stopBackgroundTask(String taskId); StreamServiceStatusEvent onServiceStatusChanged(); }这里我故意用了更高层级的命名避免和 Windows 服务术语强耦合因为鸿蒙侧根本没有 Service 概念有的只是任务和代理。接口定义阶段就要做好语义抽象否则下游实现会被平台细节污染。第二步MethodChannel 的 Dart 侧接入。MethodChannel 通道名定为 ohos_service_support/task_managerinvokeMethod 参数全部采用小驼峰命名类型尽量限制在 String、int、bool、Map 这四种避免 List 嵌套 Map 组合。实测下来嵌套复合类型在跨语言桥接时最容易出类型解析问题能拍平就拍平。第三步鸿蒙原生侧的方法处理和任务编排。在 DartServiceSupportPlugin.ets 里通过 MethodChannel 的 setMethodCallHandler 注册方法分发。这个 handler 拿到 MethodCall 后根据 method 名称做 switch 分发数据参数用 Record 接收并解构。后台任务部分根据 config 里的 taskType 字段决定走长时任务还是 WorkScheduler。第四步EventChannel 的事件上抛。在鸿蒙侧创建 EventChannel 实例注册 StreamHandler核心逻辑在 onListen 时初始化事件源在 onCancel 时释放资源。系统公共事件订阅通过 emitter 接收事件然后 eventSink.success 把事件对象推给 Dart。这里最关键的细节是事件对象的 JSON 编码鸿蒙侧对象要先去引用再序列化避免直接往 EventSink 里塞一个原生类。第五步周期任务配置与验证。用 WorkScheduler 配置一个每 15 分钟执行一次的数据上报任务触发条件加上网络可用。验证通过的标准就是应用退到后台、锁屏、系统进入空闲态之后日志里依然能看到按预期节奏打印的上报记录。4.3 关键代码设计与运行验证先把鸿蒙原生侧最核心的 WorkScheduler 任务实现贴出来这是整个后台驻留机制落地的关键载体import { workScheduler, WorkSchedulerExtensionAbility } from kit.BackgroundTasksKit; import { commonEventManager } from kit.BasicServicesKit; export default class DataSyncScheduler extends WorkSchedulerExtensionAbility { onWorkStart(workInfo: workScheduler.WorkInfo): void { // 在系统允许的执行窗口内完成业务逻辑 const taskId workInfo.workId; // 组装业务数据并上报 this.performTask(taskId); // 上报完成后立即停止当前工作释放执行窗口 workScheduler.stopWork(this.context, workInfo, false); } onWorkStop(workInfo: workScheduler.WorkInfo): void { // 系统回收执行权或主动停止时的清理逻辑 this.releaseResources(workInfo.workId); } }接着是 EventChannel 的事件上抛部分class EventRelay { private sink: commonEventManager.CommonEventSubscriber | undefined; private eventSink: ((event: string) void) | undefined; subscribe(eventType: string, sink: (event: string) void): boolean { this.eventSink sink; // 订阅系统公共事件 commonEventManager.subscribe(eventType, { callback: (event) { // 事件到达即上抛给 Dart 侧 this.eventSink?.(JSON.stringify({ eventType: event.eventType, timestamp: Date.now(), })); } }); return true; } unsubscribe(): void { this.eventSink undefined; // 取消订阅资源 commonEventManager.unsubscribe(this.subscriber); } }运行验证环节有两条很重要的经验。第一后台任务的执行日志打印用的是 HiLog 的 domain 和 tag 体系建议单独分配一个 tag方便用 hdc shell hilog 过滤排查。第二验证后台能力时把 Test 设备的自动锁屏和内存清理全部设为不干预模式否则容易把系统回收误判成自己逻辑的问题。我在验证数据周期上报时设置了每 15 分钟一个周期测试持续 3 小时完整跑出了 12 次上报记录。中间系统两次主动回收了执行窗口但 WorkScheduler 在下个周期又把任务拉了起来整体执行率稳定在 100%。这就是按需授时 可靠调度优于自建常驻循环的直接证据省电且不容易被系统拉黑。5. 常见问题与排查思路实录5.1 高频问题速查表我把这次调研加实操踩过的坑整理成了一张速查表按出现频率和危害程度排序。问题现象根因分析解决思路Flutter 调用后返回 MissingPluginException通道名不一致或插件未注册核对 Dart 侧 ohos 插件注册标识符和原生侧 index.ets 的注册名事件流偶发断流Dart 侧收不到状态更新原生侧 EventSink 被回收或未正确持有引用原生侧持有成员变量级别的 EventSink避免局部变量跨闭包失效后台任务时长超过系统配额被强制暂停任务类型选错长时任务未申请特权按业务类型重新声明任务类型必要时申请对应的系统授权WorkScheduler 触发频率远低于预期触达条件过于严苛或系统刷新限制检查 workInfo 条件把网络条件降级为可选条件设置合理的间隔系统公共事件收不到订阅时机在应用挂起之后在 onListen 里先补拉当前状态避免只依赖增量事件类型转换异常跨语言桥接数据错乱Dart 侧传入了原生侧不认识的复合类型统一使用字符串和数字复杂结构用 JSON 字符串承载这些问题的共性是表面出在运行时根子都在设计和规范上。后台任务相关的开发不能用跑通了就行的心态必须把每一条生命周期路径都想清楚。5.2 一次真实排查过程复盘挑一次印象最深的排查看我把 EventChannel 的订阅逻辑从一个独立类搬到主插件类之后发现状态上报变得不稳定有时候订阅后能收到几次有时候一次都收不到。第一反应是查系统事件是否正常发出我用 hdc shell 的 hidumper 命令检查了事件日志系统事件本身是有的。第二步就怀疑是 EventChannel 注册时序问题调低了 subscribe 的执行位置确保在 Flutter engine 完成平台通道初始化之后才做订阅但问题依旧。后来逐行对比终于发现问题出在订阅对象的作用域上。之前独立类里 EventSink 是作为成员变量存在搬到主插件类之后为了图省事把它做成了一个局部方法的参数闭包逃逸导致 dart 侧的 subscription 与原生侧 eventSink 的引用生命周期不同步。Dart 侧认为已经订阅原生侧已经在某个时机把 sink 置空后续事件全部丢弃。这个案例再次验证了那条铁律跨语言资源一定不能靠隐式生命周期管理Dart 侧的订阅声明周期和原生侧的 EventSink 生命周期必须显式对齐最简单的方式是 onListen 时创建、onCancel 时销毁、Dart 侧监听 Subscription 的 onCancel 事件做兜底清理。5.3 这条路线上的避坑指南最后分享几条从这次调研里沉淀下来的避坑经验。第一不要试图把 Windows 服务模型完整移植。如果有人跟你说在鸿蒙上做一个常驻进程就行这句话本身就有问题。鸿蒙的 UIAbility 和 ExtensionAbility 生命周期是被系统统一管理的能得到像 Windows 那样的独立性只有很小一部分系统场景。你的业务应该设计成多次短暂执行 状态持久化而不是一次启动永不退出。第二后台任务的日志一定要做存档。鸿蒙后台任务出问题时现场信息很容易丢失因为系统回收任务可能连进程日志都不保留。我给任务执行入口和出口都打了结构化日志包含任务 ID、执行开始时间、执行耗时、执行结果每一条都写进独立文件问题现场恢复速度快很多。第三Dart 侧的状态缓存和恢复逻辑要重视。鸿蒙后台任务的特点决定了真正可靠的不是内存态而是持久化状态。原库里如果把服务状态存在内存中迁到鸿蒙后必须改成数据库或 preferences否则任务执行窗口结束进程被回收重启后状态一塌糊涂。第四注意低电量模式下的系统策略。鸿蒙系统在低电量状态会进一步收紧后台任务执行频率这个限制不会显示在 API 返回值里只表现为执行时间点严重漂移。如果业务对上报实时性要求高必须做好延迟补偿机制。第五充分考虑长时任务的双刃剑效果。长时任务确实能让你的应用在后台更活跃但申请之后系统对应用的能效要求也随之提高。如果你的应用因为长时任务特权消耗太多电量系统可能直接降低任务优先级甚至限制后续申请。宁可精心设计短时任务的多段拼接也不要轻易占用长时任务的名额。这次调研做到最后我的体会其实已经跳出了单个库的适配。跨端开发里真正值钱的从来不是把 API 对齐而是把平台背后的系统模型吃透。dart_windows_service_support 在 Windows 上代表的是一切皆服务、进程常驻的经典桌面模型而鸿蒙代表的是按需授权、事件驱动的移动后台模型两者之间差着一整套后台驻留机制设计哲学。如果你也正在做类似的移植不要急着写代码先花两个下午把两边系统的任务生命周期和配额策略都列成表格逐行对比后面的开发效率会快得多。另外一个从这次实践里沉淀下来的规矩就是每移植一个平台能力先补一篇能力映射文档把 Windows 服务、鸿蒙任务、Dart 接口三者之间的关系写清楚这比代码本身更能防止后人踩坑。
