4 ms·

Actually there is a difference. If you create a table with a considerable number of cells (say, over 20) that contain a couple of labels and maybe an image when

by clawoo 15y ago

Actually there is a difference. If you create a table with a considerable number of cells (say, over 20) that contain a couple of labels and maybe an image when you swipe really fast the scrolling will hang, even if you are using the dequeue mechanism. The alternative is to paint the contents of the cell manually (that is without using UILabels and the such) using CoreGraphics. Check out the drawContentView: method here: https://github.com/ferostar/fast-scrolling/blob/master/Classes/FirstLastExampleTableViewCell.m https://github.com/ferostar/fast-scrolling/blob/master/Class...

naz 15y ago
If you avoid transparent view backgrounds (just give labels a grey background if your cell has a grey background) and disk reads then you can make fast UITableViewCells without having to resort to drawRect. You should also avoid things like layer.cornerRadius and allocating lots of objects (such as NSNumberFormatters) in cellForRowAtIndexPath. That said, if you get frame skips after all that then overriding drawRect for the content view is a great way to speed it up. You have to be careful to keep your app accessible though, since the view has no labels for the screen reader to read. And orientation changes can look awkward.
chocopuff 15y ago
you don't have to do that. preload your uitableviewcell in ViewDidLoad, then in your cellForRowAtIndexPath, just return the array instead of the cell.
reidmain 15y ago
If you had twenty different UITableViewCells in a nib that had twenty different pictures then I admit the loading of these cells will cause the scrolling to stutter if you do it in cellForRowAtIndexPath:. However I just finished an application with a UITableViewCell, defined in a nib, that had 3 labels and a image. The labels depend on the data that the row was displaying and the image was the same in every row (it was a custom disclosure image). One of the table views that that used this cell had 100 rows and it loaded and scrolled without a hitch. Most of the slowdowns people experience with scrolling is if they have transparent cells and/or they don't load lazy load images on a background thread. I agree that if you've tried all sorts of optimizations and you are still experiencing slow scrolling then painting the contents manually will probably be faster but it is IMO more work then 99% of people need to do and, like naz said below, there can be accessibility issues. When Loren Brichter wrote that 3 years ago it was a much bigger deal. The iPhone 3G was extremely underpowered compared to most of the devices people run iOS on today.

by clawoo 15y ago

naz 15y ago

If you avoid transparent view backgrounds (just give labels a grey background if your cell has a grey background) and disk reads then you can make fast UITableViewCells without having to resort to drawRect. You should also avoid things like layer.cornerRadius and allocating lots of objects (such as NSNumberFormatters) in cellForRowAtIndexPath. That said, if you get frame skips after all that then overriding drawRect for the content view is a great way to speed it up. You have to be careful to keep your app accessible though, since the view has no labels for the screen reader to read. And orientation changes can look awkward.

chocopuff 15y ago

you don't have to do that. preload your uitableviewcell in ViewDidLoad, then in your cellForRowAtIndexPath, just return the array instead of the cell.

reidmain 15y ago

If you had twenty different UITableViewCells in a nib that had twenty different pictures then I admit the loading of these cells will cause the scrolling to stutter if you do it in cellForRowAtIndexPath:. However I just finished an application with a UITableViewCell, defined in a nib, that had 3 labels and a image. The labels depend on the data that the row was displaying and the image was the same in every row (it was a custom disclosure image). One of the table views that that used this cell had 100 rows and it loaded and scrolled without a hitch. Most of the slowdowns people experience with scrolling is if they have transparent cells and/or they don't load lazy load images on a background thread. I agree that if you've tried all sorts of optimizations and you are still experiencing slow scrolling then painting the contents manually will probably be faster but it is IMO more work then 99% of people need to do and, like naz said below, there can be accessibility issues. When Loren Brichter wrote that 3 years ago it was a much bigger deal. The iPhone 3G was extremely underpowered compared to most of the devices people run iOS on today.