Optimizing Google Play Console Slow Start Metrics

[mumeka]

Hello,

I'm working to optimize the "Slow Start" metric reported in Google Play Console.

My application typically renders its first visual frame around 500 ms (device-dependent), using Animate at keyframe 1. This frame displays visible graphics designed to indicate that loading is underway.

At keyframe 3, Starling initialization and texture atlas loading begin. This process completes at between 600 ms and 9900 ms depending on the device. According to telemetry, some high-performance devices complete the entire startup sequence in as little as 190 ms.

Despite the fact that all devices display the initial screen around 500 ms, the reported "Slow Start" ratio is 2.24% (i.e., startup times exceeding 5000 ms).

What is the recommended approach to ensure Android recognizes this early screen? Are there best practices for signaling readiness earlier?

Would implementing a custom splash screen using Harman SDK improve detection?

Thank you in advance for your guidance.
Best regards,

---

AIR SDK: 51.1.4.1

AIRAppEntry represents TTID from https://developer.android.com/topic/performance/vitals/launch-time?hl=tr#time-initial

Application:
SWF size in the APK: 3.8 MB
Displayed AIRAppEntry for user 0: +1s296ms (AS3 reports: keyframe1 631 main menu reached at 851)
Displayed AIRAppEntry for user 0: +1s131ms (AS3 reports: keyframe1 544 main menu reached at 777)
Displayed AIRAppEntry for user 0: +1s259ms (AS3 reports: keyframe1 593 main menu reached at 826)
Displayed AIRAppEntry for user 0: +1s98ms (AS3 reports: keyframe1 496 main menu reached at 703)

It looks like initial start is the real issue for me. I can confirm keyframe 1 is detected as TTID.

---

AIR SDK: 51.1.4.1

Deleted every code from project. SWF size in the APK: 3 KB (no embed no font)

TTID values:

1425 ms
1099 ms
1047 ms
1111 ms
1008 ms
997 ms
973 ms
994 ms
979 ms
972 ms
1673 ms
981 ms

There are still Distriqt ANEs in the project maybe they slow down the start sequence.

---

AIR SDK: 51.2.2.4

Upgraded to newer version of AIR SDK.

TTID values:
622 ms
683 ms
602 ms
592 ms
618 ms
595 ms
609 ms
587 ms
592 ms
601 ms
590 ms
588 ms

This new values are looking excellent. Now I'm looking forward to release the game with SDK 51.2.2.4+

---

[ajwfrost]

Hi - I was going to say, have you tried with the latest AIR SDK. We had found that the start-up times reported by Android could be shortened by breaking for a frame in the start-up sequence. Essentially, the AIR runtime has to be loaded in, which takes a bit of time (big library) plus the runtime needs to be initialised (ActionScript virtual machine) and this is also then used to parse the app descriptor file, load in the ANEs, and load in the SWF. Only when the first 'show frame' instruction is read in the SWF will the ActionScript class be created.

The AS3 'time' starts from when the runtime starts up so this is also a little behind the operating system's count of the timing from when the process was created. So there's a definite delay between the process start vs the AS3 VM start and then before your app is ready to display.

The runtime loading is triggered by the 'surface created' event we get from Android, so actually we are now allowing an initial frame to be displayed by Android at this point (a black surface) and then loading the runtime immediately after this. Which has definitely helped with the TTID metric, as you found.

However we also appear to have a side effect (at least, for one customer) with a glitch in Display3D rendering (some missing assets which we believe may be due to some GPU context changes). And we had experimented with giving people the option for what do to in this initial blank frame, but weirdly if we display anything but black, the display doesn't properly refresh. So there may be a little more work to do there.

If you notice anything odd, please do let us know!!

thanks

[mumeka]

I updated one of my apps.

Slow start will decrease to %1.2 from %6,5

Thank you for the updates @ajwfrost .