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