StackOverflow2013

Note that there are some explanatory texts on larger screens.

plurals

PO
text
Body
copied!<p>The only way you'll know for sure is by experimenting a bit. I realise that's not an overly helpful answer, but I can at least give you some hints:</p> <p>Efficiently displaying more than one screenful of stuff with <code>UIScrollView</code>s is notoriously difficult. I've struggled with this for weeks in some cases. This was much worse on older hardware (iPhone 3G/2nd gen iPod or older) but you can still easily bring modern iOS devices to a crawl if you get it wrong. You will typically run into two performance issues:</p> <ul> <li>Having many <code>UIView</code>s (this includes UILabel etc.) on screen at once severely hurts performance. You'll run into this if every data point is a view and you can zoom out to see all of them.</li> <li>Conversely, having huge views (bigger than one screenful) is equally bad, as the whole view will need to be kept in memory while any of it is visible.</li> </ul> <p>You can probably see how this fits badly with zooming: you don't know exactly how much one screenful is!</p> <ul> <li>I suggest you set things up nice and simple with everything as views to begin with and don't worry too much about zooming - make sure it all works smoothly at the max zoom level. </li> <li>Then, add in zooming (you'll need to put all your little views in one container view which will be zoomed) and see how it performs on your oldest supported hardware. If you don't allow zooming out too far, you may be okay without any change.</li> <li>If it starts chugging when you zoom out, try subdividing your content into tiles. You'll need to experiment with the size of these, but 20+ subviews per tile is probably a good start. In your scroll view delegate, detect when the user is sufficiently zoomed out and force your tiles to rasterise by setting the <code>shouldRasterize</code> property to true on their <code>CALayer</code>. This should essentially pre-render all the subviews of a tiles into a texture, so when it comes to rendering the screen, it'll use that pre-rendered image instead of walking through all your subviews and rendering them individually. Make sure to disable it again once the user zooms in again sufficiently. Also try to avoid setting it for all tiles at once or it will stutter, so for example you could set up separate random zoom level thresholds for each tile.</li> </ul> <p>If you end up having trouble with <code>shouldRasterize</code>, you may need to work at the <code>CALayer</code> level directly. If none of this helps, the sledgehammer method is to use <code>CATiledLayer</code> like the <code>MKMapView</code> and others do. This requires you to do all the rendering and touch event handling yourself, and will normally also cause the (somewhat ugly) fade-in you get when scrolling in the Maps and Safari apps.</p> <p>Some additional hints:</p> <ul> <li>Avoid keeping lots of different images in memory. This means re-using a small number of <code>UIImage</code>s if you can. If each view is slightly different, generate the images on-demand in drawRect: or using filters rather than drawing them as <code>CGImage</code>s up front, or loading them from file.</li> <li>Avoid alpha blending (translucency) if at all possible.</li> <li>You can visualise UIKit compositing complexity using the Performance Tool. Check out the Core Animation and tools talks from the WWDC archives.</li> </ul> <p>I hope that helps you get started. Good luck!</p>

Querying!

Guidance

An individual column

Larger individual text columns get their own page to allow for proper reading.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload