Тайм-аут iPhone, если выполнение функции занимает слишком много времени?

Question

У меня есть функция, в которой я получаю внешний ресурс из сети, используя объект Url Какао. И он прекрасно работает на симуляторе, но иногда не работает на самом устройстве (это запрос Google, поэтому ресурс, очевидно, существует). Это приводит меня к мысли, что на оборудовании существует некоторый внутренний барьер тайм-аута, но я не читал, существует ли такой барьер или нет.

Кто-нибудь еще сталкивался с подобными проблемами? Или знает, документирован ли тайм-аут или может быть изменен?

Answer 1

iPhone OS прекратит работу вашего приложения, если оно перестает отвечать на запросы - в основном, если ваш основной поток блокируется на несколько секунд. Это также важно при выходе - если вы сохраняете при выходе, у вас есть очень маленькое окно для завершения сохранения, которое усугубляется тем, что ОС может делать другие вещи. Если для выхода из ОС требуется слишком много времени, приложение убивает ваше приложение, которое для пользователя выглядит так, как будто ваше приложение не удается сохранить.

Я НАСТОЯТЕЛЬНО рекомендую вам протестировать все, что связано с оборудованием, а не с симулятором. Симулятор отлично подходит для быстрой отладки, но не отражает производительность на реальном оборудовании.

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

Answer 2

Я заметил этот тайм-аут при чтении большого файла в ApplicationDidFinishLaunching. Мое приложение будет остановлено во время запуска. В консоли я увидел сообщение журнала:

Sun Mar  1 10:41:03 unknown SpringBoard[22] <Warning>: <myappid>.* failed to launch in time

Мое решение было использовать performSelector: withObject: afterDelay: 0.0, чтобы быстро вернуться из appliationDidFinishLaunching и поставить в очередь загрузку файлов в цикле выполнения. Это позволяет избежать настройки нового потока и справиться со сложностью многопоточности.

Answer 3

iPhone налагает тайм-аут на запуск приложения. Поэтому, если вы выполняете обширную обработку в applicationDidFinishLaunching: например, приложение будет остановлено и будет создан журнал сбоев. К сожалению, я не нашел упоминания об этом в официальной документации.

После завершения процесса запуска я не знаю ни одного таймаута, ограничивающего время выполнения функции. Я попробовал это на устройстве с помещением сна на 30 секунд в основной поток, и он отлично работает.

Answer 4

Если вы используете NSUrlRequest, убедитесь, что интервал ожидания не достигнут. Ваш телефон может иметь более медленное интернет-соединение, чем ваш симулятор.

Из документа:

+ (id)requestWithURL:(NSURL *)theURL cachePolicy:(NSURLRequestCachePolicy)cachePolicy timeoutInterval:(NSTimeInterval)timeoutInterval

Parameters
theURL
The URL for the new request.

cachePolicy
The cache policy for the new request.

timeoutInterval
The timeout interval for the new request, in seconds.

Return Value
The newly created URL request.

Answer 5

Я знаю, что iPhone OS убьет приложение, если оно использует слишком много памяти, поэтому я не удивлюсь, если оно использует ту же политику, если приложение слишком долго не отвечает на события.

Если бы вы писали настольное приложение, проблема проявлялась бы в виде вращающегося курсора на радужном мяче, а ваше приложение не реагировало бы на щелчки мышью. Mac OS X не прекратит работу вашего приложения, но предложит принудительно завершить его, если вы щелкнете по его значку в Dock по Ctrl.

Основная проблема заключается в том, что вы связываете поток обработки событий. У вас есть два варианта:

1. Используйте неблокирующий ввод / вывод, поэтому вместо выполнения веб-запроса за один вызов вы используете API, который извлекает данные в фоновом режиме, а затем вызывает метод, который вы укажете, когда это будет сделано.
2. Использовать блокировку ввода / вывода в отдельном потоке. Сделайте веб-запрос так же, как вы делаете сейчас, но в отдельном потоке, а затем сообщите основному потоку, когда вы закончите.