Android Startup slow Cause analysis

Startup took more than 40 seconds, the normal boot only need 28 seconds to boot up.

Start of the kernel I did not analyze, another colleague analyzed. I mainly analysis from the systemserver to boot animation end show Unlock the interface of this time, that is, the start of the animation of the third animation to end this period of time, this is a more time-consuming phase, generally in about 17 seconds (see Cow b mobile phone, only 5 seconds).

Systemserver is performed in two steps: Init1 and Init2. INIT1 is primarily the initialization of native services, the code in System_init.cpp System_init, initialization of the Surfaceflinger and sensorservice of these two native services. Init2 started with Java services, such as Activitymanagerservice, Windowmanagerservice, Packagemanagerservice, etc. Packagemanagerservice takes the longest time in this process because Packagemanagerservice scans the jar packages and apk files in a specific directory.

When the boot time takes more than 40 seconds, you can see from the log that the initialization from Surfaceflinger to the end of the animation takes about 27 seconds, that is, from Surfaceflinger::init logi ("Surfaceflinger is Starting ") This log to void surfaceflinger::bootfinished () logi (" Boot is finished (%ld ms) ", Long (ns2ms (duration)), It takes about 27 seconds, which is obviously too long, but where is the slow? should be in the middle of the point, two points, so think of the start before and after the service as a separate: is the service startup slow, or after the service started this period of time slow? This log of Activitymanagerservice's SLOG.I (TAG, "System now Ready") is a split point, contrasting it from Surfaceflinger is starting to system now Ready more than 7 seconds of time, this shows that systemserver in the init1 and init2 process start slow, through the investigation, found in the init1 started, spent 7 seconds more time, that is System_init Logi ("entered System_init () ") to Logi (" System server:starting Android RUNTIME.N ") This time takes more than 7 seconds, and the normal situation is 400 milliseconds can be initialized, by adding log see, It took a long time for the sensorservice to start.

Constantly add log found that when the startup Sensorservice, shut down the device file slowed down, every time the device to close a/dev/input/need about 100ms, and Sensorservice have 60~70 close the file, about 7s of time.

The calling process is:

Frameworks/base/cmds/system_server/library/system_init.cpp:system_init->sensorservice::instantiate

Frameworks/native/services/sensorservice/sensorservice.cpp:void sensorservice::onfirstref ()->SensorDevice & Dev (sensordevice::getinstance ())

Hardware/libsensors/sensordevice.cpp:sensordevice::sensordevice ()->sensors_open

hardware/libsensors/sensors.cpp:open_sensors->sensors_poll_context_t

sensors_poll_context_t when you open each sensor device, traverse the device files in the/dev/input/directory to match the device that you currently need to open, and traverse the file in

Hardware/libsensors/sensorbase.cpp Openinput, if an open device file is not an open device file, executes the else part of the following statement:

if (!strcmp (name, InputName)) {

strcpy (input_name, filename);

Break

} else {

Close (FD);

FD =-1;

}

Close each time you need about 100ms, every time you open the sensor part of the operation to do so, resulting in this has about 7s around the delay.

After this time, the system startup is 7 seconds faster, but still slow, because the comparison can be found:

Boot 28 seconds:

04-16 16:14:22.205 140 343 I surfaceflinger:using Composer version 1.0

04-16 16:14:34.167 527 542 I Activitymanager:system now ready

04-16 16:14:39.089 140 605 I Surfaceflinger:boot is finished (16985 ms)

Boot 34 seconds:

04-18 15:32:55.565 I/surfaceflinger (242): Surfaceflinger is starting

04-18 15:33:05.214 I/activitymanager (622): System now ready

04-18 15:33:17.658 I/surfaceflinger (242): Boot is finished (22091 ms)

Visible or slow 6 seconds. But this 6-second slow seems to be in the service after the start of the time, this time more difficult to analyze, because this is all the service up, and issued a Bootcomplete broadcast, application also began to get up, but not unlocked, began to think is launcher up slowly, But a Google original launcher went in, and did not get faster.

We use two versions of mobile phones, W-mode with TD, come over a few days to find TD's mobile phone faster than W, and TD 28 seconds to get up, but W but to 34 seconds, asked the driver of the colleague, W and TD and no difference, so in addition to the modem is not the same, the other is the same. Looking for a day, still no result. From the log, it's only slow, that's slower, only in the process of scanning the package, the w+gsm takes about 6 seconds, and td+gsm only takes about 3 seconds, but it doesn't take 6 seconds to Packmanager. But the software version is the same, guessing is a hardware problem, but the hardware is the same, in addition to the modem is not the same, began to suspect modem,w+gsm is the normal boot mode, and td+gsm is in the MBP mode boot, make the same boot mode, still did not change two boot time. To the most only found that W's mobile phone with a 16G of eMMC, and TD's mobile phone is 32G eMMC, and 32G eMMC than 16G eMMC read and write faster, thought found the reason, the result is very disappointed, through the electronic colleague, the EMMC switched, the boot speed is still unchanged, Fast or fast, slow or so slow, dizzy, white happy a, but at least also found eMMC read and write speed is not the same, at least not nothing. After a day of tossing and going, you get a result like this!!!

Come over a period of time later, found that the phone of W also become good, 28 seconds will be able to boot up, this is how excited is Ah, no solution, the problem is good! Unfortunately, not long ago, found that W's mobile phone boot time changed back to 33 seconds, which is really depressing, so with the capture log look, the result is surprised, From Surfaceflinger is starting to the Boot is finished whether it is time or 17 seconds, it does not grow! What's the reason? The same time crawl log found that 28 seconds to boot up, the boot is Finished this log a play, solve to understand the lock interface, but 33 seconds is, but also wait for a while to unlock the interface, no wonder! A question, just know they are in the boot is finished added a usleep (5*1000*1000), because not to do so, Unlock in the boot up after the slide or will chuck, so add 5 seconds delay