Fixed
Status Update
No update yet.
Comments
mu...@gmail.com
доколе?
th...@google.com
+1
There should be possible to open source in any installed (or minSdk for project) android API version, because compileSdk is not only one used for run the app.
Why it takes so long to release source code to SDK when the sources was already pushed to GIT?
There should be possible to open source in any installed (or minSdk for project) android API version, because compileSdk is not only one used for run the app.
Why it takes so long to release source code to SDK when the sources was already pushed to GIT?
in...@neoos.ch
Fuck this issue, always happened from android 23. Fuck this. Not friendly to developers
th...@google.com
in...@neoos.ch
yep, no 26 sources no funny ;(
all the bunnies gonna cry ;((
all the bunnies gonna cry ;((
cy...@gmail.com
in...@neoos.ch
While debugging, we consider this behavior WAI. That's because stepping through code that doesn't match SDK version of the device is not a good experience. However, we can consider fallbacks to older sources when navigating to definitions while editing your code.
br...@google.com
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?
in...@neoos.ch
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").
cc...@yahoo.com
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.
jo...@gmail.com
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.
wi...@gmail.com
I'm seeing the same thing as everyone else - in the simulator and on the device. Critical that this gets fixed.
io...@gmail.com
Latest Google SDK, same problem, Please solve it
Thanks
Thanks
wi...@gmail.com
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;
}
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;
}
wi...@gmail.com
Here is the graph after re-using the map view.
da...@gmail.com
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.
[Deleted User] <[Deleted User]>
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
th...@google.com
We believe this is resolved in 1.8.0, released today.
wi...@gmail.com
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.
wi...@gmail.com
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.
b....@gmail.com
are the above bug solved in the latest sdk??it seems it is still present ?
br...@google.com
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!
br...@google.com
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!
[Deleted User] <[Deleted User]>
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 .
Apparently `@try` somehow retains the mapView, which makes it stay in memory (via ARC). See why here:
Description
1. Launch app (Memory usage: 3.1 MB)
2. Press '+' button to instantiate GMS View (Memory usage: 52.7 MB)
3. Touch "Back" to release GMS View (Memory usage: 30.2 MB)
Why doesn't it go back to about 3 MB?
Operating system version: iOS 7.0.2
Google Maps SDK for iOS version: 1.5.0.5445
Hardware model: iPhone Simulator
*********************************************************
For developers viewing this issue: please click the 'star' icon to be
notified of future changes, and to let us know how many of you are
interested in seeing it resolved.
*********************************************************