Startup of the application
For the first time to start
When the application is first started after installation, there is no use state and no local storage, that is, no content to load or initial data to download from the server. A typical first boot typically performs multiple tasks. Such as:
- Load application defaults (user defaults, subsystem configurations)
- Check the private/test version
- Gets and initializes the unique identifier of the application
- Initialize some third-party SDK configurations (crash collection, push, buried points, etc.)
- Initialize the network configuration and establish a network link
- Build the basic UI (navigator, themes, etc.)
- Pull the latest content and other updates from the server
- Create memory cache (data cache, image cache)
The cooks of these subsystems take a lot of time and may be dependent on each other, adding up to a lot of time.
For optimization we can do:
- Determine the tasks that must be performed before the UI can be displayed
- Perform tasks sequentially
- Split tasks that are executed in the main thread and tasks that are not in the main thread separately
- Other secondary tasks (log messages, trace events) are executed after the UI is loaded or asynchronously
The above optimization relies heavily on the control mode of the subsystem, mainly for crash reporting. A/B testing, burying points, networking, image caching, etc. Secondly, it can also provide a guide chart to extend the user’s use time and achieve the purpose of initialization.
Cold start
In addition to initial launch incidents, other app launches (clicking on the app icon to launch) may require restoring the original state, such as the chat history of messages, the last article page viewed by the user, the login certificate of the user, etc. Most of the pre-load states require loading data from the local cache or pulling data from the server. The old data is typically loaded and updated when the latest data is available, injecting both data sources into the view at the same time.
Warm start
Hot start refers to switching an application that is already running.
- Restart the application
When the user clicks the app icon, no special actions are required. Background and foreground notifications can be monitored when the application is in a safe state, or when many animations are running. In the first case, the app displays the login screen every time it is in the most advanced state, in the second case, the animation or game state is mentally suspended and needs to be restored.
- Deep links
When the application receives the application: openURL: sourceAppltcation: annotation: correction, is expected to jump to the application of specific page, the user wants to do. But the target application may have changed and be in a particular state. If the deep link needs to fetch data from the server, you can display the original page related to the deep link or display a progress bar and wait for the latest data to be retrieved from the server before refreshing.
Start after upgrade
The first startup after an application upgrade follows one of the following scenarios:
- Without local caching, an application abandons caching entirely
- Local storage is available and can be used directly or switched to the upgraded version.
No special processing is required if there is no local storage or if the application decides to forgo caching (for example, data is unavailable or faster to get synchronously from the server).
Notifies users when local data changes. The following best practices can make the user experience better.
- Notify the user of the situation if the wood cache is available. If there is no need to migrate to local level storage, there is no need to notify the user because local level storage usage is implicit.
- If you must take a few minutes to migrate the data, give the user an option to postpone the move.
- If it is faster and easier to retrieve data from the server, and therefore the use of local caching must be abandoned, the user needs to be notified in this case.