UPGRADE YOUR SKILLS: Learn advanced Swift and SwiftUI on Hacking with Swift+! >>

How to optimise table views in UIKit

Recorded – watch the full episode on YouTube.

Do you have any tips for optimizing table views and collection views? When they're moving around quickly, what could people do to get really good performance there?

Janina Kutyn: Well, one of the things that people can do is use the shouldRasterize property of a layer. This property allows the contents of a layer to be pre-rendered and replaced into an off-screen buffer. So when user is scrolling, instead of redrawing every time the screen moves, the cached layer is used to display the contents of a cell instead.

The cost of this is that there's an off-screen buffer. It has an initial set-up cost. So the initial setup is a little bit slower because this needs to be rendered, but subsequently performance is faster.

“If you don't need to refresh your content once it's there, that's it, then you can just set shouldRasterize to true and that should be a bit of a performance boost.”

But you don't want to be doing this export if you have content within the cell that's changing when you scroll, like maybe you have a timer that's counting down or maybe there's something else in the cell that's making it change like you have a color, I don't know, effect. So you don't want to be doing it then, because then you've paid the price of setting up the buffer, and you're refreshing it every time.

But if you don't need to refresh your content once it's there, that's it, then you can just set shouldRasterize to true and that should be a bit of a performance boost.

Paul Hudson: So for folks who haven't tried it before, shouldRasterize, what it's effectively doing is to render the cell, the item, the view, once, and then store that rendered picture, literally the pixels for that picture, in RAM, stashed away.

So there's a cost to it. There's a CPU cost of doing that rendering and the stashing away. And there's a memory cost to it. You've now taken up more memory for that view being stored, that image being stored away in RAM. But later on, every other time that view is shown, it's not being re-rendered. It's being pulled from RAM directly and just put on the screen. And it looks the same. It interacts exactly the same way, but now it's significantly faster. So you've traded some CPU for some RAM, right?

“Does your app really need some of the dynamic content that you're displaying? Do you need a video to be playing when you're scrolling a cell, or could you pause it?”

Janina Kutyn: Exactly. But like I said, this only really works if you don't have things changing within the cells. But maybe you do want to have the dynamic content. But I think you also need to step back a little bit out of your developer shoes and put on your UX shoes, or I guess your UX hat, and think about what does your... Does your app really need some of the dynamic content that you're displaying? Do you need a video to be playing when you're scrolling a cell, or could you pause it? Do you need something to be moving and scrolling and animating, or are there ways you can simplify that will ultimately help you with performance? Are there things that may be more distracting or nice-to-haves that really don't add much value? There's some trade-offs you can make, therefore. The coolness of your effects versus performance a little bit.

“Building multi-step animations is really fun for developers, but... Is it that fun for users to watch an animation that takes multiple seconds and isn't really adding any value?”

Paul Hudson: One thing I want folks to think about when they're listening to this is that performance isn't just how fast your screen appears or how fast scrolling works. Your performance has an actual cost to users. You are draining their battery life faster by doing more work, by doing unnecessary work. And there's that thing in the settings. You can go to battery usage, and it'll tell you... The wall of shame, you want to avoid being in the top three or four of those apps. You want to be fairly light on battery. That involves things like getting your algorithms right, caching your views, not doing too much work where it isn't really required. So, performance, it is more than just about scrolling speed or rendering speed, also about battery and more.

Janina Kutyn: And not only that. I mean, now this is stepping even further away from performance, but building multi-step animations is really fun for developers, but is that fun for users to watch an animation that takes multiple seconds and isn't really adding any value? It was just fun to implement.

This transcript was recorded as part of Swiftly Speaking. You can watch the full original episode on YouTube, or subscribe to the audio version on Apple Podcasts.

Listen on Apple Podcasts

Hacking with Swift is sponsored by Essential Developer

SPONSORED Join a FREE crash course for mid/senior iOS devs who want to achieve an expert level of technical and practical skills – it’s the fast track to being a complete senior developer! Hurry up because it'll be available only until April 28th.

Click to save your free spot now

Sponsor Hacking with Swift and reach the world's largest Swift community!

BUY OUR BOOKS
Buy Pro Swift Buy Pro SwiftUI Buy Swift Design Patterns Buy Testing Swift Buy Hacking with iOS Buy Swift Coding Challenges Buy Swift on Sundays Volume One Buy Server-Side Swift Buy Advanced iOS Volume One Buy Advanced iOS Volume Two Buy Advanced iOS Volume Three Buy Hacking with watchOS Buy Hacking with tvOS Buy Hacking with macOS Buy Dive Into SpriteKit Buy Swift in Sixty Seconds Buy Objective-C for Swift Developers Buy Beyond Code

Was this page useful? Let us know!

 
Unknown user

You are not logged in

Log in or create account
 

Link copied to your pasteboard.