31

Recently I have read about the Dalvik 65K method limit. I have understood that the method invocation list can only invoke first 65536 method references.

To tackle this, we have a number of solutions. One of which being multidexing where we split the .dex files to number of classes [classes.dex, classes1.dex ...] by using Android's support library.

What I have failed to understand is: What drawback does an Android application suffer due to this multidexing and why should we put lots of effort in minimising the number of referenced methods?

Basically in my understanding, to reduce the method count, I have to reduce modularisation, which makes my code a bit less readable, leaving apart the number of hours burned in stripping down the code of third-party libraries. Is reducing the method count worth it?

Peter Mortensen
  • 30,738
  • 21
  • 105
  • 131
adnaan.zohran
  • 809
  • 9
  • 21
  • increased build time, i would suggest to avoid multidexing. – Muhammad Babar Sep 15 '16 at 07:45
  • @MuhammadBabar if you divide your application in multiple modules, you can reduce build time. – Akash Kava Aug 13 '17 at 08:31
  • @AkashKava isn't this become more hectic to manage or otherwise please give some example or good post explaining why? – Muhammad Babar Aug 15 '17 at 06:41
  • @MuhammadBabar modules are compiled separately, only when any file inside module is modified, entire module is compiled, this way already compiled modules take up less time. Each module also can be pre-dexed, this means even dexing time will reduce. – Akash Kava Aug 17 '17 at 11:19
  • Can we use multiple modules to build a single app? – Muhammad Babar Aug 17 '17 at 11:22
  • Yes you can create multiple modules, in android studio, click add new module. `app` is just a default module, but you can create more module, each module will have its own package name, resources, layouts etc. – Akash Kava Aug 17 '17 at 15:07
  • Re *"65K"*: It is 64K (of real kilobytes - before Apple messed it up). – Peter Mortensen Dec 29 '22 at 01:18

4 Answers4

35

You are overthinking about multidex, instead you should observe and identify if there is any performance issue with your app by profiling your application.

Multidexing hardly increases any size of code, major size and performance issues are with animation/image/audio/video resources, they are the ones who increase size and reduce performance.

Including many third party libraries will eventually pass 64k limit and almost all applications today are multidexed, Users demand multifeatured apps today, that requires integration with many third party libraries.

Only when you are doing animation/game programming, where speed matters the most, more method calls might be harmful, but this has nothing to do with multidexing, even poorly written small non multidexing app will perform bad on any device.

Startup time will affect with multidexing, but it can certainly be improved by changing your app logic to delay loading of other costly library and resources.

Is reducing the method count worth it??

NO

Ideally you should use more methods and modularize your code, because testing and changing mobile apps is huge challenge after it is published. Debugging and removing bugs are more costly then multidex size and its impact on performance. Due to tiny screens, different brands, different UI, users get more angry on apps on phone compared to computers. Keeping up to users demand will become easier if code is divided into multiple individual tested libraries.

Akash Kava
  • 39,066
  • 20
  • 121
  • 167
  • are you sure it wont overhead app loading time? Practically how to measure loading time of app with multi-dex/non multi-dex? – Mani Aug 13 '17 at 09:52
  • 1
    I have mentioned that startup time will affect, it means it will be slow to load modules but it may not matter much. – Akash Kava Aug 13 '17 at 10:49
  • I agree with @AkashKava. We can always tackle startup time with numerous techniques and android user are used to splash screen techniques used. Your answer helped me to have a clear mind now. – adnaan.zohran Aug 14 '17 at 09:57
  • Splash screens are not recommended if your app doesn't need any remote data to be synced first. Start time is crucial, user's get annoy if you keep them waiting to use the app! – Muhammad Babar Aug 15 '17 at 06:48
  • 1
    @MuhammadBabar Startup time is irrelevant if app performs bad after it has started. No one likes buggy app, no matter how small it is and how soon it starts. – Akash Kava Aug 15 '17 at 09:50
  • Is there a way to native measure the startup time or only the through logs? – Mani Aug 15 '17 at 11:37
  • @Mani Use `System.currentTimeMillis()` and calculate the difference between the call to application onCreate and your launcher activity onCreate. – Muhammad Babar Aug 15 '17 at 13:06
9

The main drawback is a larger dex/apk size. Dex files have pools of constants that are shared among all the classes in that dex file. When classes are split across multiple dex files, these shared constants have to be duplicated in each dex file they are used in.

JesusFreke
  • 19,784
  • 5
  • 65
  • 68
  • 2
    So you mean to say there is no run-time drawback to the android application. An android application having multiple dex classes will act exactly the same as the one with only one. Apart from compromising with the APK size, nothing else is compromised when it comes to the application in the device. Keeping aside the drawbacks in development phase. – adnaan.zohran Sep 15 '16 at 10:55
  • Well, the dex files do have to be loaded in memory, so if the dex files are larger... :) – JesusFreke Sep 15 '16 at 17:26
  • oohh!! so if the dex files are needed to be loaded in the memory and if dex files are larger it will take more time to be loaded in the memory making the cold start time of an app more. So app will take more time to start. Is this what you meant? – adnaan.zohran Sep 16 '16 at 06:40
  • Also memory usage – JesusFreke Sep 16 '16 at 08:46
  • @JesusFreke You said "The main drawback". What is the other problem about Dex files? – Dr.jacky May 05 '17 at 06:42
3

Multidexing itself is non-performing term, if application is multidex it means there is burden over android internal process which executes application.

Every android application runs inside a single process(task), when its multidexed, it means the process is divided into parts which going to create performance issues with small android processor, no matter how you write code.

I am agree with aakash kava that almost all applications are multidexed because now a days android processors are very good in performance and android RAM is excellent, But it does't ,mean we should ignore multidexing.

Jayesh L
  • 137
  • 2
  • I know this is a bit old but - do you have any references for any of the claims you made in this answer? – nasch Jan 15 '19 at 00:09
  • @nasch : to observe working of multidexed apk, check with memory tools and its performance, compare it with normal apk execution and multidexed apk execution, then you will find the difference and off course check both apk at same configuration mobile or emulator (prefrebally over real device) – Jayesh L Feb 26 '19 at 06:02
  • I don't want to spend the time to run instrumented tests just for curiosity (I need mulitdexing for my app regardless of any performance penalty) but I did some reading and I think the performance penalty is for app startup on pre-Lollipop devices (they use Dalvik, which does not natively support multidex, rather than ART which does). So if you're not supporting those, no need to worry. My opinion anyway. – nasch Feb 27 '19 at 18:37
1

Generally spoken the disadvantages of multidex are: Increased APK size, possibly slower app startup and increased memory footprint.

The reason for that is that some data (e.g. StringData) can not be shared and therefore need to be partially stored in multiple DEX files at the same time. StringData consists of string literals loaded from code as well as class, method and field names and commonly account for up to 20% of the total DEX file.

But the actual disadvantages (beside APK size) highly depend on the Android version you are running the app on.

Google optimized the Android Runtime (ART) to remove these drawbacks. Android O (API 26) introduced the VDEX container to store pre-validated DEX files. With Android P Google further optimized the precompiler (codename CompactDex) and added an shared data section to the VDEX container to deduplicate the data used in multiple DEX files. So there are little to none disadvantage when running multidex apps on Android P runtime.

Sources: What's new in Android Runtime (Google I/O '18)

G00fY
  • 4,545
  • 1
  • 22
  • 26