Modern Android apps tend to have a lot of code, and it’s easy to load multiple DEX files. Devices with lower versions of Android use the Dalvik VIRTUAL Machine as the Java runtime environment. If multiple DEX are required to run properly on these devices, the official MultiDex solution needs to be used. MultiDex requires ODEX optimization of the original DEX file in APK, so the execution time is too long, which makes MultiDex take too long to install or upgrade for the first time.

The BoostMultiDex solution developed by Douyin can greatly improve the time consumption of the original MultiDex. In addition, different from all current optimization schemes in the industry, we start from the underlying mechanism of Android Dalvik VIRTUAL machine and fundamentally solve the problem that the first execution of MultiDex takes too long after installation.

Two previous articles have been published detailing the implementation of BoostMultiDex:

Optimization practice of Douyin BoostMultiDex: Reduce the first startup time of APP on Android versions by 80% (I)

Optimization practice of Douyin BoostMultiDex: Reduce the first startup time of APP on Android versions by 80% (II)

It also shows the obvious effects of this optimization:

There may be some readers who are left wanting to see all the implementation details. As a result, we now fully open source the BoostMultiDex optimization.


Open source address


Github Project address:

https://github.com/bytedance/BoostMultiDex

Actual performance

Our previous articles only mentioned technical analysis and some optimization data. In order to let you feel the obvious effect brought by BoostMultiDex more intuitively, here is the actual performance of our project. Take Toutiao APP as an example, the left side is BoostMultiDex. On the right is the original MultiDex:

You can obviously see the difference in page opening time. The BoostMultiDex scheme on the left has a very significant optimization, and the interface is displayed immediately after a short wait, while the original MultiDex scheme on the right takes about half a minute to display the interface.

Of course, the actual experience improvement brought by this optimization depends on the combination of each APP itself. In addition to the loading time of multiple DEX, there is also a large amount of its own business logic in the startup stage of APP, which is relatively fixed in time. This is a business-level startup optimization issue, where you should minimize module loads that are not immediately available during startup. BoostMultiDex, on the other hand, has a very low access cost and guarantees instant results with just one line of code.

Quick access to the

The use of this solution is basically the same as the official MultiDex, only two steps to access.

First, add dependencies to build. Gradle dependencies:

dependencies {
. .    implementation 'com.bytedance.boost_multidex:boost_multidex:${ARTIFACT_VERSION}'
}
Copy the code

Then, with the official MultiDex similar, in the Application. The front of the attachBaseContext initialized:

public class YourApplication extends Application {

    @Override
    protected void attachBaseContext(Context base) {
        super.attachBaseContext(base);
  BoostMultiDex.install(base);  . . } Copy the code

That’s all you need to do. Compile and run the APP right away, and see if the first cold launch of the APP makes it fly?

Some supplement

The technical implementation details of BoostMultiDex scheme have been described in detail in the previous two articles, mainly covering the following technical points:

  1. Using the system hidden function, load the original DEX bytecode directly, avoiding the ODEX time-consuming
  2. Multi-level loading, the APP is started by selecting the most appropriate product from DEX bytecode, DEX file and ODEX file
  3. A separate process does OPT, and implements a reasonable interrupt and recovery mechanism

In addition, here are some additional notes.

The main DEX related

First, just like MultiDex, all classes in BoostMultiDex need to be typed into the main DEX. By default, Gradle automatically typed into the main DEX for us because the Application has a direct reference to BoostMuliDex. But if it is not done due to some rare exception, we need to do this extra processing ourselves, forcing all the classes in the com.bytedance.boost_multidex package into the main DEX.

ODEX optimization process processing

ODEX optimization process is in the process named :boost_multidex, it will start a OptimizeService background service to optimize, of course, all processes will go to the Application, Application contains a lot of logic common to other processes, For ODEX optimization process, the logic is not needed, therefore, we have provided a BoostMultiDex. IsOptimizeProcess method, facilitate users to use their judgment, just skip this has nothing to do with the business logic. Since the entire BoostMultiDex is in the main DEX, boostMultidex. install is also not required for ODEX optimization. Of course, it doesn’t matter if you don’t make this judgment, you just execute some extra useless code and lose some efficiency.

Android 4.4 ART model

Android 4.4 model integrates Dalvik and ART two sets of virtual machines at the same time, and the default factory models of general manufacturers adopt Dalvik. Since this scheme is only optimized for Android Dalvik models, it has no effect on ART. Therefore, if there is little difference in the optimization effect of a certain model, you can first look at the model and see the reason why the optimization logic is not followed from the output log.

Some Dalvik models with offset internal data structure

Our solution involves setting the DvmDex structure inside Dalvik VIRTUAL machine, and if the vendor makes special changes to these structures, it will result in setting the wrong offset. Such a situation is still rare at present. We only found that some HTC models modified this structure in our large-scale gray scale process online, and we have already made corrections. And I’m going to show you ahead of time just so you don’t get confused when you look at this code.

The last

Of course, more technical talk, rather than look at the actual benefits. At present, BoostMultiDex has been verified on The global users of Douyin billion. It can be said that it covers all kinds of complicated Android models, and it is difficult for other large apps in the industry to cover such a wide scale. As a result, we solved all sorts of weird compatibility issues and ensured maximum stability of the technical solution.

As for the open source code of the project, we guarantee that it is exactly the same as the code used by Douyin itself, directly out of the box, so as to avoid people having to step on the pit we have encountered before. If there is any problem in the actual use process, we also hope that you can raise it in time and contribute code together to make BoostMultiDex more robust and efficient.

At present, The Basic technology team of Douyin Android is still recruiting in Shanghai, Beijing, Hangzhou and Shenzhen. If you have the same passion for technology and pursuit of ultimate optimization, and want to build a global APP with 100 million users together with us, please visit byteDance’s official website to inquire about positions related to Douyin Android. You can also contact [email protected] to consult relevant information or send your resume to push directly!

More share

Open source | Objective – C & Swift the lightweight Hook

Open source | AabResGuard: AAB resources obfuscation tools

Open source | Scene: the Android open source framework page navigation and combination

Welcome to the Bytedance technical team