Наш телеграм канал
Будьте вкурсе новостей науки и IT
Влияние data-классов на вес приложения


Kotlin имеет много классных особенностей: null safety, smart casts, интерполяция строк и другие. Но одной из самых любимых разработчиками, по моим наблюдениям, являются data-классы. Настолько любимой, что их часто используют даже там, где никакой функциональности data-класса не требуется.


В этой статье я с помощью эксперимента постараюсь понять, какова реальная цена использования большого количества data-классов в приложении. Я попробую удалить все data-классы, не сломав компиляцию, но сломав приложение, а потом расскажу о результатах и выводах этого эксперимента.


Data-классы и их функциональность


В процессе разработки часто создаются классы, основное назначение которых — хранение данных. В Kotlin их можно пометить как data-классы, чтобы получить дополнительную функциональность:





Но мы платим далеко не за всю эту функциональность. Для релизных сборок используются оптимизаторы R8, ProGuard, DexGuard и другие. Они могут удалять неиспользуемые методы, а значит, могут и оптимизировать data-классы.


Будут удалены:



Не будут удалены:



Таким образом, в релизных сборках всегда остаются toString(), equals() и hashCode().


Масштаб изменений


Чтобы понять, какое влияние на размер приложения оказывают data-классы в масштабе приложения, я решил выдвинуть гипотезу: все data-классы в проекте не нужны и могут быть заменены на обычные. А поскольку для релизных сборок мы используем оптимизатор, который может удалять методы componentX() и copy(), то преобразование data-классов в обычные можно свести к следующему:


data class SomeClass(val text: String) {
- override fun toString() = ...  
- override fun hashCode() = ...
- override fun equals() = ...
}

Но вручную такое поведение реализовать невозможно. Единственный способ удалить эти функции из кода — переопределить их в следующем виде для каждого data-класса в проекте:


data class SomeClass(val text: String) {
+ override fun toString() = super.toString()
+ override fun hashCode() = super.hashCode()
+ override fun equals() = super.equals()
}

Вручную для 7749 data-классов в проекте.



Ситуацию усугубляет использование монорепозитория для приложений. Это означает, что я не знаю точно, сколько из этих 7749 классов мне нужно изменить, чтобы измерить влияние data-классов только на одно приложение. Поэтому придётся менять все!


Плагин компилятора


Вручную такой объём изменений сделать невозможно, поэтому самое время вспомнить о такой прекрасной незадокументированной вещи, как плагины компилятора. Мы уже рассказывали про наш опыт создания плагина компилятора в статье «Чиним сериализацию объектов в Kotlin раз и навсегда». Но там мы генерировали новые методы, а здесь нам нужно их удалять.


В открытом доступе на GitHub есть плагин Sekret, который позволяет скрывать в toString() указанные аннотацией поля в data-классах. Его я и взял за основу своего плагина.


С точки зрения создания структуры проекта практически ничего не поменялось. Нам понадобятся:



Самая важная часть в Gradle-плагине — это объявление KotlinGradleSubplugin. Этот сабплагин будет подключён через ServiceLocator. С помощью основного Gradle-плагина мы можем конфигурировать KotlinGradleSubplugin, который будет настраивать поведение плагина компилятора.


@AutoService(KotlinGradleSubplugin::class)
class DataClassNoStringGradleSubplugin : KotlinGradleSubplugin<AbstractCompile> {

    // Проверяем, есть ли основной Gradle-плагин
    override fun isApplicable(project: Project, task: AbstractCompile): Boolean =
        project.plugins.hasPlugin(DataClassNoStringPlugin::class.java)

    override fun apply(
        project: Project,
        kotlinCompile: AbstractCompile,
        javaCompile: AbstractCompile?,
        variantData: Any?,
        androidProjectHandler: Any?,
        kotlinCompilation: KotlinCompilation<KotlinCommonOptions>?
    ): List<SubpluginOption> {
        // Опции плагина компилятора настраиваются через DataClassNoStringExtension с помощью Gradle build script
        val extension =
            project
                .extensions
                .findByType(DataClassNoStringExtension::class.java)
                ?: DataClassNoStringExtension()

        val enabled = SubpluginOption("enabled", extension.enabled.toString())

        return listOf(enabled)
    }

    override fun getCompilerPluginId(): String = "data-class-no-string"

    // Это артефакт плагина компилятора, и он должен быть доступен в репозитории Maven, который вы используете
    override fun getPluginArtifact(): SubpluginArtifact =
        SubpluginArtifact("com.cherryperry.nostrings", "kotlin-plugin", "1.0.0")

}

Плагин компилятора состоит из двух важных компонентов: ComponentRegistrar и CommandLineProcessor. Первый отвечает за интеграцию нашей логики в этапы компиляции, а второй — за обработку параметров нашего плагина. Я не буду описывать их детально — посмотреть реализацию можно в репозитории. Отмечу лишь, что, в отличие от метода, описанного в другой статье, мы будем регистрировать ClassBuilderInterceptorExtension, а не ExpressionCodegenExtension.


ClassBuilderInterceptorExtension.registerExtension(
    project = project,
    extension = DataClassNoStringClassGenerationInterceptor()
)

ClassBuilderInterceptorExtension позволяет изменять процесс генерации классов, а значит, с его помощью мы сможем избежать создания ненужных методов.


class DataClassNoStringClassGenerationInterceptor : ClassBuilderInterceptorExtension {

    override fun interceptClassBuilderFactory(
        interceptedFactory: ClassBuilderFactory,
        bindingContext: BindingContext,
        diagnostics: DiagnosticSink
    ): ClassBuilderFactory =
        object : ClassBuilderFactory {

            override fun newClassBuilder(origin: JvmDeclarationOrigin): ClassBuilder {
                val classDescription = origin.descriptor as? ClassDescriptor
                // Если класс является data-классом, то изменяем процесс генерации кода
                return if (classDescription?.kind == ClassKind.CLASS && classDescription.isData) {
                    DataClassNoStringClassBuilder(interceptedFactory.newClassBuilder(origin), removeAll)
                } else {
                    interceptedFactory.newClassBuilder(origin)
                }
            }

        }

}

Теперь необходимо не дать компилятору создать некоторые методы. Для этого воспользуемся DelegatingClassBuilder. Он будет делегировать все вызовы оригинальному ClassBuilder, но при этом мы сможем переопределить поведение метода newMethod. Если мы попытаемся создать методы toString(), equals(), hashCode(), то вернём пустой MethodVisitor. Компилятор будет писать в него код этих методов, но он не попадёт в создаваемый класс.


class DataClassNoStringClassBuilder(
    val classBuilder: ClassBuilder
) : DelegatingClassBuilder() {

    override fun getDelegate(): ClassBuilder = classBuilder

    override fun newMethod(
        origin: JvmDeclarationOrigin,
        access: Int,
        name: String,
        desc: String,
        signature: String?,
        exceptions: Array<out String>?
    ): MethodVisitor {
        return when (name) {
            "toString",
            "hashCode",
            "equals" -> EmptyVisitor
            else -> super.newMethod(origin, access, name, desc, signature, exceptions)
        }
    }

    private object EmptyVisitor : MethodVisitor(Opcodes.ASM5)

}

Таким образом, мы вмешались в процесс создания data-классов и полностью исключили из них вышеуказанные методы. Убедиться, что этих методов больше нет, можно с помощью кода, доступного в sample-проекте. Также можно проверить JAR/DEX-байт-код и убедиться в том, что там эти методы отсутствуют.


class AppTest {

    data class Sample(val text: String)

    @Test
    fun `toString method should return default string`() {
        val sample = Sample("test")
        // toString должен возвращать результат метода Object.toString
        assertEquals(
            "${sample.javaClass.name}@${Integer.toHexString(System.identityHashCode(sample))}",
            sample.toString()
        )
    }

    @Test
    fun `hashCode method should return identityHashCode`() {
         // hashCode должен возвращать результат метода Object.hashCode, он же по умолчанию System.identityHashCode
        val sample = Sample("test")
        assertEquals(System.identityHashCode(sample), sample.hashCode())
    }

    @Test
    fun `equals method should return true only for itself`() {
        // equals должен работать как Object.equals, а значит, должен быть равным только самому себе
        val sample = Sample("test")
        assertEquals(sample, sample)
        assertNotEquals(Sample("test"), sample)
    }

}

Весь код доступен в репозитории, там же есть пример интеграции плагина.


Результаты



Для сравнения мы будем использовать релизные сборки Bumble и Badoo. Результаты были получены с помощью утилиты Diffuse, которая выводит детальную информацию о разнице между двумя APK-файлами: размеры DEX-файлов и ресурсов, количество строк, методов, классов в DEX-файле.


Приложение Bumble Bumble (после) Разница Badoo Badoo (после) Разница
Data-классы 4026 - - 2894 - -
Размер DEX (zipped) 12.4 MiB 11.9 MiB -510.1 KiB 15.3 MiB 14.9 MiB -454.1 KiB
Размер DEX (unzipped) 31.7 MiB 30 MiB -1.6 MiB 38.9 MiB 37.6 MiB -1.4 MiB
Строки в DEX 188969 179197 -9772 244116 232114 -12002
Методы 292465 277475 -14990 354218 341779 -12439


Количество data-классов было определено эвристическим путём с помощью анализа удалённых из DEX-файла строк.



Реализация toString() у data-классов всегда начинается с короткого имени класса, открывающей скобки и первого поля data-класса. Data-классов без полей не существует.


Исходя из результатов, можно сказать, что в среднем каждый data-класс обходится в 120 байт в сжатом и 400 байт — в несжатом виде. На первый взгляд, не много, поэтому я решил проверить, сколько получается в масштабе целого приложения. Выяснилось, что все data-классы в проекте обходятся нам в ~4% размера DEX-файла.


Также стоит уточнить, что из-за MVI-архитектуры мы можем использовать больше data-классов, чем приложения на других архитектурах, а значит, их влияние на ваше приложение может быть меньше.


Использование data-классов


Я ни в коем случае не призываю вас отказываться от data-классов, но, принимая решение об их использовании, нужно тщательно всё взвесить. Вот несколько вопросов, которые стоит задать себе перед объявлением data-класса:



Мы не можем совсем отказаться от использования data-классов в проекте, и приведённый выше плагин ломает работоспособность приложения. Удаление методов было сделано ради оценки влияния большого количества data-классов. В нашем случае это ~4% от размера DEX-файла приложения.


Если вы хотите оценить, сколько места занимают data-классы в вашем приложении, то можете сделать это самостоятельно с помощью моего плагина.