Dart/Flutter never release memory of "Dart/Flutter Native" leading to OOM crash
# Problem Recently I encounter some crashs on an app because it was Out Of Memory. After some digging with DevTools I quickly found that a scrollable list of images was filling anormaly the memory. After some testing I have the feeling that pictures are remove from "**Dart/Flutter**" cache but are never release from "**Dart/Flutter Native**" memory. I've tried to use **cacheWidth** and **cacheHeight** parameters but same issue the memory never empty itself. I've tried **cached_network_image** package but the same issue occurs with the fact that it fills up faster the memory since the images are cached. I've tried also to download the content of pictures (Uint8List) to display with **Image.memory** but same issue occurs. This behaviors confort me that the problem is based on the ListView keeping rasterize children in memory or something like this. On this graph we can see the evolution of the "**Dart/Flutter Native**" that increase constantly without decreasing in contrary of the "**Dart/Flutter**" that manage smarter the memory consumption.  On the **Analysis** and **Allocations** tab we can see that the **_List** class is instantiate a large number of times causing to use a lot's of bytes.  ![Allocations](https://user-images.githubusercontent.com/386
Posted by NeroThroN on Apr 19, 2022, 11:42 AM
Tags
Related issues
- Many devs love to shit on the guy from the 'I just want the exe.
- Now imagine how poor people stress if their smartphone bricks or gets damaged or lost.
- Resuming an extended-thinking session fails permanently with 400 "thinking blocks cannot be modified" (transcript stores thinking text as empty but keeps signat
- I'll preface this with a statement that as a European I want European alternatives to succeed, and MS-owned GitHub to shrivel and disappear.
- Yeah, but there’s a world of difference between “not perfect” and “we rounded a few sliders, and now the modal is a nightmare to use”.
- I used to write a lot of native Windows corporate software in the 90's and 2000's and my standard login window was a floating draggable o...
Raise real-world problems, find people facing the same issue, and discuss solutions.2,500 issues0 comments
reliability (SaaS)
Many devs love to shit on the guy from the 'I just want the exe.
Now imagine how poor people stress if their smartphone bricks or gets damaged or lost.
Resuming an extended-thinking session fails permanently with 400 "thinking blocks cannot be modified" (transcript stores thinking text as empty but keeps signat
I'll preface this with a statement that as a European I want European alternatives to succeed, and MS-owned GitHub to shrivel and disappear.
Yeah, but there’s a world of difference between “not perfect” and “we rounded a few sliders, and now the modal is a nightmare to use”.
I used to write a lot of native Windows corporate software in the 90's and 2000's and my standard login window was a floating draggable o...
App broken with Mosquitto broker 7.0.0
[BUG] Remote Control: automatic reconnection doesn't work -- connection drops silently with no recovery
Dart/Flutter never release memory of "Dart/Flutter Native" leading to OOM crash
# Problem Recently I encounter some crashs on an app because it was Out Of Memory. After some digging with DevTools I quickly found that a scrollable list of images was filling anormaly the memory. After some testing I have the feeling that pictures are remove from "**Dart/Flutter**" cache but are never release from "**Dart/Flutter Native**" memory. I've tried to use **cacheWidth** and **cacheHeight** parameters but same issue the memory never empty itself. I've tried **cached_network_image** package but the same issue occurs with the fact that it fills up faster the memory since the images are cached. I've tried also to download the content of pictures (Uint8List) to display with **Image.memory** but same issue occurs. This behaviors confort me that the problem is based on the ListView keeping rasterize children in memory or something like this. On this graph we can see the evolution of the "**Dart/Flutter Native**" that increase constantly without decreasing in contrary of the "**Dart/Flutter**" that manage smarter the memory consumption.  On the **Analysis** and **Allocations** tab we can see that the **_List** class is instantiate a large number of times causing to use a lot's of bytes.  
No comments yet. Start the discussion.