No-op versions for dev tools

Orhan Obut
4 min readAug 19, 2016

--

“In computer science, a NOP or NOOP (short for No Operation) is an assembly language instruction, programming language statement, or computer protocol command that does nothing.”

wiki

For each pull request we summarize build info along with the possible changes and send an email to corresponding group in CI server.

Recently we submitted a pull request and there were some interesting metrics. Pull request increased the apk size and method count. The following data is a small part of the report. Check buildreport for more details

The only major change in the commits was introducing Facebook Stetho. It’s a great debugging tool and we need for some specific reasons but we definitely don’t want to increase the method count and size in the release apk.

We have a few options to get rid of them from our release apk.

Proguard

We don’t use it (yet). I guess it’s time to consider it again.

Use no-op version from the library

Some libraries provide no-op version out of box such as LeakCanary. Some don’t (be like LeakCanary).

releaseCompile compiles no-op implementation which your apk won’t contain any redundant code from the library.

dependencies {
debugCompile '...:leakcanary-android':1.4-beta2''
releaseCompile '...:leakcanary-android-no-op:1.4-beta2'
}

Libraries that don’t provide no-op version

For example: Stetho doesn’t have this option out of box, therefore we have to create it by ourselves. Stetho has a lot of optional configurations, thus they don’t want to have a no-op version.

We have a few options to create our own no-op version. Essentially all does the same thing, the only difference is the implementation.

Create a module for the library

Create no-op version of the library as module. In this case we only used one method of Stetho, so let’s create a no-op for this method in the module.

  • Create a module. File -> New -> New Module
  • Create the used class exactly same name as the tool under the same package.
  • Add no-op implementation.
  • In build.gradle specify debugCompile for the tool dependency and releaseCompile for no-op version.
  • For non-debug builds, there will be only no-op implementation, nothing else.

Use variant source sets

Another solution is that you can directly manage variants in the source set level.

  • Create release source set folder. src/release
  • Create a class exactly same name as the tool under the same package.
  • Add no-op implementation.
  • In build.gradle specify only for debugCompile
  • For non-debug builds, there will be only no-op implementation, nothing else.

Use DebugApplication

Since most of the debugging tools are initialized in application class, we can take advantage of that.

  • Create debug source set folder. src/debug
  • Create DebugApplication class which inherits from your custom Application.
  • Initialize the dev tools inside DebugApplication.
  • Create AndroidManifest.xml under debug source set. We take advantage of the manifest merger and replace the actual application with DebugApplication by using “tools:replace”. This will replace “android:name” tag value with “.DebugApplication”
  • In build.gradle specify only for debugCompile
  • For non-debug builds, there will be only no-op implementation, nothing else.

Use variant source sets with DevUtils

Since we use a couple of different developer tools, we prefer to have them in variant source sets, but instead of creating a class for each tool, we created a utility class which keeps all the logic inside, therefore we don’t have to think which class is under which package etc etc.

  • Create source sets for each build type. src/debug, src/release
  • Create a utility class such as DevUtils
  • Create appropriate helper methods for each developer tools. ie: initStetho, initSomethingElse
  • Use DevUtils in your application. DevUtils.initStetho(this) etc
  • In build.gradle, use the appropriate compile option, usually it will be debugCompile unless you have other build types which you have specific tools for them.

Each solution has pros and cons but overall it’s great to use no-op versions for your build apk. Better for everyone.

--

--