Application startup speed

An App’s startup speed can affect a user’s first experience, and a slow (sensory) App launch can lead to a decrease in the user’s intention to start the App again, or to uninstall and abandon the App

This article will optimize the startup speed of the application in two directions:

  1. Visual experience optimization
  2. Code logic optimization

Visual optimization

There are three states of application startup, each of which affects how long it takes for the application to be visible to the user: cold startup, hot startup, and warm startup

Check out the Google development documentation for these three boot options

People talk about cold starts and hot starts

  1. Cold start: When an application is started, the system creates a new process and assigns the process to the application. This startup mode is cold start
  2. Warm start: when start the application, the background for the application of the process (example: press the back button, home button, although applications will exit, but the application process is still stays in the background, can enter a task list for), so in the case of existing process, this can from existing in the process to start the application, this way is called hot start

On cold startup, the application starts from scratch. In other states, the system needs to run running applications from the background to the foreground. We recommend that you always optimize against cold start assumptions. Doing so can also improve the performance of hot and warm starts

At the start of cold start, the system has three tasks. These tasks are:

  1. Load and start the application
  2. A blank startup window that displays the application immediately after startup
  3. Create the application process

Once the system has created the application process, the application process takes care of the next stages, which include:

  1. Creating an App object
  2. Start the main thread
  3. Fill loading layout Views
  4. Measure -> Layout -> draw

After the application process completes the first drawing, the system process swaps the currently displayed background window for the main activity. At this point, the user can start using the application

Since the creation of the App process is determined by the hardware and software of the phone, visual optimization is only possible during the creation process

Start theme optimization

Theme optimization is the setting of the theme of the startup window during cold startup (phases 1 and 2)

Because apps now launch into a LaunchActivity screen that displays App information

By default, there will be a blank screen. By default, the system will start a blank window when the application is started until the entry Activity of the App is successfully created and the view is drawn. Until the entry Activity of the App is successfully created and the view is drawn, the system starts a blank window when the App is started by default

You can view the implementation method of SplashActivit on the Android startup interface

Code optimization

How to calculate the startup time of the App in Android According to the output statistics of the startup time above, we can record the cold startup time before optimization, and then compare the startup time after optimization

Application to optimize

Application, as the entry point for the entire initial configuration of an Application, often carries a burden it shouldn’t

There are many third-party components (including the App itself) that preempt the initialization of the Application

However, heavy initialization operations and complex logic in the Application will affect the startup performance of the Application

Often, there is an opportunity to optimize these efforts to achieve performance improvements. Common questions include:

  1. Complex layout initialization
  2. Operations that block the main thread UI drawing, such as I/O reads and writes or network access
  3. Bitmap large image or VectorDrawable loaded
  4. Other operations that occupy the main thread

We can classify initializations according to the priorities of these components

  1. The necessary components must be initialized immediately in the main thread (the entry Activity may be used immediately)
  2. Components must be initialized in the main thread, but can be delayed
  3. Components can be initialized in child threads

Component initialization placed on child threads is recommended to be delayed so that you can see if there is any impact on the project

Therefore, for the above analysis, we can optimize the loading component of Application in the project as follows:

  • Bugly, X5 kernel initialization, SP read and write, friendship and other components in the child thread initialization. (Child thread initialization does not affect component usage.)
New Thread(new Runnable() {@override public void run() { Don't rob resources than the main Process. SetThreadPriority (Process. THREAD_PRIORITY_BACKGROUND); // The child Thread initializes the third-party component thread.sleep (5000); // It is recommended to delay initialization to see if other functions are affected, or crash! } }).start();Copy the code
  • Lazy loading of actions that need to be initialized in the main thread but don’t need to be completed immediately (this is supposed to be done in the entry Activity, but it is better to centrally manage component initialization in the Application)
Handler. PostDelayed (new Runnable() {@override public void run() {// Delay initialization component}}, 3000);Copy the code

Optimize the blinking page service

There are still a few components left to initialize the main thread, such as buried points, click streams, database initialization, etc., but these can be offset elsewhere

Requirement Background: The application App usually sets a fixed display time of the flash screen, such as 2000ms. Therefore, we can adjust the display time according to the running speed of the user’s phone, but the total time is still 2000ms

Total screen display time = component initialization time + Remaining display time

This is the total time of 2000ms, the component initialized 800ms, so show another 1200ms

About the App start process source can see the murderous programmer article: Launcher Activity work process

The Application initializes by calling the attachBaseContext() method, the Application’s onCreate() method, and the entry Activity’s creation and execution of the onCreate() method. So we can record the startup time in the Application

//Application @Override protected void attachBaseContext(Context base) { super.attachBaseContext(base); SPUtil.putLong("application_attach_time", System.currentTimeMillis()); // Record the Application initialization time}Copy the code

With the startup time, we need to know the time the Acitivty of the entry displays to the user (the View has been drawn). We learned from the blog (the View’s workflow) that the callback time of onWindowFocusChanged() indicates that the user’s touch time can be obtained and the View’s process has been drawn. So we can record the display time in this method

//Activity @Override public void onWindowFocusChanged(boolean hasFocus) { super.onWindowFocusChanged(hasFocus); long appAttachTime = SPUtil.getLong("application_attach_time"); long diffTime = System.currentTimeMillis() - appAttachTime; // The time from application to entry Acitity // so the time displayed on the splash page is 2000ms-diffTime.}Copy the code

Therefore, we can dynamically set the display time of the application flash screen, and try to make the display time of each mobile phone consistent, so that users with low mobile phone configuration will not feel the long time of the flash screen (for example, after the initialization of 2000ms, they have to display the flash screen time of 2000ms). To optimize user experience

Page optimization

The flash screen is followed by an AD page for the donor fathers

Because the pictures on the advertisement page in the project may be large pictures or APng dynamic pictures, it is necessary to download these pictures to local files and display them after downloading. This process often encounters the following two problems:

  • The AD page download, because it’s an asynchronous process, often doesn’t know when the right time to load onto the page is
  • Save the AD page, because save is I/O stream operation, it is likely to be interrupted by the user, the next time to get damaged pictures

Because the network environment of the user is not clear, some users may need a period of time to download the AD page, and at this time it is impossible to wait indefinitely. So for this problem we can start IntentService to download the AD page image

Start IntentService in the entry Acitivity to download the AD page. Or other asynchronous download operations

Record the image size after the AD page image file stream is fully written, or record a logo

In the next AD page loading, you can judge whether the AD page picture has been downloaded and whether the picture is complete, otherwise delete and download the picture again

In addition, there is still remaining display time in the flash screen page, so if the user has downloaded the picture and the picture is complete during this time, the AD page can be displayed. Otherwise, enter the main Activity, as IntentService continues to silently download and save images in the background

Blog.csdn.net/qian520ao/a… Ps: This author is really brutal… Writing long articles…