2

我发现出了什么问题：

所以显然http://www.epochconverter.com/是对输入值的精度做出假设，并且从这些假设值841073068到 1996/1997 年左右。我不确定导致那个确切日期的假设是什么，但老实说我不在乎。

使用我调用的附加调试器new Date(System.currentTimeMillis())，它正确地给了我 1070 年 1 月 10 日的日期，这意味着时钟不会像疯了一样跳出。

原始问题：

我正在运行带有 Android for 和 IoT 案例的单板计算机（此https://developer.qualcomm.com/hardware/dragonboard-410c）。运行的操作系统是高通提供的普通版 Android。

目前我正在测试电路板的可靠性，以便一次长时间执行，我看到一些非常非常奇怪的行为，我无法找到解释。

该板在 10 天前通电，但无法访问互联网（WiFi 已打开，但没有设置接入点，也没有以太网）。蓝牙打开了，办公室里有 iBeacons 和 Eddystone。该地区也有WiFi。

如果我现在转到Settings -> Date and Time，或检查通知栏或进入时钟应用程序或日历应用程序，我会看到 1970 年 1 月 10 日。这是预期的，基本上显示了董事会运行了多长时间。

它上面的应用程序有一个始终运行的服务，它进行一些数据处理和一些磁盘日志记录（用于调试）。

从日志中，我可以看到System.currentTimeMillis()在板最初通电时返回了预期值。这意味着，日志的开头表示 1970 年 1 月的纪元时间。

但是在日志的末尾（并且还在实时进程上附加了调试器）， 的值System.currentTimeMillis()在 1996 年 9 月/10 月的某个地方。示例值：841073068, 841263234,841579239

所以我的问题是：

  • 这里发生了什么？
  • 为什么System.currentTimeMillis()价值改变了，什么可以改变它？
  • 为什么 Android UI（通知、时钟应用、设置）仍然显示 1970？他们从哪里获得这个价值？

编辑：

答案有些混乱，我可以看到我的问题缺乏细节。

我不想测量时差。我需要一个实际的时间戳。这些值将通过蓝牙 LE 事件通过 POST 报告给我们的后端。这个“无网络”的东西是我们在板上运行的可靠性测试，但我们确实希望大部分时间都有网络，并且板应该使用正常的 Android 方式从网络自动更新时间。

我只是想了解当前批次的测试，出了什么问题以及为什么。

4

2 回答 2

1

好吧，正如您已经知道的，如果需要，任何进程都可以修改当前系统时间 ( System.currentTimeMillis())，它完全有可能被另一个进程修改。这不是衡量正常运行时间的可靠方法。

我会使用类似的东西：

SystemClock.uptimeMillis()

它返回自设备启动以来经过的时间（以毫秒为单位）（不包括在深度睡眠中花费的时间）。

我还想提一下，我怀疑蓝牙与它有关，我可以想象蓝牙使用系统时间进行配对和安全，就像 SSL 一样（但我不是专家）。GPS 也可能是一个问题，因为 GPS 可用于获取 UTC 时间值，但我不确定您的电路板是否有 GPS 模块。

关于您的编辑：

获得一个有效的时间戳会很容易：服务器时间减去你的董事会报告的经过时间。但我建议您要么选择接受报告的时间，System.currentTimeMillis()要么使用经过的时间。在我工作的公司，我们也使用嵌入式 Android 设备，在我们的服务器仪表板上，我们可以同时看到正常运行时间（从那时起）和当前设备时间，但至少在我看来，它们不应该混为一谈，尤其是因为System.currentTimeMillis()可能会发生变化，并受夏季和冬季时间的影响。

于 2017-01-02T10:45:28.100 回答
0

如果你想测量一些东西，最好试试System.nanoTime()。这是区别 - https://stackoverflow.com/a/351571/2793494

于 2017-01-02T10:53:24.450 回答