#objective-c #uitableview #core-data #nsfetchedresultscontroller
#objective-c #uitableview #основные данные #контроллер nsfetchedresultscontroller #core-data #nsfetchedresultscontroller
Вопрос:
Всем привет, я был бы очень признателен за помощь в этом — я стремлюсь к высокой эффективности при извлечении данных w.r.t и использовании памяти.
У меня есть основное хранилище данных, в котором хранятся элементы таблицы содержимого (tocEntity): название статьи, номер страницы. На странице может быть несколько статей, а номера страниц могут существовать или нет, т.Е. Если у вас есть статья на 5 страницах, начинающаяся со страницы 3, у вас не будет никаких записей t.o.c. для страниц 4-7.
Когда я отображаю вышеуказанное в табличном виде, в каждой ячейке отображаются названия всех статей для страницы, поэтому в некоторых ячейках будет одно название статьи, в то время как в других может быть 10 (или более)
Нет проблем с правильным размещением ячеек, но я заинтересован в эффективной выборке данных только для того, что в данный момент необходимо для представления таблицы (способ, которым работает NSFetchedResultsController) — проблема в том, что на ячейку приходится не 1 ввод основных данных, а довольно разные количества. Итак, если NSFetvhedResultsController скажет (получите мне данные для ячеек 12-17) — это не приведет к извлечению данных из одного ядра.
Есть идеи, как это реализовать?
Ответ №1:
В viewDidLoad извлеките все данные в NSArray затем используйте этот массив в UITableView методах источника данных вместо оперативных вызовов. Если вы хотите обновить данные, повторно заполните массив из данных и вызовите reloadData tableview.
Комментарии:
1. Вот как я это делаю, но это решение совсем не экономит память и не масштабируется — возможно, что только 1% от общего объема данных может отображаться на экране за один раз…
2. К сожалению, способ работы Apple code (как вы обнаружили) заключается в том, что он вызывает одни и те же методы МНОГО раз при рендеринге. Единственное, что вы могли бы сделать, это ограничить количество строк, а затем обнаружить прокрутку и вставить строки в таблицу и т.д., Но я бы не рекомендовал этого.
3. Также стоит отметить, что ошибка в CoreData, что означает, что даже если у вас есть объекты core data в массиве, вы НЕ храните ВЕСЬ объектный граф в памяти, когда вы обращаетесь к свойству объекта, он выдает ошибку, что приводит к тому, что CoreData извлекает эти данные, это довольно эффективно.
Ответ №2:
Если возможно, я бы рекомендовал сгруппировать все эти ссылки в разделе табличного представления, а не группировать их в строке табличного представления. Это связано с тем, что ячейки переменной высоты могут снизить производительность прокрутки.
Комментарии:
1. Я рассматривал это — но это приведет к таблице со многими разделами из одной ячейки (более распространенными, чем многострочные), что будет выглядеть довольно неуклюже? Есть ли какой-либо способ объединить каждую секцию с предыдущей, т. Е. не иметь разрыва между секциями?
2. Я не совсем понимаю, о каком разрыве вы говорите. Если проблема с разделами, вы можете попробовать использовать строку без отступа для представления страницы, за которой следуют строки с отступом, представляющие ссылки на страницы.
3. Выполняете ли вы итерацию по всему массиву результатов, чтобы сгруппировать названия статей по страницам? Если это так, то каждый объект в массиве отключается при обращении к его свойству. Для повышения производительности вам нужно определить способ возврата объектов, уже отсортированных и сгруппированных для отображения. Что касается разделов, вы также можете вернуть пользовательский вид для разделов таблицы, который может включать треугольник раскрытия и т.д.