Be notified of new releases
Create your free GitHub account today to subscribe to this repository for new releases and build software alongside 36 million developers.Sign up
This is the first Nuke 8 beta. There is going to be at least one more beta released in June updated according to your feedback.
Image Processing Improvements
ImagePipeline now supports caching of processed images. To enable this feature set
true in the pipeline configuration and provide a
dataCache. You can use a built-in
DataCache introduced in Nuke 7.3 which supports parallel reads, and instant writes.
Image cache can significantly improve the user experience in the apps that use heavy image processors like Gaussian Blur.
Add the following image processors:
More processors will be added in the upcoming releases.
Previously there were quite a few different ways to add processors to the request. Now there is only one, which is also better than all of the previous versions:
let request = ImageRequest( url: URL(string: "http://..."), processors: [ ImageProcessor.Resize(size: CGSize(width: 44, height: 44), crop: true), ImageProcessor.RoundedCorners(radius: 16) ] )
Processors can also be set using a respective mutable
AnyImageProcessor is also finally gone. You can just use
ImageProcessing protocol directly everywhere.
In the previous versions, the decompression was part of the processing API and
ImageDecompressor was the default processor set for each image request. This was mostly done to simplify implementation but it was confusing for the users.
In the new solution, decompression runs automatically and no longer conflicts with the other processors that you set on the request.
The new decompression is also smarter. It runs only when needed: either if there are no processors provided in the request or when these processors didn't change the original image in any way (e.g.
ImageProcessor.Resize decided not to upscale the image). Decompression also runs after reading the processed image from disk.
Decompression runs on a new separate
imageDecompressingQueue. To disable it set
An experimental feature disabled by default. To enabled it, set
true. When enabled, the pipeline will avoid any duplicated work when processing images. For example, let's take the following requests:
let url = URL(string: "http://example.com/image") pipeline.loadImage(with: ImageRequest(url: url, processors: [ ImageProcessor.Resize(size: CGSize(width: 44, height: 44)), ImageProcessor.GaussianBlur(radius: 8) ])) pipeline.loadImage(with: ImageRequest(url: url, processors: [ ImageProcessor.Resize(size: CGSize(width: 44, height: 44)) ]))
Nuke will load the image data only once, resize the image once and apply the blur also only once. There is no duplicated work done at any stage. If any of the intermediate results are available in the data cache, they will be used.
Nuke 8 introduced a major new iteration of the
ImagePipeline class. It was completely rewritten to embrace progressive decoding and deduplication introduced in Nuke 7.
The new pipeline is smaller, simpler, easier to maintain, and more reliable than the previous iteration. It is powered by a new internal
Task abstraction which is extremely powerful.
Up to 30% Faster Main Thread Performance
With some of the changed introduced in the pipeline, the primary
Nuke.loadImage(with:into:) method became even faster than any of the previous versions on the main thread, up to 30% faster.
ImagePipeline API with a new method:
public func imageTask(with request: ImageRequest, delegate: ImageTaskDelegate) -> ImageTask
This API is meant to be used for advanced features like progressive image decoding. It is also one of the primary reasons why the pipeline is so much faster in Nuke 8.
Add a new
ImagePipeline method to fetch original image data:
@discardableResult public func loadData(with request: ImageRequest, progress: ((_ completed: Int64, _ total: Int64) -> Void)? = nil, completion: @escaping (Result<(data: Data, response: URLResponse?), ImagePipeline.Error>) -> Void) -> ImageTask
This method now powers
ImagePreheater with destination
.diskCache introduced in Nuke 7.4 (previously it was powered by a hacky internal API).
The rarely used options were extracted into new
ImageRequestOptions struct and the processor initializer can now be used to customize all of the request parameters.
Result type introduced in Swift 5. So instead of having a separate
error parameters, the completion closure now has only one parameter -
public typealias Completion = (_ result: Result<ImageResponse, ImagePipeline.Error>) -> Void
There are a few improvements planned for Nuke 8 but which are still in the progress including new performance metrics, new ways to customize cache keys, more processors, more API refinements.
The documentation, the demos, and the migrations guides are also be updated later and available with RC.
- Fix Thread Sanitizer warnings. The issue was related to
unfair_lockusage which was introduced as a replacement for
OSAtomicfunctions in Nuke 7.6. In order to fix the issue,
unfair_lockwas replaced with simple
NSLock. The performance hit is pretty insignificant and definitely isn't worth introducing this additional level of complexity.
- Add Swift 5.0 support – Daniel Storm in #217
- Add SwiftPM 5.0 support - Vadim Shpakovski in #219
- Remove Swift 4.0 and Swift 4.1 support
- Remove iOS 9, tvOS 9, watchOS 2.0, macOS 10.10 and macOS 10.11 support
- Add a single
Nuketarget which can build the framework for any platform
- Replace deprecated
unfair_lock, there are no performance regressions
- #193 Add an option to
ImageDecompressorto allow images to upscale, thanks to @drkibitz
- #197 Add a convenience initializer to
ImageRequestwhich takes an image processor (
ImageProcessing) as a parameter, thanks to @drkibitz
- Add a guarantee that if you cancel
ImageTaskon the main thread, you won't receive any more callbacks (progress, completion)
- Improve internal
Operationperformance (async operation subclass), images are loading up to 5% faster
Nuke 7 had a lot of API changes, to make the migration easier it shipped with Deprecated.swift file (536 line of code) which enabled Nuke 7 to be almost 100% source-compatible with Nuke 6. It's been 6 months since Nuke 7 release, so now it's finally a good time to remove all of this code.
With all these removals, Nuke compiles up to 10% faster. Test coverage is at 93.35%.