2017-10-27 3 views
2

Hallo wir haben ein Projekt mit 30 productFlavors, die ich versuche mit jenkins zu bauen. Da wir (für Android Studio3) aktualisieren, um: - gradle 3.0.0 - Build-Tools 26.0.2Android Build Tools 26.0.2 aus dem Speicher (Flusen)

Wir bekommen nicht genügend Arbeitsspeicher Ausnahme in Lint:

:app:lintUnexpected failure during lint analysis of null (this is a bug in lint or one of the libraries it depends on) 
    `OutOfMemoryError:ByteStreams.toByteArray(ByteStreams.java:176) 
Files.readFile(Files.java:182)←Files$FileByteSource.read(Files.java:153) 
Files.toByteArray(Files.java:252)←LintClient.readBytes(LintClient.kt:249) 
ClassEntry.addEntries(ClassEntry.java:216) 
ClassEntry.fromClassPath(ClassEntry.java:120) 
LintClient.createSuperClassMap(LintClient.kt:997)` 

    You can set environment variable `LINT_PRINT_STACKTRACE=true` to dump a full stacktrace to stdout. java.lang.OutOfMemoryError: Java heap space at 
    com.google.common.io.ByteStreams.toByteArray(ByteStreams.java:176) at 
    com.google.common.io.Files.readFile(Files.java:182)  at 
    com.google.common.io.Files$FileByteSource.read(Files.java:153) at 
    com.google.common.io.Files.toByteArray(Files.java:252) at 
    com.android.tools.lint.client.api.LintClient.readBytes(LintClient.kt:249) 

I erhöhte den Gradle Speicher (gradle.properties org.gradle.jvmargs = -Xmx3098M) mit Erfolg.

Alle productFlavors haben den gleichen Java-Code. Das Ergebnis apk hat verschiedene Bilder, Paketname, Sprachen und Konfiguration.

Der Build-Lauf für 25 ProduktFlavors, bis wir aus dem Speicher kommen. Mit dem Befehl ps sehe ich JVM Optionen für Client-Prozesse von Gradle Daemon wie: java -Djava.awt.headless = true -Xmx64M com.google.devtools.build.android.desugar.Desugar Ich habe keine Ahnung, wie zu setzen JVM-Optionen, die dieses Kind verarbeitet (Android Tools)

Vielleicht ist es ein Speicherleck in der Gradle-Daemon. Ich beobachte in den ersten 20 Build meines ProduktesFlavors der Kopf ist über 2G und als es zu 3G erhöhen und der Gradel deamon jvm macht GC die ganze Zeit ...

Irgendeine Idee oder Vorschläge?

Grüße

Antwort

0

war ich, wie Sie in derselben Situation. Nach dem Upgrade android Gradle (bis 3.0.0) & Build-Tool (bis 26.0.2), ich konfrontiert Speicherfehler während Gradle Build auf meinem Slave Ubuntu Maschine in Jenkins (aber während Task transformClassesWithDexBuilderForRelease). Inzwischen habe ich die Version von Gradle von 3.5 auf 4.3.0 aktualisiert. Da sich mein Code nicht geändert hat, denke ich, dass ein Problem vorliegt, das bei einem dieser Updates zu einem Speicherverlust führen kann. Hier

ist Umgehungslösung:

export _JAVA_OPTIONS="-Xms2048m -XX:-UseGCOverheadLimit -XX:+UseConcMarkSweepGC" 
export JACK_SERVER_VM_ARGUMENTS="-Dfile.encoding=UTF-8 -XX:+TieredCompilation -Xmx4096m" 

(genannt: https://stackoverflow.com/a/18900271/5663292 & https://stackoverflow.com/a/35964827/5663292)

EDIT

Nach ein paar zu bauen, habe ich auch denselben Fehler erscheinen, wenn ich den Speicher erhöht bis 14GB :) Aber ich habe das Problem gelöst, indem ich eine Zeile zu meiner Datei gradle.properties hinzugefügt habe:

org.gradle.jvmargs=-Xmx4096m 
+0

Ich erhöhe auch die JAVA VM-Speicher und ich bin in der Lage, meine Anwendung wieder zu bauen. Meine Beobachtung ist eine Zunahme der geladenen Klassen für jeden Produktgeschmack. Auch ich erstelle ein Problem bei Google https://issuetracker.google.com/issues/68364312 – Gugelhupf

+0

@Gugelhupf Ja, Sie haben Recht. Sie können denselben Fehler nach ein paar Build sehen, auch wenn Sie den Speicher von JVM erhöht haben (ich habe es gesehen :). Aber wenn Sie diesen Block (org.gradle.jvmargs = -Xmx4096m) zu Ihrer gradle.properties hinzufügen, wird alles wie vor der Aktualisierung funktionieren. Und Sie können auch die Eigenschaften _JAVA_OPTIONS & JACK_SERVER_VM_ARGUMENTS ... usw. entfernen. –

Verwandte Themen