Разработка

10 ошибок в Kotlin, которые незаметно ухудшают производительность

Производительность редко разрушается одной большой ошибкой. Она разрушается незаметно. Небольшими решениями. Часто повторяющимися. Не в том месте.

Опубликовано

14 часов назад

10.02.2026

Автор:

AppTractor

Kotlin не замедляет работу вашего Android-приложения. Замедляете его вы сами. Не из-за больших ошибок. Не из-за неудачных архитектурных решений.

Из-за крошечных, элегантных, «лучших практик», которые незаметно расходуют ресурсы процессора, памяти и кадров.

Вот 10 из них.

1. Последовательное выполнение операций с коллекциями внутри Hot Paths

Это встречается повсюду.

val result = users
    .filter { it.isActive }
    .map { it.profile }
    .sortedBy { it.name }

Выглядит красиво. Но каждый оператор:

Создает новую промежуточную коллекцию
Выделяет память
Добавляет стоимость итерации

Если это выполняется в коллбэке прокрутки, внутри биндинга RecyclerView, при каждом ответе API, в перекомпозициях Compose, то вы просто умножаете объем работы.

Что происходит на самом деле? Каждый вызов:

filter() → создает новый List
map() → создает еще один List
sortedBy() → снова копирует

Это множественные выделения памяти и циклы.

Лучший подход в коде, критически важном для производительности

Используйте последовательности:

val result = users.asSequence()
    .filter { it.isActive }
    .map { it.profile }
    .sortedBy { it.name }
    .toList()

Последовательности вычисляются лениво и сокращают количество промежуточных выделений памяти.

Ещё лучше: иногда один ручной цикл быстрее и понятнее.

Не всё должно быть «функциональной элегантностью».

2. Использование `data class copy()` в узких циклах

Классы данных удобны.

Но вот это:

items = items.map { it.copy(isSelected = false) }

Создает новый объект для каждого элемента. Если в вашем списке 5000 элементов? Это 5000 новых выделений памяти.

И если это происходит часто (например, при обновлении состояния в Compose), вы постоянно генерируете мусор.

Почему это вредно:

Увеличивается нагрузка на кучу
Увеличивается частота сборки мусора
Увеличивается количество пауз в потоках пользовательского интерфейса

В областях, чувствительных к производительности, следует учитывать:

Обновление только измененных элементов
Тщательно используйте шаблоны неизменяемости
Избегайте полного пересоздания списка

Чистая архитектура не означает пересоздания всего мира при каждом изменении состояния.

3. Запуск слишком большого количества корутин

Корутины легковесны. Но не бесплатны.

Распространен такой шаблон:

items.forEach {
    launch {
        process(it)
    }
}

Теперь представьте 1000 элементов. Вы только что запустили 1000 корутин. Даже если они легковесные, они все равно увеличивают накладные расходы на планирование, добавляют переключение контекста, увеличивают нагрузку на диспетчер.

Лучший подход

Используйте структурированную параллельность:

coroutineScope {
    items.map {
        async { process(it) }
    }.awaitAll()
}

Или, еще лучше, выполняйте работу пакетами.

Корутины — мощный инструмент, но неограниченный параллелизм — это ловушка производительности.

4. Чрезмерное переключение диспетчеров

Это выглядит безобидно:

withContext(Dispatchers.IO) {
    val result = apiCall()
    withContext(Dispatchers.Main) {
        updateUI(result)
    }
}

Но если этот шаблон повторяется внутри циклов или вложенных вызовов, вы платите за:

Переключение контекста потока
Стоимость синхронизации
Планирование основного потока

Переключение диспетчера не является бесплатным. В высокочастотных операциях избегайте ненужного переключения между потоками.

Думайте большими блоками работы.

5. Использование Flow для всего

Современные разработчики Android обожают Flow.

Иногда даже слишком сильно.

Пример:

flowOf(data)
    .map { transform(it) }
    .flowOn(Dispatchers.Default)
    .collect { render(it) }

Для одной эмиссии. Это избыточно. Flow вводит механизмы корутин, отслеживание состояний, цепочки операторов, проверки отмены. Если вам нужен просто вызов функции, используйте функцию.

Реактивные потоки мощны, когда у вас есть несколько эмиссий, проблемы с Backpressure, долгоживущие потоки.

Не для простых преобразований.

6. Игнорирование выделения памяти внутри биндинга RecyclerView

Это тонкий момент.

override fun onBindViewHolder(holder: ViewHolder, position: Int) {
    holder.textView.text = "${user.firstName} ${user.lastName}"
}

Интерполяция строк? Создает новую строку при каждом срабатывании биндинга.

Быстрая прокрутка 100 элементов = более 100 срабатываний в секунду.

Немного? Да.

Повторяется тысячи раз? Не такое уж немного.

То же самое с созданием объектов DateFormat, созданием ClickListeners внутри биндинга, выделением новых списков при каждой привязке.

Переместите все выделения за пределы биндинга, когда это возможно.

Производительность RecyclerView умирает из-за 1000 микро-аллокаций.

7. Чрезмерное использование Inline классов и дженериков без понимания боксинга

Kotlin скрывает сложность JVM.

Но это все еще JVM.

Generic типы могут вызывать боксинг:

fun <T> process(value: T)

Если T — это Int, оно может быть упаковано в Integer.

Упаковка = выделение памяти для объекта.

Аналогично, inline/value классы не всегда исключают выделение памяти во всех контекстах.

Если важна производительность:

Проверьте байт-код
Используйте профилировщик
Поймите, когда примитивы упаковываются

Высокоуровневый Kotlin не устраняет низкоуровневые издержки.

8. Массивные графы объектов в ViewModel

Некоторые ViewModel выглядят так:

12 Flow
5 операторов объединения
Множественные преобразования
Цепочки map → filter → flatMapLatest

Это выглядит архитектурно чистым. Но во время выполнения?

Каждый оператор добавляет накладные расходы
Объединение увеличивает выбросы
Частые перерасчеты

Особенно в Compose, где изменения состояния запускают рекомпозицию.

Сложные реактивные графы могут вызывать:

Неожиданные повторные вычисления
Скачки загрузки ЦП
Разряд батареи

Иногда более простой контейнер состояния работает лучше, чем идеально реактивный конвейер.

9. «Совсем небольшая» блокировка основного потока

Это опасно, потому что не приводит к сбою.

val result = runBlocking {
    repository.getData()
}

Или:

Thread.sleep(50)

Или:

database.query()

Если блокировка длится 10–20 мс, вы можете этого не заметить.

Но 16 мс = один кадр при 60 кадрах в секунду. Всё, что больше этого = пропущенный кадр. Микроблокировки накапливаются.

Пользователи не видят «блокирующий вызов». Они чувствуют, что «приложение тормозит».

10. Не профилируют — просто предполагают

Самая большая ошибка не в Kotlin. Это образ мышления. Разработчики предполагают. «Всё выглядит нормально». «Корутины легковесны». «Поток оптимизирован». «Compose всё обрабатывает».

Производительность — это не вопрос убеждений. Это вопрос измерений.

Используйте: