Android cold start optimization you must master

Preface

The incident happened two days before the package was released and launched. When conducting mobile testing on a certain cloud, it was prompted that the cold start speed was lower than the average. I had tried to optimize it before, but found that the effect was not very obvious. As an aspiring developer, I have to take advantage of some free time to study the cold start optimization problem.

App startup process

We can learn about the description of App startup in the official document "App startup time". Application startup is divided into cold start, hot start, and warm start. Cold start is when the application starts from scratch, which involves more complex knowledge. This time we mainly analyze and optimize the cold start of the application. When the application is cold started, it needs to perform the following three tasks:

• Load and launch the application;
• A blank startup window is displayed immediately after the app is launched;
• The process of creating an App program;

After these three tasks are executed, the system creates the application process, and the application process will execute the next step:

• Create an App object;
• Start Main Thread;
• Create an Activity for the startup page;
• Load View;
• Arrange the screen;
• Perform initial drawing;

When the application process completes the initial drawing, the system process replaces the currently displayed background window with the Activity of the startup page, and the user can use the App at this moment. The following figure shows the workflow of the system and application.

From the above figure and the above steps, we can know that when the application process is created, it will definitely execute the life cycle of our Application. After the application process of the App is created, the main thread will initialize our first page MainActivity and execute the life cycle of MainActivity. I deliberately bolded the key points, which is the part we can start to optimize. Before analyzing how to optimize, we can first understand whether our application needs to be optimized for cold start.

PS: In fact, these are just what we see on the surface. If we need to fully delve into it, we need to specifically analyze the Zygote Fork process, ActivityManagerService source code, etc. We will not go into details in this article. I recommend relevant books, including Luo Shengyang's "Android System Source Code Scenario Analysis" and Liu Wangshu's "Android Advanced Decryption".

Startup time detection

So what is the appropriate startup time? The official document describes that when the cold start time is 5 seconds or longer, Android vitals will think that your app needs cold start-related optimization. However, Android vitals is an application quality detection tool for Google Play, so everyone knows that. But you can use Alibaba Cloud's mobile test like me. In the data provided by Alibaba Cloud, the median of the cold start industry indicator is 4875.67ms. You can compare it as appropriate. Okay, let's talk about how to detect the cold start time of our application.

Displayed Time

As shown in Figure 1 above, in Android 4.4 (API level 19) and higher, logcat contains a log message called Displayed. This value indicates the amount of time that has passed between the startup process and the completion of drawing the corresponding activity on the screen.

ADB Commands

 adb shell am start -W [packageName]/[packageName.MainActivity]

When using the previous method to print the Displayed Time log, we see the Displayed log, followed by the [packageName]/[packageName.MainActivity] we need below. We can copy and use it directly, and then paste it in the AS Terminal, and then print out the startup time data of the specified page.

 Status: ok
 Activity: com.xx.xxx/com.xx.xxxx.welcome. view .WelcomeActivity
 ThisTime: 242
 TotalTime: 242
 WaitTime: 288
 Complete

• ThisTime: refers to the time from the last Activity start time to the end of the startActivityAndWait call of this Activity during the calling process;
• TotalTime: refers to the time from the start of the first Activity in the calling process to the end of the startActivityAndWait of the last Activity.
• WaitTime: is the time taken to call the startActivityAndWait method;

reportFullyDrawn

In some special scenarios, we may not only need the callback time of the startup page drawing completion to be sufficient, but also need to successfully callback the splash screen advertisement interface data of the startup page to count as a complete time. In this case, we can use reportFullyDrawn

 public class WelcomeActivity extends MvpActivity<WelcomePresenter> implements WelcomeMvp. View { 
 
 @Override
    protected void onCreate(@Nullable Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_welcome);
 // Request data
        mvpPresenter.config(); 
 
 } 
 
 @Override
 public void finishRequest() {
 //Data callback
 reportFullyDrawn();
 }
 }

PS: This method requires minSdkVersion API19+, so you need to set or judge the SDK version.

Traceview

Traceview is a very useful performance analysis tool for Android devices. It allows us to track the performance of the program through a detailed interface, and clearly view the time consumption and number of calls of each function.

Systrace

Systrace intuitively displays the calling sequence and time consumption of the API on each thread.

Traceview and Systrace are both tools of the DDMS panel, but they are no longer recommended for use in versions above AS3.0, so I will not go into details here. If you are interested, you can read my previous article "Android Application Optimization: Fluency Practice", which explains the usage of these two tools in detail.

hugo

github.com/JakeWharton…

• We can use JakeWharton's hugo to get the time consumed by the corresponding class or function through annotations. We can use it to dig out details of the life cycle of the startup page Activity.

Start optimization practice

User experience optimization

I personally think that the main experience of cold start optimization is to eliminate the white screen/black screen at startup, because the first impression of the white screen/black screen for users is slowness and jamming. We can set the theme of the startup page to achieve this goal.

WindowDrawsSystemBarBackgrounds is the setting for some system operation bars. Next is the layout of the background color of this window.

 <layer-list xmlns:android= "http://schemas.android.com/apk/res/android" android:opacity= "opaque" >
  <item android:drawable= "@android:color/white" />
 <item>
 <bitmap
      android:src= "@drawable/welcome_bg"  
      android:gravity= "center" />
 </item>
 </layer-list>

After the ad on the startup page is displayed, jump to the home page, and then we set it back to our general style, which can be set in the manifest file or in the code.

 <activity
 ···
    android:theme= "@style/AppBaseFrameTheme" />

After setting the theme of the startup page, the white/black screen will be erased, and the startup image will be displayed when the user clicks the App icon, giving the user the "illusion" that the startup is very fast. At the same time, animation can be used to make the transition between the startup page and the home page more natural.

Application startup optimization

From the analysis summary of Figure 1 above, I have highlighted the optimization point Application life cycle in bold. Now let’s come back and optimize this part.

1. Application#attachBaseContext()

When the application is started, it will go through attachBaseContext()-->onCreate(); what do you think of the life cycle of attachBaseContext at this time? That's right, it is the MultiDex sub-packaging mechanism. I believe everyone will find that since the number of our methods has exceeded 65535 and processed the sub-packaging, the problem of white screen/black screen at startup has appeared. The sub-packaging mechanism is an important reason for the slow cold start. Now some applications use plug-ins to avoid the white screen problem caused by MultiDex. Although this is a method, the development cost is really high and it is unnecessary for many applications. Let's talk about MultiDex optimization. First of all, MultiDex can be divided into two parts: runtime and compile time:

• Compile time: Split the classes in the App into multiple dexes according to a certain strategy to reduce the number of classes contained in the first dex, that is, the main dex;
• Runtime: When the app starts, the virtual machine only loads the classes in the main dex. After the app starts, use Multidex.install to modify the dexElements in ClassLoader through the reflection mechanism to load other dex;

From the practice analysis of many articles on the Internet, they mainly adopt the asynchronous method. Because the App will load the main dex package first, we can handle the sub-packaging work independently. We divide the main classes such as libraries and components required for the startup page and the homepage into the main dex, so as to achieve the size of the main dex package. For the specific operation method, you can refer to the MultiDex startup optimization article on the Internet, but you should pay attention to the main dex sub-packaging process. The main dex has been reduced in size through a series of optimization operations, which also increases the possibility of NoClassDefFoundError exceptions, which will lead to the risk of our application startup failure. So we must do a good job of testing after optimization.

2. Application#onCreate()

After attachBaseContext(), it is time for onCreate() life cycle. Most of our applications will initialize the third-party libraries and components we use here. Due to the continuous iteration of versions, the initialization of third-party libraries is written directly in onCreate(). A lot of initialization work makes this life cycle too heavy. We should classify these third-party libraries. The following is the classification of the work of starting our app:

Looking at the above picture, the initialization of various third-party tools and business logic affects the startup time. Let's split them into four parts.

• Must be initialized in onCreate() and in the main process
• Can be delayed, but needs to be initialized in Application
• Initialization can be delayed until the lifecycle callback of the startup page
• Delay initialization until it is needed

You can list each initialization of your own project according to your own project, and then classify them. Although I did not post the specific operation code here, it is not because I think it is too simple to create a new thread or an IntentService, but the things that need to be paid attention to here are the most optimization of the entire cold start, because I have also stepped on the pit here. Take the example of GrowingIO. At that time, the project used a very old version of GIO. At that time, the initialization of GIO was placed in the child thread operation. Suddenly, before the contract was issued, the operation department proposed to upgrade the SDK version of GIO. After the upgrade, the compilation and operation felt that there was nothing to do, so they packaged it directly. After going online, the operation feedback that the new version did not have the circled data. After inspection, it was found that the new version of GIO could not be initialized in the child thread. From this lesson, I think that since you are interested in cold start optimization, you must not be short of a few sentences of copy and paste code. These all require specific analysis of specific situations. Let me summarize the key points.

• Slow startup does not mean you can just start a thread and then plug in the code. You need to find the right solution.
• Opening a thread is also a science. Which one should I choose among Thread, ThreadPoolExecutor, AsyncTask and IntentService?
• Suppose you have created a new Thread, but have not considered the memory leak problem. Don't dig holes while patching them.
• Note that some third-party SDKs need to be initialized in the main thread;
• If the application is multi-process, please note that some third-party SDKs require you to initialize it in the process with the same package name;
• In fact, there are many projects that have not sorted out their codes after years of version iterations. Those old and useless codes need to be classified and sorted out;

Optimization of startup page Activity

Layout optimization Our startup page Activity contains startup image controls, splash screen ad image controls, splash screen ad video controls, and *** installation introduction image controls. For layout optimization, except for the startup image control, the others are not controls that need to be initialized when the App starts. In this case, we can use ViewStub to initialize the specified controls for the specified business scenario.

Avoid I/O operations We know that I/O operations are not real-time, such as database reading and writing, SharedPreferences#apply(). We need to pay attention to whether these operations block the main thread. At the same time, we can use StrictMode strict mode to detect whether we have performed disk reading and writing operations correctly at startup.

Pay attention to the loading speed and encoding format of the image bitmap. We know that the startup page is mostly a display of images, so how do we get details in terms of images? That is to choose various third-party image loading libraries such as Glide, Picasso, Fresco, etc., and the selection of PREFER_ARGB_8888 and PREFER_RGB_565. You can choose according to your own project situation.

The core of vector graphics is to save time and space. For some users, their startup image may not be a picture, but a very simple logo. At this time, we can consider the use of vector graphics.

Pay attention to the callback of the startup life cycle in Activity. We optimized Application#onCreate() and moved some unnecessary network requests to the welcome page. However, we cannot directly copy this network request operation to the onCreate() of the startup page. We can cleverly use Activity#onWindowFocusChanged(boolean hasFocus) in the Activity life cycle. This is the real callback after all controls are initialized. We can put the network operation here. Of course, we can also use Service.

Summary of Cold Start Optimization

For cold start optimization, we need to analyze step by step, unlike layout optimization, which is a copycat approach. Therefore, the term bottleneck appears many times in official documents, which shows that our cold start optimization journey will not be smooth. We should make good use of Android Studio's CPU profiler (we will analyze the use of this function in detail when we have the chance), because many summaries on the Internet are through Traceview and Systrace, but these two have been abandoned in the upgrade of AS3.0 version, which reflects that we should read official documents frequently and think about the changes of Android from our own perspective, rather than through the translation and analysis of others. Let's encourage each other. In the current Android market, competition is becoming more and more fierce. In order to win in the comparison of competing products, we still need to do a good job of each detail step by step.