vue项目接口域名动态的获取方法
291
2022-06-06
为了跟踪性能,我们需要测量时间间隔,即两个时间点之间的差异。 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()
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()
几乎快两倍! 虽然这种差异应该不会对应用程序产生任何有意义的影响,但我们能弄清楚为什么它要快得多吗?
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; }
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
版本上速度较慢,但这在这里无关紧要。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~