Analyzing Kotlin Hidden Costs and Building a Custom Lint Tool

Background

Kotlin offers many advantages such as null‑safety, extension functions, functional programming support, and rich syntactic sugar, which make Kotlin code more concise and maintainable than Java. However, some seemingly simple Kotlin constructs can introduce hidden runtime overhead.

Kotlin Hidden Overheads

Companion Objects

Companion objects replace static members. Declaring constants inside a companion object can generate additional bytecode. The following Kotlin code:

class Demo {
    fun getVersion(): Int {
        return Version
    }
    companion object {
        private val Version = 1
    }
}

is compiled to verbose Java code that requires multiple method calls to access the constant, incurring extra cost. Recommended fixes include using const for compile‑time constants, annotating public fields with @JvmField, or storing global constants in the top‑level class instead of a companion object.

lazy() Delegated Property

The lazy() delegate supports three thread‑safety modes: LazyThreadSafetyMode.SYNCHRONIZED, PUBLICATION, and NONE. The default SYNCHRONIZED mode adds unnecessary locking if not needed. Explicitly specifying the appropriate mode avoids this overhead.

Primitive Array Types

Kotlin provides three array types: IntArray / FloatArray (compiled to primitive int[] / float[]), Array<T> for non‑null objects, and Array<T?> for nullable objects. Using the primitive array types prevents boxing and reduces memory/CPU usage.

for Loop

Kotlin’s downTo, step, until, and reversed functions simplify loops, but combining them (e.g., downTo + step) creates temporary IntProgression objects, adding overhead compared to a plain Java loop.

Kotlin Check Tool Exploration

To detect such inefficiencies, three solutions were evaluated:

Adapt ktlint – a style checker, but requires heavy modification.

Use detekt – a static analysis tool, but lacks Android variant support.

Extend the existing Android Lint framework (named KLint) – best cost‑benefit ratio.

The chosen approach modifies Lint to parse Kotlin files, load custom rule JARs from an AAR’s assets, and define new detector interfaces analogous to Java’s JavaPsiScanner.

Implementation Highlights

Created a KotlinParser that converts .kt files to KtFile using kotlin‑compiler‑embeddable.

Implemented custom KLint rules (e.g., LazyDetector) that traverse the Kotlin AST via KtVisitorVoid and report issues when lazy() is used without an explicit mode.

Integrated the KLint task into the Gradle build so that it runs before the standard Lint task, ensuring both CI and IDE checks.

Provided a real‑time IDE plugin that shows warnings directly in Android Studio, allowing developers to fix problems while coding.

Automation & Reporting

Two automation strategies were considered: pre‑commit/push hooks and PR‑based CI checks. The PR‑based approach was preferred to enforce compliance without allowing developers to bypass checks.

Generated HTML reports and IDE warnings demonstrate the effectiveness of the custom rules.

Conclusion

By leveraging a customized Lint plugin (KLint), teams can enforce performance‑aware Kotlin coding standards, eliminate hidden overhead, and improve overall code quality.

References

Exploring Kotlin's hidden costs

Android custom Lint practice

Author

Zhou Jia – former Meituan‑Dianping Android engineer, graduated 2016, contributed to the Dazhong Dianping food channel.