Android — navigation response time
How quickly the Android app reacts when you tap to switch screens — for example, tap Wallet and time until the Wallet screen is drawn. Tracked across builds so we can see whether performance improves or regresses.
- Lower is better. Most points are the median of 6 runs on a fresh account (Samsung A36); charts that work differently (single cold samples, screens faster than the measurement floor) say so in their footnotes.
- Measured with a screenshot/pixel timer that reads the screen directly — the Qt UI's accessibility tree is unreliable for timing, so we don't rely on it.
- Resolution is bounded by the screenshot round-trip. On this device the smallest values are about 0.06–0.1 s (the tap plus the first screenshot), so anything down at that level should be read as "within one frame", not as a precise latency.
- Charts show the most recent builds; the x-axis is labelled by build
(date · version/rc · short hash). Full history lives in
data/android/.
Navigation tabs
Messages and Settings navigation are not a reliable trend yet. Their timing is bimodal — most runs land near ~0.5 s, but some register the change on the very first screenshot (~0.07 s), so a single build's summary can swing between the two (the Messages chart, plotted as the fastest of 6, jumps when a build happens to produce no sub-frame sample). The measurement is being made deterministic; until then read these two as indicative, not as a regression signal. The banded Wallet/Market charts are the trustworthy headline.
First open
The session's first open of a screen includes one-time content construction, so it is tracked separately from the warm navigation trend above. Each point is a single cold sample — a session only has one first open. (It is not always slower than warm navigation; Wallet's first open lands close to its warm time.)
Settings sub-screens
Time from tapping an entry inside Settings until that screen is drawn. Every entry on the Settings list is covered except Wallet (its measurement fails consistently and is being investigated separately), Sign out & Quit (destructive) and the backup banner (an action, not a screen).
From the 2.38.0-rc.8 build onward these measurements confirm the identity of the arrived screen against a calibrated title region. Earlier points timed arrival correctly but used a weaker check that could not distinguish one sub-screen from another.
Wallet actions
Time from tapping an action in the account view until its sheet/flow is drawn. The action is opened once unmeasured first, so the samples reflect steady-state use.
Receive and Buy open within a single screenshot (the ~0.06–0.1 s floor), so their charts show the fastest of 6 and should be read as "within one frame".
Wallet accounts
Opening an account is measured as a single cold sample (repeat opens hit the cached view and drop below the floor); adding an account is a normal 6-run mean.
Cold opens
The app process is force-stopped and logged back in before every sample, so each open pays full page construction (the same cold model Android's own Macrobenchmark uses). Same fully-drawn criterion as the warm charts above, so cold and warm are directly comparable: a gap between them is cache benefit, a match means the screen is transition-dominated.
Only the Settings cold opens are shown here. The nav-tab cold opens (Wallet, Messages, Market, Communities) were captured only on a pre-final build that has since been dropped from the dashboard, so they are pending re-measure on a current build.
Communities directory (networked)
Time from arriving on Discover Communities until real card content replaces the loading skeletons, and time to open the featured community from it. These fetch live data from the community directory, so they vary with network and backend state — expect more spread than the local-render charts.
Generated by scripts/benchmark.py (the mobile chart path) from data/android/,
refreshed per release-candidate build. The desktop benchmarks and their charts are
unchanged — see the repository README.
Method changes
- 2026-06-17 — summary statistic switched from mean to median. Each build is now summarised by the median of its runs (floor-limited screens keep "fastest of"). Median is robust to one-off slow runs, so the trend reflects the app, not measurement noise. Recomputed from stored raw runs — not a re-measurement. A small downward step on a few earlier points is this change, not an app change.