不同传感器数据中纳米时间的不同值.如何弄明白?

Moh*_*Moh 10 java android timestamp nanotime elapsedtime

自最新的Android更新(第8版)以来,我在尝试读取传感器时意识到了一种非常奇怪的行为.更具体地说,我说的是WiFi和Cell Towers.这是两个例子:

我读取WiFi接入点信息数据,并尝试accessPoint.timestamp使用此代码转换为绝对时间戳:

long timeInMillis = System.currentTimeMillis() + ((accessPoint.timestamp * 1000L -
                SystemClock.elapsedRealtimeNanos()) / 1000000L);
Run Code Online (Sandbox Code Playgroud)

但是,当我阅读Cell Towers时,相同的代码无法正常工作nearbyCellTowers = mTelephonyManager.getAllCellInfo();,我必须使用其他代码:

long timeInMillis = System.currentTimeMillis() + ((gsmRecord.getTimeStamp() -
                    System.nanoTime()) / 1000000L);
Run Code Online (Sandbox Code Playgroud)

如果你没有注意到差异,那就是使用SystemClock.elapsedRealtimeNanos()或者System.nanoTime().

根据Android文档,getTimeStamp()是:

getTimeStamp():自启动以来在nanos中的此单元信息的近似时间

类似于WiFi:

timestamp:上次查看此结果时的以微秒为单位的时间戳(自引导以来).

虽然描述看起来相同(启动后的时间),但值完全不同.正如您所看到的,WiFi时间戳与值相当SystemClock.elapsedRealtimeNanos(),而CellInfo时间戳则与之相当System.nanoTime().

除非我调试并查看结果,否则我永远不会说哪个可以使用哪两个函数.我在这里错过了什么吗?有人可以为我澄清一下吗?这两个函数之间的主要区别是什么以及具有相同描述的两个时间戳具有不同的值的原因是什么?

Ber*_*yle 3

ScanResult#timestamp并且CellInfo#getTimeStamp()不一样。从文档中可以清楚地看出。

ScanResult#timestamp

最后一次看到此结果时的时间戳(以微秒为单位)(自启动以来)。

我认为“自启动”一词会让您感到困惑。这意味着计时器将在系统重新启动时重置(并且绝不意味着计时器在系统启动时启动)。

CellInfo#getTimeStamp()

自启动以来此单元格信息的大致时间(以纳秒为单位)

与前一个一样,计时器将在重新启动时重置。


WiFi时间戳相当于SystemClock.elapsedRealtimeNanos()的值,而CellInfo时间戳相当于System.nanoTime()。

我认为你的意思是“可比较”的“兼容”。这里不存在兼容性问题。和SystemClock.elapsedRealtimeNanos()都是System.nanoTime()以纳秒为单位的时间表示。

System.nanoTime()

返回正在运行的 Java 虚拟机的高分辨率时间源的当前值(以纳秒为单位)。它停止在深度睡眠中

SystemClock.elapsedRealtimeNanos()

返回自启动以来的纳秒数。即使在睡眠中也会持续抽动。




最后回答FreeNickname的问题:

根据我的理解,仅仅使用 System.nanoTime 就会破坏旧的 Android 版本。如果我们想在不同的Android版本上使用不同的方法,我们需要具体了解哪些版本的Android以哪种方式运行。还是特定于供应商的?

您可以SystemClock#elapsedRealtime()在所有版本的 Android 中使用。它是在 API 级别 1 中引入的。请注意,与 不同的是elapsedRealtimeNanos(),它返回毫秒。