8

After I started using UI elements from the android support design library the app initial load time has become really slow (about 8 seconds!) and I am really not sure why.

I ran method tracking during most of the startup (It takes time for android studio to start running the cpu monitor) and found it spend 4 seconds on: dalvik.system.DexFile.openDexFile, Im not sure why this is taking so long.

Any ideas? (I didnt add any code since there is a lot of code in my app and I dont know where the problem is coming from...)

TomerZ
  • 615
  • 6
  • 17
  • I experienced an increase in speed when build the release app instead of the debug version that I normaly run. Maybe you could test that. – miqueloi Jul 20 '16 at 07:56
  • @miqueloi Huh, Interesting, it worked, do you know why? – TomerZ Jul 20 '16 at 08:09
  • I'm not sure, but I guess it has to be because of the way the compiler links the ext libs into the apk. I once saw an interview with Chet Haase who is one of the devs on the android ui platform, who explained how they were trying to show the first activity on the app as quickly as possible to avoid dull splash screen. Maybe that feature is somehow enabled in the release build process. – miqueloi Jul 20 '16 at 08:15
  • Interesting, please write an answer so I can accept. – TomerZ Jul 20 '16 at 08:17

3 Answers3

11

I experienced an increase in speed when building the release app instead of the debug version that I normaly run.

I'm not sure why it works, but I guess it has to be because of the way the compiler links the ext libs into the apk. I once saw an interview with Chet Haase who is one of the devs on the android ui platform, who explained how they were trying to show the first activity on the app as quickly as possible to avoid dull splash screen. Maybe that feature is somehow enabled in the release build process.

EDIT: The correct answer is written below by @Embydextrous. It is cause by the dexing of the app in debug mode.

miqueloi
  • 688
  • 4
  • 13
  • 2
    release build uses proguard and removes unwanted methods. So, only single .dex file is made. Try to extract you release build and debug build. You will likely see multiple classes*.dex files in debug build and only one in release build. I have also put an answer on this question. – Embydextrous Jul 20 '16 at 08:37
  • Thanks, @Embydextrous, nice explanation – acmpo6ou Mar 04 '21 at 07:05
  • Ok. Ok. I now know. I use a very heavy library. This can be the reason behind the slow performance. – Naimul Kabir May 11 '21 at 09:41
7

This usually happens with debug builds but can also happen with release builds.

In case of multiple dex files. The primary dex file (classes.dex) is loaded first which then loads other dex files.

It usually does not show in release builds because of proguard which removes unused methods and reduces method count so only a single .dex is made. In debug build proguard is not used so there are multiple dex files.

However in very large apps like AirBnb, Facebook, twitter, etc. there are multiple dex files. And hence app launch delays which can be optimized using dex optimizers.

Embydextrous
  • 1,611
  • 1
  • 12
  • 20
2

As name suggest openDexFile is android process that loads method from dex file, the bigger and the more files that are the longer load.

So my answer to your question is just reduce number of methods you have and prefer lazy load of libraries instead of initializing them in Application

So instead of initializing your net lib in App.onCreate initialize it on first request, do not create your db until its needed.

Also use android:windowBackground in your app thame to show user preloader instead of whitescreen :)

How to better see method counts:

In android studio under plugins install "Android Methods Count", that is very simple plugi, and i do think that its name suggest what it does :)

Now given your knowladge of your project reduce, number of libraries that you are using right now, you may want to use gradle->root->Tasks->android->AndroidDependencies to see what additional libraries are added to your project.

Also remember not to use core play-services and only libs that you are actually using.

Inverce
  • 1,487
  • 13
  • 27