5 ошибок в Kotlin, которые незаметно ухудшают производительность
1️⃣ Использование data class copy() в узких циклах
Классы данных удобны.
Но вот это:
items = items.map { it.copy(isSelected = false) }
Создает новый объект для каждого элемента. Если в вашем списке 5000 элементов? Это 5000 новых выделений памяти.
И если это происходит часто (например, при обновлении состояния в Compose), вы постоянно генерируете мусор.
Почему это вредно:
🔘 Увеличивается нагрузка на кучу
🔘 Увеличивается частота сборки мусора
🔘 Увеличивается количество пауз в потоках пользовательского интерфейса
В областях, чувствительных к производительности, следует учитывать:
🔘 Обновление только измененных элементов
🔘 Тщательно используйте шаблоны неизменяемости
🔘 Избегайте полного пересоздания списка
Чистая архитектура не означает пересоздания всего мира при каждом изменении состояния.
2️⃣ Запуск слишком большого количества корутин
Корутины легковесны. Но не бесплатны.
Распространен такой шаблон:
items.forEach {
launch {
process(it)
}
}
Теперь представьте 1000 элементов. Вы только что запустили 1000 корутин. Даже если они легковесные, они все равно увеличивают накладные расходы на планирование, добавляют переключение контекста, увеличивают нагрузку на диспетчер.
🔹 Лучший подход
Используйте структурированную параллельность:
coroutineScope {
items.map {
async { process(it) }
}.awaitAll()
}
Или, еще лучше, выполняйте работу пакетами.
Корутины — мощный инструмент, но неограниченный параллелизм — это ловушка производительности.
3️⃣ Чрезмерное переключение диспетчеров
Это выглядит безобидно:
```
withContext(Dispatchers.IO) {
val result = apiCall()
withContext(Dispatchers.Main) {
updateUI(result)
}
} ```
Но если этот шаблон повторяется внутри циклов или вложенных вызовов, вы платите за:
🔘 Переключение контекста потока
🔘 Стоимость синхронизации
🔘 Планирование основного потока
Переключение диспетчера не является бесплатным. В высокочастотных операциях избегайте ненужного переключения между потоками.
Думайте большими блоками работы.
4️⃣ Использование Flow для всего
Современные разработчики Android обожают Flow.
Иногда даже слишком сильно.
Пример:
flowOf(data)
.map { transform(it) }
.flowOn(Dispatchers.Default)
.collect { render(it) }
Для одной эмиссии. Это избыточно. Flow вводит механизмы корутин, отслеживание состояний, цепочки операторов, проверки отмены. Если вам нужен просто вызов функции, используйте функцию.
Реактивные потоки мощны, когда у вас есть несколько эмиссий, проблемы с Backpressure, долгоживущие потоки.
Не для простых преобразований.
5️⃣ Игнорирование выделения памяти внутри биндинга RecyclerView
Это тонкий момент.
override fun onBindViewHolder(holder: ViewHolder, position: Int) {
holder.textView.text = "${user.firstName} ${user.lastName}"
}
Интерполяция строк? Создает новую строку при каждом срабатывании биндинга.
Быстрая прокрутка 100 элементов = более 100 срабатываний в секунду.
Немного? Да.
Повторяется тысячи раз? Не такое уж немного.
То же самое с созданием объектов DateFormat, созданием ClickListeners внутри биндинга, выделением новых списков при каждой привязке.
Переместите все выделения за пределы биндинга, когда это возможно.
Производительность RecyclerView умирает из-за 1000 микро-аллокаций.
@KotlinSenior #kotlin
400 просм.13 авг., 13:47
