Android中各种Time API Android中各种Time API详细

时间:2021-10-14 猫尾巴人气:0

想了解Android中各种Time API详细的相关内容吗，猫尾巴在本文为您仔细讲解Android中各种Time API的相关知识和一些Code实例，欢迎阅读和指正，我们先划重点：Android,Time,API，下面大家一起来学习吧。

1、时间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()

2、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() 几乎快两倍！虽然这种差异应该不会对应用程序产生任何有意义的影响，但我们能弄清楚为什么它要快得多吗？

3、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;
}

4、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 版本上速度较慢，但这在这里无关紧要。

加载全部内容