Обновления местоположения в фоновом режиме с использованием Google API — неточный поставщик плавного местоположения

Я работал и тестировал фоновые обновления местоположения, используя GoogleApiClient для обновлений на основе интервала и смещения. При тестировании и анализе в течение нескольких дней я обнаружил некоторые изменения в выводе, которых я не ожидал.

  1. При использовании setInterval и setFastestInterval для обновлений на основе интервала, скажем, я установил Интервал как 15 минут и Самый быстрый интервал как 10 минут< /em>, в 90% случаев я получаю обновления с ожидаемым интервалом (от 10 до 15 минут). Но иногда я замечал, что обновления занимают гораздо больше времени, чем указанный интервал, например, разница составляет около 30 минут и 60 минут. Любая идея о том, почему разница?

  2. При использовании setMinimumDisplacement для обновлений на основе расстояния, скажем, я установил Смещение как 200 метров, я получаю обновления только для стационарных точек (Во время путешествия он не дает обновлений, даже если он превышает 200 метров), которые составляют 200 метров и выше. Это так нормально работает?

Я использую запросы местоположения типа PendingIntent, чтобы получать обновления местоположения в BroadcastReceiver для обновлений местоположения в фоновом режиме.

fusedLocationProviderClient.requestLocationUpdates(locationRequest, pendingIntent);

Во время тестирования Службы определения местоположения были ВКЛЮЧЕНЫ, а Режим определения местоположения был HIGH_ACCURACY.


android google-api-client fusedlocationproviderclient
person Joshua    schedule 20.12.2017    source источник
comment
Я не могу сказать, что это нормальное поведение, но я видел проблемы, подобные вашей. По правде говоря, ответ таков, что @Mitesh Vanaliya процитировал из документации: Все запросы о местоположении считаются подсказками, и вы можете получать местоположения, которые являются более/менее точными и быстрее/медленнее, чем запрошено. Или, перефразируя, Вы можете сказать нам, что хотите, и мы будем делать это иногда, но в конце концов мы будем делать то, что и когда мы хотим.   -  person Gary99    schedule 18.01.2018
comment
Если вы не хотите использовать рекомендуемый Google FusedLocationApi, вы можете использовать старый LocationManager, чтобы получить больше контроля для себя. здесь есть информация о том, как это сделать.   -  person Gary99    schedule 18.01.2018
comment
Я не хотел использовать LocationListener, потому что он будет завершен, когда приложение будет закрыто. Я хочу получать обновления местоположения, даже если приложение закрыто, поэтому я выбрал PendingIntent версию requestLocationUpdates FusedLocationProviderClient. Обновления, которые я получаю от setInterval, намного лучше, чем setMinimumDisplacement, поскольку местоположения из setInterval более точны по сравнению с setMinimumDisplacement.   -  person Joshua    schedule 19.01.2018
comment
Поскольку у меня есть некоторые процессы, которые необходимо выполнить на основе расстояния, которое проходит пользователь, я ожидаю, что он будет давать обновления местоположения, по крайней мере, с точностью до 1 км. Но проблема с setMinimumDisplacement заключается в том, что он дает обновления только тогда, когда пользователь где-то останавливается. Когда пользователь постоянно путешествует, я не получаю ни одного обновления, даже если оно пересекает указанный диапазон MinimumDisplacement. Есть ли другой способ или реализация, чтобы убедиться, что я получаю обновления местоположения на основе указанного расстояния, по крайней мере, приблизительно?   -  person Joshua    schedule 19.01.2018
comment
У меня были похожие проблемы с моими испытаниями. Ознакомьтесь с моим вопросом и ответами от коллеги SO stackoverflow.com/questions/35745924/   -  person Sreehari    schedule 23.01.2018
comment
@Stallion Я думаю, что проблема, с которой вы столкнулись, нормальна для кода и API, которые вы использовали. Согласно ответу, который вы отметили как лучший, данные на основе акселерометра, гирометра и магнитометра - лучший способ получить более точные данные. Согласно этой документации, его точность составляет около 68 % Только. Но в моем случае setMinimumDisplacement даже близко не приблизителен. Я объяснил это во втором пункте вопроса.   -  person Joshua    schedule 23.01.2018

Ответы (2)


arrow_upward
4
arrow_downward

Пожалуйста, обратитесь к документации, чтобы получить правильное поведение API LocationRequest.

Документация по API LocationRequest

Из этой документации:

  • Приложения не могут указать точные источники местоположения, такие как GPS, которые используются LocationClient. Фактически, в системе может быть запущено несколько источников местоположения (поставщиков), и она может объединять результаты из нескольких источников в один объект Location.
  • Запросы местоположения от приложений с ACCESS_COARSE_LOCATION, а не ACCESS_FINE_LOCATION, будут автоматически регулироваться до более медленного интервала, а объект местоположения будет запутан, чтобы показывать только грубый уровень точности.
  • Все запросы о местоположении считаются подсказками, и вы можете получать более или менее точные местоположения, а также быстрее или медленнее, чем запрошено

Для более подробного описания прочитайте полную документацию по ссылке выше.

Надеюсь, это объяснение поможет вам.

person Mitesh Vanaliya    schedule 17.01.2018
comment
Спасибо за объяснение. Я уже знаю некоторую информацию об источниках местоположения и точности. Я ожидаю получить дополнительную информацию о втором пункте в вопросе, например, как это обычно работает? или мне нужно реализовать для него еще какой-то код. - person Joshua; 17.01.2018

arrow_upward
0
arrow_downward

Я нашел ответ на свой второй вопрос. В документации сказано, что не рекомендуется устанавливать setMinimumDisplacement в 0, но в этом и есть хитрость. Он работает так, как ожидалось, когда он установлен на 0.

Это работает правильно при наличии двух разных LocationRequest (на основе интервала и смещения), так что одна настройка не влияет на другую.

Для описанного выше сценария предпочтительнее использовать службу переднего плана, чтобы ОС не уничтожала обновления местоположения.

person Joshua    schedule 17.06.2019