O que é o processamento em lote?
O agrupamento se refere ao armazenamento em buffer de eventos do sensor em um hub de sensores e/ou FIFO de hardware antes de informar os eventos pela Sensors HAL. O local em que os eventos do sensor são armazenados em buffer (hub do sensor e/ou FIFO de hardware) é chamado de "FIFO" nesta página. Quando o agrupamento de eventos do sensor não está ativo, os eventos do sensor são informados imediatamente ao HAL de sensores quando disponíveis.
O processamento em lote pode permitir uma economia de energia significativa, ativando apenas o processador principal de aplicativos (AP, na sigla em inglês), que executa o Android, quando muitos eventos do sensor estão prontos para serem processados, em vez de ativá-lo para cada evento individual. A economia de energia potencial está diretamente relacionada ao número de eventos que o hub do sensor e/ou FIFO podem armazenar em buffer: há um maior potencial de economia de energia se mais eventos puderem ser agrupados. O agrupamento aproveita o uso de memória de baixa potência para reduzir o número de ativações de AP de alta potência.
O agrupamento só pode ocorrer quando um sensor tem um FIFO de hardware e/ou pode
armazenar eventos em buffer em um hub de sensor. Em ambos os casos, o sensor precisa informar o
número máximo de eventos que podem ser agrupados de uma só vez usando
SensorInfo.fifoMaxEventCount.
Se um sensor tiver espaço reservado em uma FIFO, ele precisará informar o
número de eventos reservados por meio de
SensorInfo.fifoReservedEventCount. Se o FIFO for dedicado ao
sensor, SensorInfo.fifoReservedEventCount será o tamanho
do FIFO. Se o FIFO for compartilhado entre vários sensores, esse valor poderá ser
zero. Um caso de uso comum é permitir que um sensor use todo o FIFO se ele for
o único sensor ativo. Se vários sensores estiverem ativos, cada sensor terá
espaço garantido para pelo menos SensorInfo.fifoReservedEventCount
eventos na fila FIFO. Se um hub de sensores for usado, a garantia poderá ser aplicada
pelo software.
Os eventos de sensor são agrupados nas seguintes situações:
- A latência máxima atual do sensor é maior que zero, o que significa que os eventos do sensor podem ser atrasados até a latência máxima antes de serem informados pelo HAL.
- O AP está no modo de suspensão, e o sensor não é de ativação. Nesse caso, os eventos não podem ativar o AP e precisam ser armazenados até que ele seja ativado.
Se um sensor não oferecer suporte a lotes e o AP estiver em repouso, apenas os eventos de ativação do sensor serão informados ao AP, e os eventos que não são de ativação não serão informados ao AP.
Parâmetros de lote
Os dois parâmetros que governam o comportamento do agrupamento são sampling_period_ns e max_report_latency_ns.
sampling_period_ns determina com que frequência um novo evento de sensor é
gerado, e max_report_latency_ns determina por quanto tempo
o evento precisa ser informado ao HAL de sensores.
sampling_period_ns
O que o parâmetro sampling_period_ns significa depende do
modo de relatório do sensor especificado:
- Contínuo:
sampling_period_nsé a taxa de amostragem, ou seja, a taxa em que os eventos são gerados. - Na mudança:
sampling_period_nslimita a taxa de amostragem de eventos, o que significa que os eventos são gerados a cadasampling_period_nsnanossegundos. Os períodos podem ser mais longos quesampling_period_nsse nenhum evento for gerado e os valores medidos não mudarem por períodos longos. Para mais detalhes, consulte o modo de relatório na mudança. - One-shot:
sampling_period_nsé ignorado. Ela não tem efeito. - Especial: para saber como
sampling_period_nsé usado para sensores especiais, consulte Tipos de sensores.
Para mais informações sobre o impacto de sampling_period_ns nos
diferentes modos, consulte Modos de
geração de relatórios.
Para sensores contínuos e de mudança:
- Se
sampling_period_nsfor menor queSensorInfo.minDelay, a implementação do HAL precisa fixá-lo silenciosamente emmax(SensorInfo.minDelay, 1ms). O Android não oferece suporte à geração de eventos a mais de 1.000 Hz. - Se
sampling_period_nsfor maior queSensorInfo.maxDelay, a implementação do HAL precisa truncar silenciosamente paraSensorInfo.maxDelay.
Às vezes, os sensores físicos têm limitações nas taxas de execução e na precisão dos relógios. Para isso, a frequência de amostragem real pode ser diferente da frequência solicitada, desde que atenda aos requisitos da tabela abaixo.
Se a frequência solicitada for |
Então, a frequência real precisa ser |
|---|---|
abaixo da frequência mínima (<1/maxDelay) |
entre 90% e 110% da frequência mínima |
entre a frequência mínima e máxima |
entre 90% e 220% da frequência solicitada |
acima da frequência máxima (>1/minDelay) |
entre 90% e 110% da frequência máxima e abaixo de 1.100 Hz |
max_report_latency_ns
max_report_latency_ns define o tempo máximo em nanossegundos, em
que os eventos podem ser atrasados e armazenados no FIFO de hardware antes de serem
informados pelo HAL enquanto o AP está ativo.
Um valor de zero significa que os eventos precisam ser informados assim que são medidos, ignorando a FIFO ou esvaziando-a assim que um evento do sensor está presente.
Por exemplo, um acelerômetro ativado a 50 Hz com
max_report_latency_ns=0 vai acionar interrupções 50 vezes por
segundo quando o AP estiver ativo.
Quando max_report_latency_ns>0, os eventos do sensor não precisam ser
informados assim que são detectados. Eles podem ser armazenados temporariamente no
FIFO e informados em lotes, desde que nenhum evento seja atrasado por mais de
max_report_latency_ns nanossegundos. Isso significa que todos os eventos
desde o lote anterior são registrados e retornados de uma só vez. Isso reduz a
quantidade de interrupções enviadas ao AP e permite que ele mude para um modo de energia
menor (inativo) enquanto o sensor captura e agrupa dados.
Cada evento tem um carimbo de data/hora associado a ele. A demora no momento em que um evento é informado não afeta o carimbo de data/hora. O carimbo de data/hora precisa ser preciso e corresponder ao momento em que o evento ocorreu fisicamente, não ao momento em que foi informado.
Permitir que os eventos do sensor sejam armazenados temporariamente no FIFO não modifica o comportamento de envio de eventos para a HAL. Eventos de sensores diferentes podem ser intercalados, e todos os eventos do mesmo sensor são ordenados por tempo.
Eventos de ativação e não ativação
Os eventos de sensores de sensores de ativação precisam ser armazenados em um ou mais FIFOs de ativação. Um design comum é ter um FIFO de ativação único, grande e compartilhado em que os eventos de todos os sensores de ativação são intercalados. Como alternativa, você pode ter uma FIFO de ativação por sensor ou ter FIFOs dedicados para sensores de ativação específicos e uma FIFO compartilhada para o restante dos sensores de ativação.
Da mesma forma, os eventos de sensores de sensores que não despertam precisam ser armazenados em uma ou mais FIFOs que não despertam.
Em todos os casos, os eventos de sensor de ativação e os eventos de sensor sem ativação não podem ser intercalados no mesmo FIFO. Os eventos de ativação precisam ser armazenados em uma FIFO de ativação, e os eventos não de ativação precisam ser armazenados em uma FIFO não de ativação.
Para o FIFO de ativação, o design FIFO único, grande e compartilhado oferece os melhores benefícios de energia. Para a FIFO sem despertar, a FIFO compartilhada única e grande e vários designs de FIFOs reservados pequenos têm características de energia semelhantes. Para mais sugestões sobre como configurar cada FIFO, consulte Prioridade de alocação FIFO.
Comportamento fora do modo de suspensão
Quando o AP está ativo (não está no modo de suspensão), os eventos são armazenados
temporariamente em FIFOs, desde que não sejam atrasados por mais de
max_report_latency.
Enquanto o AP não entrar no modo de suspensão, nenhum evento será descartado ou
perdido. Se as FIFOs internas ficarem cheias antes do término do max_report_latency, os eventos serão informados nesse momento para garantir que nenhum evento seja perdido.
Se vários sensores compartilharem a mesma FIFO e o
max_report_latency de um deles expirar, todos os eventos da
FIFO serão informados, mesmo que o max_report_latency dos outros
sensores ainda não tenha expirado. Isso reduz o número de vezes que os lotes de
eventos são informados. Quando um evento precisa ser informado, todos os eventos de todos
os sensores são informados.
Por exemplo, se os seguintes sensores forem ativados:
- acelerômetro em lote com
max_report_latency= 20s - giroscópio em lote com
max_report_latency= 5s
Os lotes do acelerômetro são informados ao mesmo tempo que os lotes do giroscópio (a cada 5 segundos), mesmo que o acelerômetro e o giroscópio não compartilhem a mesma FIFO.
Comportamento no modo de suspensão
O agrupamento é especialmente benéfico para coletar dados do sensor em segundo plano sem manter o AP ativo. Como os drivers do sensor e a implementação do HAL não podem manter um bloqueio de ativação*, o AP pode entrar no modo de suspensão mesmo enquanto os dados do sensor estão sendo coletados.
O comportamento dos sensores enquanto o AP está suspenso depende se o sensor é um sensor de ativação. Para mais detalhes, consulte Sensores de ativação.
Quando um FIFO sem ativação é preenchido, ele precisa ser agrupado e se comportar como um
buffer circular, substituindo eventos mais antigos pelos novos, substituindo os
antigos. max_report_latency não tem impacto em FIFOs que não despertam
no modo de suspensão.
Quando um FIFO de ativação fica cheio ou quando o max_report_latency de
um dos sensores de ativação expira, o hardware precisa ativar o AP e
informar os dados.
Em ambos os casos (ativação e não ativação), assim que o AP sai do
modo de suspensão, um lote é produzido com o conteúdo de todos os FIFOs, mesmo que
max_report_latency de alguns sensores ainda não tenham decorrido. Isso
minimiza o risco de o AP precisar ser ativado novamente logo após retornar ao
modo de suspensão e, portanto, minimiza o consumo de energia.
*Uma exceção notável de drivers que não podem manter um bloqueio de ativação é
quando um sensor de ativação com o modo de relatório contínuo
é ativado com max_report_latency < 1 segundo. Nesse caso,
o driver pode manter um bloqueio de ativação porque o AP não tem tempo para entrar
no modo de suspensão, já que ele é ativado por um evento de ativação antes de chegar
ao modo de suspensão.
Precauções ao agrupar sensores de ativação
Dependendo do dispositivo, pode levar alguns milissegundos para que o AP saia
completamente do modo de suspensão e comece a limpar o FIFO. É necessário alocar espaço suficiente
no FIFO para que o dispositivo saia do modo de suspensão
sem que o FIFO de ativação transborde. Nenhum evento será perdido, e o
max_report_latency precisa ser respeitado.
Precauções ao agrupar sensores de mudança sem ativação
Os sensores de mudança geram eventos apenas quando o valor que eles estão medindo está mudando. Se o valor medido mudar enquanto o AP estiver no modo de suspensão, os aplicativos vão esperar receber um evento assim que o AP for ativado. Por isso, o agrupamento de eventos de sensor de não ativação na mudança precisa ser realizado com cuidado se o sensor compartilhar o FIFO com outros sensores. O último evento gerado por cada sensor de mudança precisa ser salvo fora do FIFO compartilhado para que nunca seja substituído por outros eventos. Quando o AP é ativado, depois que todos os eventos do FIFO são informados, o último evento do sensor de mudança precisa ser informado.
Esta é uma situação a evitar:
- Um aplicativo se registra no contador de etapas sem despertar (na mudança) e no acelerômetro sem despertar (contínuo), ambos compartilhando o mesmo FIFO.
- O aplicativo recebe um evento de contador de passos
step_count=1000 stepscode>. - O AP vai ser suspenso.
- O usuário dá 20 passos, fazendo com que os eventos do pedômetro e do acelerômetro
sejam intercalados, sendo o último evento do pedômetro
step_count = 1020 steps. - O usuário não se move por um longo período, fazendo com que os eventos do acelerômetro
continuem se acumulando na FIFO, eventualmente substituindo todos
os eventos
step_countna FIFO compartilhada. - O AP é ativado, e todos os eventos do FIFO são enviados para o aplicativo.
- O aplicativo recebe apenas eventos do acelerômetro e pensa que o usuário não caminhou.
Ao salvar o último evento do contador de passos fora do FIFO, o HAL poderá informar
esse evento quando o AP for ativado, mesmo que todos os outros eventos do contador de passos tenham sido
substituídos por eventos do acelerômetro. Dessa forma, o aplicativo recebe
step_count = 1020 steps quando o AP é ativado.
Implementar o envio em lote
Para economizar energia, a execução em lote precisa ser implementada sem a ajuda do AP, e o AP precisa ser suspenso durante a execução em lote.
Se a execução em lote for realizada em um hub de sensores, o consumo de energia do hub precisa ser minimizado.
A latência máxima do relatório pode ser modificada a qualquer momento, principalmente enquanto o sensor especificado já está ativado. Isso não deve resultar na perda de eventos.
Prioridade de alocação FIFO
Em plataformas em que o tamanho do buffer do FIFO de hardware e/ou do hub do sensor é limitado, os designers do sistema podem ter que escolher a quantidade de FIFO a ser reservada para cada sensor. Para ajudar nessa escolha, confira uma lista de possíveis aplicações quando o lote for implementado nos diferentes sensores.
Valor alto: estimativa de posição por dead reckoning para pedestres de baixa potência
Tempo de lote desejado: 1 a 10 minutos
Sensores para lote:
- Detector de passos de ativação
- Vetor de rotação de ativação do jogo a 5 Hz
- Barômetro de ativação a 5 Hz
- Despertador do magnetômetro não calibrado a 5 Hz
Agrupar esses dados permite realizar a navegação estimada para pedestres enquanto o AP é suspenso.
Valor alto: atividade intermitente de média potência/reconhecimento de gestos
Tempo de lote desejado: 3 segundos
Sensores para lote: acelerômetro sem ativação a 50 Hz
O agrupamento desses dados permite reconhecer atividades e gestos arbitrários periodicamente sem precisar manter o AP ativo enquanto os dados são coletados.
Valor médio: reconhecimento de atividade/gesto contínuo de potência média
Tempo de lote desejado: de 1 a 3 minutos
Sensores em lote: acelerômetro de ativação a 50 Hz
O agrupamento desses dados permite reconhecer continuamente atividades e gestos arbitrários sem precisar manter o AP ativo enquanto os dados são coletados.
Valor médio-alto: redução da carga de interrupção
Tempo de lote desejado: < 1 segundo
Sensores em lote: qualquer sensor de alta frequência, geralmente sem ativação.
Se o giroscópio estiver definido em 240 Hz, mesmo agrupar apenas 10 eventos de giroscópio pode reduzir o número de interrupções de 240/segundo para 24/segundo.
Valor médio: coleta contínua de dados de baixa frequência
Tempo de lote desejado: 1 a 10 minutos
Sensores para lote:
- Barômetro de ativação a 1 Hz
- Ativar o sensor de umidade a 1 Hz
- Outros sensores de ativação de baixa frequência com taxas semelhantes
Permite criar aplicativos de monitoramento com pouca energia.
Valor médio-baixo: coleta contínua de sensores completos
Tempo de lote desejado: 1 a 10 minutos
Sensores para lote: todos os sensores de ativação, em altas frequências
Permite a coleta completa de dados do sensor, deixando o AP no modo de suspensão. Considere isso apenas se o espaço FIFO não for um problema.