Android Boot speed optimization Simple review

Android boot speed, basically no one said fast, usually after the system transplant, the immediate thing to see is to optimize the boot time, the following is a simple recall of the following before the optimization of those things.

Where do you spend your boot time?

Optimize the boot time, usually do the first is that there is no bug, obviously unreasonable first to solve, due to the development phase stability, some places may delay plus the large, or low frequency set, first note down, the back regularly will look again. These do not look at the words, generally get the machine, we count the boot time, mainly see the following several time period distribution:

1. Start button time, light screen time (basic fixed, unless a mistake, basic check OK)
2. Uboot Start-up time
3. After kernel boot to bootanim exit time

Our main concern here is the third, and also the focus of optimization. This part of the time, exactly what to do, the bottleneck is, can be clearly seen through the Bootchart. The following combination of the previous capture of the figure, briefly say (figure is a long time ago caught, more lazy, not run again the process)

The exit time of Bootanim is not truncated, the actual figure is there, about 33s is the end of time.

When we analyze this, we are divided into several time periods:

1. The kernel starts to start and executes to the INIT process. This can be seen through log.
2. Init process execution, mainly to deal with init.rc in the command, to the core and Mainl class service start time, you can see that the service is generally at a time point up, about 7.5S, this before a large period of empty window, but also to focus on
3. Zygote Start-up time
4. Each service start time in Systemserver
5. App launch (Systemui/launcher/keyguard.)

Above, the specific analysis look at each period of time:

1th other processing, the specific analysis of printing to see if there is an exception, this value is generally very small, unreasonable to work with the BSP colleagues to check the reasons.

The second main is init.rc execution of various commands, this can be measured in the Execute_one_command function, such as more than 100ms of the command to print out, and then analyze the location of the reason, where the command execution time is basically a bug, and BSP engineers to solve.

The 3rd main zygote startup problem, the main reason for slow, is to load resources and class library, this to read NAND, general card time is longer, the figure can be seen, zygote process a slip of small pink, indicating IO more. This preload process consumes time, in the Logcat log, also will print, generally speaking, are in nearly 10S or so.

Fourth, after the initialization of zygote, will fork system_server. The system_server process starts and takes a long time. According to the results of the previous statistical analysis, the service here is basically spent in the Packagemanagerservice Packagescan, which is a read file, card in the file read, the length of time, and the number of pre-fabricated apps and installed apps

Fifth time, is basically ready to prepare, start launcher and other applications, after the start of the completion, Systemserver request Surfaceflinger killed Bootanimation, started to complete.

The above time, mainly to optimize, or the third step and the fourth step of the IO slow problem, the other can be optimized not much. such as CPU, normally open quad-core performance mode start, also did not raise much, generally we do not care about this.

How to optimize?

After determining the direction of optimization, we mainly look at how to optimize these two time-consuming areas:

1. Zygote's preload resources and class

2. Packagemanagerservice Packet Scan

Here the first, the earliest before someone directly removed preload or cut, although you can speed up a little boot speed, but Penny Wise lost watermelon, can not do so ~

Our earliest implementation of the way, is to do parallel processing preload, after all, is now a multi-core processor, and is the preload is loaded after the resolution of processing, parallel will have a certain amplitude increase.

For packet scanning, this is not easy to split into parallel tasks, not as simple and clean as preload. Consider the Packagemanager information serialized after the save, the next boot will not sweep, but looks like a little change, not too good to engage, also gave up.

Finally, the way we implement it is the more readahead mechanism used on Linux. Specific implementation details are not expanded to say, the principle is:

1. Statistics during the boot process, read the block data information, record down to save

2. Power up again, through the recorded block data read information, directly from a service, pre-start reading, zygote or Packagemanagerservice to read the file, the file data is already in the cache.

The actual use of this trick is particularly good, the optimization is very obvious. The following is a Bootchart diagram that implements a readahead:

can see:

1. Zygote and System_server are speeding up.

2. Zygote and System_server io time, both reduced very large

3. Main IO time, run to the readahead process.

However, the above implementation, there is still a place to optimize:

1. The readahead process can be started again in advance, immediately after the system partition is mounted so that the IO in the zygote should be reduced

2. To System_server io, at this time ReadAhead is over, supposedly should not have, here or there is IO, which is generally after the APK led, this can be readahead do more robust, do not only learn to start one or two times.

Optimization of other NB

In addition, there is a very NB technology, is the Std. We've done this, and we've spent a lot of manpower and resources. STD boot time, not counting on uboot time, the basic is within 10S, 5~8s between. But so NB Technology, is now basically obsolete, with a lot of problems:

1. Boot time is low, the shutdown time is elongated.

Because it is STD (Suspend to Disk), the memory data needs to be written to NAND when shutting down, which is a very troublesome thing.

2. Stability

itself STD get up is more complex, bug quite many, in addition to use STD, is equivalent to never shut down, this also too test system software stability ...

3. No hair use

At first can be fooled customers, but then no one cares about this feature, do not give themselves to find work, we are not willing to make it

Android Boot speed optimization Simple review