Müssen Gradle-Daemonen beim Co-Hosting immer weg?

Nicht immer; aber ./gradlew --stop oder Idle-Eviction am Ende, besonders bei Kurzleases.

Teilen wenn Retros scheitern oder Compliance Signaturtrennung verlangt.

2026 Flutter/React Native Dual-Target auf Remote-Macs in sechs Regionen: iOS+Android Co-Hosting, Paralleldeckel & FinOps von Tages- bis Monatsmiete

Wenn Sie Flutter oder React Native auf dedicated Remote Macs in Singapur, Japan, Korea, Hongkong, US Ost/West bauen und nur zusammen instabil werden, liegt es meist an unified memory, SSD-Schreibverhalten und Gradle-Daemon-Politik statt an „zu wenig Kernen“. Checkliste, Matrix, Runbook, Metriken und Leasing-Hinweise mit Querverweisen.

Sechs typische Ressourcenkonflikte bei Flutter/React Native auf dedizierten Remote-Macs (Sechs Regionen)

Unified Memory vor CPU: Xcode- und Gradle-Prozessbäume drücken zuerst den Speicher; Apple Silicon zeigt das als Signal 9 oder Gradle-Abbrüche in Transform-Phasen.
Simulator vs. Android-Emulator: verwaiste Images füllen die SSD; beide Stacks parallel erhöhen die I/O-Warteschlange.
Gradle-Daemon plus Xcode-Indexing: ohne RAM-Limits und Idle-Eviction kollidieren Daemons mit DerivedData und SwiftPM-Caches.
NDK/CMake neben iOS-Native: ohne Kollokation von Git und Maven-Spiegeln zur Region dominiert Auflösungszeit die Wanduhr.
Lease-Fenster vs. Queue-Design: Android-Nightly und iOS-Archive im Tageslease erzwingen Cleanup-Rennen am letzten Tag.
Gemeinsames HOME: .gradle, .pub-cache, node_modules ohne Isolation gefährden Auditierbarkeit; personenbezogene Build-Logs sollten gemäß DSGVO/Internem Datenschutz getrennt und retention-bewusst gespeichert werden.

Ergänzend zu Simulator-Kapazität, Runner-Secrets und Hybrid-CI fokussiert dieser Text Android- und Apple-Toolchains auf demselben Host.

Drei Budgets: Seitenersetzungsdruck, freier SSD-Raum, Cross-Region-Egress. Bei Rotstufen im Kurzlease zuerst Serialisierung, nicht mehr GHz kaufen.

Szenario	M4 (16GB)	M4 Pro	Rot
Nur CLI	Gradle workers 2, Xcode seriell	workers 3–4	Swap steigt, <10GB frei
Flutter integration + Simulator	Android-Unit zuerst, keine Daemon-Volllast	`flutter drive` begrenzt	Metal+Java friert SSH
RN release + Archive	Zeitboxen, vorher `./gradlew --stop`	getrennte `GRADLE_USER_HOME`/DerivedData	codesign+zipalign I/O-Fehler

info

Prinzip: Co-Hosting bindet oft Speicher und SSD, nicht Kerne.

Sechs-Schritte-Runbook

Toolchain-Matrix versionieren und Hashes am CI-Eingang drucken.
GRADLE_USER_HOME/PUB_CACHE auf Datenvolumen; DerivedData-Repro alignen.
Standard: plattformübergreifend serialisieren.
Daemon stop → android/.cxx → DerivedData rotieren → Git.
Git/Maven-Zeile mit Region; Nähe-Matrix abgleichen.
Wöchentlich peak RSS, min frei GB, egress.

bash

./gradlew --stop || true
export GRADLE_USER_HOME="$WORK_ROOT/.gradle-isolation"
export ANDROID_SDK_ROOT="$WORK_ROOT/android-sdk"
defaults write com.apple.dt.Xcode IDECustomDerivedDataLocation -string "$WORK_ROOT/DerivedData"
export FLUTTER_ANALYZER_CONCURRENCY=2
export ORG_GRADLE_PROJECT_org.gradle.workers.max=2

Drei Kennzahlen (Beispielschwellen)

Peak RSS >~78% unified → nächstes Release serialisieren; >~88% mit Swap → keine parallelen UI-Tests.
Dreimal hintereinander <12GB frei auf 256GB → Cache-Stufen oder Lease-Up.
Gradle config-cache misses + CocoaPods resolve +30% WoW → HOME-Korruption prüfen.

Zusätzlicher Linux-Android-Host vs. lokale Doppelbuilds

Linux entkoppelt RAM, verdoppelt aber Keys/Queues. Lokale Builds erzeugen Drift.

Für Singapur, Japan, Korea, Hongkong, US Ost/West mit ausgerichteten Git/Registry-Pfaden und skriptierten DerivedData/.gradle-Wasserständen sind MACCOME Mac-Cloud-Hosts mit M4/M4 Pro und flexiblen Leases meist die sauberere Eskalationsstufe.

Drei Artefakte

Toolchain-Tabelle, Co-Host/Split-Matrix, Cleanup-zu-Lease-Karte; Grenze zu Monorepo-FinOps markieren.

Grenze

Wenn Android den Mac nie berührt, zurück zum Runner-Artikel. Mit Egress-Runbook NDK/Engine-Caches im gleichen Ledger führen.