-
-
Notifications
You must be signed in to change notification settings - Fork 481
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve efficiency of bitmap cache on Android #213
Comments
Also make this a file-based cache rather than a memory cache. Should probably manage this cache on the Flutter side so it can be reused on Android and iOS. |
d87c792 partially fixes this, right? I'm pretty sure that's a file-based cache. As for limiting the cache size, we can specify limits when implementing caching.
I'm not sure what "too big" means, though. |
The main thing I'm concerned about is the memory cache which currently grows and grows until the audio service is stopped. Bitmaps are a notorious cause of many OutOfMemoryErrors in Android, and this can happen with long media item queues, especially if the images are high resolution. One other recent change I made to address this is to downscale the images before showing them in the notification which makes a big difference alone, so this makes the LRU cache less of an urgent matter. My latest thoughts for a simple improvement are to just hold in memory those media items that are in the queue. So whenever an item is removed from the queue, it also gets removed from the cache. With downscaled bitmaps, this should be manageable. |
Closing for the time being as the bitmap scaling is probably enough for now. Will create a new issue if memory becomes a serious problem again. |
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs, or use StackOverflow if you need help with audio_service. |
Note to self. Currently the cache and memory usage will keep growing after each
setMediaItem
call with a validartUri
supplied. Consider using an LRU cache or something to similar effect so that a playlist of hundreds doesn't exhaust the device's memory.The text was updated successfully, but these errors were encountered: