Adding annotations to a map are too slow - iOS - ios

I've got a performance problem regarding adding annotations to maps in iOS (using the standard mapkit methods - hence using Apple maps). I'm trying to add a large number of annotations (10000+) in bulk, using the (void)addAnnotations:(NSArray *)annotations method. The annotation objects are nothing special - a very basic class that implements MKAnnotation with only the constructor defined as follows:
- (id)initWithTitle:(NSString *)ttl andCoordinate:(CLLocationCoordinate2D)c2d {
if(self = [super init]) {
title = ttl;
coordinate = c2d;
}
return self;
}
In order to test, I've created a basic app that simply adds the annotations to a basic map view on load, and it takes around 6-7 seconds on an iPad 2. Very acceptable performance. However, things get complicated when I embed the same basic map view in my own application. It's the exact same logic, but when I do it in my app, it takes around 50 seconds to load all the annotations.
My app has a bunch of views within each other. To pinpoint the problem, I've started embedding the map view starting from the lowest level, until I reach the top level. I've done profiling in each step to see if it helps the performance, but I don't see any results - it's still around 50 seconds. Right now, my app basically just loads and adds the annotations to the top and only level map view, ideally the same as the standalone app, but for whatever reason, I still see the annotation rendering taking around 50 seconds. The only reasonable explanation I have is in regards to some of the app settings I have that somehow interferes with the map performance. I've done a bunch of reading to come up with a solution to no avail.
Anyone have any ideas about what might be the problem here? Thanks!

There is no actual "problem". I mean, you have more than 10000 allocations, draws and renderings that are actually having impact on the performance of the application.
My suggestion is to intercept the user navigation on the map. Use something like [mapView visibleMapRect] to get the visible portion of the map on the screen. Get the coordinates of the rect (maybe a little bit bigger so that cannot be noticed by the user when moving the map) and load only the annotations within that rect.
As the user moves, you only have to load the annotations that are within the new rect MINUS the annotations that were already loaded in the previous rect. I guess you can also remove the annotation when they go out of the screen.
This resembles a little bit what Apple suggests to do when dealing with scrolling views. I remember the application in which the user would have to load the content of the previous and next section of the scrollview (and to release the content of the previous-1 view) so to have a slow memory consumption and still maintaining a good user experience.
Try to think about what the user is looking at, try to show only the annotations that matter that portion (or region as they are called in the MKMapView jargon) and I think your app responsiveness will just improve right away.

Related

how to get visible overlays in MapKit? (i.e. MKOverlay/MKOverlayRender from a Mapkit Ivew)

How does one get a list (array) of currently visible overlay from a MapkitView?
Background - for example I want to show direction arrows to the center of certain Overlay types on my mapkitview, however how do I get the visible ones? There seems to be no way to do this I can see? So do I need to got through all overlays (actually ~8000) and do my own check to see what would be showing on the screen? Seems a waste if MapKit would have already effectively done this as part of deciding what overlays need to be displayed at a given time.
I've been tinkering with some similar problems and the most efficient way I could figure out was to add the overlays as annotations as well, since MKOverlay implements MKAnnotation. Then you would be able to use annotationsInMapRect for the currently displayed mapRect. However this would also return any regular MKAnnotations, and only uses the calculated middle of the overlay. The only way (so far as I figured) to only get the overlays would be to iterate over each overlay and use:
-(BOOL)intersectsMapRect:(MKMapRect)mapRect;
on the currently visible mapRect.
If you found another way I'd be happy to hear!

MapKit (iOS) -- Live MKAnnotation Motion

I'm designing an app using Swift for a food truck. I want to use MapKit to show a pin on the live location of the truck so one can look at the app to see it moving in realtime. I was able to get the server-side element set up using PHP/MySQL. Currently, the app makes a HTTP request every 3 seconds.
How should I go about animating the moving pin (or other image)? I tried a few methods already (if you have others, please suggest!):
I removed the pin and quickly added a new one in my HTTP function. While this works, I would prefer a smooth animation, not a flashing, jerky pin.
I subclassed MKMapViewDelgate like with a didAddAnnotationViews delegate that animates the pin's frame using UIView.animateWithDuration as suggested here. Animation only occurred when the map was initially loaded. Also, I have no idea how this would work with coordinates, since it involves frames.
I subclassed MKAnnotation with a modifiable var coordinate. In my HTTP function, I changed the coordinate. EDIT: This now works since I properly refreshed the mapView (thanks #Paulw11). However, I still have two main issues:
There's no linear animation, which I desire to better simulate real-time movement. How would I go about animating the pin's coordinates? Should I use UIView, like in method 2, a fast NSTimer, or something else?
Due to using the setCenterCoordinate function to forcibly refresh the map, the map cancels any current touches. How do I detect if there's any touches on the MapView so I can prevent the forced update?

Remove subviews from an UIView perfomantly?

Hi i'm writing a iOS tiled Map component in Monotouch that requires me to remove and add a large number of (markers)UIViews from a parent UiView as part of the Main thread.
I am specifically implementing clustering for the pins. As they become to close together they cluster into nodes displaying the number of pins the node represents. Depending on the zoom level i need to add and remove pins as they move in and out of nodes
Adding the views is fine as this can be done in bulk with
_parentView.AddSubviews (viewsToAdd.ToArray());
plus it can be chunked.
but the remove is killing my performance as each individual view has to be removed with a
view.RemoveFromSuperview ();
view.Dispose ();
Is there any way to speed up the operation?
I looked into putting the views into an NsArray and using performSelector remove from superview but i couldn't find the correct syntax for that in mono touch
thanks Luke
I think you should consider recycling your views instead of disposing them and creating new ones. This is something Apple's MKMapView provides, but you don't mention if you are using it or not. It works by adding a number of MKPlacemark objects, that are represented by MKAnnotationView recyclable views as you scroll around the map.
There is a reasonable example in Xamarin's Field Service App of using MKMapView's DequeueReusableAnnotation method. Scroll down to the MapViewDelegate nested class.
If you are using another map library, like Google Maps, you should consider keeping a Queue<T> of your views in order to recycle them. That way you can merely call AddSubview and RemoveFromSuperview and not create new objects over and over.

A CATiledLayer-enabled UIView with drawRect-defined subviews crashes due to abnormal memory usage

We have an out-of-memory crash on the iPad 3 which we traced to the following scenario:
A UIView which uses a CATiledLayer and draws content (say, a PDF) has subviews with their own drawRect methods (which, for example, highlight search results). This makes Core Animation consume tons of memory (100+ MBs in the VM Tracker instrument), and can easily lead to a crash. While this issue exists on all devices, only on the iPad's Retina display does the cache size grow too large.
This can be reproduced with Apple's PhotoScroller example: subclass UIView, uncomment drawRect, and add an instance to the TilingView. The app will crash on iPad 3. Commenting drawRect resolves the memory usage.
Now, we can drop the subviews and do the drawing in the top-most UIView. However, working with subviews is convenient (since we're representing different, independent layers on top of the PDF). Two questions:
What is a good work-around? Preferably one that allows us to continue working with multiple views.
Why is this happening, exactly? I guess the cache mechanism is working overtime, but it would be great to understand the technical details behind it.
Thanks!
EDIT:
I want to elaborate on Kai's answer. The problem was indeed unrelated to CATiledLayer, but to the usage of UIViews that implemented drawRect.
In the case of PhotoScroller, I created a UIView which was of a size of the image - 2000x2000 and more, which creates a huge backing store if drawRect is present.
In the case of our app, the overlay views are full-screen (=~11 MBs on iPad 3) and we have about 5 of them per page. We keep up to three pages in memory while scrolling, and that means more than 150 MBs extra memory. Not fun.
So the solution is to optimize drawRect away, or use less such views. Back to the drawing board it is :-)
To 2.: Whenever you implement drawRect in a UIView subclass and have lots of instances of that class, your memory usage will grow dramatically. Reason is that a lot of optimization tricks in UIKit view/subview handling (e.g. when zooming or scrolling) don't work with such objects, because the framework doesn't know what you're doing/what you are drawing.
So - independent of retina or not - avoid implementing drawRect, especially when having many objects or many layers of subviews.
To 1.: I didn't exactly get what you are trying, but I implemented an PDF-Viewer which is also able to show additional content on top of the PDF. I did it all with normal UIView hierarchies, images etc. and I fear that's the only reliable work around you'll get
My experience:
Never add subviews to a UIView that's backed by a CATiledLayer
Never add sublayers to a CATiledLayer
Unfortunately, that seems to be the only practical answer - Apple's implementation goes horribly wrong in many different ways (not just performance - the rendering itself starts to exhibit visual artifact bugs, some of Apple's rendering code goes weird, etc).
In practice, I always do this:
UIView : view
+-- UIView w/ CATiledLayer : tiledLayerView
+-- UIview : subViewsView
...and safely add views and subviews to "subViewsView". Works fine.

UIScrollView image/photo viewer with paging enabled and zooming

OK, I think it's time to make an official place on the internet for this problem: How to make a UIScrollView photoviewer with paging and zooming. Welcome my fellow UIScrollView hackers.
I have a UIScrollView with paging enabled, and I'm displaying UIImageViews like the built-in photos app. (Does this sound familiar yet?)
I found the following project on github:
https://github.com/andreyvit/ScrollingMadness/wiki
Which shows how to implement zooming in a scroll view while paging is enabled. If anyone else tries this out, I actually had to remove the UIScrollView subclass and use the native class otherwise it doesn't work. I think it's because of changes in the 3.0 SDK relating to how the scroll view intercepts touch events.
So the the idea is to remove all the other views when you start zooming, and move the current view to (0, 0) in the scrollview, updating the contentsize etc. Then when you zoom back to 1.0f it adds the other views back and puts things all back in order.
Anyway, that project works perfectly in the simulator, but on the device there is some nasty movement of the view you are resizing, which looks like it's caused by the fact we are changing the contentsize/offset etc. for the view being resized. You have to do this view moving otherwise you can pan left through the whitespace left by the other views.
I found one interesting note in the "Known Issues" of the 3.0 SDK release notes:
UIScrollView: After zooming, content inset is ignored and content is left in the wrong position.
This kind of sounds like what is happening here. After zooming in, the view will shift offscreen because you have changed the offset etc.
I've spent hours on this already and I'm slowing coming to the sad realization that this just isn't going to work.
Three20's photo viewer is out of the question: it's too heavy weight and there is too much unnecessary UI and other behaviour.
The built in Photo app seems to do some magic. If you zoom in on an image and pan to the far edges, the current photo moves independently of the photo next to it which isn't what you get when trying this with a standard UIScrollView.
I've seen discussion about nesting the UIScrollView's but I really don't want to go there.
Has anybody managed this with the standard UIScrollView (and works in the 2.2 and 3.0 SDK)? I don't fancy rolling my own zoom + bounce + pan + paging code.
UPDATE
I deleted my previous answer because of the news below...
Big news for those who haven't heard. Apple has released the 2010 WWDC session videos to all members of the iphone developer program. One of the topics discussed is how they created the photos app!!! They build a very similar app step by step and have made all the code available for free.
It does not use private api either. Here is a link to the sample code download. You will probably need to login to gain access.
Check This
And, here is a link to the iTunes WWDC page:
Check This
I've written a simple and easy to use photo browser called MWPhotoBrowser. I decided to create it as Three20 was too heavy/bloated as all I needed was a photo viewer.
MWPhotoBrowser can display one or more images by providing either UIImage objects, or URLs to files, web images or library assets. The photo browser handles the downloading and caching of photos from the web seamlessly. Photos can be zoomed and panned, and optional (customisable) captions can be displayed. The browser can also be used to allow the user to select one or more photos using either the grid or main image view.
You say you've seen discussions of nesting UIScrollViews but don't want to go there - but that is the way to go! It works easily and well.
It's essentially what Apple does in its PhotoScroller example (and the 2010 WWDC talk linked to in Jonah's answer). Only in those examples, they've added a whole bunch of complex tiling and other memory management. If you don't need the tiling etc. and if you dont want to wade through those examples and try and remove the bits related to it, the underlying principle of nesting UIScrollViews is actually quite simple:
Create an outer UIScrollView and set its pagingEnabled = true. Add it to your main view and set its width and height to your main view's width and height.
Create as many inner UIScrollViews as you want images. Set their width and height to your main view's width and height. Add them as subviews to your outer UIScrollView, each one next to the other, left to right.
Set the content size of the outer UIScrollView to the total of the widths of all the inner UIScrollViews side by side (which is equal to [your main view's width]*[number of images]).
Add your images' UIImageViews to the inner UIScrollViews, one UIImageView to each inner UIScrollView. Set each UIScrollView's content size to each UIImageView's size.
Set min and max zoom scales for each inner UIScrollView and set each of the inner UIScrollView's delegate to your View Controller. In the delegate's viewForZoomingInScrollView, return the appropriate UIImageView for the UIScrollView that is passed. (To do this, just keep each of the UIImageViews in an NSArray and set the corresponding UIScrollView's tag property to the index of the appropriate UIImageView. You can then read the tag in the UIScrollView passed to viewForZoomingInScrollView and return the appropriate UIImageView from the NSArray).
That's it. Works just like the photo app.
If you have a lot of photos, to save memory you can just have two inner UIScrollViews and two UIImagesViews. You then dynamically flip between them, moving their position within the outer UIScrollView and changing their images as the user scrolls the outer UIScrollView. It's a bit more complex but the same principle.
I did some playing around with the native Photos app, and I think I can say with confidence they are using a single UIScrollView. The giveaway is this: zoom in on an image, and pull to the left or right. You will see the next or previous photo. If you tug hard enough, it will even page to the next photo at 1.0f zoom. Flip back and the previously zoomed photo will be back to 1.0f zoom as well.
Obivously I didn't write Photos.app, but I'll take a wild guess at how they did it:
A single UIScrollView and a single UIScrollViewDelegate
Populate the UIScrollView with UIImageView children
Listen for scrollViewDidScroll:
Do some math and figure out what page you are currently on
Listen for viewForZoomingInScrollView:
Return a different view depending on the page index
Listen for scrollViewDidEndZooming:withView:atScale: and optionally do some anti-aliasing, etc based on the content
If you decide to try that out, let me know how it works out for you. I'd love to know how you finally end up getting this to work. Even better, post it to github.
I did some playing around with the
native Photos app, and I think I can
say with confidence they are using a
single UIScrollView. The giveaway is
this: zoom in on an image, and pull to
the left or right. You will see the
next or previous photo. If you tug
hard enough, it will even page to the
next photo at 1.0f zoom. Flip back and
the previously zoomed photo will be
back to 1.0f zoom as well.
This is wrong. I'm using nested scrollviews, and getting exactly the same effect. If you're using some memory management scheme (which I had to start using... my page number is fairly high ('bout 50 each in 2 scrollViews)), then you can use a mechanism similar to whatever you have triggering your page loads / unloads to trigger a zoom reset for the pages -1 and +1 from the current page.
I suspect that apple sets this off as soon as the previous pic has disappeared.
What I don't understand is how to achieve smooth scrolling between pages - there's always a very short hang at the moment of transition. Do not get it. I've gotten pretty deep into fixing it - NSInvocationOperations were my first stop, then I made a reusable views queue for the page views (which retain their image views)... still this durned hang.
I only have one NSOperationQueue running, and I've tried fiddling with the max number of concurrent operations. My thought was that the main thread was getting clogged by competing Queues, or maybe even one queue trying to do to much... still, the hang.
I even tried creating super low-qual versions of my media, in case that was the problem. With each image weighing in at around 10k (these are jpegs, mind you)... you guessed it. The hang's still there.
I'm pretty much resolved to do what I've done before and use TTPhotoViewController from Three20. I've spent some hours swimming through that code, and it's always a great education. At this point, though, I would really like to know where the heck this hang comes from, if only so I can spend my can't-sleep hours wondering about something less brain boiling.
sure would be nice if apple built an image viewer like the photos app into the SDK for us to use. I'm currently using three20 and it works great. But it is a lot of extra stuff to carry around when all you really want is the photo viewer.
i write a code for that , and can be as reference
load current view scrollview and imageview ..
and for the screen next to the current view , only imageview
remove all view when current page load to save memory , so good for many photo project
use tag to differentiate different scrollview
_xxxxxxx
the download link click here
Take a look at https://github.com/facebook/three20/blob/master/src/Three20UI/Headers/TTPhotoViewController.h Not sure if that's what you are looking for

Resources