this is not a technical question.
I'm asking this because I don't understand how can this (64k limit) be avoided.
Aren't a "fancy" app always over 64k methods when it keeps adding functions and features from time to time? Or is that means those 'fancy' apps are always multidex-ed?
64K indeed doesn't make any sense in the modern era with apps coming with large amount of features, advanced and complex architectures, large libraries(try the full suite of Google Play Services), and the said libraries doing code generation for us like what an DI library like Dagger can do, the Dalvik executable has the 64K limit because thats what its designed for the limit is on the number of methods that can be referenced not defined, so we opt for multidexing, by default I would say all debug flavours of an app should have multidexing because without proguard truncating and compressing and removing everything unnecessary out we will eventually hit the 64K limit, but quite often when generating the release variant we would and can quite possibly stay under the 64K limit.
So for your question any app that crosses the 64K limit even after proguard has to be multidexed regardless of whether its fancy or not.
Related
After I installed MultiDex I noticed,first ever launch of the app takes extra 4-5 seconds. However after a few researches, I noticed that the app size inside the phone settings(app manager) went from 7 MB to 19 MB and if I clear data, app goes back to 7 MB. But every time that I launch the app for the first time, app size increases to more than double.
Now my question is, what happens that makes the app size increase so much?
So far I have found a few topics on slackoverflow about MultiDex but none talks about what really happen with the code, and what kind of data MultiDex saves/caches.
Multi-Dexing is enabled in your gradle and extended in your Application class.
This is used when you use over 64,000 methods.
https://developer.android.com/studio/build/multidex
I would say probably 90% of the time if you are hitting multi dex needs, you have likely not properly managed your dependencies. I'm NOT saying every time. However, typically the issue is people bring in entire Google dependencies instead of just the ones you need. For example the Google Play Services. If you include this, it will instantly force you into multi-dexing. However, this does come with a performance hit. You now have multiple dex files to load. There is some pre-dexing of course for things that will not change such as 3rd party dependencies to help your speed a bit on building and deploying. However, having multiple lookup tables comes with it's speed consequences. For example, if you included.
com.google.android.gms
has about 44,000 methods alone in it, You should specify which one you want like
com.google.android.gms:play-services-location:16.0.0
for example.
So before you go down the road of using Multi-Dex, ensure you have properly cleaned up your unused dependencies, and that you are properly managing your transitive dependency tree. Also don't forget to use ProGuard or the new D8 minification process as that may also help you, although may require you to run in Debug as well if you have that heavy of dependencies.
If you have done all that and you still need to use Multi-Dex (and I have run into this at larger companies that force tons of bloat libraries on you) then you go for it.
Now as for what is happening, well Dex stands for Dalvik Executable. It is the process of packaging the code into Dalvik bytes for execution. This is limited to 65,536 methods. They say 64k in the documentation, but everywhere I've read shows 65k+. Many of Google's libraries already contain 17k methods which puts you 1/4 of the way there right out the gate.
I believe the issue has something to do with the header allocation of 2 bytes per method signature and the lookup table. they are limited on number of unique IDs they can create. So it requires you to create multiple dex files with multiple lookup tables for the method signatures. So the short answer is, it makes multiple Dalvik Executable files to ensure unique method signatures are properly found and executed on the Dalvic Virtual Machine.
Other important things to note, is that prior to Android API 21, the Virtual Machine only supports 1 dex file. Therefore you need to do multi-dex install on your application onCreate to get the rest brought in properly. However, if you are using proguard, your additional dex files could have been removed so you may need to address a MultDexProguard file as well.
Now, it's important to realize that Android completely redid their Virtual Machine and no longer relies on Dex for their modern OS virtual machines. So then the next question is "should you still use it"?
Well if you are still needing to support pre-Lollipop, then you are better off leaving your multi-dex in place. Otherwise if you are Lollipop and up. Android uses ART (Android Runtime) and does not have this limitation. Honestly the population that has pre-Lollipop is so small that it is not worth supporting in my personal opinion, but it depends on your product and your needs.
Hope that helps shed some light on things here.
Happy Coding
A single .dex file can have 65,536 methods(references) so if the number of references exceeds 65,536, you go with multidex.
Maybe as your app is storing more than one .dex file it is allocating more space for new .dex files.
Breakdown your APK using APK Analyser to see what is causing the app size to increase
use the following link refer
https://developer.android.com/studio/build/apk-analyzer
if you want to decrease the size of the app this article is helpful
https://medium.com/exploring-code/how-you-can-decrease-application-size-by-60-in-only-5-minutes-47eff3e7874e
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?
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.
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.
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.
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)
As any Android developer should know, there is a 65k method limit for your apk (because the VM has just 16 bits for method handling). It should be quite hard to reach by your own, but it's easy as soon as you start to add some libraries.
Since last year you can get rid of this by enabling MultiDex on Android 5.0 and above (and adding a support library for prior Android versions). Even when this is possible, it's always better to reduce the methods number and get a smaller api (and the performance should be better, shouldn't it?).
At certain point the Android guys realized the size of their Google Play Services library was unaffordable (20k methods) and they took the great decision of split it up in different modules, so you can add simply the parts you need like (with grade):
compile ('com.google.android.gms:play-services-analytics:8.1.0')
compile('com.google.android.gms:play-services-appindexing:8.1.0')
Do you know if is it possible to do something like that with Guava library? It's around 15K methods, so it will be really helpful. I would like to use just a small part of Guava, so I don't need/want to include the other. I've been looking in the documentation and googling, but nothing found.
compile group: 'com.google.guava', name: 'guava', version: '18.0'
Some guy asked something similar two years ago, probably for a Java project, but didn't exist smaller guava parts then. Downloading part of guava-libraries
The only thing that comes to my mind is to copy just the needed Guava classes instead of loading the library, but I think is an awful solution.
Don't you think any big library should use a module splitting system like they did with Play Services?
EDIT: Besides, the multidex task takes too long (one minute and a half when before was less than 15 seconds), so each time I want to launch the app I have to wait. So, even when using Proguard is a great solution for a production release, it's not suitable for development as it takes longer than multidexing.
There is ongoing work to improve Guava on Android, but there are no plans to split it into smaller modules. As mentioned, ProGuard lets you exclude the parts of Guava you don't use from your final build.
Please Let me know Pro-guard in android applications is Essential or not before releasing in app store.
in some sources are mentioned using pro-guard in android applications, may create problem in application.
Link Source
Benefit
Reduced APK size
Improve performance
Obfuscation
Drawback
Potential misconfiguration
Additional testing required
Stack traces are difficult to read with obfuscated method names
The major drawback is that your app might crash when misconfigured.
The most important benefit of Proguard in my opinion is the obfuscation.
The gain in performance should be very limited.
The reduction of APK size is also minor in most cases: the size of the Dalvik code in an APK is usually way inferior to the size of images and other assets.
Bottom line: Proguard is essential for your app if you want to make reverse engineering more difficult (i.e. prevent other programmers from stealing and reusing parts of your code that you consider valuable).
I'd say it depends on how important those benefits are to you. I was specifically asked to reduce the size of my APK, so I had to turn it on. This meant I had to take all the tests again and to tinker with the proguard configuration to get the optimal size, but in the end the customer was a lot more satisfied, so it was worth it.
From what I've seen and read, if someone really wants to reverse-engineer your software or decompile it, ProGuard is not going to stop them. But is it at least a modest deterrent? I'm not sure if it's worth the hassle of translating my stack traces later on.
I would recommend ProGuard. Even without obfuscation (which can significantly shorten the names used in the constant pool) it can remove "dead code" (unused methods) of used libraries, etc. (It can also be used to conveniently merge everything together).
It takes a little bit of fiddling to "get correct", esp. if there is dynamically loaded classes -- but very recommended. The actual benefit from space-saving, however, "depends" on what can be eliminated and generally goes up with more external libraries.
Now, for obfuscation -- it does as much as any obfuscator: Makes "decompiling" code into things with meaningful names impossible.
Obfuscation won't save your super-secret-algorithm or hide your private keys, though: if the JVM (or Dalvik after a transformation) must understand it, then so can a decompiler and anyone who really wants to get access can. Your code could even be lifted in bytecode-form and used simply via. reflection (just imagine a terrible API with zero documentation): anyone who really wants to get access can. But perhaps obfuscation will make this task unfeasible for the cost/payout: "It depends".
Don't want to translate stack-traces? Simple: don't use it for debugging (not as useful for getting traces from users) or don't enable obfuscation (other benefits still apply) ;-)
Happy coding.
Pro guard is at least enabling you to have the app become as small as possible regarding the filesize!
That's a real plus.
It's automatically used when developing and compiling with eclipse, provided if you have proguard.config=proguard.cfg to the project's default.properties file.
That's also a real plus.