Что такое пакетная обработка?
Пакетная обработка – это буферизация событий датчиков в концентраторе датчиков и/или аппаратном FIFO перед отправкой отчетов о событиях через Sensors HAL. Места, где буферизуются события датчиков (центр датчиков и/или аппаратный FIFO), на этой странице называются FIFO. Если пакетная обработка событий датчиков неактивна, события датчиков немедленно передаются на уровень HAL датчиков, когда они доступны.
Пакетная обработка позволяет значительно экономить энергию, поскольку основной процессор приложений, на котором работает Android, активируется только тогда, когда готово много событий датчиков, а не для каждого отдельного события. Потенциальная экономия энергии напрямую связана с количеством событий, которые могут буферизовать концентратор датчиков и/или FIFO: чем больше событий можно объединить в пакет, тем выше потенциал экономии энергии. Пакетная обработка позволяет использовать память с низким энергопотреблением, чтобы сократить количество пробуждений процессора приложений с высоким энергопотреблением.
Пакетная обработка возможна только в том случае, если у датчика есть аппаратный FIFO и/или он может буферизовать события в сенсорном концентраторе. В любом случае датчик должен сообщать максимальное количество событий, которые могут быть объединены в пакет за один раз, через SensorInfo.fifoMaxEventCount.
Если для датчика зарезервировано место в FIFO, он должен сообщать количество зарезервированных событий через SensorInfo.fifoReservedEventCount. Если FIFO предназначен для датчика, то SensorInfo.fifoReservedEventCount – это размер FIFO. Если FIFO используется несколькими датчиками, значение может быть нулевым. Например, если активен только один датчик, он может использовать весь буфер FIFO. Если активны несколько датчиков, то каждому из них гарантируется место для хранения не менее SensorInfo.fifoReservedEventCount событий в очереди FIFO. Если используется концентратор датчиков, гарантия может обеспечиваться программным обеспечением.
События датчиков группируются в следующих случаях:
- Текущая максимальная задержка отчета датчика больше нуля, а это значит, что события датчика могут быть задержаны до максимальной задержки отчета, прежде чем будут переданы через HAL.
- Процессор приложений находится в режиме ожидания, а датчик не является датчиком пробуждения. В этом случае события не должны выводить процессор приложений из спящего режима и должны храниться до тех пор, пока он не выйдет из него.
Если датчик не поддерживает пакетную передачу, а процессор приложений находится в спящем режиме, то ему передаются только события от датчиков пробуждения. События от датчиков, не поддерживающих пробуждение, не передаются.
Параметры пакетной обработки
Поведение пакетирования определяется двумя параметрами: sampling_period_ns и max_report_latency_ns.
sampling_period_ns определяет, как часто генерируется новое событие датчика, а max_report_latency_ns – сколько времени должно пройти, прежде чем о событии будет сообщено HAL датчиков.
sampling_period_ns
Значение параметра sampling_period_ns зависит от режима передачи данных указанного датчика:
- Непрерывный:
sampling_period_ns– это частота дискретизации, то есть частота, с которой генерируются события. - "При изменении" (On-change):
sampling_period_nsограничивает частоту дискретизации событий, то есть события генерируются не чаще, чем каждыеsampling_period_nsнаносекунд. Периоды могут быть длиннееsampling_period_ns, если событие не генерируется и измеренные значения не меняются в течение длительного времени. Подробнее о режиме отправки данных при изменении… - Запрос с одним примером:
sampling_period_nsигнорируется. Она ни на что не влияет. - Специальные. Подробнее о том, как
sampling_period_nsиспользуется для специальных датчиков, рассказывается в разделе Типы датчиков.
Подробнее о том, как sampling_period_ns влияет на разные режимы, читайте в статье Режимы отчетов.
Для датчиков непрерывного действия и датчиков, реагирующих на изменения:
- Если значение
sampling_period_nsменьшеSensorInfo.minDelay, реализация HAL должна без уведомления изменить его наmax(SensorInfo.minDelay, 1ms). Android не поддерживает создание событий с частотой более 1000 Гц. - Если
sampling_period_nsбольшеSensorInfo.maxDelay, то реализация HAL должна автоматически усечь его доSensorInfo.maxDelay.
Физические датчики иногда имеют ограничения по частоте работы и точности часов. Чтобы учесть это, фактическая частота выборки может отличаться от запрошенной, если она соответствует требованиям в таблице ниже.
Если запрошенная частота |
Тогда фактическая частота должна быть |
|---|---|
ниже минимальной частоты (<1/maxDelay) |
от 90% до 110% минимальной частоты; |
между минимальной и максимальной частотой; |
от 90% до 220% от запрошенной частоты; |
выше максимальной частоты (>1/minDelay) |
от 90 до 110 % максимальной частоты и ниже 1100 Гц; |
max_report_latency_ns
max_report_latency_ns задает максимальное время в наносекундах, на которое могут быть отложены и сохранены в аппаратном FIFO события, прежде чем они будут переданы через HAL, пока процессор приложений активен.
Нулевое значение означает, что события должны регистрироваться сразу после измерения, либо полностью пропуская FIFO, либо очищая FIFO, как только появляется одно событие от датчика.
Например, если акселерометр активирован на частоте 50 Гц с параметром max_report_latency_ns=0, то при пробуждении процессора приложений будет 50 прерываний в секунду.
Если max_report_latency_ns>0, события датчика не нужно регистрировать сразу после обнаружения. Они могут временно храниться в очереди FIFO и передаваться пакетами, если ни одно событие не задерживается более чем на max_report_latency_ns наносекунд. Это означает, что все события, произошедшие с момента предыдущей пакетной передачи, записываются и возвращаются одновременно. Это уменьшает количество прерываний, отправляемых в процессор приложений, и позволяет процессору приложений перейти в режим пониженного энергопотребления (ожидания), пока датчик собирает и группирует данные.
Каждое событие имеет временную метку. Задержка отправки отчета о событии не влияет на временную метку события. Временная метка должна быть точной и соответствовать времени, когда событие произошло, а не когда о нем было сообщено.
Разрешение временного хранения событий датчиков в FIFO не изменяет поведение отправки событий в HAL; события от разных датчиков могут чередоваться, и все события от одного и того же датчика упорядочены по времени.
События пробуждения и другие события
События от датчиков пробуждения должны храниться в одном или нескольких FIFO пробуждения. Обычно используется один большой общий FIFO для пробуждения, в котором чередуются события от всех датчиков пробуждения. В качестве альтернативы вы можете использовать один FIFO пробуждения для каждого датчика или иметь выделенные FIFO для определенных датчиков пробуждения и общий FIFO для остальных датчиков пробуждения.
Аналогично, события датчиков без пробуждения должны храниться в одном или нескольких FIFO без пробуждения.
В любом случае события датчиков пробуждения и обычных датчиков не могут быть перемешаны в одном FIFO. События пробуждения должны храниться в очереди FIFO пробуждения, а остальные события – в очереди FIFO без пробуждения.
Для FIFO пробуждения наилучшие результаты с точки зрения энергопотребления дает единый большой общий FIFO. Для FIFO, не предназначенных для пробуждения, одинаковые характеристики энергопотребления имеют как один большой общий FIFO, так и несколько небольших зарезервированных FIFO. Дополнительные рекомендации по настройке каждого FIFO приведены в разделе Приоритет распределения FIFO.
Поведение вне режима приостановки
Когда процессор приложений активен (не находится в режиме ожидания), события временно хранятся в FIFO, если они не задерживаются более чем на max_report_latency.
Пока процессор приложений не перейдет в спящий режим, ни одно событие не должно быть пропущено или потеряно. Если внутренние очереди FIFO заполняются до истечения времени max_report_latency, события передаются в этот момент, чтобы не потерять их.
Если несколько датчиков используют один и тот же FIFO и истекает max_report_latency одного из них, сообщаются все события из FIFO, даже если max_report_latency других датчиков ещё не истекло. Это уменьшает количество случаев, когда передаются пакеты событий. Если нужно сообщить об одном событии, сообщается обо всех событиях со всех датчиков.
Например, если активированы следующие датчики:
- акселерометр, пакетная обработка с
max_report_latency= 20 с - гироскоп, пакетный режим с
max_report_latency= 5 с;
Пакеты данных акселерометра передаются одновременно с пакетами данных гироскопа (каждые пять секунд), даже если акселерометр и гироскоп не используют один и тот же FIFO.
Поведение в режиме ожидания
Пакетная обработка особенно полезна для сбора данных датчиков в фоновом режиме без поддержания активности процессора приложений. Поскольку драйверы датчиков и реализация HAL не могут удерживать блокировку пробуждения*, процессор приложений может перейти в режим ожидания, даже когда собираются данные датчиков.
Поведение датчиков во время приостановки работы процессора приложений зависит от того, является ли датчик датчиком пробуждения. Подробнее о датчиках пробуждения…
Когда буфер FIFO без пробуждения заполняется, он должен работать как кольцевой буфер, перезаписывая старые события новыми. max_report_latency не влияет на FIFO, не предназначенные для выхода из спящего режима.
Когда очередь FIFO для пробуждения заполняется или истекает время ожидания max_report_latency одного из датчиков пробуждения, аппаратное обеспечение должно разбудить процессор приложений и передать данные.
В обоих случаях (с пробуждением и без) сразу после выхода процессора приложений из спящего режима создается пакет с содержимым всех FIFO, даже если max_report_latency некоторых датчиков ещё не истекло. Это снижает риск того, что процессору приложений придется снова выйти из спящего режима вскоре после возвращения в него, и, следовательно, минимизирует энергопотребление.
*Исключение составляют драйверы, которым разрешено удерживать блокировку пробуждения, когда датчик пробуждения с режимом непрерывной передачи данных активирован с max_report_latency < 1 секунды. В этом случае драйвер может удерживать запрет блокировки, поскольку процессор приложений не успевает перейти в спящий режим, так как событие пробуждения происходит до этого.
Меры предосторожности при пакетной обработке датчиков пробуждения
В зависимости от устройства процессору приложений может потребоваться несколько миллисекунд, чтобы полностью выйти из режима ожидания и начать очистку FIFO. В FIFO должно быть достаточно места, чтобы устройство могло выйти из режима ожидания без переполнения FIFO для пробуждения. Ни одно событие не должно быть потеряно, а значение параметра max_report_latency должно соблюдаться.
Меры предосторожности при пакетной обработке датчиков, не пробуждающих устройство при изменении
Датчики, которые генерируют события только при изменении значения, которое они измеряют. Если измеренное значение меняется, пока процессор приложений находится в режиме ожидания, приложения должны получить событие сразу после того, как процессор приложений выйдет из этого режима. Поэтому пакетная обработка непробуждающих событий датчиков, которые срабатывают при изменении, должна выполняться с осторожностью, если датчик использует FIFO совместно с другими датчиками. Последнее событие, сгенерированное каждым датчиком изменений, всегда должно сохраняться вне общего буфера FIFO, чтобы его нельзя было перезаписать другими событиями. Когда точка доступа выходит из спящего режима, после того как будут зарегистрированы все события из очереди FIFO, необходимо зарегистрировать последнее событие датчика, связанное с изменением.
Вот пример ситуации, которой следует избегать:
- Приложение регистрируется для счетчика шагов без пробуждения (по изменению) и акселерометра без пробуждения (непрерывно), которые используют один и тот же FIFO.
- Приложение получает событие счетчика шагов
step_count=1000 stepscode>. - ТД переходит в режим ожидания.
- Пользователь проходит 20 шагов, в результате чего события шагомера и акселерометра чередуются. Последнее событие шагомера –
step_count = 1020 steps. - Пользователь долго не двигается, поэтому события акселерометра продолжают накапливаться в FIFO и в итоге перезаписывают все события
step_countв общем FIFO. - Процессор приложений пробуждается, и все события из очереди FIFO отправляются в приложение.
- Приложение получает только события акселерометра и считает, что пользователь не ходил.
Сохраняя последнее событие счетчика шагов за пределами FIFO, HAL может сообщать об этом событии, когда процессор приложений выходит из спящего режима, даже если все остальные события счетчика шагов были перезаписаны событиями акселерометра. Таким образом, приложение получает step_count = 1020 steps, когда процессор приложений выходит из спящего режима.
Как реализовать пакетную обработку
Чтобы экономить заряд батареи, пакетная обработка должна выполняться без помощи процессора приложений, а сам процессор должен иметь возможность приостанавливать работу во время пакетной обработки.
Если пакетная обработка выполняется в концентраторе датчиков, его энергопотребление должно быть минимальным.
Максимальную задержку отчета можно изменить в любое время, в том числе когда указанный датчик уже включен. Это не должно приводить к потере событий.
Приоритет распределения FIFO
На платформах, где размер буфера FIFO и/или концентратора датчиков ограничен, разработчикам системы может потребоваться выбрать, сколько FIFO зарезервировать для каждого датчика. Чтобы помочь вам с выбором, ниже приведен список возможных применений пакетной передачи данных для разных датчиков.
Высокая ценность: пешеходный алгоритм инерциальной навигации с низким энергопотреблением
Целевое время группировки: от 1 до 10 минут.
Датчики для группировки:
- Детектор шагов для пробуждения
- Вектор вращения для игр с частотой 5 Гц
- Барометр с частотой 5 Гц
- Некалиброванный магнитометр с частотой 5 Гц, выводящий устройство из спящего режима
Пакетная обработка этих данных позволяет выполнять пешеходный инерциальный расчет, пока точка доступа находится в режиме ожидания.
Высокое значение: распознавание жестов и периодических действий со средним энергопотреблением.
Целевое время пакетной обработки: 3 секунды.
Датчики для пакетной обработки: акселерометр без пробуждения, 50 Гц
Пакетная обработка данных позволяет периодически распознавать произвольные действия и жесты без необходимости поддерживать процессор приложений в активном состоянии во время сбора данных.
Среднее значение: непрерывное распознавание действий/жестов со средним энергопотреблением.
Целевое время пакетной обработки: 1–3 минуты.
Датчики для пакетной обработки: акселерометр пробуждения с частотой 50 Гц
Пакетная обработка этих данных позволяет непрерывно распознавать произвольные действия и жесты, не поддерживая активность процессора приложений во время сбора данных.
Средневысокая ценность: снижение нагрузки при загрузке
Целевое время группировки: менее 1 секунды.
Датчики для пакетной обработки: любые высокочастотные датчики, обычно не пробуждающие устройство.
Если гироскоп настроен на частоту 240 Гц, даже пакетная обработка всего 10 событий гироскопа может уменьшить количество прерываний с 240 в секунду до 24 в секунду.
Среднее значение: непрерывный сбор данных с низкой частотой
Целевое время группировки: от 1 до 10 минут.
Датчики для пакетной обработки:
- Барометр пробуждения с частотой 1 Гц
- Датчик влажности с пробуждением при частоте 1 Гц
- Другие низкочастотные датчики пробуждения с аналогичной частотой.
Позволяет создавать приложения для мониторинга с низким энергопотреблением.
Средне-низкая ценность: непрерывный сбор данных со всех датчиков
Целевое время группировки: от 1 до 10 минут.
Датчики для пакетной обработки: все датчики пробуждения, высокая частота
Позволяет собирать данные датчиков, когда точка доступа находится в режиме ожидания. Учитывайте только в том случае, если проблема с пространством FIFO не возникает.