Когда обратный вызов Какао получает контроль?

Question

Я искал в Интернете ответ на этот вопрос, но не смог найти ответ, с другой стороны, я думаю, что это что-то довольно распространенное, поэтому есть вероятность, что я здесь пропускаю некоторые ключевые слова. Во всяком случае, проблема заключается в следующем:

Когда управление предоставляется функции обратного вызова в ObjC (iPhone)?

Это происходит после того, как управление передано высокому классу иерархии, ответственному за цикл выполнения? Может ли это произойти в середине выполнения другого вызова функции?

В качестве примера, давайте возьмем NSURLConnection , мы не знаем или не можем предсказать, когда он собирается вызвать didReceiveResponse или другие методы обратного вызова, может ли это быть в случае, если didReceiveResponse get вызывается, когда я нахожусь в середине другой функции? (крайне сомневаюсь, что, но не смог найти информацию о обратных вызовах, ожидающих окончания цикла выполнения)

Ура, Каспа

Answer 1

может ли быть так, что getReceiveResponse get вызывается, когда Я нахожусь в середине другой функции?

Нет, в пределах одного потока код не выполняется параллельно. Runloop планирует выполнение всех сообщений и распределяет их последовательно. Даже NSTimers не гарантируют стрельбу с точностью, на которую они теоретически способны, потому что они должны ждать runloop, как и все остальное.

Answer 2

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

Если вы хотите знать, кто именно вызывает ваш обратный вызов, поместите в него точку останова и проверьте трассировку стека.

Answer 3

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

ОС может сделать это, вставив свои обратные вызовы в расписание цикла выполнения. Также есть несколько случаев, когда один из ваших вызовов также приведет к обратному вызову в том же стеке - например, если вы вызываете resignFirstResponder для объекта, который уведомляет своего делегата, когда это происходит, например UITextField.

Пара соответствующих сообщений в блоге:

• краткое введение в NSRunLoop
• Дружественный обзор обратных вызовов Objective C

Answer 4

Единственный раз, когда didReceiveReponse будет вызываться во время выполнения чего-то другого, - это если вы запустили соединение в своем собственном потоке (обычно в NSOperation).

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