阅读 381

Android中各种Time API

时间API

为了跟踪性能,我们需要测量时间间隔,即两个时间点之间的差异。 JDK 为我们提供了两种获取当前时间的方法:

// Milliseconds since Unix epoch (00:00:00 UTC on 1 January 1970)
System.currentTimeMillis()
// Nanoseconds since the VM started.
System.nanoTime()
复制代码

Android 提供了一个 SystemClock 类,它增加了一些:

// (API 29) Clock that starts at Unix epoch.
// Synchronized using the device's location provider.
SystemClock.currentGnssTimeClock()
// Milliseconds running in the current thread.
SystemClock.currentThreadTimeMillis()
// Milliseconds since boot, including time spent in sleep.
SystemClock.elapsedRealtime()
// Nanoseconds since boot, including time spent in sleep.
SystemClock.elapsedRealtimeNanos()
// Milliseconds since boot, not counting time spent in deep sleep.
SystemClock.uptimeMillis()
复制代码

我们应该选择哪一个? SystemClock 的 javadoc 有助于回答这个问题:

  • System#currentTimeMillis 可以由用户或电话网络设置,因此时间可能会不可预测地向后或向前跳跃。 间隔或经过时间测量应使用不同的时钟。

  • SystemClock#uptimeMillis 在系统进入深度睡眠时停止。 这是大多数间隔计时的基础,例如 Thread#sleep(long)、Object#wait(long) 和 System#nanoTime。 当间隔不跨越设备休眠时,该时钟适用于间隔计时。

  • SystemClock#elapsedRealtime 和 SystemClock#elapsedRealtimeNanos 包括深度睡眠。 该时钟是通用间隔计时的推荐基础。

应用程序的性能对深度睡眠中发生的事情没有影响,所以我们最好的选择是 SystemClock.uptimeMillis() 和 System.nanoTime()

uptimeMillis() vs nanoTime()

System.nanoTime() 比 uptimeMillis() 更精确,但这仅对微基准测试有用。 在生产中跟踪性能时,我们需要毫秒级的分辨率。

让我们比较一下它们的性能影响。 我克隆了 Android Benchmark Samples 存储库并添加了以下测试:

@LargeTest
@RunWith(AndroidJUnit4::class)
class TimingBenchmark {
    @get:Rule
    val benchmarkRule = BenchmarkRule()

    @Test
    fun nanoTime() {
        benchmarkRule.measureRepeated {
            System.nanoTime()
        }
    }

    @Test
    fun uptimeMillis() {
        benchmarkRule.measureRepeated {
            SystemClock.uptimeMillis()
        }
    }
}
复制代码

在运行 Android 10 的 Pixel 3 上的结果:

System.nanoTime() 中值时间:208 ns

SystemClock.uptimeMillis() 中值时间:116 ns

SystemClock.uptimeMillis() 几乎快两倍! 虽然这种差异应该不会对应用程序产生任何有意义的影响,但我们能弄清楚为什么它要快得多吗?

uptimeMillis() 实现

SystemClock.uptimeMillis() 实现为带有@CriticalNative 注释的本机方法。 CriticalNative 为不包含对象的方法提供更快的 JNI 转换。

public final class SystemClock {
    @CriticalNative
    native public static long uptimeMillis();
}
复制代码

原生实现在 SystemClock.c++ 中:

int64_t uptimeMillis()
{
    int64_t when = systemTime(SYSTEM_TIME_MONOTONIC);
    return (int64_t) nanoseconds_to_milliseconds(when);
}
复制代码

systemTime() 在 Timers.cpp 中定义:

nsecs_t systemTime(int clock) {
    static constexpr clockid_t clocks[] = {
        CLOCK_REALTIME,
        CLOCK_MONOTONIC,
        CLOCK_PROCESS_CPUTIME_ID,
        CLOCK_THREAD_CPUTIME_ID,
        CLOCK_BOOTTIME
    };
    timespec t = {};
    clock_gettime(clocks[clock], &t);
    return nsecs_t(t.tv_sec)*1000000000LL + t.tv_nsec;
}
复制代码

nanoTime() 实现

System.nanoTime() 也被实现为带有@CriticalNative 注释的本地方法。

public final class System {
    @CriticalNative
    public static native long nanoTime();
}
复制代码

本地实现在 System.c 中:

static jlong System_nanoTime() {
  struct timespec now;
  clock_gettime(CLOCK_MONOTONIC, &now);
  return now.tv_sec * 1000000000LL + now.tv_nsec;
}
复制代码

这两个实现其实很相似,都调用clock_gettime()。

事实证明,@CriticalNative 最近才被添加到 System.nanoTime(),这就解释了为什么它变慢了!

结论

在生产应用中跟踪性能时:

对于大多数用例,毫秒分辨率就足够了。 要测量时间间隔,请使用 SystemClock.uptimeMillis() 或 System.nanoTime()。 后者在较旧的 Android 版本上速度较慢,但这在这里无关紧要。

文章分类
Android
文章标签