У меня есть приложение, которое позволяет пользователю отправлять сообщения с изображениями. Пользователь может нажать «отправить», а затем немедленно закрыть свой телефон или переключиться на другое приложение.iOS Networking - HTTP-соединения и работающие в фоновом режиме
Мы столкнулись с проблемой, что, если есть временное плохое сетевое соединение, сообщение не сможет отправить. Мы переключились на использование NSURLSession backgroundConfigurationWithIdentifier, чтобы фоновая ссылка на приложение не сразу задерживала запрос на запуск. Мы перешли на использование этого для всех наших запросов api, считая, что для каждого запроса не помешает продолжить работу в фоновом режиме, если приложение будет закрыто в неподходящее время.
Ускоренная перемотка вперед через пару недель мы замечаем, что все запросы кажутся медленными. Используя wirehark, я только что обнаружил, что этот фоновый сеанс, по-видимому, использует новое HTTP-соединение для каждого запроса, то есть он требует настройки TCP-соединения и нового рукопожатия TLS для каждого запроса, который добавлял латентность ~ 500 мс при каждом запросе в нашем приложении. Это довольно серьезная сделка, но я не могу найти это поведение в любом месте, включая ссылку выше или Apple background transfer considerations.
Так что мой вопрос: это поведение ожидается, или я что-то делаю неправильно? Есть ли простой способ с NSURLSession сделать HTTP-запрос, который будет использовать существующее соединение keep-alive, если оно есть, но может вернуться к backgroundConfiguration, если приложение будет перенесено в фоновый режим?
Я пробовал 'discretionary = true', и он также не работает. Я не уверен, но я прочитал эту опцию, чтобы означать, что это может задержать выполнение запроса, если он находится в фоновом режиме, и iOS занят, я бы не ожидал, что это будет иметь эффект, если приложение находится на переднем плане. Я подал ошибку с Apple, мы посмотрим, что они скажут. – danny