50-секундная задержка при запуске задания немедленного сканирования предназначена для предотвращения состояния гонки, при котором одновременно запускаются два задания немедленного сканирования. Когда вы устанавливаете для фонового режима значение true, предполагается, что вы изменяете фоновый режим, поэтому он отменяет любое текущее задание сканирования (предназначенное только для использования на переднем плане), чтобы переключиться на фоновые операции, когда задание сканирования отсутствует. Планирование происходит дважды, потому что первый BeaconManager:startMonitoringBeaconsInRegion и BeaconManager:setBackgroundMode запускают процесс «перепланирования». Вы можете избежать всего этого оттока, сначала позвонив BeaconManager:setBackgroundMode:, ранее в процессе инициализации. Таким образом, библиотека уже находится в фоновом режиме, когда вы вызываете BeaconManager:startMonitoringBeaconsInRegion, и все будет работать более плавно.
Планировщик Android Job работает следующим образом: если вы установите период c задание с наиболее частым (~ 15 минут) интервалом, запускается не сразу. Поэтому, когда библиотека запускается в фоновом режиме, она ничего не делает, пока не начнется следующий интервал. Этот интервал может наступить совсем скоро или может достигать 25 минут. Можно было бы оптимизировать этот процесс, запланировав немедленное сканирование, если мы определим, что последнее из них не запускалось в течение длительного времени с помощью некоторой постоянной временной метки. Это разумная оптимизация, которую можно добавить в библиотеку, подготовив запрос на перенос, если вы хотите поработать над ним.
Библиотека устанавливает сканирование с намеренной доставкой с низким энергопотреблением только после завершения цикла сканирования, так как это нормальный ход операций. Я согласен с тем, что если приложение будет убито, оно не обязательно будет настроено как можно скорее после перезапуска приложения. Самый простой способ оптимизировать это - завершить оптимизацию, предложенную в (2) выше, которая решит эту проблему как побочный эффект.
Если вы не хотите навредить точности При оценке расстояния вы хотите, чтобы мощность передатчика ваших аппаратных маяков была как можно выше, и вы хотите, чтобы скорость рекламы была как можно выше. Меньшее количество пакетов в секунду дает меньше статистических выборок для работы и увеличивает шум при оценке расстояния. Более низкая выходная мощность увеличивает минимальный уровень шума относительно сигнала и дает очень небольшой запас в обнаруживаемой разнице между RSSI на расстоянии 1 метра и 10 метров. Я понимаю, что высокая мощность передатчика и высокие расценки на рекламу существенно влияют на срок службы маяков с батарейным питанием. Тем не менее, ИМО, если вы уменьшите мощность передатчика достаточно, чтобы сэкономить батарею или снизить частоту рекламы ниже, скажем, 5 Гц, вам, вероятно, следует отказаться от оценок расстояния.
Как лучше всего использование библиотеки действительно зависит от вашего варианта использования. Если сканирование каждые ~ 15 минут достаточно для вашего случая использования, вам, вероятно, следует придерживаться фонового режима. Я не уверен, сработает ли описанный вами взлом, чтобы библиотека работала так, как вы хотите, без изменений. Вы можете попробовать, но это может занять больше времени, чем просто внесение изменений, как описано в пункте (2) выше.
Теоретически Android имеет аппаратную поддержку API для быстрых обратных вызовов, связанных с исчезновением маяков. К сожалению, функция Doze Android делает это ненадежным и бесполезным для большинства случаев использования. Смотрите мое резюме работы над этим здесь