iOS startup optimization

Start speed optimization background:

Our project is an old project with many years of development and iteration. Before that, we did not pay much attention to the startup performance of the project. As a result, the startup speed of the APP was relatively slow. The startup sometimes took 3 or 4 seconds, and the overall startup performance was worrying. Our supervisor arranges me to be responsible for optimization, and I will do my best to optimize the startup speed of the APP.

Encountered challenges:

There are two biggest challenges. One is that the code history code performance consumption is not controlled, and there are unreasonable codes in many places; the second is that as a newcomer who has just joined the company, it needs to be optimized within one month, and the time is tight and the task is heavy;

Optimization steps:

First of all, we sort out the goals, iOS startup can be divided into cold startup and hot startup. A cold start means that the APP itself is not in the background system, from the user clicking the app icon to the completion of the appDelegate didFinishLaunching method until the user sees the home page of the APP; a warm start means the APP itself runs in the background of the system, from the back to the click to enter the APP scene. Our focus is on optimizing the speed of cold start, the start speed time target is reduced from 3s to 1.2s;
After having a clear goal, the next step is to disassemble the goal. To optimize the cold start, we need to know what the cold start process does, and which part of the execution node takes more time. App cold start can be roughly divided into three stages. The first stage is before the main function, the system performs a series of loading and linking work; the second stage is after the main function, from the main function to the completion of didFinishLaunchingWithOptions of AppDelegate; the third stage It is from the execution of didFinishLaunchingWithOptions to the rendering of the APP's homepage; we need to optimize from these three stages. First, we need to analyze the time-consuming situation of these three stages.
To measure the time before the main function, we can configure xcode. In the editScheme of xcode Run→ Environment Variables, add the name DYLD_PRINT_STATISTICS to 1, so that an output report example in the xcode console can be as follows:

From the above figure, we can clearly understand the time consuming before the main function, as well as the time consuming to load the dynamic library, the time consuming to initialize the oc class, and the time consuming to redefine the pointer. After the main function, we can count by adding timing code, this piece of statistics is relatively simple;

Core optimization before main function: mainly includes optimization of dynamic loading library, Rebase/Binding optimization and optimization initialization phase

Dynamic library loading optimization:
We mainly carry out two optimizations,
1. Eliminate the embedded dynamic library, because the system loads the embedded dynamic library will consume relatively large performance;
2. To reduce the number of dynamic libraries, you can achieve the goal by merging existing dynamic libraries. The more dynamic libraries, the higher the performance overhead;

Rebase/Binding optimization:
Mainly carried out 2 types of optimization,
1. Reduce oc categories, reduce methods, and reduce the number of categories;
2. Using Swift structs can greatly reduce the number of symbols;

Initializers stage optimization: The core is to reduce the use of the load method. The more load execution code, the slower the startup will be. We can delay the implementation code of the load in the initiailize method. The initiailize method will not affect the startup speed of the APP;

Main function post-stage optimization: The core optimization idea at this stage is to reduce the performance consumption of the main thread. The initialization of the basic components can be delayed, and the initialization of the sub-thread can be placed in the sub-thread initialization.
After the above optimization, the startup speed of our APP has been greatly improved, from the original 3s to about 1.2s.

Access summary and suggestions: The overall access is still relatively simple, and the official website is relatively clear in terms of overall documentation. The entire apm does a good job of crashing. Compared with the listening cloud and bugly used before, it is still good. It is particularly good in the comprehensiveness of information collection. In addition, it is better in terms of crash log analysis and accuracy. The crash stack is easier than other products. Understand.

Recommendations for the product: The following problems are found during use, and it is recommended to refer to optimization
(1) After registering from u-apm, I can’t find any content about u-apm on the homepage after registration. After registering, I registered an APP and found that it was connected to the basic SDK of Youmeng, which was not what I wanted. Only found u-apm by returning to the event.
(2) I want to access a version without idfa, but I can't find it. Look at the access and notice that idfa is mandatory. Positioning and idfa countries have restrictions on our industry, especially location permissions are not allowed;
(3) The video played on the official website is superimposed with the introduction below and cannot be viewed in full screen (Safari browser)
(4) In the overview, the crash rate and ANR description use specific terms, and now they all use "error" collectively, which does not conform to the development cognition. For example, the crash is the crash rate, and anr is called anr instead of being collectively called crash;
(5) For the real-time overview, I would like to see some general data tables, such as crashes, Android crashes, and hope to see the total crashes of java and native bottom layers. In addition, it is recommended that the real-time overview increase the freeze rate, network error rate, startup speed, etc. An overview map of indicators; additional details such as freezes and crashes will be added to the secondary page;

Author: Midsummer
Engaged in iOS development for 5 years, doing social and educational APP development