We've already established how similar UITableView is to UICollectionView. In terms of performance, the similarities just don't stop. UICollectionView is optimized to display cells on screen as fast as possible with as little memory usage as possible. This is especially important for UICollectionView because in a collection, a lot more views could potentially be on screen than in a table. This depends heavily on your layout choices, and this makes it even more important for UICollectionView to be optimized the way it is.

The fact that UICollectionView can show a lot of cells at once makes it a little bit harder to manage its performance. Before iOS 10, cell reuse was managed as depicted in the next screenshot. All of the cells on a single row would be requested right before they are needed to be displayed. This is a costly operation, and any set of cells with a reasonable amount of setup would cause frames to drop, which results in a choppy scrolling in UICollectionView:

When you're aiming for a 60fps scrolling, you only get about 16 milliseconds to perform the calculations you need for the layout before the system wants to render a new frame. So, assuming that the UICollectionView works just like UITableView and that it requests cells just in time, you would calculate the layout for not just one cell in 16 milliseconds, but potentially for five cells or more. This is a significant increase in calculations that need to be performed, and it's easy to miss that 16-millisecond window. Also, once this expensive operation is finally completed, there would be a short period of time with barely any calculations going on. The following diagram displays this uneven distribution of the work that's required with the pre-iOS 10 way of requesting cells:

You can see the peaks and drops in the time that's spent for each frame. In iOS 10, the process of requesting cells has become a lot smarter. Cells aren't requested just in time, but they are requested in a more predictive manner. While a user is scrolling in a certain direction, the UICollectionView will start asking for cells that aren't just on the next row but also for cells that are one or two rows down or up. It won't request all of them at once but it will request them in small portions. The next image shows how this would look compared to the old visualization:

This results in a much more evenly distributed workload for the UICollectionView, which means better scrolling performance for your users. The following graph visualizes the new iOS 10 style. You can see that there aren't peaks in the 16ms+ range anymore. If your app is built with Xcode 8 you'll get this performance gain for free on all iOS 10 devices. There is no manual setup required to take advantage of this huge performance boost.

The final performance optimization you should know about is prefetching. This technique is present in UITableView as well, and it helps the HelloContacts collection view with decoding images, just like it did for the original table. With the knowledge you gained from the previous chapter, you should be able to implement this on your own. If you want to see the implementation for the collection view, you can check out this book's git repository on GitHub.

Prefetching in UICollectionView will give more boost to your application than it did for UITableView. This is mainly because the UITableView won't prefetch as many cells as the UICollectionView has owing to the amount of cells that are displayed at any given time. Typically, a UICollectionView will display more cells so prefetching will have greater benefits.

If you have prefetching enabled and want to test what happens when it's not present, for example, for users that are on iOS 9, you can set the isPrefetchingEnabled property of UICollectionView to false. This will disable prefetching and will allow you to measure the performance you gained with prefetching enabled.