У меня есть приложение для iPad, которое запускает обычный процесс синхронизации с сервером - он запускается каждые 10 секунд или около того. Процесс синхронизации загружает записи, которые вставляются в хранилище на базе CoreData SQL. Иногда количество обрабатываемых записей может набирать сотни или тысячи.NSOperation против асинхронного NSURLConnection
Текущий процесс синхронизации основан на Asynchronous NSURLConnection
, инициированном основной нитью. Как только все NSData
было собрано на звонок async
, тогда основная нить запускает NSOperation
в фоновом режиме, чтобы разобрать NSData
и вставить его в дБ.
Итак, NSURLConnection
работает асинхронно, а вставка db работает в фоновом режиме NSOperation
. Тем не менее, оркестровка NSURLConnection
и NSOperation
выполняется в основном потоке. Учитывая, что загружается большое количество данных, я думаю, что даже это небольшое количество оркестровки в основном потоке может повлиять на мою отзывчивость интерфейса.
Итак, я собираюсь реорганизовать код в один фон NSOperation
и сделать NSURLConnection
синхронным вызовом. Один NSOperation
затем будет синхронно загружать NSData
и управлять вставками db.
Прежде чем я приступлю к крупному рефакторингу, меня будут интересовать взгляды людей относительно того, является ли это хорошим решением.
В текущем механизме я замечаю некоторые случайные колебания в пользовательском интерфейсе. Поместив весь механизм на задний план NSOperation
Я надеюсь, что пользовательский интерфейс останется отзывчивым.
Любые слова мудрости были бы очень оценены.
Спасибо.
Вы можете указать очередь, в которой обрабатываются методы делегата NSURLConnection, этот код не требуется. – jrturton