Wie lösche ich den Gradle-Cache?

Ich versuche, Android Studio zu verwenden, und beim ersten Start dauert das Kompilieren etwa 45 Minuten. Wenn ich die Anwendung nicht beende, ist dies in Ordnung. Jede nachfolgende Kompilierung / Ausführung der App dauert etwa 45 Sekunden.

Ich habe versucht, einige meiner Caches zu überprüfen: .gradle/cachesIn meinem Home-Verzeichnis befindet sich ein Ordner mit 123 MB.

Es gibt auch einen .gradleOrdner in meinem Projektordner ... einer davon taskArtifactswar wie 200 MB. Ich habe Angst, sie beide zufällig zu zerstören. Welche Teile der Ordner können sicher gelöscht werden?

Gibt es eine bessere Erklärung dafür, warum mein Android Studio gradle assemblebeim ersten Laden der Anwendung ewig braucht, um die Aufgabe auszuführen ?

Muss ich auch den Intellij-Cache leeren?

Wie @ Bradford20000 in den Kommentaren gradle.propertieshervorhob , befinden sich möglicherweise eine Datei sowie globale Gradle-Skripte unter $HOME/.gradle. In diesem Fall muss beim Löschen des Inhalts dieses Verzeichnisses besondere Aufmerksamkeit geschenkt werden.

Das .gradle/cachesVerzeichnis enthält den GradleBuild-Cache. Wenn Sie also einen Fehler beim Erstellen des Cache haben, können Sie ihn löschen.

Der Gradle- Cache befindet sich bei

• Unter Windows: %USER_HOME%\.gradle/caches/
• Unter Mac / Unix: ~/.gradle/caches/

Sie können zu diesem Verzeichnis navigieren und es manuell löschen oder ausführen

rm -rf $HOME/.gradle/caches/

auf Unix-System. Wenn Sie diesen Befehl ausführen, wird auch das Herunterladen von Abhängigkeiten erzwungen.

Update 2: Leeren Sie den Android- Build-Cache des aktuellen Projekts

Hinweis: Android Studio- Datei | Durch ungültige Caches / Neustart wird der Android-Build-Cache nicht gelöscht , sodass Sie ihn separat bereinigen müssen.

Unter Windows:

gradlew cleanBuildCache

Auf Mac oder Linux:

./gradlew cleanBuildCache

EDIT: cleanBuildCache funktioniert nicht mehr

Das Android Gradle Plugin nutzt jetzt die Gradle Cache Funktion

REF: https://guides.gradle.org/using-build-cache/

CACHE LÖSCHEN

Bereinigen Sie das Cache-Verzeichnis, um Treffer aus früheren Builds zu vermeiden

 rm -rf $GRADLE_HOME/caches/build-cache-*

REF: https://guides.gradle.org/using-build-cache/#caching_android_projects

ANDERE DIGRESSIONEN

siehe hier (einschließlich Änderungen).

================

OBSOLETE INFO:

Neueste Lösung mit Gradle-Aufgabe

cleanBuildCache

verfügbar über Android Plugin für Gradle, Revision 2.3.0 (Februar 2017)

Abhängigkeiten:

1. Gradle 3.3 oder höher.
2. Build Tools 25.0.0 oder höher.

mehr bei:

https://developer.android.com/studio/build/build-cache.html#clear_the_build_cache

Hintergrund

Cache erstellen:

speichert bestimmte Ausgaben, die das Android-Plugin beim Erstellen Ihres Projekts generiert (z. B. nicht gepackte AARs und vordefinierte Remote-Abhängigkeiten). Ihre sauberen Builds sind bei Verwendung des Caches viel schneller, da das Build-System diese zwischengespeicherten Dateien bei nachfolgenden Builds einfach wiederverwenden kann, anstatt sie neu zu erstellen. Projekte, die das Android-Plugin 2.3.0 und höher verwenden, verwenden standardmäßig den Build-Cache. Weitere Informationen finden Sie unter Verbessern der Build-Geschwindigkeit mit dem Build-Cache.

Hinweis: Die cleanBuildCache-Task ist nicht verfügbar, wenn Sie den Build-Cache deaktivieren.

Verwendungszweck:

Fenster

gradlew cleanBuildCache

Linux / Mac

gradle cleanBuildCache

Android Studio / IntelliJ

gradle tab (default on right) select and run the task or add it via the configuration window 

** gradle / gradlew sind systemspezifische Dateien, die Skripte enthalten. Weitere Informationen zur Ausführung des Skripts finden Sie in den Systeminformationen

1. Linux - https://www.cyberciti.biz/faq/howto-run-a-script-in-linux/
2. Windows - https://technet.microsoft.com/en-us/library/bb613481(v=vs.85).aspx
3. mac https://developer.apple.com/library/content/documentation/LanguagesUtilities/Conceptual/MacAutomationScriptingGuide/index.html

Seien Sie vorsichtig mit dem gradle-Daemon. Sie müssen ihn stoppen, bevor Sie gradle löschen und erneut ausführen.

Stoppen Sie den ersten Daemon:

./gradlew --stop

Bereinigen Sie den Cache mit:

rm -rf ~/.gradle/caches/

Führen Sie die Kompilierung erneut aus

Der Gradle-Daemon erstellt außerdem viele große Textdateien für jedes einzelne Build-Protokoll. Sie werden hier gespeichert:

~/.gradle/daemon/X.X/daemon-XXXX.out.log

"XX" ist die verwendete Gradle-Version wie "4.4", und "XXXX" sind nur Zufallszahlen wie "1234".

Die Gesamtgröße kann in wenigen Monaten auf mehrere hundert MB anwachsen . Es gibt keine Möglichkeit, die Protokollierung zu deaktivieren, und die Dateien werden nicht automatisch gelöscht und müssen nicht wirklich beibehalten werden.

Sie können jedoch eine kleine Gradle-Aufgabe erstellen , um sie automatisch zu löschen und viel Speicherplatz :

Fügen Sie dies zu Ihrem hinzu app/build.gradle:

android {

    buildTypes {
        ...
    }

    // Delete large build log files from ~/.gradle/daemon/X.X/daemon-XXX.out.log
    // Source: https://discuss.gradle.org/t/gradle-daemon-produces-a-lot-of-logs/9905
    def gradle = project.getGradle()
    new File("${gradle.getGradleUserHomeDir().getAbsolutePath()}/daemon/${gradle.getGradleVersion()}").listFiles().each {
        if (it.getName().endsWith('.out.log')) {
            // println("Deleting gradle log file: $it") // Optional debug output
            it.delete()
        }
    }
}

Um zu sehen, welche Dateien gelöscht werden, können Sie die Debug-Ausgabe in Android Studio -> Ansicht -> Tool Windows -> Erstellen anzeigen. Klicken Sie dann in diesem Fenster auf die Schaltfläche "Ansicht umschalten", um die Textausgabe anzuzeigen.

Beachten Sie, dass eine Gradle-Synchronisierung oder ein Gradle-Build das Löschen von Dateien auslöst.

Eine bessere Möglichkeit wäre, die Dateien automatisch in den Papierkorb zu verschieben oder sie zuerst in einen Papierkorb zu kopieren. Aber ich weiß nicht, wie ich das machen soll.

Hier scheint es falsche Informationen zu geben. Einige Leute berichten, wie der Android Builder-Cache (mit Aufgabe cleanBuildCache) geleert werden kann, scheinen jedoch nicht zu erkennen, dass dieser Cache unabhängig von Gradles Build-Cache AFAIK ist.

Mein Verständnis ist, dass der Cache von Android vor dem von Gradle liegt (und ihn inspiriert hat), aber ich könnte mich irren. Ob der Android Builder aktualisiert wird / wurde, um Gradles Cache zu verwenden und seinen eigenen zurückzuziehen, weiß ich nicht.

BEARBEITEN: Der Android Builder-Cache ist veraltet und wurde entfernt. Das Android Gradle-Plugin verwendet jetzt stattdessen den Build-Cache von Gradle. Um diesen Cache zu steuern, müssen Sie jetzt mit der generischen Cache-Infrastruktur von Gradle interagieren.

TIPP: Suchen Sie online nach Gradles Cache-Hilfe, ohne das Schlüsselwort "android" zu erwähnen, um Hilfe für den aktuell relevanten Cache zu erhalten.

EDIT 2: Aufgrund der Frage von tir38 in einem Kommentar unten teste ich mit einem Android Gradle Plugin v3.4.2 Projekt. Der Gradle-Cache wird durch org.gradle.caching=truein aktiviert gradle.properties. Ich mache ein paar clean buildund das zweite Mal zeigen die meisten Aufgaben FROM-CACHEals ihren Status, was zeigt, dass der Cache funktioniert.

Überraschenderweise habe ich eine cleanBuildCacheGradle-Aufgabe und ein <user-home>/.android/build-cache/3.4.2/Verzeichnis, die beide auf die Existenz eines Android-Builder-Cache hinweisen.

Ich führe aus cleanBuildCacheund das 3.4.2/Verzeichnis ist weg. als nächstes mache ich noch einen clean build:

• Nichts hat sich geändert: Die meisten Aufgaben werden FROM-CACHEals Status angezeigt und der Build mit Cache-fähigen Geschwindigkeiten abgeschlossen.
• Das 3.4.2/Verzeichnis wird neu erstellt.
• Das 3.4.2/Verzeichnis ist leer (außer für 2 versteckte Markierungsdateien mit der Länge Null).

Schlussfolgerungen:

1. Das Caching aller normalen Android Builder-Aufgaben wird von Gradle übernommen.
2. Durch das Ausführen cleanBuildCachewird der Build-Cache in keiner Weise gelöscht oder beeinflusst.
3. Dort gibt es noch einen Android Builder Cache. Dies könnte ein Restcode sein, den das Android-Build-Team vergessen hat, zu entfernen, oder es könnte tatsächlich etwas Seltsames zwischenspeichern, das aus irgendeinem Grund nicht auf die Verwendung des Gradle-Caches portiert wurde oder nicht portiert werden kann. (Die Option "kann nicht" ist meiner Meinung nach sehr verbesserungsfähig.)

Als nächstes deaktiviere ich den Gradle-Cache durch Entfernen org.gradle.caching=trueaus gradle.propertiesund versuche ein paar von clean build:

• Die Builds sind langsam.
• Alle Aufgaben zeigen ihren Status als ausgeführt und nicht zwischengespeichert oder aktuell an.
• Das 3.4.2/Verzeichnis ist weiterhin leer.

Weitere Schlussfolgerungen:

4. Es gibt keinen Fallback für den Android Builder-Cache, wenn der Gradle-Cache nicht getroffen werden kann.
5. Der Android Builder Cache, zumindest für allgemeine Aufgaben, wurde tatsächlich entfernt, wie ich bereits sagte.
6. Das entsprechende Android-Dokument enthält veraltete Informationen. Insbesondere ist der Cache nicht standardmäßig aktiviert, wie dort angegeben, und der Gradle-Cache muss manuell aktiviert werden.

BEARBEITEN 3: Benutzer tir38 hat bestätigt, dass der Android Builder-Cache veraltet ist und mit diesem Fund entfernt wurde . tir38 hat dieses Problem ebenfalls erstellt . Vielen Dank!

Befehl: rm -rf ~/.gradle/caches/