What is… Nuke?

5) Deserialize & Decode Images

Once you request an image from the network, there are two things that must happen before iOS can display it on the screen: image deserialization, and image decoding.

Image Deserialization

The first is image deserialization, which translates a binary blob to the image file.

UIImage can handle deserialization for you, but this potentially expensive operation usually happens on the main thread and can affect your UI. Nuke helps you maintain a buttery smooth UI by handling deserialization in the background. This occurs in Nuke’s ImageDecoder class, with the important bit as follows:

return UIImage(data: data, scale: UIScreen.mainScreen().scale)

Note: There isn’t anything in Apple’s official documentation stating init?(data data: NSData, scale scale: CGFloat) is thread-safe. Nevertheless, from an empirical point of view, and mostly agreed upon in the development community at large, init?(data data: NSData, scale scale: CGFloat) works outside the main thread.

Image Decoding

The step after deserialization is image decoding. An image always comes to you encoded in a particular image format, usually denoted by the file’s extension, such as .JPG or .PNG. Image decoding takes the encoded file and uses image standards to translate the file into a 2-D grid of colors to show on the screen.

The good news is that UIImage and UIImageView handle image decoding for you automatically. The bad news is that, like deserialization, decoding usually happens on the main thread, which again can degrade UI performance.

Nuke handles image decoding off the main thread as well. Nuke’s ImageDecompressor class internally forces early decompression into a Core Graphics context in the background. Very cool! :]

6) Preheat Images

The most exciting feature in Nuke is probably the ability to preheat images.

If you’re an expert at preheating food but don’t know how to preheat images, here’s what it means: you make the image request at some time well before you need to display the image, download it and store it in the application’s network cache.

Later when you need to display the image, the response to your request will come back from the cache instead of the network, which is much faster and more reliable than making a network request and hoping it will succeed and download in enough time before your user notices the delay.

Imagine you have have a screen that displays an article with an image at the bottom; you know there’s a good chance the user will eventually scroll down to see the image. With Nuke, you can preheat the image as soon as the user opens the article; as soon as she scrolls down the image will load so quickly as to give the impression it was there all along.

Here’s how you preheat an image with Nuke:

let articleImagesRequests = article.imagesRequests() // get the article's images requests
Nuke.startPreheatingImages(articleImagesRequests)    // start the oven

Stopping the operation is just as easy:

Nuke.stopPreheatingImages(articleImagesRequests)

The great thing about this approach is that explicit image requests are of a higher priority than preheating requests. Grebenyuk wrote a comprehensive explanation of this feature in the Nuke repo’s wiki.

Preheating and UICollectionView

Nuke also extends its preheating functionality to work seamlessly with UICollectionViews by way of ImagePreheatingControllerForCollectionView and the ImagePreheatingControllerDelegate protocol, which defines a single method:

func preheatingController(controller: ImagePreheatingController,
    didUpdateWithAddedIndexPaths addedIndexPaths: [NSIndexPath],
    removedIndexPaths: [NSIndexPath])

This delegate method passes in two important index path arrays:

• addedIndexPaths: The index paths to preheat.
• removedIndexPaths: The index paths to remove from preheating.

How does ImagePreheatingControllerForCollectionView know which index paths to start and stop preheating? Basically, it observes the UICollectionView‘s UIScrollView contentOffSet and figures out which cells are coming in and out of the view port, taking into consideration the scrolling direction and the device orientation.

If you want to use this feature with UITableView, you can use ImagePreheatingControllerForCollectionView‘s superclass ImagePreheatingController. This class observes UIScrollView directly, which UITableView subclasses. However, a little bird told me that full support for UITableView is coming soon! :]

To see a small demo of preheating in action, check out the example in Nuke’s repository here and the PreheatingDemoViewController.swift class.

When Should You Use Nuke?

You should always ask the following two questions before you adopt a third party library:

• Is it being maintained?
• Does it do what it’s supposed to do?

You can answer the first question by checking the frequency of commits and if open issues are being dealt with in a timely fashion. In this case, I think Grebenyuk is doing an excellent job on both fronts! You can check the commit history and the issues list of the repo to see for yourself.

The second question isn’t trivial to answer; determining whether it’s true or false depends on your project. The easiest way is to start using the library see if it does exactly what it says on the tin. You can do this using Instruments and see how it behaves in different scenarios. In this case, Allocations, Time Profiler and Leaks would be your best bets. Once you’ve checked that it behaves as expected in your particular use case, you’re good to go.

In my day to day experience with Nuke, it’s worked as promised; as a standard image fetcher and cacher, Nuke does a flawless job.

Alternatives to Nuke

There are other interesting libraries out there that are comparable to Nuke; one of them is Kingfisher. Although Kingfisher is a perfectly valid option, the preheating feature offered by Nuke was something I really needed, so having it work out of the box made it an easy decision to use Nuke.

On the other hand, if you’re already using something like Alamofire, you could probably just use its companion library AlamofireImage for image handling. It’s difficult to justify the use of Nuke in this case, just for the sake of preheated images.

Why is this useful? If you’re already using Alamofire in your project and decide to leverage Nuke as well, this plugin passes the network tasks of image loading to Alamofire, while preserving Nuke’s caching, processing and decoding abilities. It’s the best of both worlds!

If you need more powerful image processing than Nuke can provide, you could make a combo with Alamofire and Path’s popular FastImageCache to solve your particular problem.