Theoretical basis for improving your App startup speed

1. To do a good job, you must first sharpen your tools.

The Analects of Confucius says: If you want to do your work well, you must first sharpen your tools. If you want to improve the startup speed of the App, we need to first find the points that hold it back. To find these points, we need to use our tools.

Many tools have been mentioned in the previous article. Today we will use Traceview to analyze our startup process.

1.1 Introduction to Traceview

Traceview is a performance analysis tool, which mainly analyzes the current thread status, the execution time of each method, etc. as follows:

Indicator Description:

Incl(Inclusive) CPU Time

The method itself and all sub-methods it calls occupy CPU time.

Excl(Exclusive) CPU Time

The method itself takes up CPU time.

Incl Real Time

The time taken from the start to the end of a method (including submethods).

Excl Real Time

The time taken for the method itself to start and end.

Call + Recursion Calls/Total

The number of times the method is called + the number of times the method is called recursively.

Cpu Time/Call

A method call takes up CPU time once.

Real Time/Call

The actual execution time of a method call.

Generally speaking, we use Real Time/Call sorting to find out the methods that take the most time.

It is necessary to explain CPU Time and Real Time:

• CPU Time: actual execution time of the method (excluding IO waiting time)
• Real Time method start and end time difference (including waiting time)

Reference: http://stackoverflow.com/questions/15760447/what-is-the-meaning-of-incl-cpu-time-excl-cpu-time-incl-real-cpu-time-excl-re/17902682#17902682

1.2 Traceview Usage

There are two ways to use Traceview:

a, through DDMS:

When you click Start, a box will pop up to select the trace mode. By default, "Sample based profiling" is selected:

Sample based profiling

The VM is interrupted regularly according to the sampling time interval to record the method call stack. The overhead is proportional to the sampling frequency.

Trace based profiling (based on complete trace data analysis)

Record the entry and exit of each method, and enable recording when each method is executed, no matter how small the method is, so the overhead is very high.

b. Use code:

 // Start where you want to start debugging
 Debug.startMethodTracing( "GithubApp" );
 // Stop at the appropriate place
 Debug.stopMethodTracing();

Note: The above method is equivalent to "Trace based profiling", which records the execution of each method. Android 4.4 and above can call startMethodTracingSampling() to enable "Sample based profiling" trace mode with code.

2. App startup process analysis

• To optimize the App startup process, you must first understand its startup process.
• For the specific process, please refer to this translation: Analysis of Android Application startup process.

3. How to start the app

Generally speaking, an App startup can be divided into the following three different states:

Cold Start

• The App has never been started or the App process has been killed. The App process does not exist in the system. Starting the App at this time is called a cold start.
• The cold start process is the entire App startup process described in Section 2, which requires creating an App process, loading related resources, starting the Main Thread, initializing the first screen Activity, etc.
• During this process, the screen will display a blank window (the color is based on the theme) until the first screen Activity is fully started.

The following figure shows the timeline of a cold start:

Hot Start

• Hot start means that your App process is just in the background, and the system just brings it from the background to the foreground and displays it to the user.
• Similar to a cold start, during this process, the screen will display a blank window (the color is based on the theme) until the activity is rendered.

Warm start

Between cold start and hot start, generally occurs in the following two situations:

• The user back exits the app and then starts it again. The app process may still be running, but the activity needs to be rebuilt.
• After the user exits the App, the system may kill the App due to memory reasons. Both the process and the activity need to be restarted, but the state saved by the passive kill lock (saved instance state) can be restored in onCreate.

Through the description of the three startup states, we can see that the startup optimization we want to do is actually for cold start. Hot start and warm start are relatively fast.

4. What are the enemies of App quick launch?

According to the cold start time chart, we can see that for App, the points of the startup timeline that we can control are nothing more than:

• Application's onCreate
• Rendering of the first screen Activity

Our current apps often integrate a lot of third-party services. When starting up, we need to check advertisements, registration status, and a series of interfaces, which are all done in the onCreate of the Application or the onCreate of the first screen.

• Many third-party platform SDK documents also suggest this.

5. Conclusion

Now that you understand the principles of App startup, know which parts of the App startup process are prone to blocking, and know what tools to use to analyze the execution time of each method, the next step will be easy.