Afternoon Stroll by audreyjm529
Below is the first of a two part series on how to improve your app start-up times. – Erin
Every Millisecond Counts
In order to produce highly competitive app launch times, we need to trim the fat and refine our application code to bring users stunning results every time. In this post, we will explore some general methodology and hints and tips that you can use to improve your applications launch performance. This will also serve as your one stop shopping experience for links to as many relevant articles as possible that could help you shave off milliseconds from startup.
First off, you should understand the difference between cold, warm, initial, and usable launch. When we say an app launch is ‘Cold’, that means the system hasn’t had a chance to pool or pre-cache any of the application resources. An example of this would be launching an app for the first time after first boot. If you close the app and re-open it several times, this is known as a ‘Warm’ launch, and will produce different results. Time to launch ‘Initial’ view is how long the app takes to show the user its first frame. It usually ends up being some basic chrome before the rest of the content has loaded. This time is important to measure because it gives the user a sense of how responsive the system is, and this ‘immediate’ feedback is important for a competitive user experience. Finally, the time to ‘Usable’ launch is how long it takes to load the app, its chrome, and content that the user can interact with.
In a perfect world, we would want the time to cold launch a usable experience to seem instantaneous (<150ms) but we all know it’s not so easy! Therefore you should take the time to measure all of these scenarios, and try to optimize each one as much as possible to create a well-rounded and consistent user experience. World champions perform at or near the top, lap after lap, race after race. Consider the following strategies to help you minimize the start-up time of your app:
- If something isn’t visible initially, then don’t load it. This is a great way to save time on the initial view of your app. The idea should be to load things on demand, and reduce the set of components required for initial view to its bare minimum. Some examples of things to defer would be other qml pages (deferred tabs), expandable sections of the UI, and conditional images or components.
- Reduce app size. Take the time to look through your assets and optimize them. This means removing duplicates, and replacing single-colour images with a simple container. You can shrink your image assets using an app like pngcrush, utilize nine slicing, or opt for tiling with ImagePaint. All of these strategies can dramatically reduce an app’s asset footprint and save both memory and startup cost.
- Be aware of the different connection types in Qt. For example, multiple direct connections can result in more than one signal sent. This could be redundant and waste time on startup. Qt::UniqueConnection would solve this since it does not allow duplicates.
- Try to use QSettings sparingly, and don’t parse them multiple times during startup. Since this can be expensive, redundant or unnecessary calls are a waste.
- Keep the app constructor simple. Also be aware that the constructors of attached objects will get called when parsing QML, so keep those as simple as possible.
Next week we’ll discuss some more tips and tricks to reduce your app launch time!