IssueTracker

Hi
Android Studio Meerkat | 2024.3.1

Pixel 9 Pro XL
Android 16.0("Baklava") | x86_64
Api: 36

======================================================================
-- AppData\Local\Android\Sdk\skins\pixel_9_pro_xl\layout

parts {
  device {
    display {
      width 1344
      height 2992
      x 0
      y 0
      corner_radius 0  <--------------- no effect
    }
  }
  portrait {
    background {
      image back.webp
    }
    foreground {
      mask mask.webp
      cutout 0 <------------------------ Deleting or changing it has no effect
    }
  }
}
layouts {
  portrait {
    width 1466
    height 3101
    event EV_SW:0:1
    part1 {
      name portrait
      x 0
      y 0
    }
    part2 {
      name device
      x 57
      y 56
    }
  }
}

-- No Effect
==========================================================

The same problem occurred when using different APIs on different devices.

But after deleting all
        AppData\Roaming\Google\AndroidStudio...
directories and restarting, it seems to have been resolved.

Best regards

Cutout hole appears again. I attatch a screenshot.

Same... for simulator and device.

I've replaced the Google Maps SDK in the example project GMSMemory.zip with version 1.6.0.6204 and did test it again. Unfortunately nothing has changed, the exact same behavior is seen as described in the three steps in the original bug description.

I can confirm previous comment - I've also replace maps in my project  with new version, and nothing has changed. At start application use about 3Mb, when I open VC with map - memory usage increase to 40-50 Mb, and after closing this VC, memory usage is about 10-12 Mb.

How are you guys measuring memory usage on the device? We had a leak that we found and fixed, but that sounds like it was a different issue to the one you are looking at.

I'm using the "Debug Navigator" in Xcode (View > Navigators > Show Debug Navigator). It just gives a high-level view of memory consumption. You can use the attached GMSMemory.zip demo project to reproduce it.

While we agree that the Debug Navigator is showing growth in memory on the simulator, we are not seeing a matching growth in memory consumption on physical devices. Do you have a methodology for testing memory usage of adding and releasing a map on a physical device?

If I run the attached project on a device I get the same picture: starting with 2.7mb, then going up to 23.6 when displaying the map, and then back to 13.1mb when releasing the map (running on iPhone 5 attached to Xcode and monitoring memory consumption in "Debug Navigator").

Google, please debug and resolve this memory leak, it's making your latest SDK (1.7) impossible to use in a commercial product.  Panoramic street views really exacerbate the memory leak too, I'm hitting it within minutes in my iOS app.

Google, as per the comments above we are also using your latest SDK v1.7 in iOS v7 and our app falls to its knees in 1-2 minutes due to leaking memory from your API, please fix asap otherwise we will need to switch to apple maps and we really want to avoid this.

I'm seeing the same thing as everyone else - in the simulator and on the device. Critical that this gets fixed.

Latest Google SDK, same problem, Please solve it
Thanks

A workaround is to keep a reference to the same map view instance and re-use it. In my testing, memory climbs to about 60mb and then plateaus - instead of climbing indefinitely (see graphs).

Something like this.

-(GMSMapView *)getMapView {
    if (self.mapView == nil) {
        self.mapView = [[GMSMapView alloc] init];
    } else {
        self.mapView.delegate = nil;
        [self.mapView clear];
        [self.mapView removeFromSuperview];
        for (UIGestureRecognizer *recognizer in self.mapView.gestureRecognizers) {
            [self.mapView removeGestureRecognizer:recognizer];
        }
    }
    return self.mapView;
}

Here is the graph after re-using the map view.

The same problem with 1.7.2 sdk on different kinds of apple devices and simulators. Temporary solution for me was to use a single shared instance of GMSMapView. In that case used memory size is big (60-80Mb) but limited.  

yep i'm seeing the same issue, can only agree that current solution is to retain a copy of the map view insteading of creating new map view.s

We believe this is resolved in 1.8.0, released today.

Just tried the new version. Definitely not fixed for me. This graph shows a map being created, then destroyed several times. Each time, memory is never released by the map instance.

Scratch that. It is fixed now. My previous memory issue was with a self reference in a block not letting the view controller get released.

are the above bug solved in the latest sdk??it seems it is still present ?

Engineering investigated and fixed the instances we had on hand. If you have a new instance that demonstrates this issue, please raise a new issue with a reproduction sample hosted on GitHub or the like. Thanks!

Engineering investigated and fixed the instances we had on hand. If you have a new instance that demonstrates this issue, please raise a new issue with a reproduction sample hosted on GitHub or the like. Thanks!

What worked for me after a long time was removing the `@try` clause I wrapped a `        [self.mapView removeObserver:self forKeyPath:@"myLocation"];` statement I had upon in `dealloc`. My intention was to remove `self` as observer when the ViewController is dealloc'd, 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.