🆕 iOS 15 brings radical new cell prefetching behavior to UICollectionView and (for the first time ever!) UITableView — this is a quantum leap forward for smooth scrolling performance and power efficiency.
Here's a thread with some key takeaways ⬇️
Here's a thread with some key takeaways ⬇️
What's the big deal?
In iOS 15, the system intelligently identifies spare time between frames, and uses that to start work on the next cell, giving you up to 2x time to prepare each cell!
Best part: just build your app with the iOS 15 SDK, and you get it automatically for free!
In iOS 15, the system intelligently identifies spare time between frames, and uses that to start work on the next cell, giving you up to 2x time to prepare each cell!
Best part: just build your app with the iOS 15 SDK, and you get it automatically for free!
The new cell prefetching behavior "just works" because it doesn't change the threading model or API contract: cells are still requested the same way as before, just with slightly different timing; it's all about better scheduling and utilization of time on the main thread.
With more time to finish all the work that goes into preparing a cell — loading your model object, formatting, image decoding, text measurement, layout & drawing, etc — you're much more likely to avoid hitches (frame drops).
If this sounds too good to be true, I don't blame you!
If this sounds too good to be true, I don't blame you!
So what's the catch?
The main thing to keep in mind with cell prefetching is how it affects cell lifecycle. For example:
• Cells are requested earlier before displaying (and may never display)
• Cells are cached for awhile after displaying (to display again for the same item)
The main thing to keep in mind with cell prefetching is how it affects cell lifecycle. For example:
• Cells are requested earlier before displaying (and may never display)
• Cells are cached for awhile after displaying (to display again for the same item)
When using cell prefetching, watch out for cases where the data for a cell changes after the cell has been prefetched, but before it becomes visible (thus it won't be included in visibleCells).
The best way to handle this is using the new reconfigure API:
The best way to handle this is using the new reconfigure API:
https://twitter.com/smileyborg/status/1403908057185144832
Also look out for existing code which assumes your data source cellForItemAt/cellForRowAt method (or diffable cell provider) is always followed immediately by willDisplayCell.
Similarly, you can get more than one pair of willDisplay + didEndDisplaying for the same prepared cell.
Similarly, you can get more than one pair of willDisplay + didEndDisplaying for the same prepared cell.
Don't forget that cell prefetching (automatic, with new behavior in iOS 15) is separate from data source prefetching, which is opt-in (by setting a prefetchDataSource on the collection/table view since iOS 10) and gives you a "heads up" to start fetching data for upcoming items.
To learn more about how the new iOS 15 cell prefetching behavior works under the hood, see illustrations of the cell lifecycle before/after it, and hear tips & tricks for maximizing scrolling performance, check out this #WWDC21 video (and sample code):
developer.apple.com/videos/play/ww…
developer.apple.com/videos/play/ww…
• • •
Missing some Tweet in this thread? You can try to
force a refresh
