iOS. Полагаются ли NSURLConnection и setNeedsDisplay UIView на GCD для асинхронного поведения?

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

Я хочу сосредоточиться на setNeedsDisplay и наборе методов NSURLConnectionDelegate.

  1. Правильно ли называть setNeedsDisplay асинхронным? Я часто вызываю его через dispatch_async(dispatch_get_main_queue(), ^{}), что меня смущает.
  2. Обратные вызовы NSURLConnectionDelegate описываются как асинхронные, но на самом деле они не выполняются одновременно в основном потоке/цикле выполнения. Я не совсем понимаю различие здесь.

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

С уважением,
Дуг


ios grand-central-dispatch nsurlconnection setneedsdisplay nsurlconnectiondelegate
person dugla    schedule 10.01.2013    source источник
comment
Возможно, вы захотите рассмотреть перефразировку вопроса с конкретными примерами практических проблем, с которыми вы боретесь, если это возможно, а не с концептуальными вопросы. Я думаю, что если вы сделаете это немного более конкретным (например, вопрос о конкретном примере кода), это будет более продуктивно.   -  person Rob    schedule 10.01.2013
comment
Ну, проблема на самом деле концептуальна. Да, я знаю, что это кажется тревожным сигналом, но я решил попробовать. Концептуальный не должен быть ругательным словом, особенно для сложных концепций, таких как GCD, циклы выполнения и т. д.   -  person dugla    schedule 10.01.2013

Ответы (1)


arrow_upward
0
arrow_downward

  1. Нет, обычно вы не вызываете setNeedsDisplay асинхронно. Но если вы вызываете это из очереди, отличной от основной очереди (которой, как я полагаю, вы являетесь), то вы должны отметить, что вам никогда не следует выполнять обновления пользовательского интерфейса из фоновых очередей. Вы всегда запускаете их из основной очереди. Итак, это выглядит как очень типичный шаблон отправки обновления пользовательского интерфейса из фоновой очереди в основную очередь.

  2. NSURLConnection описывается как асинхронный, потому что когда вы вызываете его, если вы не использовали sendSynchronousRequest, ваше приложение немедленно возвращается во время соединения. Тот факт, что события делегата находятся в основной очереди, вполне совместим с представлением о том, что само соединение является асинхронным. Лично я бы счел дурным тоном, если бы я мог делегировать некоторые методы, которые не вызывались из той же очереди, из которой был инициирован процесс, если только это не было явно выражено через интерфейс.

  3. Что касается заголовка вашего вопроса, использует ли NSURLConnection GCD внутри, а не другую технологию параллелизма (NSOperationQueue, потоки и т. д.), это внутренняя проблема реализации, о которой мы, как разработчики приложений, обычно не беспокоимся.

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

person Rob    schedule 10.01.2013
comment
Роб - по поводу NSURLConnection. Обратные вызовы делегата выполняются в потоке/очереди, из которой они были запущены (обычно это основная очередь). В случае, когда возвращаемые данные требуют последующей длительной обработки, будет ли эта обработка зависать в пользовательском интерфейсе или фреймворк каким-то образом чередует обработку, чтобы пользовательский интерфейс оставался отзывчивым? - person dugla; 10.01.2013
comment
@dugla Если вы делаете что-то очень трудоемкое в своих методах делегата, то да, вы, вероятно, отправите их в свою собственную фоновую очередь, если хотите, чтобы пользовательский интерфейс оставался отзывчивым. Фреймворк не сделает этого за вас. Однако, как правило, обработка, которую мы выполняем в методах делегата, незначительна по сравнению со временем, затрачиваемым на взаимодействие с каким-либо удаленным сервером, тем более что мы обрабатываем данные, полученные didReceiveData небольшими пакетами, поэтому часто вам не о чем беспокоиться. об этом. Это зависит от того, что вы делаете, когда данные получены. - person Rob; 10.01.2013
comment
Прохладно. Спасибо за помощь, Роб. - person dugla; 10.01.2013