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

到此这篇关于android中各种time api详细的文章就介绍到这了,更多相关android中各种time api内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！