我认为 DispatchTime 和 DispatchWallTime 之间的区别与应用程序是否已暂停或设备屏幕是否已锁定或其他原因有关:DispatchTime 应该暂停，而 DispatchWallTime 应该继续运行，因为现实世界中的时钟继续运行。

所以我写了一个小测试应用程序:

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
    var window: UIWindow?
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
        // Override point for customization after application launch.
        return true
    }
    func applicationDidEnterBackground(_ application: UIApplication) {
        print("backgrounding the app, starting timers for 60 seconds", Date())
        DispatchQueue.main.asyncAfter(deadline: .now() + 60) {
            print("deadline 60 seconds ended", Date())
        }
        DispatchQueue.main.asyncAfter(wallDeadline: .now() + 60) {
            print("wallDeadline 60 seconds ended", Date())
        }
    }
    func applicationWillEnterForeground(_ application: UIApplication) {
        print("app coming to front", Date())
    }
}

我在我的设备上运行了该应用程序。我将应用程序置于后台，等待一段时间，然后将应用程序带到前台。有时“等了一会儿”包括关闭屏幕。我得到了这样的结果:

backgrounding the app, starting timers for 60 seconds 2018-08-15 17:41:18 +0000
app coming to front 2018-08-15 17:41:58 +0000
wallDeadline 60 seconds ended 2018-08-15 17:42:24 +0000
deadline 60 seconds ended 2018-08-15 17:42:24 +0000

backgrounding the app, starting timers for 60 seconds 2018-08-15 17:42:49 +0000
app coming to front 2018-08-15 17:43:21 +0000
wallDeadline 60 seconds ended 2018-08-15 17:43:55 +0000
deadline 60 seconds ended 2018-08-15 17:43:55 +0000

deadline 计时器触发之前的延迟没有我预期的那么长:它比 60 秒的截止日期多了 6 秒，尽管我让应用“休眠”的时间比这长得多。但更令人惊讶的是，两个计时器同时触发。

wallDeadline 在 iOS 上的作用与 deadline 的作用有哪些不同？

最佳答案

The Dreams Wind的回答没有错，但我想更准确地理解这些API。这是我的分析。

调度时间

这是上面的评论DispatchTime.init :

/// Creates a `DispatchTime` relative to the system clock that
/// ticks since boot.
///
/// - Parameters:
///   - uptimeNanoseconds: The number of nanoseconds since boot, excluding
///                        time the system spent asleep
/// - Returns: A new `DispatchTime`
/// - Discussion: This clock is the same as the value returned by
///               `mach_absolute_time` when converted into nanoseconds.
///               On some platforms, the nanosecond value is rounded up to a
///               multiple of the Mach timebase, using the conversion factors
///               returned by `mach_timebase_info()`. The nanosecond equivalent
///               of the rounded result can be obtained by reading the
///               `uptimeNanoseconds` property.
///               Note that `DispatchTime(uptimeNanoseconds: 0)` is
///               equivalent to `DispatchTime.now()`, that is, its value
///               represents the number of nanoseconds since boot (excluding
///               system sleep time), not zero nanoseconds since boot.

所以 DispatchTime 是基于 mach_absolute_time 的。但是什么是 mach_absolute_time？它在 mach_absolute_time.s 中定义.每种 CPU 类型都有单独的定义，但关键是它在 x86-like CPU 上使用 rdtsc 并在 ARM 上读取 CNTPCT_EL0 寄存器。在这两种情况下，它得到的值单调增加，并且仅在处理器未处于足够深度的 sleep 状态时增加。

请注意，即使设备看起来处于 sleep 状态，CPU 也不一定 sleep 足够深。

DispatchWallTime

DispatchWallTime 定义中没有类似有用的注释，但我们可以查看其now 方法的定义:

public static func now() -> DispatchWallTime {
    return DispatchWallTime(rawValue: CDispatch.dispatch_walltime(nil, 0))
}

然后我们可以咨询the definition of dispatch_walltime :

dispatch_time_t
dispatch_walltime(const struct timespec *inval, int64_t delta)
{
  int64_t nsec;
  if (inval) {
      nsec = (int64_t)_dispatch_timespec_to_nano(*inval);
  } else {
      nsec = (int64_t)_dispatch_get_nanoseconds();
  }
  nsec += delta;
  if (nsec <= 1) {
      // -1 is special == DISPATCH_TIME_FOREVER == forever
      return delta >= 0 ? DISPATCH_TIME_FOREVER : (dispatch_time_t)-2ll;
  }
  return (dispatch_time_t)-nsec;
}

当inval为nil时，调用_dispatch_get_nanoseconds，所以let's check that out :

static inline uint64_t
_dispatch_get_nanoseconds(void)
{
  dispatch_static_assert(sizeof(NSEC_PER_SEC) == 8);
  dispatch_static_assert(sizeof(USEC_PER_SEC) == 8);

#if TARGET_OS_MAC
  return clock_gettime_nsec_np(CLOCK_REALTIME);
#elif HAVE_DECL_CLOCK_REALTIME
  struct timespec ts;
  dispatch_assume_zero(clock_gettime(CLOCK_REALTIME, &ts));
  return _dispatch_timespec_to_nano(ts);
#elif defined(_WIN32)
  static const uint64_t kNTToUNIXBiasAdjustment = 11644473600 * NSEC_PER_SEC;
  // FILETIME is 100-nanosecond intervals since January 1, 1601 (UTC).
  FILETIME ft;
  ULARGE_INTEGER li;
  GetSystemTimePreciseAsFileTime(&ft);
  li.LowPart = ft.dwLowDateTime;
  li.HighPart = ft.dwHighDateTime;
  return li.QuadPart * 100ull - kNTToUNIXBiasAdjustment;
#else
  struct timeval tv;
  dispatch_assert_zero(gettimeofday(&tv, NULL));
  return _dispatch_timeval_to_nano(tv);
#endif
}

它引用 POSIX CLOCK_REALTIME 时钟。因此它基于时间的普遍概念，如果您在“设置”(或 Mac 上的“系统偏好设置”)中更改设备的时间，它会发生变化。

神秘的六秒

你说你的计时器启动了

6 seconds over the 60 second deadline

让我们看看它是从哪里来的。

asyncAfter(deadline:execute:) 和 asyncAfter(wallDeadline:execute:) 调用相同的 C API，dispatch_after。截止日期(或“时钟”)的类型与时间值一起被编码到 dispatch_time_t 中。 dispatch_after 函数调用 the internal GCD function _dispatch_after ，我在这里部分引用:

static inline void
_dispatch_after(dispatch_time_t when, dispatch_queue_t dq,
      void *ctxt, void *handler, bool block)
{
  dispatch_timer_source_refs_t dt;
  dispatch_source_t ds;
  uint64_t leeway, delta;

截图

  delta = _dispatch_timeout(when);
  if (delta == 0) {
      if (block) {
          return dispatch_async(dq, handler);
      }
      return dispatch_async_f(dq, ctxt, handler);
  }
  leeway = delta / 10; // <rdar://problem/13447496>

  if (leeway < NSEC_PER_MSEC) leeway = NSEC_PER_MSEC;
  if (leeway > 60 * NSEC_PER_SEC) leeway = 60 * NSEC_PER_SEC;

截图

  dispatch_clock_t clock;
  uint64_t target;
  _dispatch_time_to_clock_and_value(when, &clock, &target);
  if (clock != DISPATCH_CLOCK_WALL) {
      leeway = _dispatch_time_nano2mach(leeway);
  }
  dt->du_timer_flags |= _dispatch_timer_flags_from_clock(clock);
  dt->dt_timer.target = target;
  dt->dt_timer.interval = UINT64_MAX;
  dt->dt_timer.deadline = target + leeway;
  dispatch_activate(ds);
}

_dispatch_timeout 函数可以在 time.c 中找到.可以说它返回当前时间和传递给它的时间之间的纳秒数。它根据传递给它的时间时钟确定“当前时间”。

因此 _dispatch_after 获取执行 block 之前要等待的纳秒数。然后它将 leeway 计算为该持续时间的十分之一。当它设置计时器的截止日期时，它会为您传入的截止日期添加余地。

在您的情况下，delta 大约为 60 秒(= 60 * 10⁹ 纳秒)，因此 leeway 大约为 6 秒。因此，您的 block 将在您调用 asyncAfter 后大约 66 秒执行。

关于ios - DispatchWallTime 在 iOS 上有什么作用？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/51863940/