Walkthrough

SDImageCache changed encoding and thumbnail-storage behavior, removed synchronous disk→memory sync, and added a cache-options helper. SDWebImageManager now synchronously writes disk cache hits back into the memory cache.

Changes

Sequence Diagram(s)

sequenceDiagram
    participant Client
    participant Manager as SDWebImageManager
    participant Cache as SDImageCache
    participant Disk
    participant Memory

    Client->>Manager: request image for key
    Manager->>Cache: query cache for key
    Cache->>Memory: check memory cache
    alt not in memory
        Cache->>Disk: read disk data
        Disk-->>Cache: disk image/data
        Cache-->>Manager: return cachedImage (cacheType: Disk)
    else in memory
        Cache-->>Manager: return cachedImage (cacheType: Memory)
    end
    alt returned from Disk
        Manager->>Memory: store cachedImage in memory cache (synchronous write-back)
    end
    Manager-->>Client: return cachedImage

Estimated code review effort

🎯 4 (Complex) | ⏱️ ~45 minutes

Poem

🐰 I nibbled through the cache and quay,
Kept tiny thumbs light on their way.
Disk handed back what memory missed,
I stitched it quick — a tiny twist.
Hooray for hops and faster display! 🥕

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

• 📝 Generate docstrings

• X
• Mastodon
• Reddit
• LinkedIn

SDWebImage/Core/SDImageCache.m (1)

22-27: Fragile string-based key detection acknowledged as temporary.

SDIsThumbnailKey relies on a hardcoded substring "-Thumbnail(" to identify thumbnail keys. If the key format generated by SDThumbnailedKeyForKey ever changes, this detection silently breaks. The // TODO, remove this markers indicate awareness — just flagging to ensure the follow-up refactor (likely centralizing the key-format check in one place) stays on the radar.

SDWebImage/Core/SDImageCache.h (1)

315-315: Vague version reference in @note comments.

The added notes say "From new version" without specifying which version. Consider using the actual version number (e.g., "From v5.x.y") so users of the public API can reason about behavioral differences across releases.

Also applies to: 328-328, 342-342, 357-357

SDWebImage/Core/SDImageCache.m (1)

22-27: Fragile thumbnail key detection via string matching.

SDIsThumbnailKey relies on finding the literal substring "-Thumbnail(" in the key. While the format is currently consistent (generated by SDThumbnailedKeyForKey via SDTransformedKeyForKey), this string-matching approach creates a maintenance risk—if the key format ever changes or evolves, the detection will silently break. Additionally, a URL could theoretically contain that substring and cause false positives, though the dual condition with image.sd_isThumbnail mitigates this in practice.

The TODO comment confirms this is a known concern. Consider extracting the thumbnail key format into a shared constant and deriving detection logic from the same place that constructs the keys, ensuring detection stays in sync with generation.