Benchmark cold start of an application with login screen about performance-samples HOT 7 CLOSED

I'm looking for a way to measure the App start time without using test credentials or something.

For the vast majority of apps, the scenario would be
First time launch -> login page -> home -> Second time launch -> Home Page.

We would be making different API calls and different flows between the first and second-time launch.
I think for this we need to look for a solution without clearing application data.

from performance-samples.

There are multiple ways to achieve this.

• Log in each time by providing a test user account in your benchmark test.
• Provide an intent which is available for testing and launch the benchmark with that intent rather than your main intent.
• Use the setupBlock parameter and run through the user flow before running the benchmark.

from performance-samples.

There's a new benchmark to show multiple ways to measure login as described above here.

This only demonstrates how to benchmark the LoginActivity, not any screen when depends on the user being logged in already. As bagadesh outlines above, many apps have Activities which rely on the user being logged in and will crash (or immediately call finish() upon creation because they expect a valid user to exist.

from performance-samples.

There's a new benchmark to show multiple ways to measure login as described above here.

Correct url :
https://github.com/android/performance-samples/blob/main/MacrobenchmarkSample/macrobenchmark/src/main/java/com/example/macrobenchmark/benchmark/LoginBenchmark.kt

from performance-samples.

Any updates on this?

We have a similar use case. On the first run, users interact with CMP (consent management platform), based on that some stuff (e.g. firebase crashlytics) gets enabled/disabled - this might affect start times.

The macrobenchmark lib clears user data on each run, meaning the performance is always measured with CMP turned off which is not representative to startup times for real users.

One possible solution would be to pull the default shared preferences from the device and commit it to git. Then we would have some code in the setup that pushes the shared preferences fine to the device.

Is the issue here enough or should we file a ticket on the official issue tracker with the use case?

from performance-samples.

@LouisFn @LordRaydenMK We had the same problem. We used uiautomator library to automatically login and go through the initial user set-up that ultimately launches out main activity. After that, we went ahead and launches a few top screens in our app. Although after the user logs in, the first few screens are rarely used, we couldn't figure out any other way. This way, out baseline profile was almost 6.8 MB which compresses down to 28 KB in total only.

from performance-samples.

There's a new benchmark to show multiple ways to measure login as described above here.

from performance-samples.