Почему 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% совместимость с Java Annotation Processing API.

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

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