IssueTracker

I do have found that sometimes, under some "isolated non-obvious" circumstances, some memory is actually freed (see attached image). But I agree with this post, because in general, it seems like no memory is ever freed by Google Maps SDK.

To me, the most important problem here is that the map does not free memory nor even when memory warnings are received, so you can have your app performing really bad at a given moment just because there are tiles in memory from Google Maps SDK that you actually are not seeing in your map view at that moment.

yes that is it... thanks for the image. it reflects what I see.

I think a serious problem, for old devices (3GS / 4).

We can also confirm that memory usage keeps going up while new tiles are loaded. Any word on when we can expect a fix?

I can confirm this behavior; on a (256K RAM) iPod Touch, my app is getting repeated warnings after scrolling/zooming, and eventually, memory-kicked by iOS. Memory is not reclaimed after initial Google Maps use, although no memory leaks show up in Instruments.

yes, to me it seems like the MOM used for caching tiles just keeps growing without bounds.
so unbounded caching seems to happen -- no leak

Yes, same for me, when i m zooming allocation memory is increased, after there is memory warning, after app crashes.

Same for us.
But for us the leak appear for set marker image. You can easily crash the application if you'll set large images for any markers.
As per call trace analysis it seems that library creates atlas for markers to draw it and never free it.

yes, I can confirm it crashes for markers too ... :(

This is also happening to Foodspotting.

App launches and settles in at 14mb until the first map view is loaded and finished setup it grows to 90mb.  Once the map view is dealloc'd the app returns to 30mb.

how to fix ？

In 1.5.0, memory usage has been reduced significantly.

This is definitely not fixed in the 1.5.0 SDK. I can reproduce 100% of the time a situation in which doing all of the following:

    [_mapView clear];
    [_mapView stopRendering];
    _mapView.delegate = nil;
    _mapView = nil;

Still results in a huge amount of memory not being released.

Just to be clear, if memory usage is at 14mb when I push a view controller that instantiates GMSMapView, the expectation is that when I release the instance of GMSMapView, memory should return to 14mb fairly quickly.
'Aggressive' cacheing should be optional, especially since in this case it's a guaranteed crash if the user visits this view controller regularly.

Still have same issue with 1.7.2v. Memory doesn't release after destroy mapView. Any suggestion about fixing?

[Comment deleted]

Still not fixed.

Still seeing this in 1.8.1 with Swift

Yes, I'm running it on an iPhone4s with iOS8 with 1.9.3

well, 1.10.1 have too ((

is memory issue solved ?

I can still see the that huge amount of memory is still not cleared for mapView. How to manually clear the cache or GMSMapView data. There must be some way.

Same to me, the memory keeps increasing each time I open the map view, especially when interact with the map (zoom in, out, moving map). How could I release the memory of that?

I am also still facing same issue. Not yet solved.

The problem is still there with v1.12.3. Memory keeps increasing when we do Zoom In or Out. Any solution to this, please help

Here as well - horrible...

any update for this problem?

Indeed, anything???

What worked for me was removing the `@try` clause I had in `dealloc`:
   
    @try {
        [self.mapView removeObserver:self forKeyPath:@"myLocation"];
    }
    @catch (NSException *exception) {
    }

My intention was to remove `self` as observer when the ViewController is dealloc'd (ironically to avoid a memory issue), and ignore the exception if it is not an observer.

Apparently `@try` somehow retains the mapView, which makes it stay in memory (via ARC). See why here: http://stackoverflow.com/questions/27140891/why-does-try-catch-in-objective-c-cause-memory-leak.

After removing `@try` clause (and conditioning the `removeObserver` with some flag to avoid the exception), the memory went back to behave normally!