Poor UITableView Scrolling Performance issue iOS 7 - ios

Question

I have a UITableView that contains more than 20 rows, each UITableViewCell contains a UITextView which I can set different UIFont, alignment and colour. When I scroll down or up there is a choppy or lagging during the scrolling, when I remove the font and text colours and alignment everything become perfect. Did Apple changes the way of redrawing text in iOS 7? This did not happen with the previous iOS versions.
instruments shows that the time consumed at dequeueReusableCellWithIdentifier:forIndexPath:
-- UPDATE Add Code
if (unit.fontName != nil ) {
textView.font = [UIFont fontWithName:unit.fontName size:unit.fontSize.floatValue];
}
if (unit.fontColor) {
textView.textColor=[self convertString:unit.fontColor];
}
else {
textView.textColor=[UIColor colorWithRed:0 green:0 blue:0 alpha:1];
}
if ([unit.fontSize floatValue] !=0) {
textView.font = [UIFont fontWithName:textView.font.fontName size:[unit.fontSize floatValue]];
}
if (unit.textAlignment) {
switch ([summaryUnit.textAlignment intValue]) {
case 0:
textView.textAlignment = NSTextAlignmentLeft;
break;
case 1:
textView.textAlignment = NSTextAlignmentCenter;
break;
case 2:
textView.textAlignment = NSTextAlignmentRight;
break;
default:
break;
}
}

Answer 1

There are a lot of things going on behind the scenes in an UITableView, that might not make it obvious why it appears unresponsive.
As an example, you should not do tons of work in the tableView:heightForRowAtIndexPath: as the UITableView needs to ask for the height of every single row in your dataset, regardless of whether they are apparent on the screen or not. It does this in order to determine the content size.
It might not at all be your data or your cells that causes the problem. Complex cells with lots of subviews might render slow in the compositor. Especially if you have things like transparency.
Therefore I always put four basic rules down for myself whenever I am implementing a UITableView.
1) Always know what you need to tell the table view when you reload the data. Don't do lot's of stuff in the data source or delegate methods. Have things ready for when UITableView needs it.
2) Don't destroy and create views in the scroll cycle. By that, you should not create new UIView (or whatever) - as an example in your prepareForReuse methods. Just reset content of existing views and controls, and then reconfigure them whenever UITableView asks you to.
3) Don't have complex view hierarchies in your cells. Especially transparency and out-of-bounds content that needs to be rendered, can be cumbersome for the compositor to render at fast enough speeds.
4) Don't configure your cells in tableView:cellForRowAtIndexPath:. Just dequeue and return the cell needed. Always configure and setup your cells in the tableView:willDisplayCell:forRowAtIndexPath: delegate method.
That being said, there are some tricks that can help you. As I mentioned above, don't create and destroy views or controls in the cell's prepareForReuse method. Don't do heavyweight work at all. Just reset your views and go on. Which it might sound like you're doing, since it is the dequeueReusableCellWithIdentifier:forIndexPath: that causes your troubles.
Lastly if it is because of compositing (Instruments would show work in some Quartz-related methods) you could succeed by using the shouldRasterize and rasterizationScale of your cell's CALayer. This can sometimes speed up rendering of cells considerable.
Let me know if any of this stuff makes sense, and if it might have solved your problem.
EDIT:
PS. Yes. Apple did change the text-rendering in iOS 7. But why are you using UITextView?!? I don't know it that well, but I know it is much more heavyweight than UITextField or UILabel. Maybe you could consider using those instead. UITextView is usually for editing something that resembles documents (like the Notes app). I really think this might be what is causing your troubles.