I thought I had read that for a UITableView
that heightForRowAtIndexPath
doesn't get called on all rows, but only on the ones that will be visible. This isn't what I'm seeing however. I'm seeing hundreds of calls to heightForRowAtIndexPath
for the simple situation of the orientation being changed of the iPhone for example.
So I'm assuming here therefore that for a UITableView
with heightForRowAtIndexPath
implemented, it does (i.e. heightForRowAtIndexPath
) get called for all rows (not just the visible ones)...let me know if this isn't quite correct.
QUESTION: Given the above, how many rows in a UITableView
(where heightForRowAtIndexPath
is implemented) can you have before performance issues occur typically?
Is there a way around the performance issues? i.e. set a nominal/standard height for each row and not implement heightForRowAtIndexPath
, but then correctly set each row height only when it is displayed and set it correctly here...but which method would one do this in?
See Question&Answers more detail:
os 与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…