Flutter时钟库system_clock鸿蒙适配实战：时序一致性与高精度计时

如果你的Flutter应用要在鸿蒙生态里站稳脚跟，早晚会被一个问题拦住——时间。不是UI渲染那种"卡顿"问题，而是底层的时钟精度和时序一致性问题。system_clock这个Dart三方库，乍一看只是封装了几个取时间的API，好像没什么了不起，但在真正做高性能应用运行时间追踪、精密计时、日志归集和卡顿检测时，它给出的系统时间、单调时钟、高精度时钟，决定了你整个数据底座的可信度。问题在于，这个库默认支持的是Android和iOS的Flutter运行时，拿到鸿蒙设备上，底层时间源并没有被正确映射，Dart层的DateTime.now()在部分鸿蒙版本上取到的依然是应用沙箱视角的近似时间。于是"鸿蒙化适配"就成了绕不开的一步。

这篇文章写给三类人：正在把Flutter应用迁移到鸿蒙的移动端开发者，做性能监控SDK或埋点系统的中间件开发者，以及那些在游戏、播放器、动画引擎里被"时间精度"折磨的客户端同学。我会从system_clock的核心能力讲起，拆清楚鸿蒙侧需要映射哪些系统时间源，再给出完整的插件改造方案、时序一致性治理思路、精度验证方法，最后把我在适配过程中踩过的坑和排查技巧原原本本列出来。每个关键决策我都会说明"为什么"，尽量让你不仅能照做，还能理解背后的逻辑。

1. 为什么需要给Flutter时钟库做鸿蒙化适配

1.1 先搞清楚system_clock到底在解决什么问题

在Dart生态里，大部分人取时间就一行：DateTime.now()。这个API确实方便，但放到严谨的业务场景里，它有几个说不出口的痛点。

第一，精度不保证。对，DateTime.now()拿到的是微秒级单位，但微秒级单位不代表微秒级精度，底层实现完全看平台。在Android上它走的是System.currentTimeMillis()或者更高精度的SystemClock相关封装，在iOS上走的是mach_absolute_time换算，在鸿蒙上又可能是另一套时间服务，精度差异直接导致跨端日志的时间戳对不齐。

第二，只有wall clock，没有monotonic clock。DateTime.now()给的是系统墙上时间，它会受NTP校时、用户手动改时间、时区切换影响。你用它计算动画帧间隔、统计卡顿时长、判断请求超时，结果可能突然变成负数，或者出现一个离谱的几百秒差值。这不是Dart的错，是墙钟本身的语义决定的。

第三，平台差异化接口太多。如果项目里只有iOS和Android，你还可以分别判断平台做适配。但加入鸿蒙之后，同一套业务代码要维护三种底层逻辑，代码里全是if (Platform.isAndroid)这种分支，时间戳还互相不兼容，早晚要出乱子。

system_clock这个库的价值就在这：它把"系统当前时间""单调时钟""高精度纳秒时间戳"三个能力统一成一套Dart API，让上层业务不用关心底层是哪个平台。它的核心调用大致是这样：

• SystemClock.now()：获取当前系统日期时间，相当于加强版DateTime.now()。
• SystemClock.monotonicNow()：获取从某个固定启动点（通常是系统启动或设备上电）开始经过的时长，只增不减，不受墙钟调整影响。
• SystemClock.preciseNow()/nanos()：获取高精度时间戳，用于性能基准测试和帧耗时统计。

这个设计思路其实不复杂，但非常实用：需要"人类可读的时间"就走now()，需要"计算时间间隔"就走monotonicNow()，需要"极致精度"就走nanos()。问题在于，鸿蒙作为一个新平台，它的系统API还没被这个第三方库覆盖，Dart层能调用到的鸿蒙时间源，跟Android/iOS的语义不完全一致。这就是我们要做鸿蒙化适配的原因。

1.2 鸿蒙生态下Flutter应用的时间困境

我有一次在某团队协助排查线上性能问题时，遇到过一个很典型的案例：应用内所有埋点都正常上报，但一旦服务端按时间戳排序，总是出现"后发生的日志时间戳比先发生的还小"的怪异现象。排查到最后发现，Flutter侧的埋点用的是DateTime.now()，每次App从后台切回前台，墙钟做了一次校准，时间戳往前跳了，导致时间线错乱。

这类问题在鸿蒙上有放大效应。原因是鸿蒙设备的系统时间策略、后台应用冻结机制、NTP校准频率跟Android/iOS都有差异。具体体现在几个方面：

• Flutter运行时跑在鸿蒙的应用沙箱内，Dart层的DateTime.now()在某些系统版本上拿到的不是全局真实时间，而是受限视角的时间近似值。单独看一次调用没问题，但跟原生侧获取的系统时间对比，会有肉眼可见的偏差。
• system_clock库在鸿蒙上没有对应的原生实现，monotonicNow()拿不到真正的单调时钟。于是Dart层只能退化用墙钟差值模拟，一旦系统时间跳变，性能统计全部失真。
• 鸿蒙对后台应用有严格的挂起策略，应用从后台恢复时，如果不重新校准本地时间基准，基于运行时长推断的时间戳会产生累计漂移。

说白了，不是鸿蒙没有好用的时间API，而是Flutter侧的三方库还没有把这些API接进来。适配的核心工作就是补上这个缺口，让system_clock在鸿蒙上跟它在Android/iOS上一样"可信"。

2. 鸿蒙化适配的整体设计与拆解

2.1 适配边界：哪些能力必须落到原生侧

做适配之前，先想清楚一个问题：哪些时间能力必须在鸿蒙原生侧实现，哪些可以在Dart层自己算。这个边界划错了，后面全是坑。

我的判断标准很简单：凡是依赖"设备全局时间基准"的能力，都必须落到原生侧。Dart层只是一个请求方，不能自己缓存时间、自己对时。因为Dart虚拟机跑在应用进程里，它对系统时间调整、NTP校准这些外部事件一无所知。

落到具体能力上，可以这样划分：

我做适配时喜欢先画一个"能力边界表"贴在看板上，每完成一项就打个勾。这样做的好处是，团队里其他人接手时能一眼看懂哪些能力是Dart层已有的，哪些是鸿蒙原生侧必须新做的，避免重复造轮子。

2.2 时钟类别的映射方案：从Dart时钟到鸿蒙时钟

鸿蒙系统的时间能力，粗分也是三类，跟system_clock的设计天然对应：

• 系统时间（墙钟）：对应SystemClock.now()。鸿蒙侧可以通过系统时间服务获取当前日期时间，支持纳秒级时间戳返回。适配时要注意区分"本地时间"和"UTC时间"，业务层建议统一使用UTC时间戳传递，到UI层再做时区转换。
• 系统启动时间（单调时钟）：对应SystemClock.monotonicNow()。这是设备从上电或系统启动开始累计的纳秒数，不受用户改时间、NTP校时影响。它天然适合计算时间差、判断超时、统计运行时长。鸿蒙上有对应的系统运行时间API，适配时直接绑定即可。
• 高性能计数器（高精度时钟）：对应SystemClock.preciseNow()。底层通常是CPU的TSC（时间戳计数器）或者系统提供的高精度定时器。这个时钟的读取开销极低，适合高频调用，但它的参考基准是任意的，不能直接当墙钟用，必须配合单调时钟做换算。

映射关系清晰之后，实现就顺理成章。需要注意一个细节：鸿蒙的系统时间API和单调时钟API返回的精度单位可能不一样，有的是毫秒，有的是纳秒。一定在原生侧统一成纳秒单位，再用Dart层的Duration(microseconds: nanos ~/ 1000)做转换，避免单位换算在各业务层重复出现。

这里我额外强调一句：不要试图在Dart层用DateTime.now()的两次差值模拟单调时钟。那个方案看起来能跑，但墙钟一旦跳变，数据就废了，而且会在日志里留下负数的间隔，排查起来极其迷惑。

2.3 通信链路设计：MethodChannel还是FFI

适配Flutter插件，绕不开通信链路的选择。开发过插件的人都知道，Flutter和原生侧通信有几种方式：MethodChannel、EventChannel、BasicMessageChannel、Dart FFI、Dart Native Extension。对时钟这个场景，我的结论是：主力路径用FFI，辅助降级用MethodChannel。

原因很简单，读取时钟是一个高频操作。性能监控SDK经常每秒采样几十次甚至上百次，每帧动画都可能取一次时间戳。MethodChannel走的是异步消息通道，每次调用要跨语言边界、做序列化、走消息循环，单次开销很容易到几十微秒甚至上百微秒，高频下会有明显的CPU开销和延迟抖动。而且它是异步的，日志打点处为了取一个时间还得等回调，代码写起来也别扭。

FFI路径就好很多。做鸿蒙适配时，可以在鸿蒙原生侧封装一个C接口，导出类似这样的函数：

int64_t native_now_nanos(void); int64_t native_monotonic_nanos(void);

Dart侧用dart:ffi直接绑定：

typedef NativeNowNanos = Int64 Function(); typedef DartNowNanos = int Function(); final DartNowNanos _nativeNowNanos = _lib .lookup<NativeFunction<NativeNowNanos>>('native_now_nanos') .asFunction();

这样一次时间读取就是一次同步的native函数调用，开销可以压到纳秒级读取本身的开销，基本可以忽略。而且它在调用线程上直接执行，不需要切到UI线程或IO线程，语义清楚、时序可控。

当然，FFI也有代价：动态库的加载路径要处理好，不同鸿蒙设备架构（x86模拟器、ARM真机）要分别打包，调试时定位问题比MethodChannel费劲一些。所以我建议保留一条MethodChannel路径作为兜底，一旦FFI初始化失败，还能退回到普通通道，保证功能不中断。

3. 核心实现：精密计算与运行时间追踪的落地

3.1 环境准备与工程接入

工欲善其事，必先利其器。鸿蒙化适配的工程基础，关键是让你的Flutter插件工程同时支持标准Flutter和鸿蒙侧的原生工程结构。

我在实际适配时，工程结构大致是这样的：

• Flutter插件根目录，里面是pubspec.yaml和Dart源码。
• android/目录，保留原有Android实现。
• ios/目录，保留原有iOS实现。
• ohos/目录，新增鸿蒙原生工程，里面放ArkTS桥接代码和C/C++动态库源码。
• lib/目录，Dart层统一入口，通过条件导入或者运行时能力检测决定走哪套实现。

创建插件骨架之后，第一时间在pubspec.yaml里把flutter:插件的平台声明补全，让鸿蒙作为新平台可以被识别。接着在ohos/目录里初始化一个鸿蒙模块，把FFI要用的C源码挂上去。

这里有个容易踩的坑：鸿蒙工程的构建产物命名和路径跟Android的jniLibs不一样，直接沿用Android的构建脚本会导致动态库加载失败。我的做法是单独维护一套鸿蒙构建配置，输出so文件到鸿蒙工程能识别的位置，然后在Dart层用DynamicLibrary.open()加载时指定完整的包内路径。

DynamicLibrary _loadLibrary() { try { return DynamicLibrary.open('libsystem_clock_harmony.so'); } catch (_) { // 兜底：某些设备上so路径可能不同 return DynamicLibrary.process(); } }

加载失败时回到MethodChannel路径，保证上层业务无感。

3.2 获取系统时间与单调时钟的关键实现

工程骨架就绪后，核心就是Dart侧API与鸿蒙侧原生函数的正确绑定。先看Dart侧，我建议把system_clock的公开API保持原样，这样业务代码不需要任何改动：

class SystemClock { static DateTime now() { final nanos = _nativeNowNanos(); final micros = nanos ~/ 1000; return DateTime.fromMillisecondsSinceEpoch( micros ~/ 1000, isUtc: true, ).toLocal(); } static Duration monotonicNow() { final nanos = _nativeMonotonicNanos(); return Duration(microseconds: nanos ~/ 1000); } static int preciseNowNanos() { return _nativeNowNanos(); } }

鸿蒙原生侧，重点在C接口里选对时间源。对于墙钟，用系统时间服务API取UTC纳秒时间戳；对于单调时钟，用系统运行时间API取自启动以来的纳秒数。两个接口都做成extern "C"导出，方便Dart FFI绑定。

有一个细节必须提醒：注意线程安全。时钟接口可能被任意线程调用，不要在C接口里加重量级锁。鸿蒙的系统时间API设计上就是线程安全的，直接透传即可。如果你自己加了锁，反而会引入不必要的等待，拉高耗时。

我第一版实现时就在C层加了一个互斥锁保护一个缓存时间变量，结果高频调用下性能直接掉了好几倍，后来删掉锁、改成每次直接读取系统时间，性能才恢复正常。读取系统时间本身的开销远远小于线程锁竞争的开销，这个教训值得记住。

3.3 精密计算的落地：纳秒级时间差的稳定性治理

很多用system_clock的人会忽略一个关键问题：now()和monotonicNow()单独看都没问题，但能不能组合成一个"既稳定又不失真"的高精度时间戳？

设想一个场景：性能监控SDK需要给每个卡顿事件打一个"人类可读"的时间戳，同时还要记录这个卡顿持续了多长时间。如果打点用now()，计算时长用monotonicNow()，那这两个值的参考基准完全不一致。日志里看到一个时间戳，跟另一个时间戳做减法，结果可能完全没意义。

解决方案是很多底层系统都在用的"墙钟+单调时钟偏移"合成方案。原理很简单：

• 在某个基准时刻，同时记录原生侧单调时钟值monoBase和墙钟UTC时间戳wallBase。
• 之后任意时刻的"合成墙钟时间" =wallBase + (当前monotonic值 - monoBase)。

这样算出来的时间戳，语义上永远是墙钟时间，不会因为系统时间调整而跳变，同时又天然对齐了单调时钟的稳定性，计算时间间隔也就有了意义。

class TimeKeeper { int? _monoBase; int? _wallBase; int sync() { _monoBase = _nativeMonotonicNanos(); _wallBase = _nativeNowNanos(); return _wallBase!; } int currentSyntheticWallNanos() { final mono = _nativeMonotonicNanos(); return _wallBase! + (mono - _monoBase!); } }

这个方案的精度取决于单调时钟的稳定性和校准时机的选择。实测下来，只要校准时没有发生系统时间跳变，合成时间戳的精度可以稳定保持在亚毫秒级别。这里推荐在应用启动时校准一次，然后每次从后台切回前台时重新校准，覆盖鸿蒙后台挂起可能导致的时钟偏差。

3.4 性能优化：高频打点场景下的开销控制

适配不是功能通了就算完，性能才是硬指标。时钟库的使用场景往往伴随高频打点，比如帧率监控每帧取一次时间，网络监控每个请求记录开始和结束时间，卡顿检测在UI线程标记耗时临界点。这些场景下，时间戳获取的开销会被无限放大。

我在性能优化上有几个亲测有效的原则：

• 一次native调用尽可能返回更多信息。与其分别调用"获取墙钟"和"获取单调时钟"，不如封装一个native_get_time_snapshot()，一次性返回两个64位纳秒值。这样高频场景只需要一次跨边界开销。
• 减少Dart层对象分配。DateTime对象有包装开销，如果业务只需要时间戳做差值计算，可以提供int版本的接口，让调用方完全绕过DateTime对象创建。
• 避免频繁校准。合成时间戳的校准是有开销的，不要在每个采样点都做。正常情况下启动时校准一次，前后台切换时校准一次就够了。校准太频繁反而可能引入墙钟跳变的影响。

一个实际的高频采样代码示意：

typedef struct { int64_t wall_nanos; int64_t mono_nanos; } TimeSnapshot; void native_get_time_snapshot(TimeSnapshot* out) { out->wall_nanos = get_wall_clock_nanos(); out->mono_nanos = get_monotonic_nanos(); }

Dart侧直接读取结构体内容，避免多次回调。实测下来，单次快照读取可以控制在极低的耗时区间，具体数值跟设备性能有关，但相比MethodChannel动辄几十微秒的延迟，已经是数量级的改善。

4. 时序一致性治理：让业务时间线不再"打架"

4.1 时序一致性到底指什么

大多数团队都是等到线上日志时间线对不上了，才开始认真思考时序一致性问题。所谓时序一致性，用一句大白话说就是：所有模块对"同一时刻"的记录，必须得到一致的、可比较的时间值。

比如用户点了一个按钮，UI线程在埋点日志里记为T1，网络线程收到请求记为T2，服务端收到请求记为T3。如果T1用的是墙钟，T2用的是自己封装的本地时间，T3用的是服务端NTP时间，这三个值之间存在随机偏移，那么用户操作路径的还原就是一笔糊涂账。

更隐蔽的场景在媒体播放器里：音频渲染用的是音频硬件时钟，视频渲染用的是系统实时时钟，两边的同步错位毫秒级就能被人感知。如果应用内没有统一时钟源，音画同步修正会反复跳动，怎么调都调不稳。

鸿蒙适配之后，时序一致性治理的落点就在统一时间源。所有模块都从同一个TimeKeeper拿时间，要么拿墙钟，要么拿单调时钟，要么拿合成时间戳，但绝对不能今天用A明天用B。

4.2 单调时钟回拨问题的规避

"回拨"这个词第一次听容易懵，其实就是墙钟往前跳。NTP服务发现本地时间偏快时，会把时间往回拨；用户手动改时间、运营商时间同步，也可能导致回拨。

墙钟回拨带来的最大问题：基于墙钟做间隔计算时，差值可能为负。你统计一个页面加载耗时，开始时间记录为10:00:00.000，结束时间因为墙钟回拨变成09:59:59.900，算出来加载耗时是负100毫秒。这种数据在监控系统里不仅没有价值，还会拉低数据质量，触发各种误报。

规避手段非常明确：间隔计算一律走单调时钟，展示和上报才用墙钟。在TimeKeeper里，把所有"时长"语义的API强制用monotonicNow()实现，把"时间点"语义的API用合成墙钟时间实现。这样即使墙钟跳了，时长统计完全不受影响，时间点也只是记录了一个标准化的参考值。

如果业务真的很担心墙钟跳变影响对外上报的时间戳，还可以加一道防护：检测到前后两次读取的墙钟差值超过某个阈值（比如500毫秒）时，丢弃当前这个时间戳，重新校准base，用新基准继续合成。这个逻辑几行代码就能写完，但能挡住绝大多数异常场景。

bool _detectWallJump(int newWallNanos) { final last = _lastWallNanos; if (last == null) { _lastWallNanos = newWallNanos; return false; } final delta = newWallNanos - last; _lastWallNanos = newWallNanos; return delta.abs() > jumpThresholdNanos; }

4.3 时间基准对齐：跨线程、跨进程的时间戳统一

时序一致性的进阶需求是跨线程、跨进程，甚至跨端对齐。鸿蒙的应用模型支持多进程能力，如果Flutter业务跑在UI进程，一些耗时任务放在后台进程，两个进程各自维护了一套TimeKeeper，那时间戳之间依然可能互相对不上。

跨线程对齐相对容易，TimeKeeper内部的基准数据用原子变量或者简单的同步机制保护即可，因为线程之间共享同一份内存。跨进程对齐就要费点心思，我建议用共享内存存放基准值，或者通过进程间通信在启动时同步一次基准。各自进程内继续维护自己的单调时钟偏移，不影响合成逻辑。

跨端对齐这个问题往往被忽略。手机、平板、电脑多端同步同一个账号数据时，每台设备挂钟可能差几分钟。这时候日志时间戳全部对齐到服务端下发的参考时间，或者统一换算成UTC毫秒时间戳，才能正常比较。我这里特别提示：设备本地时间不可信，服务端下发的会话时间才是权威基准。TimeKeeper可以把服务端时间也纳入校准体系，把"本地合成时间"和"服务端时间偏移"两个值分开记录，上报时统一修正。

5. 性能与精度验证：适配做完了，怎么证明是对的

5.1 验证维度：精度、稳定性、性能开销

功能跑通只是第一步，时钟库适配的交付标准必须量化。我们通常从三个维度做验证：精度、稳定性、性能开销。

精度验证解决的是"取到的时间到底准不准"。做法很简单：在鸿蒙设备上，同时用Flutter侧适配后的接口和原生侧系统API取时间，连续采样上千次，计算两边差值的均值、标准差和最大误差。理想情况下，适配层的额外误差应该保持在微秒级以内。

稳定性验证针对的是墙钟跳变场景。做法是人为改变系统时间或者触发时间同步，观察适配后的合成时间戳是否出现跳变，单调时钟是否保持稳定。这里建议在测试设备上开启自动时间同步，然后手动切换时区、手动改时间，多场景组合测试。

性能开销验证主要量化单次时间读取的耗时和内存分配。高频采样场景下，分别统计MethodChannel路径和FFI路径的单次耗时，作为选型的最终依据。

5.2 实操验证方案与通过标准

这里给一个可以直接抄的验收表格，你照着执行就行：

我自己在执行这套验证时，习惯先跑精度和稳定性，再跑性能，最后跑长稳，因为长稳最容易暴露内存泄漏和基准漂移问题。如果你时间紧张，至少把稳定性和长稳跑完，这两项出问题的概率最高。

6. 常见问题与排查技巧实录

6.1 设备时间偏了几秒，怎么定位是谁的锅

适配完上真机，很多人第一反应是跟系统设置里的时间对比，发现偏了几秒甚至几分钟，立刻怀疑是自己的适配代码写错了。别急，先做个对照实验：用鸿蒙原生侧接口直接取一次时间，用Flutter侧适配接口取一次时间，两个值打印出来对比。

如果原生侧准确、Flutter侧偏移，问题多半出在Dart层的单位换算或者时区处理上。检查nanos到DateTime转换时是否错误地做了本地时区补偿。如果原生侧本身就偏移，那就不是适配层的问题，而是设备系统时间本身的策略问题，你需要校准测试设备后再继续排查。

这个排查技巧非常实用，能帮你省掉大量无意义的debug时间。

6.2 高频调用性能突然劣化，接口都在吃时间

性能劣化的头号元凶是FFI没有生效，Dart层静默降级到了MethodChannel路径。很多适配代码为了稳妥会让FFI初始化失败时自动降级，但没有任何日志打出来，线上性能问题就是这样悄悄出现的。

排查方法：在插件初始化时打一条日志，明确记录当前走的是"FFI路径"还是"MethodChannel路径"。如果发现降级，检查动态库是否打进了鸿蒙包的so目录，路径是否和DynamicLibrary.open()的参数一致。鸿蒙的工程目录结构和Android不完全一样，动态库放的层级稍微差一点就找不到。

6.3 卡顿检测频繁误报，间隔时长负几百毫秒

这类问题几乎全是墙钟跳变引起的。卡顿检测的逻辑如果用DateTime.now()计算两次主线程消息处理的间隔，系统时间往回拨一点，就会算出负值，然后误判成"消息循环卡死"。

修复方法就是我在4.2节说的：所有间隔计算改用单调时钟。把卡顿检测模块里所有跟"耗时"相关的取时调用全部替换成monotonicNow()，对外展示卡顿时长时再转成合成时间戳。改完之后，误报率会肉眼可见地降下来。

6.4 后台挂起恢复后，时间戳出现分钟级漂移

鸿蒙对后台应用的限制比Android更严格，应用在后台可能被冻结，Dart侧的定时器和时间读取都不会被唤醒。恢复前台时，本地基准时间还停留在挂起前，合成时间戳自然会出现分钟级漂移。

解决方案是在生命周期回调里监听应用从后台恢复的事件，统一触发一次TimeKeeper重校准。校准逻辑在上文sync()基础上增加一个检测：如果monotonic时钟的增量明显超出预期（比如当前时间和上次校准时间之差超过阈值），就重新读取墙钟和单调时钟基准，丢弃旧的偏移量。

@override void didChangeAppLifecycleState(AppLifecycleState state) { if (state == AppLifecycleState.resumed) { timeKeeper.sync(); } }

这个处理看着简单，但能救回大量线上数据质量问题，值得每个适配了时钟能力的App都加上。

6.5 多端日志时间戳对不上，先别怪时钟库

如果手机、平板、电脑三端同时上报日志，服务端排序后总是有错乱，大概率不是某个端适配错了，而是三端设备系统时间本身就不一致。这种情况再怎么调时钟库都没用，应该用服务端下发的参考时间统一修正所有端的上报时间戳，本地时间只作为辅助信息保留。

我甚至建议在埋点SDK层直接做成"所有时间戳都是服务端偏移校准后的UTC纳秒值"，彻底避免终端系统时间差异带来的数据脏乱。这个改动会动到底层协议，但长期来看是值得的。

这套适配方案落地之后，我自己最大的体会是：时钟库的鸿蒙化适配，难点从来不是"怎么调用系统API"，而是"怎么让这些API在业务语义上保持一致"。system_clock给了统一的Dart接口，鸿蒙侧给了足够的系统能力，中间差的只是适配层对时间语义的准确理解和治理意识。如果你正在做类似的跨平台时钟库适配，我建议从第一天就把时序一致性治理方案设计进去，别等埋点数据打架了再回头补。最后分享一个小技巧：无论你的插件最终面向多少平台，在Dart层保留一个统一的TimeKeeper入口，绝对是不后悔的决定。