Repository navigation
Closed
Labels
c: performanceRelates to speed or footprint issues (see "perf:" labels)Relates to speed or footprint issues (see "perf:" labels)customer: crowdAffects or could affect many people, though not necessarily a specific customer.Affects or could affect many people, though not necessarily a specific customer.engineflutter/engine related. See also e: labels.flutter/engine related. See also e: labels.perf: memoryPerformance issues related to memoryPerformance issues related to memory
Description
This is a tracking bug for the collection of sub-issues around improving Flutter's memory consumption, and offering developers more flexibility in choosing where to set the dial on the time performance vs memory consumption spectrum.
Related issues:
- Flutter should provide more control over image caching #13493: Flutter should provide more control over image caching
- Flutter should be smarter about memory limits for images #26187: Flutter should be smarter about memory limits for images
- Free resources after a Flutter view is destroyed #16995: Free resources after a Flutter view is disposed
- Unmount everything and dispose States when host activity dies #19358: Unmount everything and dispose states when host activity dies
- Memory Leaks on iOS #23231: Memory leaks on iOS
- More deterministic measurement of memory consumption #20690: More deterministic measurement of memory consumption.
- Remove in memory decoded frame cache #26081: Disable in-memory decoded frame cache by default
- Consider mipmapping
ui.Image's generated by the engine. #26443: Consider mipmapping ui.Images generated by the engine - OnMemoryPressure is unreliable on Android #15479: OnMemoryPressure is unreliable on Android
- Raster cache images may be much bigger than the visible/clipped area #25155: Raster cache images may be much bigger than the visible/clipped area
- IO thread GrContext memory needs to be cleaned up #19558: IO thread GrContext memory needs to be cleaned up
- Persist the memory profile timeline #44013: Persist the memory profile timeline
Reacted by Sacchi, dannywu, Sebastian Roth, Audrius Karosevicius, rsaf, anylei, Miguel Medeiros, Jun Gu, Ramon Honório, Ornstein and 27 more
Metadata
Metadata
Assignees
Labels
c: performanceRelates to speed or footprint issues (see "perf:" labels)Relates to speed or footprint issues (see "perf:" labels)customer: crowdAffects or could affect many people, though not necessarily a specific customer.Affects or could affect many people, though not necessarily a specific customer.engineflutter/engine related. See also e: labels.flutter/engine related. See also e: labels.perf: memoryPerformance issues related to memoryPerformance issues related to memory
Activity
rsaf commentedon May 16, 2019
This is a really worrying issue for many developers. I created a similar issue.
#32820
deverlion commentedon Jul 24, 2019
We also have completely similar problems.We are now in v1.5.4-hotfix.2, the video plays normally, and iOS does not crash. But when I upgrade to v1.7.8+hotfix.3, iOS video playback is easy to crash because of iOS memory issues. (Only iOS has problems, Android is OK)
DyaryRaoof commentedon Oct 12, 2019
any solution guys ?
alectogeek commentedon Nov 9, 2019
Is there any news? It really prevents us from releasing an app because it becomes too memory consuming because of a huge count of images in the app :(
DyaryRaoof commentedon Nov 9, 2019
@alectogeek
Try changing to master channel and use the cacheWidth and cacheHeight parameters with your image widgets like so Image.Network(cacheWidth:100, cacheHeight : 100) or use it with Cached_Network_Image(cacheWidth:100, cacheHeight : 100).
This is supposed prevent too much memory consumption.
I haven't yet tested it because I have problem with changing to the master channel and there are errors preventing me from testing this. It may not be the same in your case. I use a lot of plugins wich maybe causing the issue that I haven't had time to find a solution for.
Please let me know if the solution worked for you.
alectogeek commentedon Nov 9, 2019
@DyaryRaoof Thank you for answer! But looks like cached_network_image 2.0.0-rc.1 package doesn't have cacheHeight/cacheWidth properties
DyaryRaoof commentedon Nov 9, 2019
It think it 's present if I am not mistaken. But did you try it in the Image.Network and see if it's present or not. because the last time I checked I couldn't find it either I had to install the flutter SDK again then switch to the master channel but I am not sure if it was present in the Cached_Network_image.
And as a side note. why not try Image.Network with the cacheWidth and cacheHeight constructors if it is present . It may make your app a lot more stable.
alectogeek commentedon Nov 9, 2019
@DyaryRaoof Unfortunately, I can't try this. I need to cache images in local storage so I use cached_network_image absolutely everywhere in my app. Moreover, I show almost the whole picture, so, I guess, it will not help in my case. :(
AAverin1994 commentedon Nov 22, 2019
Any news? I am also having problems with memory leak. #45391
Mohammad-Adam commentedon Jan 24, 2020
FutureBuilder<File>( initialData: File.fromRawPath(kTransparentImage), builder: (cx, file) { return Image.file( file.data, cacheWidth: 250, cacheHeight: 250, fit: BoxFit.contain, ); }, future: DefaultCacheManager() .downloadFile(widget.post.postImages[index]) .then((fileInfo) => fileInfo.file), );i'm facing this problem, and i'm using this code to use cacheWidth and cacheHeight with cache managing, using package:
flutter_cache_manager: ^1.1.3davewise commentedon Feb 5, 2020
cacheHeight/cacheWidth properties fixed the massive memory usage in my case. I actually only use cacheWidth to maintain aspect. Even when I set the cacheWidth to 1200 the memory usage is 5 times smaller than without that property set. Seems like the cacheWidth should default to some reasonable number that doesn't cause memory hogging and can be overridden with a larger or smaller number if the developer wishes.
danielgchap commentedon Feb 10, 2020
Hi davewise! Are you using cachednetworkimage or the out of the box Image.network approach? (I'm currently using cachednetworkimage, I'm just trying to find the best approach)
pacifio commentedon Mar 8, 2020
It happens mostly when showing images ..
liyuqian commentedon Mar 23, 2020
@dnfield : would you also prefer to close this meta issue and just track memory issues from label "perf: memory"? (Similar to what you've done with #13493)
dnfield commentedon Mar 23, 2020
I'm not a huge fan of meta issues like this - they tend to get outdated. And at least one of the linked issues in the top of this bug would actually increase memory consumption.
I think before closing this one we should make sure the linked bugs are closed/addressed though. With the image cache one the bugs it referred to were all either out of date or closed.
davewise commentedon Apr 2, 2020
I'm using the Image.network approach. Not sure which is the best approach though...
ShekarMudaliyar commentedon May 9, 2020
Any updates on this? my app is in production and want to send an update but cannot coz its crashing on ios
dnfield commentedon May 18, 2020
I've closed out a few of the bugs linked here that I believe are resolved. Some of them are still not, so I've made sure to label with with
perf: memory. There are a number of other bugs related to memory under that tag, which should be the most up to date way of finding and tracking memory related issues.I'm going to close this issue since it is not really up to date and will quickly get out of date again if we add more bugs to it. Instead, follow perf: memoryPerformance issues related to memory
github-actions commentedon Aug 21, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.