In my app, I am loading several images onto a UIScrollView and I highlight a portion of the scroll view using Core Graphics routine. I have used the CGImageRelease and CGContextRelease to manage the memory during the routines.
When I run the app using instruments (allocation), I see that the memory consumption keeps rising with every swipe of the scrollView. This at one point leads to the app becoming really slow.
For loading different images, I use the UIImage ImageNamed method, I have come across some posts indicating that this is not a good idea since the method results in autoreleased images which creates memory issues. I would like to know if I am looking a the right place for the error. What could be the possible place to look for this unusual memory consumption?
Also, using the allocation of Instruments, I can just see that increase in the memory, is it possible to pin point the code where these allocations happen?
Thanks in advance for your help!
Best
DKV
For loading different images, I use the UIImage ImageNamed method, I have come across some posts indicating that this is not a good idea since the method results in autoreleased images which creates memory issues.
No, that's not the issue. Anything that doesn't involve you calling alloc, init[WithSomethingOrOther:], and release yourself is going to get the image autoreleased.
The problem is that imageNamed: continues to own the image after it hands it to you. Every image you obtain from imageNamed: stays in that cache, permanently associated with that name. It's not merely a “load this image” method; it's a “load this image and keep it alive forever*” method.
*Where “forever” means “until the end of my process”.
I would like to know if I am looking a the right place for the error. What could be the possible place to look for this unusual memory consumption?
In Instruments. It will tell you exactly how many of each kind of object you are creating, and how much total memory objects of each kind are occupying, and you can sort that list to determine what's eating up memory. Then you can drill down into each class and into each object to determine what's keeping objects alive after you need them.
Related
I am displaying images from the internet in a vertical ListView. I fetch the images using http.get (not using cached network image cuz I do not want to cache the images). Then I insert the image Uint8List into image.memory(). What happens is that as the user scrolls the list and images are loading, the ram keeps increasing until the whole app crashes. Any ideas what to do ?
Yeah, this is the normal behavior. I don't know why exactly. My theory is that the images by default are disposed if the dart objects holding references to them are garbage collected rather then when the widgets are knocked off the widgets tree, but don't take my word for it- that's just my personal reasoning. It may be completely wrong.
To get around this, I use Extended Image pakcage It's constructors take a bool clearMemoryCacheWhenDispose which disposes of images in RAM in scroll lists. You may do that or visit the package code to see how he's doing it, and replicate it.
Other advice I can give is to make sure your images are of the appropriate size. If you are loading your images locally check this part of the documentation to have different dimensions selected for different screen sizes https://flutter.dev/docs/development/ui/assets-and-images#loading-images
If you are fetching your images from network which is more likely, make sure their sizes are appropriate, and have different sizes served if you can. If you don't have control over that set cacheWidth and cacheHeight in Image.memory these will reduce the cached image in memory (RAM). You see by default Flutter caches images in full resolution despite their apparent size in the device/app. For example if you want your image to display in 200x200 box then set cacheWidth to 200 * window.devicePixelRatio.ceil() you will find window in dart:ui, and if you only set cacheWidth, the ratio of your images will remain true. Same true if you only set cacheHeight. Also do use ListView.builder as suggested.
I am disappointed at how little is said about this in Flutter docs. Most of the time people discover this problem when their apps start crashing. Do check your dev tools regularly for memory consumption. It's the best indicator out there.
Cheers and good luck
I was having the same issue and found a fix thanks to #moneer!
Context:
Users in my app can create shared image galleries which can easily contain several hundred images. Those are all displayed in a SliverGrid widget. When users scrolled down the list, too many images were loaded into RAM and the app would crash.
Things I had already implemented:
Image resizing on the server side and getting the appropriate sized images on the client based on the device pixel ratio and the tile size in the gallery
I made sure that my image widgets were properly disposing when out of view, but the memory size kept building up as the user scrolled through all the images anyway
Implement cacheHeight to limit the size of the cached image to the exact size of the displayed image
All these things helped but the app would eventually still crash every time the user scrolled down far enough.
The fix:
After some googling I stumbled upon this thread and tried the extended_image_package as #moneer suggested. Setting the clearMemoryCacheWhenDispose flag to true fixed the issue of the app crashing as it was now properly clearing the images from memory when they were out of view. Hooray! However, in my app users can tap on an image and the app navigates to an image detail page with a nice Hero animation. When navigating back the image would rebuild and this would cause a rebuild 'flicker'. Not that nice to look at and kind of distracting.
I then noticed that there's also an enableMemoryCache flag. I tried setting this to false and that seems to work nicely for me. The Network tab in Dart DevTools seems to show that all images are only fetched from the network once when scrolling up and down the gallery multiple times. The app does not crash anymore.
I'll have to more testing to see if this leads to any performance issues (if you can think of any please let me know).
The final code:
ExtendedImage.network(
_imageUrl,
cacheHeight: _tileDimension,
fit: BoxFit.cover,
cache: true, // store in cache
enableMemoryCache: false, // do not store in memory
enableLoadState: false, // hide spinner
)
I had a similar issue when I loaded images from files in a ListView.
[left-side: old code, right-side: new code]
The first huge improvement for me: not to load the whole list at once
ListView(children:[...]) ---> ListView.builder(...).
The second improvement was that images are no longer loaded at full-size:
Image.file("/path") ---> Image.file("/path", cacheWidth: X, cacheHeight: Y)
These two things solved my memory problems completely
Ideally caching happens kind of by default after some conditions are fulfilled. So its upon your app to be responsible to handle and control how the caching will happen.
Checkout this answer
https://stackoverflow.com/a/24476099/12264865
I am having some memory issues with our android app when handling bitmaps (duh!).
We are having multiple activities loading images from a server, this could be a background image for the activity.
This background image could be the same for multiple activities, and right now each activity is loading its own background image.
This means if the flow is ac1->ac2->ac3->ac4 the same image will be loaded 4 times and using 4x memory.
How do I optimize imagehandling for this scenario? Do I create an image cache where the image is stored and then each activity ask the cache first for images. If this is the case, how do I know when to garbage collect the image from the cache?
Any suggestions, link to good tutorials or similar is highly appreciated.
Regards
EDIT:
When downloading images for the device the exact sizes is used, meaning that if the ui element needs an 100x100 pixel image it gets that size and therefore no need for scaling. So i am not sure about downscaling the image when loading it into the memory. Maybe it is needed to unload images in the activity when moving on the the next and then reload when going back.
One thing you might want to try is scaling down your bitmaps (make a thumbnail) to a size that is more appropriate to your device. It's pretty easy to quickly use up all the RAM on an Android device with a bitmap if you don't scale it down. This recipe shows how to do so on the fly. You could adapt this to save the images to disk.
You could also create your own implementation of the LRUCache to cache the images for your app.
After ready your update I will give you an other tip then.
I can still post the patch too if people want that..
What you need to do with those bitmaps is call them with a using block. That way Android will unload the bitmap as soon as that block is executed.
Example:
using(Bitmap usedBitmap = new Bitmap()){
//Do stuff with the Bitmap here
//You can call usedBitmap.Dispose() but it's not really needed
}
With this code your app shouldn't keep all the used bitmaps in memory.
There are a lot of answers for this question. But all of them are incorrect!
For example if I have created a CCLayer object with one CCSprite object. I have 3 textures and I want to switch between them on every touch.
For example I will use something similar to this:
link
I run this application in Simulator. Then I call a memory warning. Then I try to switch between images (textures). And I see that 2 of 3 images are deleted (except of the image was shown at the same time memory warning appeared).
I tried to use retain/release commands for CCSprite and ССTexture2D but they cause a situation when dealloc method of released object is never called.
So how to store them correctly? I want to store them at memory warning and release/remove them when the current layer is destroyed.
Store them in one texture atlas, created with Texture Packer. Then it's as simple as calling [Sprite setDisplayFrame:frameName] to switch the displayed texture.
By default on memory warning cocos2d will remove unused textures. The whole point of memory warning is that OS tells your app "hey, that's not okay, cut down your memory appetite or I'll shut you down", and your app should be like "oops, sorry, freeing memory now".
If you receive a memory warning when preloading textures, cocos2d's default behavior of removing unused textures will shoot you in the foot. More about this issue here.
My advice: remove the call to purge cocos2d's caches in the memory warning method in AppDelegate. Of course you want to be extra careful with your memory usage. Alternatively you could simply disable the behavior while you're preloading images, but this might simply move the problem to a later point.
I am writing a Cocoa program for Mac, and it includes a picture viewer.
What the picture viewer's job is to download a picture from web and show it. It would do this every time I click a button who would give it a picture URL. So this would be frequent.
My design goal is, every time after I change to another picture or close it temporarily (it is not the main window), it will release the memory it takes. For example, before I open the picture viewer for a picture, my application takes 1M memory. After I open a picture, it takes about, say, 2M memory. And after I close it, it will decrease the memory usage to the original 1M.
The problem is, sometimes after I viewed a picture, especially a big one, the viewer won't give all the memory it took, for example, opening it cost about 20M memory, but after I close it, just 10 of the 20 released, the another 10 is still there and never be freed. It looks like memory leak, but I checked my code and analyzed it many times, I couldn't find any memory leak, and also, some other pictures won't behave like this.
this is weird, is this possibly certain Cocoa internal memory cache policy? Any suggestions would be appreciated. Thanks in advance!
Update: Today after I added a scrollView as a wrapper of the imageView, this weird memory problem seems almost fixed.
Thanks for your advice, edc1591, I will continue to figure out what happened.
Without seeing the code it's hard to tell quite what the problem is. But until I see the code, I'll give you a few pointers for dealing with this:
Enable Garbage Collection. If you already have it enabled, try forcing a garbage collection after releasing the image file like this:
[[NSGarbageCollector defaultCollector] collectIfNeeded];
Try heapshot analysis. Here's a good tutorial on that.
I'll update this answer once the code has been posted.
Interesting problem here - I'm making a small game using Flex 3 - now I have a static ImageAccess class, which first loads up all images and stores them in a static array for quicker access in the future.
Now since I address the physical bitmapdata without calling Clone() (for efficiency issues) and once by accident I've written directly onto the bitmapdata.
Now the weird part - Flex uses some kind of weird caching and stores the bitmap with the new changes made to it - no matter what I do (restart Flex Builder, delete my cache, restart browser) the bitmap data is still loaded with the extra info (even though the image is without all that data).
Please help :D
Can you give more details about what extra info you're talking about?
Correct me if I'm wrong but Flex doesn't cache anything as such, the browser does, in any case , viewing with another browser should display the original image. If it doesn't , you may consider the possibility of some forgotten function still acting on the original bitmap... have you tried viewing the application in another browser by the way?
there's also the possibility of the original image being corrupted for whatever reason...