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内容请搜索Devmax以前的文章或继续浏览下面的相关文章希望大家以后多多支持Devmax！