Brief Introduction to Android startup Speed Optimization (including application startup Speed Optimization)

As we all know, Android boot is slow, so how to speed up the boot becomes a question worth discussing.

After reading a lot of materials (especially Google group's Android-Platform), I have summarized the following basic points.

 

Android boot takes two hours to start, namely preload classes and scan packages.

Here, preload classes is the most time-consuming. It usually takes about 13 seconds on my host. For more information about preload classes optimization, see http://www.eoeandroid.com/thread-29953-1-1.html. This post does not show how to optimize the preloaded-Classes list. In fact, after reading many topics about preload class in Google group, you can determine the following facts:

• The preloaded classes in the preloaded-Classes list are located in the heap of the Dalvik zygote process. After zygote derives a new Dalvik process, the new process only needs to load classes not pre-loaded in heap (these classes that are then loaded become private and unique to the process ), this speeds up application startup. In fact, this is a way to change the time of space, because almost no application can use all the pre-loaded classes, there must be many classes for this application is redundant. But as Google said, smartphone boot is far from frequently started applications-users start once, but may run multiple applications until the next boot. Therefore, it is cost-effective to sacrifice a little startup time in exchange for the fast loading speed of the application.
• Preloaded-Classes list is an optimized pre-load list formed by Google Android engineers who use a variety of test tools for analysis and manual fine-tuning, it covers the various types required for the longest-seen application types on smart machines. It's hard to imagine what we can do to get a better preload list than this. Therefore, unless your Android system is transplanted to a non-smartphone device for use (such as mid and ebook, you do not need telephony-related classes ), we do not recommend "optimize" preloaded-Classes list.
• Is it feasible to start a single thread in zygote for preload? The answer is no. First, no new threads can be created in zygote. Second, even if a new thread is created, unless there is a large amount of storage Io, otherwise, we cannot see the desired acceleration start effect.

Scan packages. By referring to the post mentioned above, we can see the fact that the fewer APK installs, the shorter the startup time. In fact, the number of APK installations does affect the boot speed, but the scan packages takes far less time than the preload Classe. It seems that there is not much oil and water to squeeze, but at least we know: minimizing the number of Preset APK in the product can increase the startup speed (even if it is simplified to the extreme, it may only save 2 S ).

 

Finally, for the start services stage mentioned in that post, I think that although this stage does take a considerable amount of time, as mentioned in the article, optimizing these services is not only removing services we don't need, but also modifying systemserver. java issues. Any code used for the optimized and excluded services must be modified. Otherwise, the system cannot start. In this way, the workload is large, difficult, and risky. Therefore, you must be cautious when optimizing these services.

 

Is there no way to speed up startup? No. In addition to hardware changes, blcr technology can also be used in software to solve this problem. In. I personally think the application of blcr is not complex and it is worth trying.

 

 

At the same time, I think it is necessary to raise the issue of application startup speed acceleration. If you have used Android, you will find that it is slow to start an application for the first time, but as long as you do not shut down and restart it, it will be much faster to start it again in most cases. Therefore, we can easily think of a way to "pre-load" our application once, so the next time the user starts us again, will it be faster?

 

First, let's clarify that any idea of "pre-loading" is impractical. First, we will not discuss the technical possibility of implementation. We just need to take a look at the android activity lifecycle management and understand that even if you "pre-load" your activity in some way, you cannot ensure that the activity you pre-load still exists when the user really asks to start running it, because android will probably GC the activity shortly after you start the activity for "pre-load. It is obviously unwise to rely on an unreliable technology.

 

So there is no other way? The answer is yes, but it only makes sense in a few cases. In the source code of frameworks/base/CORE/RES/values/arrays. in XML, we can see the item "preloaded_drawables", which lists the graphic resources pre-loaded by Android at startup, in this way, an application does not need to load these graphic resources. If an application contains a large amount of graphic resources, we can add it to this preloaded_drawables item to speed up the startup of our application. However, this has an obvious drawback: Like preload classes, not every application requires all the pre-loaded graphics resources. These redundant resources occupy the memory space of the application process. Therefore, the practical application of this technology has great limitations. It is limited to the following situations: a device only runs several fixed applications, and these applications contain a large amount of graphics resources that need to be loaded. But what kind of device will this be?

 

Now, I have written my research experience over the past two days. Limited level of understanding is limited. If the text is incorrect or someone can have a better idea, please leave a message below: if I have any further experiences, I will update this article.