Я пытаюсь узнать о создании модулей, поддерживающих реакцию, для iOS, и есть один аспект, который возник.
Официальная документация по многопоточности упоминает этот блок кода вместе с его вариациями.
- (dispatch_queue_t)methodQueue
{
return dispatch_get_main_queue();
}
Есть еще один недокументированный мир, который я много видел в сторонних библиотеках: это
+ (BOOL)requiresMainQueueSetup
{
return NO;
}
Мне они кажутся похожими, но разными, поэтому я хотел попросить объяснений по следующим вопросам.
Когда нужно добавлять dispatch_get_main_queue в модуль и что делать, если его не использовать?
Когда следует добавлять requiresMainQueueSetup в модуль и что делать, если его не использовать?
Можно ли использовать dispatch_get_main_queue и requiresMainQueueSetup вместе, если да, то почему и когда?
В чем разница между возвратом YES и NO из requiresMainQueueSetup?





dispatch_get_main_queue() понадобится вам всякий раз, когда вы обрабатываете события во вторичном потоке, которые будут влиять на основной поток. Обычно это связано с изменениями пользовательского интерфейса. Если вы создаете модуль, поддерживающий реакцию, который не включает собственный рендеринг, вам, вероятно, не понадобится основная очередь. Асинхронный материал должен вызываться во вторичном потоке, и именно здесь вы должны реализовать dispatch_get_main_queue(), чтобы убедиться, что ваш пользовательский интерфейс обновляется после завершения асинхронных действий.
Я задал этот же вопрос о SO несколько недель назад безуспешно, и после некоторых исследований я теперь знаю, что это связано с пунктом № 1. React-native ожидает, что вы реализуете этот метод (никоим образом не связан с iOS), и вам нужно будет вернуть YES, если вы хотите выполнить рендеринг в iOS. Это гарантирует, что ваш собственный модуль будет запущен в основном потоке, что актуально в случае взаимодействия с пользовательским интерфейсом. Вы же не хотите, чтобы приложение зависало в вашем пользовательском интерфейсе в случае интенсивной обработки.
Если вы не предоставите requiresMainQueueSetup(), response-native выдаст предупреждение вам в лицо, но на этом этапе установит для него значение YES. Это значение по умолчанию изменится в следующем выпуске на NO. Итак, чтобы ответить на ваш вопрос: их можно использовать вместе, но не каждая комбинация имеет смысл. Также в этом случае, если вы не создаете новый собственный компонент пользовательского интерфейса iOS, вам, вероятно, не потребуется доступ к основному потоку через dispatch_get_main_queue(). Мост, поддерживающий реакцию, гарантирует, что собственные события и методы всегда будут передаваться из iOS в JS и наоборот, независимо от того, в каком потоке они работают.
Это было рассмотрено в предыдущих пунктах.
Редактировать:
Дополнительная информация, чтобы убедиться, что все понятно. Подводя итог: requiresMainQueueSetup() не имеет ничего общего с iOS и создается только с помощью response-native, чтобы узнать, каковы намерения вашего собственного модуля (пользовательского интерфейса или другого). dispatch_get_main_queue() не имеет ничего общего с react-native и имеет отношение только к вашему собственному коду. По сути, это обратный вызов для вторичных потоков, чтобы информировать основной поток о завершении некоторых асинхронных действий.
Нет, в этом случае вам не понадобится dispatch_get_main_queue. Мост, поддерживающий реакцию, отправит новые значения в ваш JS-код, где поток JS, поддерживающий реакцию, возьмет на себя управление, и вам больше не придется беспокоиться о потоках
dispatch_get_main_queue следует добавлять, когда методы вашего собственного модуля нуждаются в доступе к пользовательскому интерфейсу (в первую очередь) во время выполнения. Его можно поместить в Instant methodQueue или другое решение - обернуть блок кода, например * dispatch_async (dispatch_get_main_queue (), ^ {
какой-то код здесь }) *
requiresMainQueueSetup - это метод класса (обозначенный знаком +), он работает только во время инициализации. Так что это необходимо, если ваш метод в этом вызывает UI или вы переопределяете метод constantToExport.
Об этом говорится выше.
Об этом говорится выше.
Это потрясающее объяснение! Чтобы установить это для меня в камне, я работаю над модулем для гироскопа, который возвращает мне значения x, y, z каждые 50 мс или около того, думая об этом, он не выполняет никакого собственного рендеринга пользовательского интерфейса, но в react-native (js ) когда я получаю новые значения, я изменяю пользовательский интерфейс. Я немного не уверен, нужен ли для этого
dispatch_get_main_queue?