Skip to content

ScreenTune Boot Benchmarks

These captures provide the data behind ScreenTune’s boot optimization. An on-device profiler timestamped each milestone against the unit’s own clock. The stock baseline and a ScreenTune configuration with wireless CarPlay startup and the test car’s unused-service selections ran on the same v74.00.324A CMU back-to-back.

A small profiler installs as the first ScreenTune startup task. It writes one log per boot containing:

  • Milestone timestamps, read from /proc/uptime (seconds since power-on) as each key process or network event appears: main UI process, touch input, WiFi access point, phone association, CarPlay session, audio stream.
  • A steady-state resource snapshot, taken ~3 minutes after boot: process count, free memory, per-process memory, and load average.

The profiler uses under ~1% CPU.

CaptureBuildBoots
Stock baselineProfiler only, no other changes7
ScreenTuneCustomer configuration with wireless CarPlay startup enabled6

Each milestone below is the number of seconds from power-on to when that event appeared in the log.

MilestoneStock (typical)ScreenTune (typical)Sooner by
Interactive screen up~48 s~32 s~16 s
Touch ready~48 s~32 s~16 s
WiFi access point ready~55 s~39 s~16 s
Phone Wi-Fi associated~62 s~50 s~13 s
CarPlay session active~71 s~55 s~16 s
Audio stream running~71 s~57 s~14 s

The full spread shows the boot-to-boot variation, in seconds from power-on:

MilestoneStock (7 boots)ScreenTune (6 boots)
Interactive screen up46.8 – 57.131.4 – 32.5
Touch ready47.0 – 57.431.5 – 33.7
WiFi access point ready53.4 – 67.338.8 – 42.6
hostapd (AP service) up54.6 – 69.239.6 – 43.5
Phone Wi-Fi associated59.1 – 76.148.9 – 55.4
CarPlay session active64.9 – 84.851.3 – 71.4
Audio stream running65.8 – 99.055.4 – 72.2

The screen-ready and WiFi/hostapd milestones are the most consistent; ScreenTune clusters them tightly (the screen comes up in a ~1-second window every boot). CarPlay varies more, on both builds, because the last stretch before CarPlay is partly the phone’s own Wi-Fi and CarPlay handshake, which the head unit doesn’t control.

Later post-boot captures saw 244–280 MB completely unused, compared with 167–170 MB in two stock-service snapshots. Those captures span several ScreenTune revisions and service selections, so the difference is not a matched per-checkbox result. Menu frame times were not measured.

Read these numbers as measurements, not a specification:

  • Small sample on one unit. The comparison covers 6 ScreenTune boots and 7 stock boots on one v74.00.324A CMU. Later builds logged more than 50 additional boots on that unit, but another unit or vehicle can produce different absolute times.
  • The phone-handshake tail varies. The last ~12–16 seconds before CarPlay is partly your phone’s own Wi-Fi/CarPlay handshake, which the head unit can’t speed up. One slower ScreenTune boot reached CarPlay at ~71 s (about the same as a typical stock boot), while the typical ScreenTune boot is ~55 s. A good ScreenTune boot reaches CarPlay near 51 s, about 20 s sooner than a typical stock start, which is why we cite the CarPlay win as a 16–20 s band rather than a single number.
  • One incomplete stock capture. CarPlay appeared on all 6 ScreenTune boots and 6 of 7 stock captures; the remaining stock capture ended before that milestone.

These results came from an internal profiling build. Customer packages do not need the profiler to apply ScreenTune. If you need comparable logs for troubleshooting or validation, contact support for a profiling package and collection instructions.