在标准 JVM(例如 1.8 版)中,我们可以像这样访问当前线程的时间:
ManagementFactory.getThreadMXBean().getCurrentThreadCpuTime();
在Android(即Dalvik VM)中获取当前线程时间的等效方法是什么。
在标准 JVM(例如 1.8 版)中,我们可以像这样访问当前线程的时间:
ManagementFactory.getThreadMXBean().getCurrentThreadCpuTime();
在Android(即Dalvik VM)中获取当前线程时间的等效方法是什么。
从实现中您可以看到它使用CLOCK_THREAD_CPUTIME_ID
, 并将 nanos 划分为 millis。同样有currentThreadTimeMicro。这两个使用@CriticalNative注解,它甚至比@FastNative
. 这种特殊的优化要求方法不使用对象,只使用原语,并且是静态的。因此,根本没有JNIEnv
使用 no。与 类似@FastNative
,这些注解仅用于平台调用,并没有动态链接,而是由框架预先专门链接的。
获取线程 CPU 使用率的指示。返回的值表示当前线程执行代码或等待某些类型的 I/O 所花费的时间。时间以纳秒表示,并且仅在与较早调用的结果相比时才有意义。请注意,纳秒分辨率并不意味着纳秒精度。
通过检查 Android 运行时 (ART),这将调用ThreadCpuNanoTime方法,该方法使用CLOCK_THREAD_CPUTIME_ID
. 此外,它被标记为快速 Native 方法,并在 Java 中注释为@FastNative
. 这允许通过加速 JNI 转换来优化它。我想这种优化,类似于@CriticalNative
,利用了他们不需要完全构造/破坏 JNI 环境的事实,因为这里没有真正的依赖关系。它本质上只是一个syscall。
或者,可以实现一个做同样事情的 JNI 方法,但不会有更快的 JNI 处理。
两者System.nanoTime()
, 和currentTimeMillis()
都没有绑定到线程,并使用CLOCK_MONOTONIC
.
我不熟悉 Java API 中的任何此类等价物。
然而,超越 Java API 的思考......你能从中收集到任何有用的信息top
吗?
top -t
显然会在报告中包含线程特定的信息。这是在我的一台设备上运行的结果:
那里似乎有可用的线程和 CPU 利用率数据。
访问此输出将涉及某种原始形式的输入流处理,例如
try {
final String cmd = "top -t"
final Process ps = Runtime.getRuntime().exec(cmd);
ps.waitFor();
final InputStream instream = ps.getInputStream();
...
} catch(Throwable t) { /* handle errors */ }
} finally { /* clean-up */ }