Memory footprint in large scale Android projects
summary
Shows concrete fixes and measurements rather than theory and promises: Gradle and Kotlin compile daemons run as JVMs and need explicit XMX tuning so builds stop spending 3–30 seconds in garbage collection, example 4 GB→2 GB causing stalls; unit tests run in separate Gradle workers each default ~250 MB so set per‑module XMX (example 700 MB→300 MB); a heap dump finds a Mockito leak solved by its clear API heap dump + fix removed the extra memory and restored tests; JVM crashes happen when summed heaps plus non‑heap exceed physical RAM so tune totals, IDE, emulator VM heap and consider 64 GB or cloud IDEs.
AI-written summary · about
chapters (13)
- 0:00Introduction
- 1:08Memory footprint matters
- 7:06JVM memory allocation tools
- 13:26Gradle daemon GC
- 23:43Unit test memory issues
- 30:23Debugging leaks with heap dumps
- 34:20Non-heap memory crashes
- 37:56IDE memory config
- 40:01Avoid duplicate daemons
- 40:43UI test emulator settings
- 41:24LeakCanary detection
- 41:45Holistic memory view
- 42:29Summary
related talks
40mHow Much Memory Does a Build Need? JVM for Android Developers
37mBuild bigger, better: Gradle for large projects
31mImproving Android Build performance
37mWhat's new in Android Development Tools
38mAndroid Studio Tips & Tricks
19mCOMPILING...? HOW TO REDUCE YOUR WAIT TIMES AND "GET BACK TO WORK"
41mKeeping your team's Gradle builds in top shape
27mFaster builds on Android: from 2 minutes to 2 seconds