vinnishtein Mar 25 2010 at 13:16

Ускорение UITableView в iPhone

3 min

4.3K

Development for iOS*

Comments 22

UFO landed and left these words here

vinnishtein Mar 25 2010 at 14:19

Извиняюсь, не смог найти подствеку кода для Objective-C

SilenceAndy Mar 25 2010 at 15:27

Оформите хотя бы в теги code

Dr_Zoidberg Mar 25 2010 at 14:59

ИМХО что-то явно не так в реализации UITableView в iPhone. Сильно тормознутый контрол.

hellraiser09 Mar 25 2010 at 15:21

да нормально там все, у меня тоже довольно сложные ячейки и особых тормозов не замечалось

farcaller Mar 25 2010 at 15:17

А еще есть drawRect: ;)

bealex Apr 18 2010 at 15:54

Подтверждаю.

Если много внутренних элементов — нужно просто рисовать все это руками в drawRect, это сделает тот самый «скриншот», но средствами ОС. Там есть несколько нюансов (например, нужно корректно обрабатывать выделение), но в целом — все отлично работает.

hellraiser09 Mar 25 2010 at 15:22

уважаемый, а можно посмотреть на реализацию вашей ячейки? просто при правильном написании тормозов не будет, т.к. она будет всего-лишь один раз, что эквивалентно вашему хаку отрисовываться

vinnishtein Mar 25 2010 at 16:05

Реализацию к сожалению предоставить не могу. Объясните если можно как сделать чтоб она отрисовывалась один раз без извращений моих

hellraiser09 Mar 25 2010 at 18:25

в том то и дело, то она должна один раз рисоваться, а дальше скролится уже отрендеренной до первого нажатия или принудительной перерисовки

SilenceAndy Mar 25 2010 at 15:32

Поддерживаю hellraiser09, тормозить не должно. В нашем приложении точно такие же элементы (по 8-12 элементов на ячейку) и использования идеи ReusableItem's быстро отрабатывает скролл. Вероятнее проблема в чем-то другом, проведите профайлинг аппликации и посмотрите, на что уходит время.

UFO landed and left these words here

SAKrisT Mar 25 2010 at 15:42

это сленг, ничего страшного в этом нету

UFO landed and left these words here

vinnishtein Mar 25 2010 at 15:58

В данном приложении не смог использовать уже созданые ячейки
1)3 типа разных ячеек
2)На каждой ячейке своя уникальная анимация иногда используется и в итоге глюки лезут

SAKrisT Mar 25 2010 at 15:43

Что-то вы намудрили, есть попроще решения…

vinnishtein Mar 25 2010 at 16:03

Предложите тогда. Сейчас посчитал, включая UIView насчитал 22 элемента.

XA0C Mar 25 2010 at 17:58

Реально намудрили, уж проще все в массиве держать и уже его оптимизировать.
Либо улучшаете свой UITableViewCell, чтобы был компактнее и быстрее, либо загружайте его после UIScrollViewDidEndDecellerating()
А то, что Вы тут написали, о, ужас.

vinnishtein Mar 25 2010 at 19:00

Я и так улучшил все что мог. Если заказчику нужен именно такой внешний вид я че ему скажу что надо выкинуть половину картинок или текста?

XA0C Mar 25 2010 at 17:59

еще можно использовать UIWebView

Medlay Mar 26 2010 at 14:21

Какой-то божественный хардкор и праздник непонимания документации.

1) — (UITableViewCell *)dequeueReusableCellWithIdentifier:(NSString *)identifier
Эта фукнция позволяет сэкономить время на создании ячейки из NIB файлов

А, собственно, в программной реализации ячеек оно разве не позволяет этого сделать? И какая это вообще «функция»? Для школьников что-ли пишете?

2) Предварительное создание всех ячеек и хранение их в NSArray или NSMutableArray.

Вообще что-то атомное. Тяжело комментировать.

MyCell это оригинальная, уже заполненая нужным контентом ячейка
UIGraphicsBeginImageContext(((UIView*)MyCell.frame.size);
[((UIView*)MyCell.layer renderInContext:UIGraphicsGetCurrentContext()];
UIImage* image = UIGraphicsGetImageFromCurrentImageContext();
UIGraphicsEndImageContext();

Прикольно будет падать аплекуха в процессе многопоточной генерации, например.

Вы бы для трех видов ячеек наследовали бы клас UITableViewCell, и при необходимости изменяли бы элементы в методе prepareForReuse. Тогда бы такое не писали.

biseptol Apr 16 2010 at 19:31

А можно посмотреть ячейку, в которой 22 элемента?