Альтернатива для QNetworkAccessManager
Я рисую карту в BB10. Карта разделена на тайлы. В начале пользователь задает долготу, широту и уровень масштабирования, и карта отображается в этой координате. Я получаю одну плитку, выполняя запрос http с помощью QNetworkAccessManager. Сначала загружаются плитки размером 7х5. Но проблема в том, что когда пользователь начинает очень быстро выполнять панорамирование на экране и продолжает это делать иногда, то после того, как пользователь прекратил панорамирование, плитки загружаются с большой задержкой. Каждый раз, когда пользователь выполняет панорамирование, некоторые новые плитки загружаются для отображения на экране. Теперь, поскольку пользователь некоторое время продолжает панорамирование, с QNetworkAccessManager возникает так много ненужных сетевых запросов. И я думаю, именно поэтому загрузка плитки происходит медленно. Я попытался прервать QNetoworkReply QNetworkAccessManager, используя метод abort () для ненужных запросов. Но все еще очень медленно. Есть ли альтернативный способ добиться того, что я пытаюсь? Благодарю.
Решение
Я лично считаю, что проблема в том, что вы делаете слишком много ненужных подключений.
Как правило, HTTP рассматривается как несколько тяжеловесный протокол. Он основан на TCP, поэтому для его установления требуется трехстороннее рукопожатие и четырехстороннее рукопожатие, не считая времени на генерацию и анализ этих заголовков HTTP.
Также учитывайте нагрузку на сервер. Небольшой обычный веб-сервер обрабатывает ~ 100 запросов в секунду. Если ваш клиент выполняет такой частый запрос, я боюсь, что сервер не будет рад приветствовать ваше приложение.
Поэтому попробуйте ограничить плотность запросов вручную, отправляя запросы только тогда, когда скорость панорамирования ниже порогового значения, или сохраняйте очередь ожидающих запросов фиксированного размера и создавайте новые запросы только тогда, когда очередь не заполнена. Просто избегайте наводнений с запросами. Это бесполезно ни для клиентов с низкой пропускной способностью, ни для каких-либо не так простаивающих серверов, какими бы оптимизациями вы ни занимались.
Другие решения
Других решений пока нет …