Spec-Zone.ru › Kotlin 1.7

Почему KSP

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

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

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, более идиоматичный API Kotlin и возможность понимания только символов 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 ничего не знают о сгенерированном коде.

Последнее изменение: 06 сентября 2022
Быстрый старт KSP Примеры KSP

© 2010–2022 JetBrains s.r.o. and Kotlin Programming Language contributors
Licensed under the Apache License, Version 2.0.
https://kotlinlang.org/docs/ksp-why-ksp.html

Spec-Zone.ru

Настройки Оффлайн Что нового Помощь О нас
Spec-Zone .ru
спецификации, руководства, описания, API