Есть несколько вариантов: прозрачно распечатать данные или внедрить что-то наподобие почты, где вы щелкнете, чтобы загрузить еще 25.
Если вы прозрачно перелистываете данные
UITableView имеет обратные вызовы, такие как итоговые и загрузочные данные для строки, так что это прекрасно, он виртуален, и ячейки используются повторно.
Но вы не можете сделать базовый выбор, вы должны выбрать x за раз - дляНапример, страница 50. Вы должны сначала выбрать count (*) для полного запроса, чтобы вы знали, а затем считать.Затем, когда обратный вызов запрашивает строку 353, вам необходимо рассчитать, что это страница 8 (чтение страниц 50), выбрать эти 50 и вернуть данные для строки 353. Когда запрашивается 354, у вас уже есть страница 8 в памяти, так что вывернуть.Вам придется повторно выбрать, когда вы пересекаете границу страницы.Память сокращается, потому что вы храните в памяти только страницу результатов за один раз.
Интересным вопросом является то, как вы стабильно запрашиваете 50 за раз.Простейшим шаблоном будет увеличение стабильных идентификаторов.Это зависит от ваших данных.Например, если это пользовательский предикатный запрос, как вы сохраняете 20K, чтобы перейти к странице 50 за раз?Без памяти вы были бы вынуждены записать результаты пользовательского предиката в другую таблицу в sqlite.
Если вы хотите оптимизировать, вы можете читать вперед до следующей страницы в направлении, которое пользователь прокручивает (этоСтрока запрашивается для увеличения или уменьшения?) Это может быть выше паузы на границах страницы.
Если вы загружаете еще 25 одновременно
Этот шаблон гораздо проще.В нижнем колонтитуле таблицы пользователь может щелкнуть, чтобы загрузить еще 25, а затем изменить общий номер обратного вызова и перезагрузить данные.
Компромиссы?
Что ж,Преимущество прозрачного пейджинга заключается в том, что он никогда не выбирает в память более одной (или n) страницы за раз, независимо от того, как далеко пользователь прокручивает.В еще 25 моделях, когда пользователь углубляется и углубляется в набор данных, он потребляет больше памяти.Прозрачная подкачка, очевидно, намного сложнее, поэтому вы должны подумать о том, какой пользовательский интерфейс вам нужен и как далеко зайдут люди в набор данных.
И последнее замечание: если у вас столько строк, вам понадобится алфавитный указатель (или похожая концепция), чтобы пользователь мог просматривать такие данные.Вы также можете вернуться к чертежной доске и подумать, есть ли другие данные или шаблоны доступа, чтобы избежать 20K строк в представлении:)