APP is generally divided into hot startup and cold startup
- Cold start means that before the APP is clicked to start, its process is not in the system, and the system needs to create a new process and assign it to start. This is a complete start process.
- Hot startup refers to that after cold startup, the user exits the APP and hangs it in the background. At this time, its process still exists in the process of the system. The user needs less time to start here and can do few things.
This is only optimized for cold start.
First of all, we need to know what the App is doing at startup so that we can optimize for it. The startup of App can be summarized into three stages:
The main ()Before function executionThe main ()After the function is executed- The first screen is rendered
Before the main () function
Before the main () function is executed, the system does several things:
- Load executable files (collection of.o files for APP)
- Load the dynamic link library, adjust the Rebase pointer and bind the bind symbol
- Initial processing of Objc runtime, including registration of Objc related classes, category registration, selector uniqueness checking, etc
- Initialization, including execution of the +load () method, invocation of the attribute(((constructor)) modified function, and creation of C++ static global variables
What can be done to start speed optimization in this phase:
- Reduce dynamic library loading
- Reduce classes or methods that will not be used after loading starts
- The contents of the +load () method can be placed after the first rendering is complete, or replaced with +initialize ()
- Controls the number of C++ global variables
Main () after the implementation of correspondence
Refers to the main () after the execution stage, from the main () to the appDelegate didFinishLaunchingWithOptions method in the first screen rendering completes relevant methods.
- Initialize the read and write operations of the configuration file on the first screen
- Read big data from the first screen list
- A lot of calculations for the first screen rendering
A more optimized development approach here is to determine which initializations are necessary for the first screen rendering, which are necessary for APP startup, and which only need to be initialized at the start of the corresponding function. After sorting them out, put them in the corresponding stages for initialization
After rendering the first screen
This stage is from the beginning of the rendering is finished, to the end of the didFinishLaunchingWithOptions method at the end of the scope. At this stage, users can already see the home page information of the App, so the optimization level is put at the end, but time-consuming operations should be dealt with first, so as not to affect the user experience.
Startup optimization at the function level
Starting from the stage after the execution of main () function, the idea of optimization is to only deal with the operations related to the first screen rendering from the execution of main () function to the completion of the first screen rendering, and the initialization of non-first screen services, listening registration, configuration file reading and other operations will be processed after the first screen rendering layer.
Method level optimization
Check if there are any time-consuming methods on the main thread before the first screen rendering is complete, and execute unnecessary time-consuming methods after or asynchronously. In general, the time-consuming approach occurs when computing large amounts of data, such as loading, editing, and storing resources such as images and files. There are two ways to monitor App startup speed:
- Periodically capture the main thread method call stack, calculate a period of time method time
- Hook the objc_msgSend method to see how long all methods take