iOS UIScrollView performance

Question

I\'m trying to increase the scrolling performance of my UIScrollView. I have a lot of UIButtons on it (they could be hundreds): every button has a

Answer 1

Don't touch a line of code until you've profiled. Xcode includes excellent tools for exactly this purpose.

1. First, in Xcode, make sure you are building to a real device, not the simulator

2. In Xcode, choose Profile from the Product menu

3. Once Instruments opens, choose the Core Animation instrument

4. In your app, scroll around in the scroll view you're looking to profile

You'll see the real time FPS at the top, and in the bottom, you'll see a breakdown of all function and method calls based on total time ran. Start drilling down the highest times until you hit methods in your own code. Hit Command + E to see the panel on the right, which will show you full stack traces for each function and method call you click on.

Now all you have to do is eliminate or optimize the calls to the most "expensive" functions and methods and verify your higher FPS.

That way you don't waste time optimizing blind, and potentially making changes that have no real effect on the performance.

---

My answer is really a more general approach to improving scroll view and table view performance. To address some of your particular concerns, I highly recommend watching this WWDC video on advanced scroll view use: https://developer.apple.com/videos/wwdc/2011/includes/advanced-scrollview-techniques.html#advanced-scrollview-techniques

Answer 2

My most common solution is to rasterize the Views:

_backgroundView.layer.shouldRasterize = YES;
_backgroundView.layer.rasterizationScale = [[UIScreen mainScreen] scale];

But it works not in every situation.. Just try it

Answer 3

Here's a few recommendations:

1) First, understand that scrollViewDidScroll: will get called continuously, as the user scrolls. Not just once per page. So, I would make sure that you have logic that ensures that the real work involved in your loading is only triggered once per page.

Typically, I will keep a class ivar like int lastPage. Then, as scrollViewDidScroll: is called, I calculate the new current page. Only if it differs from the ivar do I trigger loading. Of course, then you need to save the dynamically calculated index (currentPage in your code) in your ivar.

2) The other thing is that I try not to do all the intensive work in the scrollViewDidScroll: method. I only trigger it there.

So, for example, if you take most of the code you posted and put it in a method called loadAndReleasePages, then you could do this in the scrollViewDidScroll: method, which defers the execution until after scrollViewDidScroll: finishes:

- (void)scrollViewDidScroll:(UIScrollView *)tmpScrollView {
    CGPoint offset = tmpScrollView.contentOffset;
    //322 is the height of 2*2 buttons (a page for me)
    int currentPage = (int)(offset.y / 322.0f);

    if (currentPage != lastPage) {
        lastPage = currentPage;
        // we've changed pages, so load and release new content ...
        // defer execution to keep scrolling responsive
        [self performSelector: @selector(loadAndReleasePages) withObject: nil afterDelay:0];
    }
}

This is code that I've used since early iOS versions, so you can certainly replace the performSelector: call with an asynchronous GCD method call, too. The point is not to do it inside the scroll view delegate callback.

3) Finally, you might want to experiment with slightly different algorithms for calculating when the scroll view has actually scrolled far enough that you want to load and release content. You currently use:

int currentPage=(int)(offset.y / 322.0f);

which will yield integer page numbers based on the way the / operator, and the float to int cast works. That may be fine. However, you might find that you want a slightly different algorithm, to trigger the loading at a slightly different point. For example, you might want to trigger the content load as the page has scrolled exactly 50% from one page to the next. Or you might want to trigger it only when you're almost completely off the first page (maybe 90%).

I believe that one scrolling intensive app I wrote actually did require me to tune the precise moment in the page scroll when I did the heavy resource loading. So, I used a slightly different rounding function to determine when the current page has changed.

You might play around with that, too.

Edit: after looking at your code a little more, I also see that the work you're doing is loading and scaling images. This is actually also a candidate for a background thread. You can load the UIImage from the filesystem, and do your scaling, on the background thread, and use GCD to finally set the button's background image (to the loaded image) and change its frame back on the UI thread.

UIImage is safe to use in background threads since iOS 4.0.

Answer 4

The line that is likely killing your performance is:

addButton.layer.cornerRadius=10.0;

Why? Turns out the performance for cornerRadius is AWFUL! Take it out... guaranteed huge speedup.

Edit: This answer sums up what you should do quite clearly.

https://stackoverflow.com/a/6254531/537213