When we profiled the application, we noticed that the first call to fetch the Google device identifier was much slower than the subsequent calls.
Since this module is meant to be below-the-fold, we decoupled the homepage load and below-the-fold content. To decrease the load times, we decided to delay third-party API calls until they were required. The native app makes the third-party API call to populate the content. In this case, the homepage backend sends a placeholder to where the content would go. One of the “below the fold” homepage modules is populated through a call to a third-party API. To circumvent the slow speed, we parallelize the work needed to write to disk for caching, populating and creating the user interface.Ĭoncentrate on Populating Above the Fold Modules First After the homepage backend call succeeds, we write to the cache, which can take time because this is an I/O operation. The homepage response is cached on the app for a few minutes in order to avoid too many disrupting home page refreshes.
Look through the call stacks for Async Tasks, onCreate() of various activities.Stop profiling once the homepage load completes and wait for the call charts to populate.Launch the application using the profile run configuration.Of note, the best results were with Sampled Java and an API 26 or newer. The aim of application initialization is to do the minimum amount of work required to show the homepage, so that the user can start interaction with the app right away.įor this, we used the profiler that comes with Android Studio (more details here).īelow are a few tips that worked well within our application. To better understand how we can improve our load times, we decided to profile our app initialization logic. To make that possible, we look at both cold boot and warm boot times on Android. This type of historical data is used to compute the speed budget that the eBay Android home page must adhere to and optimize for future releases.ĮBay’s homepage is unique - while we load the homepage, we are also accountable for the app initialization that happens during first launch. We measure vVC for various sites and app versions. Based on the sample data above, it is computed as (activity_atf_render - lifecycle_create. Simply, vVc is computed as ‘end time’ minus ‘start time’. These metrics are used to derive the time it takes the page to render ready and can respond to user interactions. activity_first_render - completion of Activity onCreate.lifecycle_start - beginning of the Android Activity onStart lifecycle method.lifecycle_create - beginning of the Android Activity onCreate lifecycle method.This speed beacon contains timestamps when key transitions occur in the Android lifecycle. The native app makes calls to this service to drop a speed beacon at critical points in the flow and uses this data to compute a metric called Virtual Visual Complete (vVC). The eBay Android app uses a backend service to measure the real-world speed metrics. With the introduction of speed budgets at eBay, we were tasked with a mission of ensuring that the homepage load times were consistent with every global Android release.īelow are the steps we took to achieve the speed goal. At eBay, we have a company-wide speed initiative on most visited pages like the Homepage, Listing page and Search pages. There is tremendous value in identifying application speed issues early in the development lifecycle. Speed means better customer experience and engagement.
0 kommentar(er)
