Почему KSP

KSP упрощает создание лёгких плагинов компилятора

KSP разработан для скрытия изменений в компиляторе, минимизируя усилия по обслуживанию для процессоров, которые его используют. KSP разработан таким образом, чтобы не быть привязанным к JVM, что позволит легче адаптировать его к другим платформам в будущем. KSP также разработан для минимизации времени сборки. Для некоторых процессоров, таких как Glide, KSP сокращает время полной компиляции на 25% по сравнению с kapt.

Сам KSP реализован как плагин компилятора. На репозитории Maven Google есть предварительно собранные пакеты, которые вы можете загрузить и использовать без необходимости собственной сборки проекта.

Сравнение с плагинами компилятора kotlinc

Плагины компилятора kotlinc имеют доступ практически ко всему, что доступно в компиляторе, и поэтому обладают максимальной мощностью и гибкостью. С другой стороны, поскольку эти плагины потенциально могут зависеть от чего угодно в компиляторе, они чувствительны к изменениям компилятора и требуют частой поддержки. Эти плагины также требуют глубокого понимания реализации kotlinc, поэтому кривая обучения может быть крутой.

KSP стремится скрыть большинство изменений в компиляторе с помощью хорошо определённого API, хотя существенные изменения в компиляторе или даже в языке Kotlin могут потребовать раскрытия некоторых данных для пользователей API.

KSP пытается выполнить распространённые задачи, предоставив API, который меняет мощность на простоту. Его возможности являются строгой подмножеством общего плагина kotlinc. Например, в то время как kotlinc может анализировать выражения и операторы и даже изменять код, KSP не может.

Хотя написание плагина kotlinc может быть очень интересным, это также может занять много времени. Если вы не готовы изучать реализацию kotlinc и не нуждаетесь в изменении исходного кода или чтении выражений, KSP может подойти вам.

Сравнение с рефлексией

API KSP похож на kotlin.reflect. Основное различие заключается в том, что ссылки на типы в KSP необходимо разрешать явно. Это одна из причин, по которой интерфейсы не совмещаются.

Сравнение с kapt

kapt — замечательное решение, которое позволяет большому количеству процессоров аннотаций Java работать с Kotlin-программами «из коробки». Основными преимуществами KSP перед kapt являются улучшенная производительность сборки, независимость от JVM, более удобный Kotlin API и возможность понимания только Kotlin-символов.

Для работы с Java-процессорами аннотаций без модификаций kapt компилирует Kotlin-код в Java-заглушки, которые сохраняют информацию, необходимую Java-процессорам аннотаций. Для создания этих заглушек kapt должен разрешить все символы в Kotlin-программе. Генерация заглушек занимает примерно 1/3 времени полного анализа kotlinc и того же порядка kotlinc генерации кода. Для многих процессоров аннотаций это значительно дольше, чем время, потраченное на сами процессоры. Например, Glide рассматривает очень ограниченное количество классов с предопределённой аннотацией, и его генерация кода довольно быстрая. Почти вся нагрузка на сборку приходится на фазу генерации заглушек. Переход на KSP сразу уменьшит время, затрачиваемое на компилятор, на 25%.

Для оценки производительности мы реализовали упрощённую версию Glide в KSP, чтобы генерировать код для проекта Tachiyomi. Хотя общее время компиляции Kotlin в проекте составляет 21,55 секунды на нашем тестовом устройстве, для генерации кода kapt потребовалось 8,67 секунды, а для нашей реализации KSP — 1,15 секунды.

В отличие от kapt, процессоры в KSP не видят входные программы с точки зрения Java. API более естественен для Kotlin, особенно для Kotlin-специфичных функций, таких как функции верхнего уровня. Поскольку KSP не делегирует javac, как kapt, он не предполагает JVM-специфические поведения и потенциально может использоваться на других платформах.

Ограничения

Хотя KSP пытается быть простым решением для большинства распространённых случаев, он сделал ряд компромиссов по сравнению с другими решениями для плагинов. Следующие цели не являются целями KSP:

• Анализ информации на уровне выражений исходного кода.

• Модификация исходного кода.

• 100% совместимость с API обработки аннотаций Java.

Мы также изучаем несколько дополнительных функций. Эти функции в настоящее время недоступны:

• Интеграция с IDE: в настоящее время IDE ничего не знают о сгенерированном коде.