Recording device activity over a short period of time and collecting traces of your app's startup period can help identify potential bottlenecks and improve overall app performance.
Use the Macrobenchmark library
The Macrobenchmark library measures larger end-user interactions, such as startup, interacting with the UI, and animations. The library provides direct control over the performance environment you're testing. It allows you to control compiling, starting, and stopping your application to directly measure precise app startup time and works to minimize the noise and differences between test runs.
Use mid-range devices to identify potential performance issues
You should test performance on each device type you care about. High-end devices with fast components can potentially hide performance problems on older, slower, or lower RAM devices. Lower-end devices can take longer to load data or run code, making it easier to identify bottlenecks. Optimizing performance on low-end devices usually benefits the high-end as well.
- Network: Test your apps (or processes) with strong and stable internet WiFi speeds. If the app startup time includes a network request, note this as a place where variability may occur.
- RAM usage: Your device shouldn't have any other apps in the background while testing app startup performance.
- Battery: Ensure your device is charged to avoid any hardware-specific low power performance throttling.
Test on release builds
Use release builds to test performance. Debug builds are unsuitable for performance debugging as they don’t provide compilation optimization, which has a significant impact on performance.
However, it's okay to use an unobfuscated release build to identify classes and
operation names. Specifically, minify (R8)
should still be enabled, but obfuscation should be disabled, with
-dontobfuscate in the proguard file.
Identifying layouts, assets, and resources is easier if the build is
Make sure that you include the profileable flag in the manifest so that your custom events are visible in non-debuggable builds. This flag is available on Android 10 (API level 29) and higher.
Add custom traces to your app operations
Adding custom traces within your app makes it easier to identify what operations are performed by your app compared to other libraries. This helps give you more context about what the app is doing at all times.