Von Kapt zu KSP migrieren

Mit Kapt (das Kotlin-Annotationsverarbeitungstool) können Sie Java-Annotationsprozessoren mit Kotlin-Code verwenden, auch wenn diese Prozessoren keine spezifische Unterstützung für Kotlin haben. Dazu werden aus den Kotlin-Dateien Java-Stubs generiert, die von den Prozessoren dann gelesen werden können. Diese Stub-Generierung ist ein teurer Vorgang und hat erhebliche Auswirkungen auf die Build-Geschwindigkeit.

KSP (Kotlin Symbol Processing) ist eine Kotlin-basierte Alternative zu kapt. KSP analysiert Kotlin-Code direkt, was bis zu doppelt so schnell ist. Außerdem werden damit die Sprachkonstrukte von Kotlin besser verstanden.

Kapt befindet sich jetzt im Wartungsmodus. Wir empfehlen, nach Möglichkeit von kapt zu KSP zu wechseln. In den meisten Fällen erfordert diese Migration nur Änderungen an der Build-Konfiguration Ihres Projekts.

Sie können kapt und KSP parallel in Ihrem Projekt ausführen, während Sie migrieren, und die Migration kann Modul für Modul und Bibliothek für Bibliothek durchgeführt werden.

Hinweis: Wenn in einem Modul noch kapt-Prozessoren vorhanden sind, werden in diesem Modul weiterhin Stubs generiert. Das bedeutet, dass der Großteil der Leistungssteigerung nur dann zunimmt, wenn alle Verwendungen von kapt aus dem Modul entfernt werden.

Übersicht über die Migrationsschritte:

1. Überprüfen Sie die verwendeten Bibliotheken für die Unterstützung von KSP
2. KSP-Plug-in in Projekt einfügen
3. Annotationsprozessoren durch KSP ersetzen
4. kapt-Plug-in entfernen

Überprüfen Sie die verwendeten Bibliotheken für die Unterstützung von KSP

Prüfen Sie zuerst, ob die Bibliotheken, die Sie mit kapt verwenden, bereits KSP-Unterstützung haben. Dies ist bei vielen beliebten Bibliotheken der Fall, darunter Dagger, Glide, Room und Moshi. Andere fügen Unterstützung hinzu.

Sie können die Liste der unterstützten Bibliotheken in der Dokumentation oder die Dokumentation und den Issue Tracker der von Ihnen verwendeten Bibliotheken prüfen.

Hinweis: Obwohl es sich bei der Datenbindung nicht um eine ursprünglich enthaltene Bibliotheksabhängigkeit handelt, wird für ihre Funktionen auch ein Annotationsprozessor verwendet. Die Unterstützung des KSP für Datenbindung ist nicht geplant. Sie können die Auswirkungen von Kapt auf Ihren Build reduzieren, indem Sie die Nutzung der Data Binding-Funktion auf separate Module isolieren.

KSP-Plug-in in Projekt einfügen

Deklarieren Sie zuerst das KSP-Plug-in in der Datei build.gradle.kts auf oberster Ebene. Wählen Sie eine KSP-Version aus, die der Kotlin-Version Ihres Projekts entspricht. Eine Liste der Releases finden Sie auf der GitHub-Seite für die wichtigen Verkaufsargumente.

Kotlin

plugins {
    id("com.google.devtools.ksp") version "1.8.10-1.0.9" apply false
}

Groovig

plugins {
    id 'com.google.devtools.ksp' version '1.8.10-1.0.9' apply false
}

Aktivieren Sie KSP dann in der Datei build.gradle.kts auf Modulebene:

Kotlin

plugins {
    id("com.google.devtools.ksp")
}

Groovig

plugins {
    id 'com.google.devtools.ksp'
}

Annotationsprozessoren durch KSP ersetzen

Wenn KSP aktiviert ist, können Sie damit beginnen, kapt-Verwendungen durch KSP zu ersetzen. Bei den meisten Bibliotheken müssen dazu nur die Kapt-Funktion in der Abhängigkeitsdeklaration geändert werden, da sie den Annotationsprozessor und den KSP-Prozessor im selben Artefakt versenden.

Hinweis: Bei einigen Bibliotheken (z. B. Glide) muss die Abhängigkeit möglicherweise auch in ein anderes Artefakt geändert werden. Weitere Informationen finden Sie in der entsprechenden Dokumentation.

Kotlin

dependencies {
    kapt("androidx.room:room-compiler:2.5.0")
    ksp("androidx.room:room-compiler:2.5.0")
}

Groovig

dependencies {
    kapt 'androidx.room:room-compiler:2.5.0'
    ksp 'androidx.room:room-compiler:2.5.0'
}

Synchronisieren und erstellen Sie nach der Umstellung auf KSP Ihr Projekt, um zu prüfen, ob es noch korrekt funktioniert.

Häufige Probleme, auf die Sie achten sollten:

• Einige Bibliotheken unterstützen nicht dieselben Funktionen wie kapt und KSP. Wenn Ihr Code nach der Migration beschädigt wird, sehen Sie in der Dokumentation der Bibliothek nach.
• KSP verfügt über genauere Kotlin-Typinformationen als kapt (z. B. zur Null-Zulässigkeit). Das bedeutet, dass KSP-Prozessoren die Typanforderungen genauer definieren können. Dazu müssen Sie möglicherweise nicht nur Ihre Build-Dateien aktualisieren, sondern auch einige Korrekturen im Quellcode vornehmen.
• Wenn Sie zuvor Argumente an den Annotationsprozessor übergeben haben, müssen Sie diese Argumente jetzt wahrscheinlich an KSP übergeben. Das Format der Argumente kann zwischen „kapt“ und „KSP“ unterschiedlich sein. Weitere Informationen finden Sie in der Dokumentation zu den wichtigsten Verkaufsargumenten und in der Dokumentation der verwendeten Bibliothek.

kapt-Plug-in entfernen

Wenn in Ihrem Modul keine Abhängigkeiten mehr mit kapt enthalten sind, entfernen Sie das kapt-Plug-in.

Hinweis :Für die Datenbindung muss außerdem kapt im Modul aktiviert sein. In Modulen, in denen Data Binding verwendet wird, kann kapt nicht entfernt werden.

Wenn es in einem Plug-in-Block deklariert wurde:

Kotlin

plugins {
    id("org.jetbrains.kotlin.kapt")
}

Groovig

plugins {
    id 'org.jetbrains.kotlin.kapt'
}

Wenn die Plug-in-Syntax mit Groovy verwendet wurde:

apply plugin: 'kotlin-kapt'

Sie sollten auch alle übrig gebliebenen kapt-Konfigurationen entfernen, zum Beispiel:

Kotlin

kapt {
    correctErrorTypes = true
    useBuildCache = true
}

Groovig

kapt {
    correctErrorTypes true
    useBuildCache true
}

Weitere Informationen

• KSP-Dokumentation auf Kotlinlang.org
• KSP auf GitHub
• kapt auf Kotlinlang.org -->