Flutter Timer.periodic执行速度远慢于真实时间问题咨询

Dart的Timer运行在主Isolate的事件循环队列中，不存在抢占式调度：只有当事件队列中排在定时器回调之前的所有任务全部执行完毕，定时器的tick回调才会被触发。
你遇到的间隔远大于设定值的问题，本质是主Isolate被同步阻塞了：你代码中调用的_StartDataCollection、_StopDataCollection、createUser，或是定时器回调内部存在CPU密集型计算、同步IO、空转循环等待这类同步耗时操作，占住了事件循环的执行权，导致下一次定时器事件迟迟无法被调度。
你观察到tick值能从1连续打印到5，是因为tick仅统计回调成功触发的次数，不会因为回调执行慢就跳过计数；实际总耗时拉长到25秒，是因为每一次tick回调的执行本身就占用了4秒左右的时间，加上定时器本身的5秒间隔等待，最终单次tick的实际间隔被拉长到了近5秒+阻塞时长，总耗时翻倍。

• 定位阻塞点：在定时器回调的开头和结尾打印时间戳，统计每次回调的实际执行耗时，逐一排查三个调用方法里的同步阻塞逻辑，重点查大批量数据遍历、同步文件读写、大JSON/数据结构解析、while(flag){}空转等待这类代码。
• 转移耗时任务：所有CPU密集、同步IO的耗时操作，不要放在主Isolate执行，使用compute函数将任务投递到独立后台Isolate运行，避免阻塞主事件循环。注意传给compute的执行函数必须是顶层函数或者静态函数，不能是类的实例普通方法。
• 不要依赖tick计数做时间敏感逻辑：Timer本身不保证精准触发，只要主Isolate有阻塞就会出现延迟，涉及时间判断的逻辑直接用DateTime.now()和任务启动时间做差值计算，比tick计数可靠。

修正示例代码 #

// 耗时逻辑抽成顶层/静态函数，供后台Isolate调用
static void _heavyCollectionWork(dynamic params) {
  // 原_StartDataCollection里的同步阻塞逻辑
}

static void _heavyStopWork(dynamic params) {
  // 原_StopDataCollection里的同步阻塞逻辑
}

static void _heavyCreateUserWork(dynamic params) {
  // 原createUser里的同步阻塞逻辑
}

void startTheTimer(){
  var counter = 5;
  // 零延迟任务同样受事件循环调度，耗时逻辑也要扔后台
  Timer.run(() async {
    await compute(_heavyCollectionWork, null);
  });
  Timer.periodic(const Duration(seconds: 5), (timer) async {
    final taskStartTime = DateTime.now();
    print('tick: ${timer.tick}, triggerTime: ${taskStartTime.toIso8601String()}');
    counter--;
    if (counter == 2) {
      await compute(_heavyStopWork, null);
    }else if (counter == 1){
      await compute(_heavyCreateUserWork, null);
    }
    if (counter == 0) {
      print('Cancel timer');
      timer.cancel();
      print(numbers.length);
      print(fifo.length);
    }
    // 打印当前回调执行耗时，方便排查剩余阻塞问题
    print('current tick cost: ${DateTime.now().difference(taskStartTime).inMilliseconds}ms');
  });
}

额外注意：主Isolate的阻塞来源不只是定时器内调用的方法，页面build逻辑、同步插件调用、其他事件队列里的耗时任务，都会导致所有Timer、UI动画、手势响应出现延迟，排查时不要只局限在定时器相关代码里。

内容的提问来源于stack exchange，提问作者taha khamis