Closed robinbanbury closed 5 years ago
Hey @robincsmith you are probably right, as you note I was just following the supposed "best practice". This particular message is sent to the app when the device is low on memory, which may or may not be due to this specific app - the OS broadcasts to ALL apps to attempt to reclaim memory.
I spent some time profiling this a few days ago and this plugin really doesn't use much memory, no more than expected anyway. What do you think of just ignoring the warning?
Yes, I believe you are right about the cause of the 'low memory' message and about the memory footprint of this plugin.
Like I say, I've not observed well-established music-playing apps halting playback so abruptly when the device is low on memory, even when they are in the background.
If background audio playback can be a critical feature for developers using this plugin, it doesn't seem right to simply destroy the playlist. Maybe there's something a that can be done to free up some less critical memory? Then the memory warning message can be passed on as this user suggests. If there's nothing you can think of, then perhaps this warning can be ignored - all the non-critical memory will have been freed up and only memory critical for operation (i.e. playlist playback) remains.
Happy to help you on this issue where I am able :-)
--
P.S. I started looking at a workaround for this issue, by setting a flag in-app when the {"type":120,"trackId":"INVALID","value":{"reason":"memory-warning"}}
status is thrown, and recover afterwards when the user next opens the app and selects a song to play. But I found that after the 'memory-warning' status is thrown, no further statuses get thrown, even after a new playlist is loaded into the app and starts playing (effectively putting the app in a kind of 'degraded' state). Could that be caused by the call to [super onMemoryWarning];
?
I've done some testing on the fix this week (using v0.9.1 of the plugin) and it's working really well. Happy to close this issue.
Something that I didn't know about before this week - you can simulate an iOS memory warning during testing! It's available in XCode under Debug > Simulate Memory Warning
when running an app on a device simulator. Really handy for testing this fix.
Expected Behaviour
Audio playback does not crash when device memory usage is high
Actual Behaviour
Playlist is wiped and playback stops when device memory usage is high.
I found that the message
RmxAudioPlayer, queuePlayerCleared, MEMORY_WARNING
is logged in theonMemoryWarning
method, which presumably is called after the OS issues a warning about high memory usage.Does anyone know if the OS memory warning is being sent because of low available memory on the device, or because this plugin/app is using up too much memory? I don't see any spikes in the plugin/app memory usage when the error occurs, and I only seem to get the error when my app is in the background. So my guess would be the former - that it's something the OS is doing when memory is low on the device, to free up memory used by background apps. That seems to align with the contents of this article.
If that's the case, maybe it's better not to wipe the playlist when the memory warning is received? That might be controversial, but I rarely see other music-playing apps such as Spotify or SoundCloud stop playing music when my phone is busy, so I have my doubts that those apps do anything drastic with their active playlist when they get this kind of warning.
If anyone has any advice or suggestions to the contrary on this (or to explain to me what obvious thing I'm doing wrong with my memory management!), I'm open to hearing that! :-)
Reproduce Scenario
iOS with Ionic, streaming tracks from SoundCloud using stream URLs
Steps to Reproduce
RmxAudioPlayer, queuePlayerCleared, MEMORY_WARNING
appears in the logs, the bug has been reproducedPlatform and Version
iOS 12.1.4
Cordova CLI version and cordova platform version
Cordova CLI version 7.1.0 Cordova iOS version 4.5.4
Plugin version
0.7.1