Although I didn’t get an Out of Memory exception, my app was allocating massive amounts of memory, resulting in unresponsiveness and a soft crash. It was quite apparent at this point that I had a memory issue. However, the Memory monitor had a story to tell…Įvery time I opened the Now Playing screen to play this troublesome song, I saw a massive spike in memory usage, pictured above. The CPU, GPU, and Network monitors, were relatively stable and uninteresting. I opened up the performance monitors, and reproduced the bug. More information about Android Studio’s performance monitors can be found here, but there are basically 4 monitors you need to know about: the Memory, CPU, GPU, and Network monitors.

How was I supposed to know what was going on with my code? In desperation, I turned to Android Studio’s performance monitors, which easily allow you to visualize the behavior and performance of your app. W/art: Suspending all threads took: 170.488msīut no actual stacktrace. I/Choreographer: Skipped 265 frames! The application may be doing too much work on its main thread. There were several entries in the logcat along the lines of

The logcat wasn’t giving me any useful information as to where the problem could be, just that there was a problem. Eventually, the Now Playing screen would just terminate, returning to the previous Activity, while the logcat would reset itself as if the app had just launched. Clicking or swiping on any part of the screen gave no response, and my entire device (Nexus 6P), not just the app, became incredibly sluggish, if not completely unresponsive. For most songs this screen loads just fine, but for some reason, playing a few seconds of Dum Dee Dum by Keys N Krates, turned the app into an unresponsive mess. As you can see, we’ve got all the basics: title, artist, album and some nice images (artist image and album cover) to tie everything together.

Nexus 6p android studio debug