Kotlin Developer

Вопрос с собеседования по Kotlin Расскажите о Data классах. Какие преимущества они имеют? 👇 Правильный ответ: Data класс предназначен исключительно для хранения каких-либо данных. Основное преимущество: для параметров, переданных в основном конструкторе автоматически будут переопределены методы toString(), equals(), hashCode(), copy(). Также для каждой переменной, объявленной в основном конструкторе, автоматически генерируются функции componentN(), где N — номер позиции переменной в конструкторе. Благодаря наличию вышеперечисленных функций внутри data класса мы исключаем написание шаблонного кода. @KotlinSenior #kotlin

Kotlin Android MVVM Template — шаблон Android-приложения Kotlin Android MVVM Template — простой и легкий шаблон для приложения Jetpack Compose с полностью настроенной навигацией, Retrofit и Dagger-Hilt для вашего удобства, чтобы вы могли сосредоточиться только на важном. Фичи: 🔘 Полностью на Jetpack Compose 🔘 Jetpack Compose Navigation 🔘 Полностью настроенный Retrofit 🔘 MVVM 🔘 Kotlin DSL 🔘 Gradle Version Catalog для инъекции зависимостей detekt для проверки кода 🔘 Dependabot для обновления зависимостей 🔘 GitHub Actions CI/CD для проверки линтера, тестов и сборки APK 🔘 Coil для изображений 🖥 Kotlin Android MVVM Template на GitHub @KotlinSenior #kotlin

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

Пишете на Kotlin, но асинхронность всё ещё ощущается как магия с непредсказуемым результатом? Пора разобраться по-настоящему. Курс от автора книги «Асинхронный Kotlin» (БХВ, 2026) — про то, как корутины и Flow работают изнутри, а не про заучивание рецептов. Без привязки к платформе: подойдёт и Android-, и backend-, и multiplatform-разработчикам. Вы научитесь: - управлять жизненным циклом корутин и структурной конкурентностью - грамотно обрабатывать ошибки и отмену - строить реактивные потоки данных на Flow, работать с холодными и горячими потоками - тестировать асинхронный код - уверенно отвечать на каверзные вопросы о suspend, scope и Flow на собеседованиях Быстрый старт: уже во второй главе вы напишете свою первую корутину. Учитесь в удобном темпе, без дедлайнов. В конце — сертификат Stepik, подтверждающий знания по Coroutines и Flow. Скидка 25% до конца лета по промокоду AUGUST Записаться на курс! Реклама. Седова Я.А. ИНН 301507078318.

Какие коллекции есть в Kotlin Коллекция — это объект, содержащий в себе набор значений одного или различных типов, а также позволяющий к этим значениям обращаться и извлекать. Другими словами — это контейнер, в который вы можете помещать то, что вам нужно, а затем каким-либо образом с ним взаимодействовать. В Kotlin есть три типа коллекций: 🔘 List (список). Упорядоченная коллекция, в которой к элементам можно обращаться по их индексам. Идентичные элементы (дубликаты) могут встречаться в списке более одного раза. Примером списка является предложение: это группа слов, их порядок важен, и они могут повторяться. 🔘 Set (множество/набор). Неупорядоченная коллекция без повторяющихся значений. Примером множества является алфавит. 🔘 Map (словарь/ассоциативный список). Набор из пар "ключ-значение". Ключи уникальны и каждый из них соответствует ровно одному значению. В коллекции могут присутствовать повторяющиеся значения, но не повторяющиеся ключи. Пример — ID сотрудников и их должностей. Map не является наследником интерфейса Collection. Два типа интерфейсов, на основе которых создаются коллекции: 1. Неизменяемый (read-only) — дают доступ только для чтения (Set, List, Map, Collection). 2. Изменяемый (mutable) — расширяет предыдущий интерфейс и дополнительно даёт доступ к операциям добавления, удаления и обновления элементов коллекции (MutableSet, MutableList, MutableMap, MutableCollection). @KotlinSenior #kotlin

Kotlin DSL: создание предметно-ориентированных языков от теории до JsonBuilder. Бесплатный урок курса «Проектирование и разработка Kotlin-бэкенда» Одна из сильных сторон Kotlin — возможность создавать выразительные DSL, которые делают код понятнее и позволяют описывать сложную бизнес-логику практически как естественный язык. Однако многие разработчики используют готовые DSL, не понимая, как они устроены и какие возможности языка стоят за их реализацией. На открытом уроке 19 августа в 20:00 разберём принципы построения предметно-ориентированных языков в Kotlin. Поговорим о задачах и сценариях использования DSL, на практике создадим собственный JsonBuilder, изучим лямбды с получателем и extension-функции, а также посмотрим, как эти возможности помогают создавать удобные API и упрощать разработку. Урок не для тех, кто хочет ограничиться базовым синтаксисом Kotlin и не планирует использовать его продвинутые возможности. Будет полезен как Kotlin-разработчикам, так и тем, кто только знакомится с языком и хочет понять его сильные стороны. 👉 Записаться: https://vk.cc/d0q20O Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576, www.otus.ru

5 ошибок в Kotlin, которые незаметно ухудшают производительность 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️⃣ Чрезмерное использование Inline классов и дженериков без понимания боксинга Чрезмерное использование Inline классов и дженериков без понимания боксинга Kotlin скрывает сложность JVM. Но это все еще JVM. Generic типы могут вызывать боксинг: fun <T> process(value: T) Если T — это Int, оно может быть упаковано в Integer. Упаковка = выделение памяти для объекта. Аналогично, inline/value классы не всегда исключают выделение памяти во всех контекстах. Если важна производительность: 🔘 Проверьте байт-код 🔘 Используйте профилировщик 🔘 Поймите, когда примитивы упаковываются Высокоуровневый Kotlin не устраняет низкоуровневые издержки. 3️⃣ Массивные графы объектов в ViewModel Некоторые ViewModel выглядят так: 🔘 12 Flow 🔘 5 операторов объединения 🔘 Множественные преобразования 🔘 Цепочки map → filter → flatMapLatest Это выглядит архитектурно чистым. Но во время выполнения? 🔘 Каждый оператор добавляет накладные расходы 🔘 Объединение увеличивает выбросы 🔘 Частые перерасчеты Особенно в Compose, где изменения состояния запускают рекомпозицию. Сложные реактивные графы могут вызывать: 🔘 Неожиданные повторные вычисления 🔘 Скачки загрузки ЦП 🔘 Разряд батареи Иногда более простой контейнер состояния работает лучше, чем идеально реактивный конвейер. 4️⃣ «Совсем небольшая» блокировка основного потока Это опасно, потому что не приводит к сбою. val result = runBlocking { repository.getData() } Или: Thread.sleep(50) Или: database.query() Если блокировка длится 10–20 мс, вы можете этого не заметить. Но 16 мс = один кадр при 60 кадрах в секунду. Всё, что больше этого = пропущенный кадр. Микроблокировки накапливаются. Пользователи не видят «блокирующий вызов». Они чувствуют, что «приложение тормозит». 5️⃣ Не профилируют — просто предполагают Самая большая ошибка не в Kotlin. Это образ мышления. Разработчики предполагают. «Всё выглядит нормально». «Корутины легковесны». «Поток оптимизирован». «Compose всё обрабатывает». Производительность — это не вопрос убеждений. Это вопрос измерений. Используйте: 🔘 Профилировщик ЦП 🔘 Профилировщик памяти 🔘 Отслеживание выделения памяти 🔘 Системную трассировку Проверяйте: 🔘 Время холодного запуска 🔘 Рендеринг кадров 🔘 Частоту сборки мусора 🔘 Горячие точки выделения памяти Без профилирования вы просто гадаете. А в производительности полагаться на догадки — дорого. @KotlinSenior #kotlin

Вопрос с собеседования по Kotlin Что такое нелокальный return? 👇 Правильный ответ: В Котлин non-local return — это механизм, который позволяет выйти из внешней функции или лямбда-выражения и вернуться к вызывающему коду, обходя оставшуюся часть текущей функции или лямбда-выражения. Он работает по-разному в зависимости от того, является ли функция inline или не-inline. В не-inline функциях: • Если внутри функции есть лямбда-выражение, non-local return из лямбда-выражения может привести к нелокальному завершению внешней функции. • Для использования non-local return внутри лямбда-выражения в не-inline функции, необходимо использовать метку (label) и оператор return@label. В inline-функциях: • В inline-функциях, лямбда-выражения становятся частью кода функции и имеют локальный контроль над потоком управления. • Оператор return внутри лямбда-выражения в inline-функции приведет только к завершению самого лямбда-выражения, не влияя на внешнюю функцию. @KotlinSenior #kotlin

Почему reified можно использовать только с обобщенными типами (generics) Ключевое слово reified в языке Kotlin можно использовать только с обобщенными типами, потому что оно предназначено для решения конкретной проблемы, связанной именно с дженериками. Одна из особенностей обобщенных типов заключается в том, что информация о типе становится недоступной на этапе выполнения программы. Вместо этого на этапе компиляции создается код, который работает с типом-параметром "на уровне объекта", то есть как с любым другим объектом, не зная его конкретного типа. Именно reified позволяет сохранить информацию о типе-параметре на этапе выполнения программы. И дает нам возможность проверять типы в рантайме, создавать объекты типа-параметра и передавать их в качестве параметров других функций. Таким образом, ключевое слово reified не имеет смысла применять к необобщенным типам, поскольку они уже доступны в качестве конкретных объектов на этапе выполнения. @KotlinSenior #kotlin

Rebound — мониторинг рекомпозиций Rebound — это плагин компилятора Kotlin, который инструментирует каждую функцию с аннотацией @Сomposable легковесными вызовами отслеживания. Во время выполнения он отслеживает частоту рекомпозиции в соответствии с бюджетами для каждого composable-объекта, обнаруживает нарушения и сообщает о них через окно инструментов Android Studio, CLI или logcat. Работает на Android и iOS (Compose Multiplatform). Настройка не требуется — просто примените плагин Gradle. Плагин IDE предоставляет панель мониторинга производительности с 5 вкладками, включающую мониторинг в реальном времени, ранжирование проблемных мест, тепловую карту временной шкалы, анализ стабильности и историю сессий с корреляцией с системами контроля версий. 🖥 Rebound на GitHub @KotlinSenior #kotlin

Аннотация @JvmStаtic в Kotlin С помощью аннотации @JvmStatic есть возможность объявить методы по настоящему статическими, ее можно добавить как к методам object, так и к методам companion object. object ObjectWithStatic { @JvmStatic fun staticFun(): Int { return 5 } } В этом случае метод staticFun будет действительно объявлен статическим: public final class ObjectWithStatic { public static final ObjectWithStatic INSTANCE; @JvmStatic public static final int staticFun() { return 5; } private ObjectWithStatic() { INSTANCE = (ObjectWithStatic)this; } static { new ObjectWithStatic(); } } @KotlinSenior #kotlin

Вопрос с собеседования по Kotlin Какие требования должны быть соблюдены для создания data класса? 👇 Правильный ответ: 🔵 Класс должен иметь хотя бы одно свойство, объявленное в основном конструкторе. 🔵 Все параметры основного конструктора должны быть отмечены val или var (рекомендуется val). 🔵 Классы данных не могут быть abstract, open, sealed или inner. @KotlinSenior #kotlin