View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0012415 | MMA | General | public | 2014-12-04 16:36 | 2015-08-21 14:44 |
| Reporter | rusty | Assigned To | |||
| Priority | urgent | Severity | major | Reproducibility | sometimes |
| Status | resolved | Resolution | fixed | ||
| Product Version | 1.1.0 | ||||
| Target Version | 1.1.3 | Fixed in Version | 1.1.3 | ||
| Summary | 0012415: Memory Optimization | ||||
| Description | In some cases, MMA's memory utilization increases to 500MB even on reboot. We've not been able to reproduce this internally, but many clues are at: http://www.mediamonkey.com/forum/viewtopic.php?f=21&t=78517 | ||||
| Tags | No tags attached. | ||||
| Attached Files | |||||
| Fixed in build | 468 | ||||
|
|
Fixed unreliable way of storing of temporary files Fixed in build 351 |
|
|
User has indicated that the issue remains. See the link above. |
|
|
Fixed in build 353 |
|
|
Users have confirmed that this issue is fixed, but that the fix doesn't retroactively solve the problem (i.e. if a user already has high memory utilization because of this bug, MMA doesn't fix the issue). Is it possible to resolve that as well? |
|
|
Fixed in build 359 |
|
|
I'm still observing utilization of 63-79MB on a Nexus 5 with 1280 tracks :-( What additional info might help? |
|
|
Added logs to build 368. Please just Send logs. |
|
|
Debug log upon starting MMA: I4MWDV7NG5 54MB utilized |
|
|
I see that /MMA/files and /MMA/cache dirs have only 2 MB. Could you please attach your app info screenshot. I have to know which part of app has so much MB. |
|
|
The Apps stats don't show anything useful. Just e.g. ---------------------------------- MediaMonkey 66MB 1 process and 1 service Storage Observer Service Started by app. Processes --------- MediaMonkey 66MB Main process is in use ----------------------------------- Further testing, however, showed that: a) On a clean install, MMA uses ~25MB b) Once some data is syncing, that bumps up to ~40MB c) As soon as a large playlist is played, utilization bumps up to 66MB d) The size of the Now Playing playlist dramatically affects the amount of memory used e) Once utilization is bumped up (e.g. case b) or c) ) all subsequent runs of the app use the higher memory threshold. e.g. once case d) occurs, all subsequent launches of MMA use 66MB. |
|
|
You are sending me "Running app" activity info. It shows info about used heap memory. It is not related to issue above that is about internal storage. This amount of memory is used (mostly) due to large number of bitmaps (artworks) in cache. There is a threshold that doesn't allow to get OutOfMemory error. Each app has its maximum amount of heap memory and MMA will not exceed it. It is certainly possible to lower it but it is really hard to debug and it is a long term work. And I don't think that it is crucial. Android has its own system that frees memory when it is needed by killing services with low priority or informing services that some resources are needed. Btw. you can see used memory (on interna storage, not the heap size) in App info activity which is reachable by long press on Home button -> long press on MMA -> App info. There you can see more categories. |
|
|
Yes, there are some tools for it and I agree with you. It quite time consuming and we didn't have time for it yet. I think that it is reasonable to push it now. |
|
|
1) I have improved bitmap caching in 1.1.3.467 - size of cache is set according device heap size - max 16 MB or 1/5 of heap size. It will improve performance on newer devices where small cache (2 MB) was not sufficient for artworks on big screens - LRU with aging algorithm is used for cache - artworks are removed on cache max size or after 15 minutes 2) I am now using new HPROF tool in Android Studio. I have found some leaks in Now Playing activity. But I still didn't found the cause. |
|
|
2) There was an issue with some AsyncTaskManagers that were used as non-static classes and this classes were kept in other threads when activity was destroyed. It caused big leaks because activities are large in memory and contain all it's views (UI components). 3) I have found out that logs needs big amount of allocation operations. It can be up to 60% (by size) of allocations during some operations (like sync, activity change) - screenshot attached. This has impact to performance (due to Garbage collector operations) and mainly memory usage. So I have disabled logs for STABLE versions. We do not use it much because we normally fix bugs in BETA version. We should also think about reducing number of logs. NOTE: Java uses Garbage collector so memory is not released right after Activity or other instance is destroyed and it might look like unreleased. It is possible to start garbage collector manually from Android Studio but it is hard to test it without it because it can take up to 5 minutes (when Android does not need the memory) Fixed in 1.1.3.468 |
