As an Android developer, you’ve probably seen the famous message on your monitor:
Too many field references: 88974; max is 65536.
You may try using –multi-dex option.
First of all, what does the 65K methods limit mean? Why does it exist?
An Android mobile application is packaged on a file called an APK. This contains executable bytecode files (DEX – Dalvik Executable) which contain the code that makes an app work.
DEX specification limits the total number of methods that can be referenced within a single DEX file to 65,536, including Android framework methods, library methods, and methods in your own code. Exceed this limit and you’ll have to configure your app build process to generate more than one DEX file (multidex configuration).
There are some random compatibility issues when multidex configuration is enabled on Android apps, so our initial approach (before deciding to activate multidex) was to decrease the number of methods, to avoid these issues.
We asked some specific questions before making any changes in our app:
- How many methods do we have?
- Where do so many methods come from?
- What is the main source of these methods?
- Do we need all of these methods?
The search for answers to these questions uncovered some helpful tools and tips:
MethodsCount.com will tell you how many methods a library has, and also provides the dependencies of each library. Once you know the number of methods per library, you can evaluate if the relationship # methods added / feature value is good enough to include it in your app.
JakeWharton/dex-method-list utility shows all the method references in an .apk, .aar, .dex, .jar or .class file. This is really useful for discovering if a specific library’s methods are used on your app, and using it is as easy as cloning the project and running:./build/dex-method-list path/to/apk/file
mihaip/dex-method-counts is a tool that outputs per-package method, counts the methods in an Android DEX executable and groups them by package. This is useful for understanding which libraries are the main sources of methods, as well as evaluating whether the value each library adds makes it worth keeping. To use this tool you must clone the repo and run:./gradlew assemble
./dex-method-counts path/to/apk/file # or .zip or .dex or directory
Gradle build system provides valuable information about a project structure. One interesting task was called “dependencies”, which lets you view a library’s dependencies tree to locate any duplicated dependencies and remove them to decrease method numbers. Run this task by executing the following command on your terminal:./gradlew app:dependencies and you should see the following dependencies tree:
Classyshark is an Android executables browser. With this Java tool you can open any Android executable (.jar, .class, .apk, .dex, .so, .aar and Android XML) to analyze its content. The latest ClassyShark.jar release is available here and then simply run the following command :java -jar path/to/ClassyShark.jar -open path/to/apk/file and you should be able to see this Java application:
Now you can find valuable information about your apk, e.g., the number of methods, used classes, abstract methods, generated resources, etc.
apk-method-count is a tool that provides a quick overview of the number of methods in your apk. Dragging and dropping apk files will show something like this:
After using these tools, the methods in our app fell by around 10K – not enough to avoid multidex configuration, but still a good apk optimization.
We hope this post helps you deal with the 65K methods limit in any of your projects. Until now we have not had issues with our multidex configuration enabled and everything works as expected.