Highly recommended article: Welcome to collect Android dry goods to share

##### Read five minutes, 10 o ‘clock every day, and learn for life with you. This is Android programmer

Users expect the APP to respond and load quickly. An APP that starts slowly and doesn’t live up to expectations may disappoint users, and may lead to poor reviews and uninstallation of your APP.

This article will discuss how to optimize the startup time of your APP. First, we need to understand the relevant content of APP startup.

Through this article, you’ll learn the following

  1. App startup mode classification
  2. Cold startup in applications to avoid white screen, black screen solution
  3. Framework layer solution cold start white screen, black screen solution
  4. Principle of App startup optimization
  5. Introduction to App Startup optimization
  6. App startup optimization scheme
  7. App starts optimization scheme in PMS

1. App startup mode classification

App startup modes fall into the following three categories:

1. Cold startup 2. Hot startup 3

  • 1. The cold start

APP starts from scratch. Before APP starts, the system does not create a separate process for APP. For example, after the device is started, the APP is launched for the first time or the APP is killed. This type of startup optimization is challenging because there are many more background processes running on the Android system or application.

The startup process is as follows:

Click the icon on the Launcher to start loading the app –> display the white screen or black screen immediately –> Application onCreate –> Activity Init—-> Activity onCreate –> initialize the data, Fill in the display View –> Activity onResume, please see the following figure for details:

    1. Warm start

Hot startup of an APP is much easier than cold startup, and the memory overhead is lower. All systems bring your Activity to the foreground when an APP is hot on. If all of the APP’s activities remain in memory, the APP can avoid repetitive object initialization, layout drawing, and display. If the APP is cleaned up in memory, such as by calling ontrimMemory (), these objects will be created again when the response is hot started.

Hot start has the same screen behavior as cold start: the system process displays a blank screen until the blank screen is removed after the application finishes rendering. The screen creation is created immediately after the APP loads. To see the creation process, look at the AddWindows method in PhoneWindosManger.

    1. Warm boot

Between cold start and hot start, it contains both some operations of cold start and some functions of hot start. For example, the following two states:

  1. User exitAPPafterLaunch.

At this point, the APP process may exist, and the Activity must be recreated and call the onCreate method

  1. When the APP is cleared from the cache.

When the user relaunches the APP, both the APP process and the Activity need to be re-created, but some APP instance data (bundle type) will be stored in the task stack and an Activity onCreate method will be passed

2. Measurement and analysis of App startup time

In order to more accurately measure the startup time of APP, please be sure to use the User version for verification. The UserDebug or ENG version has many debugging switches that affect the normal results of the test.

How to obtain the startup time of APP, please see the following measurement method

Main: The following test methods should be performed on Android 4.4 and later versions

1. Use ADB command to measure APP cold startup time

The method of using ADB command to directly start APP and then measure the startup time of APP is as follows:

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

Or adb [-d | -e | -s < serialNumber >] shell am start – s – W/packageName] / [packageName. MainActivity] – c Android. Intent. The category. The LAUNCHER – a android. Intent. Action. The MAIN as to measure the app without source, such as: QQ, please use the following command to get, the current focus of the Activity, method information is as follows:

adb shell dumpsys activity |findstr "mFocused"

Please refer to the ellipse red box in the following picture for details of APP startup time.

2. Run adb Logcat to check the APP startup time

The Displayed time of the APP in ActivityManager: Displayed is analyzed in the Log. The Displayed time contains the following comprehensive information:

  1. Launch process
  2. Initialize an object
  3. Create and initialize the Activity
  4. Fill in the layout
  5. Draw app content for the first time

For example, in the following figure, the startup time of ProgramAndroid is 700ms

3. The method of measuring app startup performance in the code is as follows:

In the Activity code, call reportFullyDrawn(); Method to feed the information back to Log after drawing, similar to the time viewed in logcat. For example, the startup time of running ProgramAndrod APP is as follows

11-24 11:47:00. 363 982 1191 I ActivityManager: Fully drawn. Com programandroid /. MainActivity: + 998 msCopy the code

4. Use Systrace to analyze the startup time of the app

Of course, if you feel that the above method is troublesome, you can use Systrace tool for analysis, tool analysis of the situation, next post.

2. Cold startup to avoid white screen and black screen

When the APP is started for the first time (not in the recent task list, or has been running but has cleared the startup record in the recent task list), it is called cold start. In this case, the white screen or black screen flashes when the APP is opened, especially when the system theme is black or white.

Circumvented open APP flash on the application end white and black screen problem, mainly from android: windowIsTranslucent make white transparent, and not let the user see white and black screen.

However, this solution will lead to a slight lag phenomenon when clicking the APP icon in the Launcher, which will make users mistake the mobile phone card and slow APP startup, thus blaming the mobile phone manufacturer for opening the blinking white screen of the APP.

1. The solution is as follows:

    1. Custom transparent styles inres/values/style.xmlCustom styles in

    1. Custom styles are used in the App launch entry Activity

Note: The windowDisablePreview =false attribute can prevent the blank screen display. Losing the excessive blank screen in the middle will bring users a bad experience. For example, after clicking, they need to wait a little before opening the APP, which will make users mistakenly doubt whether they have successfully clicked the icon. Google strongly discourages this practice.

2. Use the app logo and other picture styles as follows

  1. Custom Theme

  1. Set a custom style for the Activity to start

  1. You can also set styles in Java classes

This method is also recommended by Google. It is suggested that you can use a custom Theme to replace the white screen in the system. Of course, you can also make any advertising pages and so on.

3. The Framework layer solves the cold startup white screen and black screen solution

The root cause of opening APP flash black screen and white screen is the addStartingWindow method in PhonewindowManger.

After such modification on Framwork, the white screen will be replaced with our customized color, which will affect the startup of all apps.

4. Principle of App startup optimization

After version L, all apps on mobile phones need to be processed by Dex2OAT before they can be run. Dex2oat is a pre-translation of the original DEX file, so as to speed up the running time of apps.

Dex2oat optimization is based on method in DEX file. Dex2oat will optimize a certain amount of method as required, that is to say, not all optimized methods will be translated into OAT mode.

According to the amount of optimization method, it can be divided into the following modes:

5. Introduction to App startup optimization

For later versions of Android L, if there is no special processing, the APP startup mode is Speed mode, which has good performance, but the optimized file occupies a large space. For different modes, see the reference standard provided by MTK above.

The optimization of APP is carried out through Dex2OAT, and the parameters of the optimization mode are controlled by the external parameters transmitted by calling Dex2OAT method. If there is no transmission parameter, the default parameter is Speed.

So what are the paths to call Dex2OAT?

  • 1. When installing the APP

The parameters are passed to mAppInstallDir through the PackageManagerService in the Framework, which then calls Dex2OAT, so the optimization mode in this way is controlled by PMS.

In this mode, the path of APP, the optimized OAT storage path, is transferred to Dex2OAT. However, as the content may change, we may not be able to identify APP in Dex2OAT. Therefore, at this time, we can judge in InstalLD or PMS whether it is an APP that we think is slow to install. If so, we can change its optimization mode.

    1. When the APP itself optimizes the plug-in

This mode usually specifies the mode as speed mode or does not specify the package name of the APP in the optimized save path.

At present, some APK apps, such as Facebook and WeChat, are large and have high code complexity, which may lead to installation failure and slow installation.

The installation failed because the dex2OAT process was compiled too long and reached timeout. Of course, the slow installation is the reason for the long compiler made by Dex2OAT.

In addition, apK like WeChat will optimize the plug-in when the application is launched (instead of being optimized when the application is installed), which will lead to the application lunch time is too long, giving users the feeling that they are late in the application, and the mobile phone is stuck and so on, which makes the mobile phone manufacturers bear the burden. If you need to change the optimized mode to speed up the installation time, please note that this change will reduce the performance of the APP.

Note: The duration of APP installation/lunch depends on the number of CPU cores. An 8-core CPU is definitely faster to optimize than a 4-core CPU. In addition, it depends on EMMC performance, memory, and other system factors.

6. App starts the optimization scheme

There are currently three areas where APP optimizations can be addressed.

    1. In the PackageManagerService

This place is the only way to install APP, and the code storage address is as follows:

    1. The installd commands. The CPP

This is also the only way to install the APP. The code store address is as follows:

    1. In the dex2oat

Ex2oat is the gateway for all APP or JAR packages, but may not be recognized due to the limited parameters passed to Dex2OAT.

Therefore, changes can be made in PMS for installed APPS and dex2OAT for JAR packages. Because in PMS, we can know the PKG information of APP, which is unique to each APP. For JAR packages, each APP likes to put the optimized JAR package under its installed APP path when it is optimized. So, you can use this feature to judge.

7. Start the optimization scheme in PMS App

This solution works with Android N

The packageDexOptimizer.java file is optimized in the performDexOptLI method.

In this function, we can determine if the PKG passed is the APP we want, and if so, set targetCompilerFilter to speed-profile. Speed-profile takes interperter-only at installation time, and then optimizes those commonly used methods to speed mode after running for a while. In other words, selective optimization.

At this point, this has ended, if there is wrong place, welcome your suggestion and correction. Meanwhile, I look forward to your attention. Thank you for reading. Thank you!