Fixed
Status Update
Comments
ch...@google.com <ch...@google.com> #2
Information redacted by Android Beta Feedback.
ch...@google.com <ch...@google.com> #3
also the navbar on this page is not transparent
cc...@google.com <cc...@google.com> #4
We have passed this to the development team and will update this issue with more information as it becomes available.
ch...@google.com <ch...@google.com> #5
Battery jaldi khatam ho jata hai
cc...@google.com <cc...@google.com> #6
Please solve my battery
ch...@google.com <ch...@google.com> #7
We have received this feedback and will continue to polish the design.
ch...@google.com <ch...@google.com> #8
Also, wondering whether it should be "frame[Cpu|Ui]Duration" or "frameDuration[Cpu|Ui]"
The latter feels better to me, like cpu/ui are qualifiers (at the end) of a similar core concept (frameDuration)
The latter feels better to me, like cpu/ui are qualifiers (at the end) of a similar core concept (frameDuration)
ch...@google.com <ch...@google.com> #9
btw, the overrun docs (https://developer.android.com/reference/kotlin/androidx/benchmark/macro/FrameTimingMetric ) say that it requires API 29, vs the 31 stated in #1 above. I assume we need the new 'deadline' metric, so 31 is correct and the doc is wrong?
cc...@google.com <cc...@google.com> #10
I'll just expose three Nanos metrics for now
SGTM. I prioritize keeping thins in ns for API consistency (time is always a long, in ns) in the app, whereas macrobench prioritizes user reading a string.
@RequiresAPI is about making it clear which is available where.
Duration cpu/ui SGTM.
That doc is correct - we can implement it in API 29 in traces, since deadlines are there, but it's not in FrameMetrics until API 31.
ap...@google.com <ap...@google.com> #11
Project: platform/frameworks/support
Branch: androidx-main
commit 7173e42e85d2a209555a6e45251d50dc5fc1744b
Author: Chet Haase <chet@google.com>
Date: Mon Jan 24 15:19:14 2022
Align timing metrics with other performance libraries
Previously, JankStats used a single "actualDuration" in reporting
and determining jank frames. Now, JankStats uses UI duration (equivalent
to previous actualDuration) on releases prior to API 24. As of API 24,
a new Cpu duration is added (with additional timing info provided by
FrameMetrics). And in API 31, a final Overrun value is added to
provide additional information on how much a jank frame missed its
deadline.
Relnote: Added enhanced timing metric properties
Test: existing JankStatsTest automated tests
Bug: 202072375
Change-Id: I05ec5afc5d3e4ef7ea27ab70dc7fc4e8e372a9ee
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi31Impl.kt
M metrics/metrics-performance/api/public_plus_experimental_current.txt
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/FrameData.kt
M metrics/metrics-performance/api/restricted_current.txt
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi24Impl.kt
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStats.kt
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi16Impl.kt
M metrics/metrics-performance/src/androidTest/java/androidx/metrics/performance/test/JankStatsTest.kt
M metrics/integration-tests/janktest/src/main/java/androidx/metrics/performance/janktest/JankAggregatorActivity.kt
M metrics/integration-tests/janktest/src/main/java/androidx/metrics/performance/janktest/JankLoggingActivity.kt
A metrics/metrics-performance/src/main/java/androidx/metrics/performance/FrameDataApi31.kt
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi26Impl.kt
A metrics/metrics-performance/src/main/java/androidx/metrics/performance/FrameDataApi24.kt
M metrics/metrics-performance/api/current.txt
https://android-review.googlesource.com/1959648
Branch: androidx-main
commit 7173e42e85d2a209555a6e45251d50dc5fc1744b
Author: Chet Haase <chet@google.com>
Date: Mon Jan 24 15:19:14 2022
Align timing metrics with other performance libraries
Previously, JankStats used a single "actualDuration" in reporting
and determining jank frames. Now, JankStats uses UI duration (equivalent
to previous actualDuration) on releases prior to API 24. As of API 24,
a new Cpu duration is added (with additional timing info provided by
FrameMetrics). And in API 31, a final Overrun value is added to
provide additional information on how much a jank frame missed its
deadline.
Relnote: Added enhanced timing metric properties
Test: existing JankStatsTest automated tests
Bug: 202072375
Change-Id: I05ec5afc5d3e4ef7ea27ab70dc7fc4e8e372a9ee
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi31Impl.kt
M metrics/metrics-performance/api/public_plus_experimental_current.txt
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/FrameData.kt
M metrics/metrics-performance/api/restricted_current.txt
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi24Impl.kt
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStats.kt
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi16Impl.kt
M metrics/metrics-performance/src/androidTest/java/androidx/metrics/performance/test/JankStatsTest.kt
M metrics/integration-tests/janktest/src/main/java/androidx/metrics/performance/janktest/JankAggregatorActivity.kt
M metrics/integration-tests/janktest/src/main/java/androidx/metrics/performance/janktest/JankLoggingActivity.kt
A metrics/metrics-performance/src/main/java/androidx/metrics/performance/FrameDataApi31.kt
M metrics/metrics-performance/src/main/java/androidx/metrics/performance/JankStatsApi26Impl.kt
A metrics/metrics-performance/src/main/java/androidx/metrics/performance/FrameDataApi24.kt
M metrics/metrics-performance/api/current.txt
Description
See per-frame metrics proposal here:
These metrics have already landed as part of macrobenchmark withhttps://android-review.googlesource.com/c/platform/frameworks/support/+/1828135 (though FrameUiTime isn't used, as Renderthread time is always queryable from trace data)
So, on
FrameData
, instead of justframeDurationNanos
, it would be:As an example, implementation of frameCpuTimeNanos would be effectively:
(need to optimize that, though)