Kotlin под капотом: inline функции

Я провожу довольно много технических интервью и вижу, что многие разработчики не до конца понимают суть inline функций. Не понимают в чем профит от использования inline функций. Зачем нужен crossinline и как работает reified. Отчасти, источник популярных заблуждений про inline функции в том, что раньше на сайте kotlinlang.org было дано не совсем верное описание. Мне захотелось это исправить и наглядно показать как работают inline функции и какой профит мы получаем от их использования.

https://habr.com/ru/articles/775120/

✍️ @kotlin_lib

Как я писала DSL

Здравствуйте. Я учусь на последнем курсе бакалавриата и уже через месяц с небольшим буду защищать свою выпускную квалификационную работу (или же дипломную). Мне захотелось рассказать про неё здесь, чем я сейчас и займусь.

Меня давно интересуют инструменты для обеспечения работы языков программирования - лексеры, парсеры, интерпретаторы, компиляторы и всякое такое. Настолько интересуют, что уже в конце первого курса я решила, что в конце обучения буду защищать свой маленький язык программирования. Увы, создание собственного языка оказалось делом довольно сложным, из-за чего пришлось искать новую тему. Примерно на третьем курсе мы изучали в университете Kotlin, который быстро запал мне в душу и стал моим любимцем (после Lua). Мне захотелось написать дипломную именно на нём, поэтому я стала думать, что бы такое написать. Так как меня интересовал геймдев, я подумала: "Почему бы не создать свой движок для текстовых квестов как альтернативу Ren'Py?". Подумала и написала простой движок. Увы, в нём не было научной новизны, да и писать под него было неудобно, ну хоть получила опыт создания язычков, когда дала жизнь своему Av, про который писала в прошлой статье.

В университете мне сказали, что подобная тема совершенно не подходит для защиты, после чего я снова задумалась, что бы написать. Вспомнила, что довольно неплохо знакома с ANTLR, и решила написать DSL, который позволит превращать классы, которые сгенерировал ANTLR, в AST Kotlin. Эта мысль возникла довольно внезапно, но мне быстро стало интересно, во что она может превратиться. Как писать такой DSL, а главное, зачем? Как я объясняла нашей завкафедрой, подобный инструмент позволит автоматически переводить кодовые базы с разных языков на один - мой любимый Котлин. Кроме того, это поможет поддержать авторов новых языков программирования, поскольку он позволяет не писать свой рантайм, а положиться на уже существующий JVM, ведь Котлин исполняется на нём.

https://habr.com/ru/articles/905766/

✍️ @kotlin_lib

Kotlin Explorer — это настольный инструмент для быстрого изучения дизассемблированного кода на Kotlin.

Он позволяет быстро и удобно дизассемблировать Kotlin-код в:

* байткод Java,
* байткод Android DEX,
* ассемблер Android OAT (AOT-компиляция).

Как использовать

После запуска Kotlin Explorer введите корректный Kotlin-код в левую панель, затем нажмите Build > Build & Disassemble или используйте Cmd-Shift-D (macOS) / Ctrl-Shift-D (Linux и Windows).

По умолчанию:
* средняя панель покажет DEX-байткод Android,
* правая панель — нативный ассемблер, полученный в результате предварительной компиляции (AOT).
Видимость панелей настраивается через меню View.


Возможности
* Build > Optimize with R8 — включает оптимизации R8. Может повлиять на отображение номеров строк исходного кода в байткоде и DEX.
* View > Sync Lines — синхронизация текущей строки между исходным кодом, байткодом и DEX. Для корректной работы может потребоваться отключение R8.
* View > Presentation Mode — увеличивает размер шрифта для презентаций.
* Build > Build on Startup — автоматическая компиляция при запуске приложения.
* Build > Run — компиляция и локальный запуск Kotlin-кода. Результаты отображаются в логах.
* Нажатие на команду перехода (jump instruction) показывает стрелку к целевой инструкции.
* Отображается количество инструкций и ветвлений на метод.
* Клик по инструкции или регистру подсвечивает все их вхождения.
* Встроенная документация по aarch64 (ARM 64-bit). Включается через View > Show Logs & Documentation.

https://github.com/romainguy/kotlin-explorer

✍️ @kotlin_lib

Как мы «убили» Application Context, и проект стал чище

В большинстве Android-проектов Application и его Context используются как "корзина" для синглтонов, сервисов, preferences и всего подряд. Это удобно, но быстро превращает код в неуправляемую помойку. В одном из проектов мы решили отказаться от хранения зависимостей в Application, и вот что получилось.


🧩 Проблема
В проекте Application класс использовался для:

* инициализации SDK,
* предоставления доступа к SharedPreferences,
* доступа к репозиториям,
* передачи контекста в ViewModel и утилиты.

Со временем этот "божественный" объект стал точкой ошибок и зависимостей, которые тяжело мокать, тестировать и отслеживать.


✅ Что сделали

1. DI в Application только для инициализации
Application остался, но теперь он инициализирует Dagger/Hilt-модули, не предоставляя никаких данных напрямую.

2. Всё через DI

* Репозитории, UseCase’ы, утилиты — больше не держатся в Application, а инжектятся через Hilt.
* SharedPreferences теперь обёрнуты в провайдер, который зависит от @ApplicationContext и инициализируется DI.

3. ViewModel не знает про контекст
Никаких передач context в конструктор ViewModel. Всё, что нужно, приходит через зависимости. Даже WorkManager задачи создаются через HiltWorkerFactory.

4. Утилиты без статиков
Вынесли "утильные" классы в сервисы или обёртки. Например, AnalyticsTracker стал интерфейсом, имплементация которого инжектится в нужные классы.


🚀 Результат

* Код стал легче тестировать — особенно ViewModel и UseCase.
* Снизили количество «странных» багов, где терялся или менялся context.
* Избавились от синглтонов, создающих утечки памяти.


📌 Вывод
Контекст приложения не должен быть мусорной корзиной. Если у вас в проекте Application весит больше 100 строк — это красный флаг. Попробуйте вынести оттуда всё, что можно заменить инжекцией зависимостей.

✍️ @kotlin_lib

Управляем зависимостями и lifecycle во Flutter: yx_scope без генерации кода 📢

13 мая в 20:00 МСК в OTUS пройдёт открытый вебинар «DI и жизненный цикл модулей во Flutter на yx_scope».

Что разберём
— yx_scope vs Kiwi, Injector, Auto Injector, Scope — когда и почему выигрывает первое решение
— Безопасное DI на этапе компиляции — без глобальных синглтонов
— Гибкий lifecycle — как избежать утечек памяти при навигации
— Интеграция yx_scope в многомодульный интернет‑магазин (live‑код)

Спикер — Дмитрий Золотов, Flutter + Kotlin Developer в Yandex. 23 года опыта: full‑stack (Flutter/Python/Kotlin/Go/C++), DevOps, системное администрирование. Контрибьютор ReOpenLDAP, автор серий вебинаров по Kubernetes и кроссплатформенной разработке, приглашённый преподаватель в ИТМО.

Кому будет полезно
— Flutter‑инженерам, которые ищут чистую архитектуру без лишнего codegen
— Разработчикам, поддерживающим проекты с десятками экранов и активной навигацией
— Тем, кто хочет ускорить релизы, сохраняя контроль над памятью и зависимостями

После вебинара вы сможете
— Внедрять зависимости без шаблонов и ловить ошибки до запуска
— Управлять жизненным циклом компонентов так, чтобы память оставалась под контролем
— Масштабировать фичи, не переписывая DI‑слой

Участие бесплатное. Мест ограничено — бронируйте прямо сейчас.

→ Регистрируйтесь

Реклама. ООО «Отус онлайн‑образование», ОГРН 1177746618576

Cryptography for Kotlin Multiplatform

Проект предоставляет криптографические API, работающие на JVM, Android, JS и Native. Цель — дать разработчикам безопасный и кроссплатформенный способ работы с криптографией на Kotlin.

Основные возможности:
• Хэш-функции: SHA-256, SHA-512 и др.
• HMAC
• Генерация ключей
• Подписи и проверка: Ed25519 и др.
• Шифрование/дешифрование: AES (в процессе)
• Безопасные API с прицелом на использование Kotlin DSL и корутин

Текущий статус:
Проект ещё не стабилен и активно развивается. Пока нет релизов — используется только через mavenLocal() или сборку из исходников.

Пример использования (HMAC):

val key = HMAC.keyGenerator().generate()
val hmac = HMAC(key).digest("data".encodeToByteArray())


https://github.com/whyoleg/cryptography-kotlin

✍️ @kotlin_lib

Автоматическое обнаружение проблем с производительностью в ваших Kotlin-приложениях

Узнайте, как эффективно диагностировать и устранять проблемы с производительностью в Kotlin-приложениях, использующих Koin, с помощью платформы Kotzilla — нового инструмента отладки, специально разработанного для приложений на базе фреймворка Koin. Он решает распространённую задачу выявления проблем производительности в мобильных приложениях. Это руководство познакомит вас с автоматизированным подходом к оптимизации производительности.

0:00 Introduction to Performance Debugging
0:41 Understanding the Kotzilla Platform Dashboard
0:52 Automated Issue Detection
1:20 Deep Dive: Performance Issue Analysis
2:35 IntelliJ & Android Studio Integration
2:45 How to get started

источник

✍️ @kotlin_lib

Осталось 2 дня до вебинара! Успейте зарегистрироваться ⌛️

Управляем зависимостями и lifecycle во Flutter: yx_scope без генерации кода

🗓 13 мая, 20:00 МСК — открытый вебинар OTUS

Коротко о программе
— yx_scope vs Kiwi / Injector / Auto Injector / Scope — покажем, где выигрывает yx_scope
— Безопасное DI на этапе компиляции, никаких глобальных синглтонов
— Гибкий lifecycle: как избежать утечек памяти при навигации
— Live-код: интегрируем yx_scope в многомодульный интернет-магазин

Спикер — Дмитрий Золотов, Flutter + Kotlin Developer в Yandex, 23 года опыта full-stack и DevOps.

Кому зайдёт
— Flutter-инженерам, ищущим чистую архитектуру без лишнего codegen
— Разработчикам, поддерживающим большие проекты с активной навигацией
— Всем, кто хочет ускорить релизы и держать память под контролем

После вебинара вы сможете
— Внедрять зависимости без шаблонов и ловить ошибки до запуска
— Управлять жизненным циклом компонентов без утечек
— Масштабировать фичи без переписывания DI-слоя

Участие бесплатное, мест всё меньше.

→ Регистрируйтесь сейчас

Реклама. ООО «Отус онлайн-образование», ОГРН 1177746618576