最新国产好看的视频,伊人天堂AV在线,国产Aaaaaa视频,蜜臀视频在线观看一区,人妻av色图,密臀久久久精品影片,青青视频免费观看毛片,久草在线观看视,国产三级精品色情在线

Android中各種Time API詳細

 更新時間:2021年10月14日 14:41:17   作者:貓尾巴  
這篇文章要分享的是Android中各種Time API, SystemClock.uptimeMillis()、System.nanoTime(),下面我們就來看看他們到底有什么區(qū)別吧

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 可以由用戶或電話網(wǎng)絡設置,因此時間可能會不可預測地向后或向前跳躍。 間隔或經過時間測量應使用不同的時鐘。

SystemClock#uptimeMillis 在系統(tǒng)進入深度睡眠時停止。 這是大多數(shù)間隔計時的基礎,例如 Thread#sleep(long) 、Object#wait(long) System#nanoTime。 當間隔不跨越設備休眠時,該時鐘適用于間隔計時。

SystemClock#elapsedRealtime SystemClock#elapsedRealtimeNanos 包括深度睡眠。 該時鐘是通用間隔計時的推薦基礎。

應用程序的性能對深度睡眠中發(fā)生的事情沒有影響,所以我們最好的選擇是 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() 實現(xiàn)

SystemClock.uptimeMillis() 實現(xiàn)為帶有@CriticalNative 注釋的本機方法。 CriticalNative 為不包含對象的方法提供更快的 JNI 轉換。

public final class SystemClock {
    @CriticalNative
    native public static long uptimeMillis();
}

原生實現(xiàn)在 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() 實現(xiàn)

System.nanoTime() 也被實現(xiàn)為帶有@CriticalNative 注釋的本地方法。

public final class System {
    @CriticalNative
    public static native long nanoTime();
}

本地實現(xiàn)在 System.c 中:

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

這兩個實現(xiàn)其實很相似,都調用clock_gettime() 。

事實證明,@CriticalNative 最近才被添加到 System.nanoTime() ,這就解釋了為什么它變慢了!

結論:

在生產應用中跟蹤性能時:

對于大多數(shù)用例,毫秒分辨率就足夠了。 要測量時間間隔,請使用 SystemClock.uptimeMillis() System.nanoTime() 。 后者在較舊的 Android 版本上速度較慢,但這在這里無關緊要。

到此這篇關于Android中各種Time API詳細的文章就介紹到這了,更多相關Android中各種Time API內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家!

相關文章

最新評論

永新县| 福泉市| 启东市| 慈利县| 儋州市| 砀山县| 平山县| 镇安县| 汶上县| 青浦区| 南宁市| 临沂市| 大方县| 彭阳县| 全州县| 桓仁| 邵阳市| 尚志市| 合山市| 二手房| 洪泽县| 汶上县| 武隆县| 桂阳县| 隆子县| 文昌市| 龙口市| 蚌埠市| 桐庐县| 金平| 申扎县| 南平市| 大同市| 吴忠市| 阳新县| 棋牌| 城口县| 舟山市| 朝阳区| 广丰县| 敦煌市|