У меня есть UITableView, который считывает информацию из CoreData с помощью соответствующих механизмов (с помощью FetchedResultsController и т. Д.). Эта информация является текстовой или URL-адресом для локального изображения для загрузки в представление таблицы.Плохая начальная загрузка с высотойForRowAtIndexPath и UITableView scrollToBottom
Данные должны быть заполнены в таблице снизу вверх (аналогично приложению для обмена сообщениями). Я ориентируюсь на iOS 8+, но если я использую оценочную диаграммуHeightForRowAtIndexPath, я получаю ужасную подлость на 3 + многострочных меток и изображений. Оценка кажется слишком далекой, если только это не одна строка UILabel. Моя догадка заключается в том, что высота ячейки оценивается сверху вниз, так что высоты ячеек растут от верхней части ячейки до нижней части ячейки. Это означает, что прокрутка сверху вниз хорошо, но снизу вверх нет, так как ячейка динамически изменяется «вниз» динамически, когда я просматриваю вверх.
В настоящее время я использую heightForRowAtIndexPath для расчета высоты ячейки. Проблема заключается в том, что для первоначального загрузки представления требуется очень много времени, поскольку высоты ячеек вычисляются сразу. Я использую кеширование высоты ячейки, чтобы сохранить высоту ячейки, чтобы после загрузки представления прокрутка была гладкой.
Итак, мой вопрос:: как вы используете heightForRowAtIndexPath, не принимая 3-5-секундный удар начальной нагрузки?
И последующий вопрос о бонусе, есть ли способ надежно использовать оценочныйHeightForRowAtIndexPath, когда у вас есть ячейки, которые сильно отличаются по высоте? Мы говорим где угодно от 44 до 300 пикселей. Из того, что я читал, в этой ситуации я не могу использовать расчет расчетного значения.
Я исчерпал все сообщения stackoverflow, касающиеся validHeight/heightForRowAtIndexPath, и теперь я начинаю рассматривать одни и те же сообщения более одного раза. Поэтому я застрял.
Что говорят вам инструменты? Профайлер времени выполнения против приложения и вместо того, чтобы догадываться, вы будете знать для ** определенного **, где задержка. –
Догадка о том, как Apple динамически выделяет пространство на экране для ячеек. Я точно знаю, что heightForRowAtIndexPath является причиной начального удара в 3-5 секунд. Он потребляет 73% времени выполнения, когда сначала загружается представление. Ничто больше не превышает 1-2%. – FrostRocket
Приятно знать, что вы запустили его в Инструменты. Какая строка * внутри * heightForRowAtIndexPath стоит времени? Это выборка или это что-то еще? Проводка профиля «Инструменты» будет очень полезна. –