Turo is the world’s largest car sharing marketplace where guests can book any car they want, and wherever they want it, from a vibrant community of trusted hosts.
Developers at Turo recently invested heavily in improving the startup performance of its Android application. Startup time is the first impression users have of an app, and slower load times can negatively impact user retention and engagement. The team wanted to give users a faster, more streamlined experience every time they launched the app. And using Android’s best tools, resources, and practices, they were able to cut the app’s startup time by 77%.
App initialization includes an application’s entire startup process and all the code it runs before rendering its first UI frame. For Turo, this meant users had to wait for the app to run its initial startup, synchronous network requests, and a custom splash animation — all before they were ever shown the app’s home screen.
Turo’s developers knew that to improve the application’s loading times, they would need to condense and remove many of these cumbersome startup events. To help pare down these events, Turo engineers used Android’s App Startup library.
The App Startup library gave Turo’s developers a simple, streamlined way to initialize multiple components during the application’s launch. It also enabled them to select which components to initialize and in what order, allowing them to significantly improve load times. Having the App Startup library in place set the foundation for the rest of Turo’s startup optimization.
Prior to optimization, the app performed multiple network requests sequentially and then displayed a custom, one-second splash animation before users could access the app’s home screen. This resulted in a slow startup process, especially if a user had poor network connectivity.
Removing the splash animation was an easy way for Turo developers to improve perceived loading time. And by making network requests parallel and asynchronous, users could access the home screen much faster. “Initially, we used a dedicated SplashActivity to run all the startup work before routing the app to the HomeActivity. However, the latest guidelines advise against this approach. Therefore, we eliminated the redundant SplashActivity and transferred all the startup logic to our root activity by leveraging the Splash Screen API,” said Pavlo Stavytskyi, a senior staff software engineer at Turo.
At the same time, the app was also performing a number of other startup network requests to tailor the experience to individual users, resulting in inconsistent user experiences.“If the app is used by a guest, some network requests help decide which screen should be shown after the splash screen,” said Pavlo. “By default, it’s the home screen. However, there are special cases where the user could be redirected either straight to an active vehicle reservation or to a feedback screen.”
The team didn’t want to slow down every app startup by checking for these niche scenarios. Instead, Turo now always opens the home screen by default while making network requests asynchronously. If a redirect is required, the appropriate screen is displayed on top of the home screen.
