What is UITableViewDataSourcePrefetching

Prefetching is useful when we need to download large models (usually images or video files) from the web or obtain from disk. Prefetching also gives us some kind of laziness in accessing data models: we don’t have to obtain all the data models, but rather only those, which are about to display. This approach reduces battery and CPU consuming and, thus, leads to better user experience.

Cells Rendering is a Critical Task

The table view is requesting the cell that needs to be displayed (tableView(:cellForRowAt:)). The table view is about to display the cell (tableView(:willDisplay:forRowAt:)). The cell has been removed from the table view (tableView(_:didEndDisplaying:forRowAt:)).

First off, the tableView(_:cellForRowAt:) method should be as fast as possible. This method is called every time a cell needs to be displayed. The faster it executes, the smoother scrolling the table view will be.

Define the View Model for the Cells

One way is to have all the properties we need to show be readily available and just assign those to the proper cell counterpart. In order to achieve this, we can take advantage of the MVVM pattern

Fetch Data Asynchronously and Cache View Models

Avoid blocking the main thread while fetching data. Updating the table view right after we retrieve the data.

We can use the above snippet to fetch the users data in a few different ways:

Only the when loading the table view the first time, by placing it in viewDidLoad(). Every time the table view is displayed, by placing it in viewWillAppear(_:). On user demand (for instance via a pull-down-to-refresh), by placing it in the method call that will take care of refreshing the data. The choice depends on how often the data can be changing on the backend. If the data is mostly static or not changing often the first option is better. Otherwise, we should opt for the second one.

Load Images Asynchronously and Cache Them

Use Opaque Layers and Avoid Gradients

Since using a transparent layer or applying a gradient requires a good amount of computation, if possible, we should avoid using them to improve scrolling performance. In particular, we should avoid changing the alpha value and preferably use a standard RGB color (avoid UIColor.clear) for the cell and any image it contains:

We are using the cached View Model data.
We are fetching the images asynchronously.

Use Self-Sizing Cells for Cells of Variable Height

override func viewDidLoad() {
   [...]
   tableView.estimatedRowHeight = ... // Estimated default row height
   tableView.rowHeight = UITableViewAutomaticDimension
}

Cell Lifecycle in iOS10

In iOS10, the lifecycle of a cell is mostly the same as in iOS9. However, there are a few significant differences.

The first difference is that the OS calls collectionView(_:cellForItemAt:) much earlier than it used to. This means two things:

The heavy lifting of loading the cell can be done way before the cell needs to be displayed. The cell may not end up being displayed at all (as it may not ever be brought into the visible field). The second difference is in what happens when a cell goes off the visible field. With iOS10, collectionView(didEndDisplaying:forItemAt:) is called as usual but the cell is not immediately recycled. The OS keeps it around for a little bit in case the user inverts the scrolling direction; if this happens, the cell is still available and can be displayed again (collectionView(_:willDisplay:forItemAt:) will be called) without having to reload its content.

Prefetching API