Investigate Method Count & Code Analysis in Android Kotlin Project

Analyze Methods Count

In an Android project, dependencies can be added effortlessly using Gradle, and it is such a headache when you hit the method limit of 65,536. At that point, you need to enable Dex, which may inflict more pain on you by increasing Gradle build time. Unfortunately, there is still no way to get rid of this, but it can be prevented by carefully adding dependencies and also by keeping an eye on your project method count.

In this post, we are going to use a Gradle plugin called DexCount, which not only prints out your method, field and classes count but also draws a visualization so that you can understand which dependencies are using most of your method count.

Before you start, make sure that you already have a minimum of Java 8 installed, otherwise the DexCount can’t run properly. For the first step, add a dexcount plugin classpath in project build.gradle

classpath 'com.getkeepsafe.dexcount:dexcount-gradle-plugin:0.8.3'

Open app build.gradle and apply dexcount plugin. Make sure to apply it after ‘com.android.application’.

apply plugin: 'com.getkeepsafe.dexcount'

That’s it, the setup phase is done! Now open a terminal and run

./gradlew assemble debug

Gradle will start building the project, and it will also print out the statistic of methods, fields and classes inside our app.

To see the visualization of our app methods count, head over your project app/build/outputs/dexcount select your app_flavorDebugChart or app_flavorReleaseChart folder and open index.html file.

This chart is interactive. Each segment represents a package and sub-packages. You can hover your mouse to each section to learn how much methods that a package/class has.

Now, you can understand your codes better. By looking at this chart, you can refactor a dependency that has lots of methods, maybe by removing it and use an alternative dependency that has smaller method count.

Code Smell Detection

A code smell is a surface indication that usually corresponds to a deeper problem in the system. Because of its smell, these problems are easy to spot on. Some popular signs of code smell inside a class are a large class, too long method, complex condition, and deeply nested block. Some developers may rely only on linter to detect and fix code smell. Linter itself can detect some code smell and fix the codes to follow the official/recommended style guide. Sometimes, developers need more than that, they need a tool to detect and warn them about more code smell indications inside their project.

Detekt

Thankfully, Android developers who use Kotlin as the primary language to develop their apps have a tool called Detekt that can detect code smells. To use Detekt, we need to add the Detekt Gradle plugin by adding this line inside root build.gradle after buildscript and before all projects.

plugins {
    id "io.gitlab.arturbosch.detekt" version "1.0.0.RC7-3"
}

Next, add configuration for detekt. Add this lines after plugins

detekt {
    version = "1.0.0.RC7-3"
    profile("main") {
        input = "$projectDir"
        config = "$projectDir/default-detekt-config.yml"
        filters = ".*test.*,.*/resources/.*,.*/tmp/.*"
    }
}

Sync your changes! Next, we need to generate default-detect-config.yml file which contains default configuration rules for detekt. Open terminal and run

./gradlew detektGenerateConfig

Now, run detekt using

./gradlew detektCheck

Don’t worry if the build failed as long as you can see the analysis report. By running those command, detekt will analyze, try to find every possible code smell detection and create a report. Here is the output from my project :

After Ruleset: <type of ruleset> you can see there’s a debt value in a time unit. Debt is the time that a developer needs in order to fix a problem. This debt value is also useful for prioritizing a fix/refactor. At the bottom, you can see the report summary even includes overall debt (time) needed to fix all of those code smells!

Happy checking & refactoring.