Extrem langer Build mit Gradle (Android Studio)

Question

Im Moment sind wir in einer Situation, in der wir für sehr einfache Änderungen Bauzeiten von 2 Minuten und 30 Sekunden haben.Dies ist (im Vergleich zu ANT) erstaunlich langsam und beeinträchtigt die Produktivität des gesamten Teams.Ich verwende Android Studio und verwende die Option „Lokale Gradle-Distribution verwenden“.Ich habe versucht, Gradle mehr Speicher zu geben:

org.gradle.jvmargs=-Xmx6096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

Viel mehr Speicher.UND ES GIBT IMMER NOCH VON Zeit zu Zeit FEHLER IM SPEICHER.

Ausnahme im Thread „pool-1-thread-1“ java.lang.OutOfMemoryError:GC-Overhead-Grenze überschritten

Toll.Ich verwende die parallele Option und den Daemon:

org.gradle.parallel=true

org.gradle.daemon=true

Es hilft nicht wirklich.

Ich habe die oben genannten Parameter in ~/.gradle/gradle.properties eingefügt (und ich habe sogar bezweifelt, dass Android Studio das ignoriert, also habe ich es getestet – es ignoriert es nicht).

Vom Terminal aus erhalte ich immer noch eine Build-Zeit von 1:30 gegenüber 2:30 in Android Studio, daher bin ich mir nicht sicher, was dort falsch ist.1:30 ist im Vergleich zu Ant IMMER NOCH VERRÜCKT.Wenn Sie wissen, was Android Studio tut (oder ignoriert oder als Gradle-Konfiguration umschreibt), wäre ich Ihnen dankbar.

Nur CMD + B (einfaches Kompilieren) ist also nach Änderungen superschnell, etwa 7 Sekunden.Aber wenn es darum geht, die App auszuführen, startet sie die Aufgabe dexXxxDebug, die uns einfach umbringt.Ich habe es mit dem Putten versucht

dexOptions {
    preDexLibraries = false
}

Hilft nicht.

Ich verstehe, dass Gradle wahrscheinlich immer noch nicht für Produktionsumgebungen bereit ist, aber ich bereue langsam unsere Entscheidung, so früh darauf umzusteigen.Wir haben viele Module, was wahrscheinlich Teil des Problems ist, aber bei Ant war das kein Problem.

Jede Hilfe geschätzt, Dan

Weitere Informationen zu den Ausführungszeiten:

Beschreibung Dauer

Total Build Time    1m36.57s
Startup 0.544s
Settings and BuildSrc   0.026s
Loading Projects    0.027s
Configuring Projects    0.889s
Task Execution  1m36.70s

Der Zeitfresser::app:dexDebug 1m16.46s

Answer 1

Ich bin mir nicht ganz sicher, warum Android Studio langsamer als die Befehlszeile ist, aber Sie können Ihre Builds beschleunigen, indem Sie inkrementelles Dexing aktivieren.Fügen Sie diese Option in der Build-Datei Ihres Moduls hinzu android Block:

dexOptions {
    incremental true
}

Darin dexOptions Block können Sie auch die Heap-Größe für den Dex-Prozess angeben, zum Beispiel:

dexOptions {
    incremental true
    javaMaxHeapSize "4g"
}

Diese Optionen stammen aus einem Thread auf der adt-dev-Mailingliste (https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ), was etwas mehr Kontext hat.

Answer 2

Unser Team konfrontierte das gleiche Problem. Unser Projekt übersteigt das Methodengrenze für Dex (> 65k). Also, im Out-Bibliotheksprojekt setzen wir die Optionen in Build.gradle:

generasacodicetagpre.

In unserem Projekt Build.gradle:

generasacodicetagpre.

Zuvor hatten wir inkrementell wahr.Nach dem Kommentieren ergab es um 20 Sekunden, um im Vergleich zu 2 Minuten 30 Sekunden zu laufen. Ich weiß nicht, dass dies Ihr Problem lösen kann.Aber es kann anderen helfen.:)

Answer 3

Haftungsausschluss: Dies ist keine Lösung - es ist eine Aussage, dass es keine Lösung mit relevanten Linkquellen gibt, um es zu beweisen, dass es sich um ihn beweisen .

Da alle Antworten hier kein Problem lösen, das seit 2014 anständig ist, werde ich ein paar Links posten, die ein sehr simillares Problem beschreiben und os-spezifische Tweaks präsentieren, die möglicherweise nicht helfen oder nicht helfen könnten, Da OP es nicht anscheinend anscheinend anscheint, und Lösungen variieren viel über sie.

erstes ist der tatsächliche AUSSP-Bug-Tracker-Ausgabe in Bezug auf die Parallelisierung < / A>, mit vielen relevanten Sachen, noch offen und noch mit vielen Menschen, die sich als Off-Version 2.2.1 beschweren. Ich mag den Kerl, der das Problem notiert (eine hohe High-Prevision, die zu diesem Zeitpunkt einschließlich "666", nicht ein Zufall ist. So wie die meisten Menschen Musikprogramme und Mausbewegungen, die während der Builds stottern, beschreiben, fühlt sich an, als würden Sie in einen Spiegel schauen ...

Sie sollten anmelden. Personen berichten gutes Zeug mit Prozesslasso für Windows, während ich nicht wirklich etwas Gutes mit Renice'ing- oder CPU-Limiting in * NIX-Varianten melden.

Dieser Kerl (der heißt, er nützt nicht Gradle) stellt tatsächlich einige sehr schöne Sachen in Bitten Ubuntu, das leider nicht Arbeite in meinem Fall.

Hier ist eine andere alternative , die Threads der Gradle-Ausführung begrenzt, aber das ist in meinem wahrscheinlich nicht wirklich fälligen Szenario verbessert zu dem, was jemand auf einem anderen Link über das Studio mit mehreren Gradle-Instanzen gibt (während der Parameter nur die Parallelität der Instanz beeinflusst).

Beachten Sie, dass dies alles auf das Original "666" zurückgeht, High-Priority-Ausgabe ...

Ich konnte persönlich viele der Lösungen nicht testen, weil ich an einem verwalteten (keine Root-PRIVS) Ubuntu-Maschine arbeite und kann nicht getestet / Renice, aber ich kann Ihnen sagen, dass ich einen I7-4770, 8 GB RAM habe und eine Hybrid-SSD, und ich habe dieses Problem auch nach viel Erinnerung und Gradle-Tweaks im Laufe der Jahre . Es ist ein tantalisierendes Thema, und ich kann nicht verstehen, wie Google die notwendigen Humanressourcen für das Gradle-Projekt nicht begangen hat, etwas zu beheben, das sich auf der Entwicklung für die wichtigste Plattform, die sie bauen, auf der Entwicklung ist.

Eine Sache, die in meiner Umwelt anmerkt ist, ist: Ich arbeite mit einem Multi-Devencency Studio-Projekt mit etwa 10 Unterprojekten, alle bauen alleine auf und füllen die Gradle-Pipeline auf.

Answer 4

Beim Übergeben eines Werts können Sie den Buchstaben 'k' anhängen, um Kilobytes anzuzeigen, "M", um Megabyte anzugeben, oder "G", um Gigabyte anzugeben.

Answer 5

'- offline' löste mein Problem.