Основные данные: может ли большая фоновая выборка заблокировать запрос выборки в главном потоке?

Question

У меня есть приложение для iPad с большим количеством текстовых данных в Core Data (около 75 МБ). Новые данные импортируются еженедельно. Импорт происходит во вторичном потоке с собственным NSManagedObjectContext и даже с собственным NSPersistentStoreCoordinator.

Процесс импорта содержит несколько выборок, все из которых очень эффективны, кроме одной, поскольку он возвращает огромное количество записей (возможно, это можно оптимизировать немного больше, но не так существенно). К сожалению, во время большая выборка сделана, основной интерфейс пользователя заблокирован (так как он также должен извлечь из магазина, и выборка задерживается).

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

Возможно ли, что даже с отдельным NSPersistentStoreCoordinator большой запрос на выборку в фоновом режиме все еще может блокировать запросы на выборку в главном потоке, или я что-то не так делаю?

Answer 1

Операция в фоновом потоке не может блокировать основной поток, но может занимать столько памяти, что основной поток может дольше работать эффективно.

Похоже, что ваши многочисленные фоновые выборки, которые "возвращают огромное количество записей", создают большой объектный граф живых объектов в памяти, который пожирает вашу память. Недостаток памяти мешает основному потоку.

Используйте инструменты для профилирования вашей памяти для подтверждения.

Решение состоит в том, чтобы хранить в памяти только реальные, заполненные объекты, которые вам абсолютно необходимы. Вы можете использовать меньшие выборки, извлекать как ошибки, извлекать свойства или извлекать как managedObjectIDs и подобные методы, чтобы уменьшить объем памяти.

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

Answer 2

Звучит так, как будто вы уже имеете дело с многопоточностью (хотя технически вам не нужно нужен новый NSPersistentStoreCoordinator на поток, если у вас есть NSManagedObjectContext на поток).

Ваша большая выборка звучит как проблема; Вы смотрели на NSFetchedResultsController для пакетирования результатов?

Если у вас уже есть, вам нужно найти способ оптимизации запроса - какой NSP-предикат вы используете для большой выборки?

---

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

Вы можете просто добавить метод к вашему подклассу NSManagedObject, который получил текст по запросу из файла - ваш пользовательский интерфейс не должен знать, как вы храните свой текст!

Answer 3

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

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

В этом случае одной из тактик является предварительная выборка с returnsObjectsAsFaults = NO любых объектов, которые вы, вероятно, будете использовать во время массовой выборки.

Возможно ли, что даже с отдельным NSPersistentStoreCoordinator большой запрос на выборку в фоновом режиме все еще может блокировать запросы на выборку в главном потоке

В этом случае он не должен блокироваться, но, как вы заметили, в вашем вопросе есть другие факторы, которые могут вызвать блокировку. У этого решения есть свои проблемы: объединение изменений, но если вы можете объединить два координатора, то оно работает в принципе.