Debugging without a Stacktrace: Using Android Studio’s Performance Monitors
summary
A music player app becomes completely unresponsive for one specific song (Dumdum by Keys and Crates) while logcat only shows choreographer and ART pauses with no stacktrace. GPU, CPU and network monitors stay flat but the Android Studio performance monitors memory graph spikes; the allocation tracker attributes 43% of memory to a Picasso thread. The culprit is a 3600×5400 artwork (3600×5400 -> 78 MB) when the view needs ~150px square (150px -> 90 KB). Fix: request smaller images and use Picasso.resize, which stops the crash.
AI-written summary · about
chapters (9)
- 0:00Introduction and setup
- 1:57Crash with no stack trace
- 4:49Performance monitors overview
- 7:41Memory monitor reveals spike
- 9:27Allocation tracker identifies culprit
- 11:54Image size analysis
- 12:59Solving the memory issue
- 13:42Key takeaways and advice
- 14:05Q&A session
related talks
45mFinding and Fixing Performance Problems
37mUI profiling in examples. Where is my bottleneck?
41mWays to reduce your app’s memory and storage footprint
41mDeep dive into Android Studio Profilers
38mOptimize your app performance for the next generation of Android
49mKeynote: Android Development
45mHigh performance in Android
31mImprove app performance with Android Studio Profilers