У меня есть приложение, которое должно обновлять свой дисплей каждую минуту или около того. Чтобы достичь этого, я использовал executeSelector: withObject: afterDelay, вызывая селектор, который в большинстве случаев просто изменяет некоторый текст в метке на основе очень простого (и быстрого) вычисления.
[self performSelector:@selector(updateDisplay) withObject:nil
afterDelay:60];
Иногда во время обновления мне приходится уходить и получать некоторые данные из Интернета, и поэтому я делаю это в другом потоке, используя detachNewThreadSelector. Это все сработало, и вызов «executeSelector after Delay» завершается за доли секунды и выполняется только раз в минуту. Несмотря на это и несмотря на то, что на симуляторе все работает нормально, единственная кнопка в приложении практически не отвечает, не реагирует на несколько ударов.
Итак, я предположил, что peformSelector: afterDelay не будет блокировать, но теперь мне интересно, блокирует ли он каким-то образом? Я даже пытался НЕ делать поиск в Интернете, если это как-то все еще влияло на отзывчивость. Нет радости.
[NSThread detachNewThreadSelector:@selector(updateFromURL)
toTarget:self withObject:nil];
Затем я протолкнул его через акулу, чтобы увидеть, смогу ли я увидеть что-нибудь очевидное. Отсюда я вижу, что поиск в Интернете - это единственное, что занимает какое-то время, но это делается только каждые пару минут, а затем явно не работает в главном потоке. Само приложение потребляет крошечную долю 1% ЦП (0,0000034%) в течение 20 минут, так что это просто проблема блокировки.
Итак, я что-то упускаю из-за executeSelector: afterDelay? Какие другие распространенные ошибки новичка я могу сделать. Если это поможет, хотя я разрабатывал приложения более 20 лет, предыдущие 10 были в основном Java. Возможно, у меня загружено предположение о Java :-) По сути, я предположил, что основной поток похож на EDT (только выполняйте над ним интерфейс, но оставляйте все остальное вне него).