Add protect when custom animated image class image data is nil during progressive animation check
This commit is contained in:
parent
1ed0b8cfe8
commit
c76b9e3c2a
|
@ -626,6 +626,10 @@ static NSUInteger SDDeviceFreeMemory() {
|
||||||
NSData *previousData = [((UIImage<SDAnimatedImage> *)previousImage) animatedImageData];
|
NSData *previousData = [((UIImage<SDAnimatedImage> *)previousImage) animatedImageData];
|
||||||
NSData *currentData = [((UIImage<SDAnimatedImage> *)image) animatedImageData];
|
NSData *currentData = [((UIImage<SDAnimatedImage> *)image) animatedImageData];
|
||||||
// Check whether to use progressive rendering or not
|
// Check whether to use progressive rendering or not
|
||||||
|
if (!previousData || !currentData) {
|
||||||
|
// Early return
|
||||||
|
return;
|
||||||
|
}
|
||||||
|
|
||||||
// Warning: normally the `previousData` is same instance as `currentData` because our `SDAnimatedImage` class share the same `coder` instance internally. But there may be a race condition, that later retrived `currentData` is already been updated and it's not the same instance as `previousData`.
|
// Warning: normally the `previousData` is same instance as `currentData` because our `SDAnimatedImage` class share the same `coder` instance internally. But there may be a race condition, that later retrived `currentData` is already been updated and it's not the same instance as `previousData`.
|
||||||
// And for protocol extensible design, we should not assume `SDAnimatedImage` protocol implementations always share same instance. So both of two reasons, we need that `rangeOfData` check.
|
// And for protocol extensible design, we should not assume `SDAnimatedImage` protocol implementations always share same instance. So both of two reasons, we need that `rangeOfData` check.
|
||||||
|
|
Loading…
Reference in New Issue