Confirmed users
975
edits
Performance/Fenix/Performance reviews: Difference between revisions
Jump to navigation
Jump to search
Performance/Fenix/Performance reviews (view source)
Revision as of 23:57, 5 November 2021
, 5 November 2021→Example: Add first code point
(→Example: Add first code point) |
|||
| Line 76: | Line 76: | ||
# Compare the results, generally by comparing the ''median'' of the two runs | # Compare the results, generally by comparing the ''median'' of the two runs | ||
=== Example === | === Example: time to display the home screen === | ||
For step 1) in the outline, we want to measure the time it takes to fully display the home screen. We always need to be very specific: we'll want the duration from hitting the home button on an open tab until the homescreen is visually complete. | |||
For step 2), ... | For step 2.1), we'll '''first add code to capture the timestamp when the home button is pressed.''' To get the duration closest to what the user experiences, we need to record the time when the touch event is initially received: <code>HomeActivity.dispatchTouchEvent</code>. | ||
object TimestampBenchmark { | |||
var start = -1L | |||
} | |||
class HomeActivity(...) { | |||
... | |||
override fun dispatchTouchEvent(ev: MotionEvent?): Boolean { | |||
TimestampBenchmark.start = SystemClock.elapsedRealtime() | |||
return super.dispatchTouchEvent(ev) | |||
} | |||
When running the test, we'll need to be careful that we don't touch the screen after we press the home button because it'd override this value and give us the wrong measurement. We could avoid this problem by recording the timestamp in the home button's click listener but that may leave out a non-trivial duration: for example, what if the touch event was handled asynchronously and got blocked before dispatching to the home button? Furthermore, this may be simpler: the home button's click listener may exist in android-components, requiring us to build it as well. | |||
TODO... | |||
== Profile == | == Profile == | ||
TODO | TODO | ||