¿Qué es el procesamiento por lotes?
El procesamiento por lotes hace referencia al almacenamiento en búfer de eventos de sensores en un concentrador de sensores o un FIFO de hardware antes de informar los eventos a través de la HAL de sensores. En esta página, se hace referencia a la ubicación en la que se almacenan en búfer los eventos del sensor (conmutador de sensores o FIFO de hardware) como "FIFO". Cuando el procesamiento por lotes de eventos del sensor no está activo, los eventos del sensor se informan inmediatamente al HAL de sensores cuando están disponibles.
El procesamiento por lotes puede permitir ahorros significativos de energía, ya que solo activa el procesador de aplicaciones (AP) principal, que ejecuta Android, cuando muchos eventos del sensor están listos para procesarse, en lugar de activarlo para cada evento individual. El posible ahorro de energía está directamente relacionado con la cantidad de eventos que el concentrador de sensores o el FIFO pueden almacenar en búfer: hay un mayor potencial de ahorro de energía si se pueden agrupar más eventos. El procesamiento por lotes aprovecha el uso de la memoria de bajo consumo para reducir la cantidad de activaciones de AP de alta potencia.
El procesamiento por lotes solo puede ocurrir cuando un sensor tiene un FIFO de hardware o puede almacenar en búfer eventos dentro de un concentrador de sensores. En cualquier caso, el sensor debe informar la cantidad máxima de eventos que se pueden agrupar a la vez a través de SensorInfo.fifoMaxEventCount.
Si un sensor tiene espacio reservado dentro de un FIFO, debe informar la cantidad de eventos reservados a través de SensorInfo.fifoReservedEventCount. Si el FIFO está dedicado al sensor, SensorInfo.fifoReservedEventCount es el tamaño del FIFO. Si el FIFO se comparte entre varios sensores, este valor puede ser cero. Un caso de uso común es permitir que un sensor use todo el FIFO si es el único sensor activo. Si hay varios sensores activos, a cada uno se le garantiza un espacio para al menos SensorInfo.fifoReservedEventCount eventos en la lista FIFO. Si se usa un concentrador de sensores, la garantía se puede aplicar a través del software.
Los eventos del sensor se agrupan en las siguientes situaciones:
- La latencia máxima de informe actual del sensor es mayor que cero, lo que significa que los eventos del sensor se pueden retrasar hasta la latencia máxima de informe antes de informarse a través del HAL.
- El AP está en modo de suspensión y el sensor no es de activación. En este caso, los eventos no deben activar el AP y deben almacenarse hasta que este se active.
Si un sensor no admite el procesamiento por lotes y el AP está inactivo, solo se informan al AP los eventos de activación del sensor y no se deben informar los eventos que no son de activación.
Parámetros de lotes
Los dos parámetros que rigen el comportamiento de los lotes son sampling_period_ns y max_report_latency_ns.
sampling_period_ns determina la frecuencia con la que se genera un nuevo evento de sensor, y max_report_latency_ns determina cuánto tiempo queda hasta que se debe informar el evento al HAL de sensores.
sampling_period_ns
El significado del parámetro sampling_period_ns depende del modo de informes del sensor especificado:
- Continuo:
sampling_period_nses la tasa de muestreo, es decir, la velocidad a la que se generan los eventos. - Al cambiar:
sampling_period_nslimita la tasa de muestreo de los eventos, lo que significa que los eventos no se generan más rápido que cadasampling_period_nsnanosegundos. Los períodos pueden ser más largos quesampling_period_nssi no se genera ningún evento y los valores medidos no cambian durante períodos prolongados. Para obtener más detalles, consulta el modo de informes on-change. - Único: Se ignora
sampling_period_ns. No tiene efecto. - Especial: Para obtener detalles sobre cómo se usa
sampling_period_nspara sensores especiales, consulta Tipos de sensores.
Para obtener más información sobre el impacto de sampling_period_ns en los diferentes modos, consulta Modos de informes.
Para sensores continuos y de cambio:
- Si
sampling_period_nses menor queSensorInfo.minDelay, la implementación de HAL debe restringirlo de forma silenciosa amax(SensorInfo.minDelay, 1ms). Android no admite la generación de eventos a más de 1,000 Hz. - Si
sampling_period_nses mayor queSensorInfo.maxDelay, la implementación de HAL debe truncarlo de forma silenciosa aSensorInfo.maxDelay.
A veces, los sensores físicos tienen limitaciones en las velocidades a las que pueden ejecutarse y en la precisión de sus relojes. Para tener en cuenta esto, la frecuencia de muestreo real puede diferir de la frecuencia solicitada, siempre y cuando cumpla con los requisitos que se indican en la siguiente tabla.
Si la frecuencia solicitada es |
Luego, la frecuencia real debe ser |
|---|---|
por debajo de la frecuencia mínima (<1/maxDelay) |
entre el 90% y el 110% de la frecuencia mínima |
entre la frecuencia mínima y máxima |
entre el 90% y el 220% de la frecuencia solicitada |
por encima de la frecuencia máxima (>1/minDelay) |
entre el 90% y el 110% de la frecuencia máxima, y por debajo de 1,100 Hz |
max_report_latency_ns
max_report_latency_ns establece el tiempo máximo en nanosegundos, por lo que los eventos se pueden retrasar y almacenar en el FIFO de hardware antes de informarse a través del HAL mientras el AP está activo.
Un valor de cero significa que los eventos deben informarse en cuanto se miden, ya sea omitiendo el FIFO por completo o vaciándolo en cuanto haya un evento del sensor.
Por ejemplo, un acelerómetro activado a 50 Hz con max_report_latency_ns=0 activará interrupciones 50 veces por segundo cuando el AP esté activo.
Cuando max_report_latency_ns>0, no es necesario informar los eventos del sensor en cuanto se detectan. Se pueden almacenar temporalmente en la fila FIFO y generar informes por lotes, siempre y cuando ningún evento se retrase más de max_report_latency_ns nanosegundos. Esto significa que todos los eventos desde el lote anterior se registran y se muestran a la vez. Esto reduce la cantidad de interrupciones que se envían al AP y le permite cambiar a un modo de menor consumo (inactivo) mientras el sensor captura y agrupa datos.
Cada evento tiene una marca de tiempo asociada. Retrasar la hora en la que se informa un evento no afecta la marca de tiempo del evento. La marca de tiempo debe ser precisa y corresponder a la hora en que ocurrió físicamente el evento, no a la hora en que se informó.
Permitir que los eventos del sensor se almacenen temporalmente en la lista FIFO no modifica el comportamiento de enviar eventos a la HAL. Los eventos de diferentes sensores se pueden intercalar, y todos los eventos del mismo sensor se ordenan en el tiempo.
Eventos de activación y no activación
Los eventos del sensor de los sensores de activación se deben almacenar en uno o más FIFO de activación. Un diseño común es tener un FIFO de activación único, grande y compartido en el que se intercalan los eventos de todos los sensores de activación. Como alternativa, puedes tener un FIFO de activación por sensor o tener FIFOs dedicados para sensores de activación específicos y un FIFO compartido para el resto de los sensores de activación.
Del mismo modo, los eventos de los sensores que no activan deben almacenarse en uno o más FIFOs que no activen.
En todos los casos, los eventos del sensor de activación y los eventos del sensor que no son de activación no se pueden intercalar en la misma lista FIFO. Los eventos de activación deben almacenarse en una lista FIFO de activación, y los eventos que no son de activación deben almacenarse en una lista FIFO que no sea de activación.
En el caso de la FIFO de activación, el diseño de FIFO único, grande y compartido proporciona los mejores beneficios de energía. En el caso del FIFO sin activación, el FIFO único y grande compartido y varios diseños de FIFO reservados pequeños tienen características de energía similares. Para obtener más sugerencias sobre cómo configurar cada FIFO, consulta Prioridad de asignación de FIFO.
Comportamiento fuera del modo de suspensión
Cuando el AP está activo (no en modo suspendido), los eventos se almacenan temporalmente en FIFO, siempre que no se retrasen más de max_report_latency.
Mientras el AP no entre en modo de suspensión, no se descartará ni se perderá ningún evento. Si los FIFO internos se llenan antes de que transcurra max_report_latency, los eventos se informan en ese momento para garantizar que no se pierda ninguno.
Si varios sensores comparten la misma lista FIFO y transcurre el max_report_latency de uno de ellos, se informan todos los eventos de la lista FIFO, incluso si aún no transcurrió el max_report_latency de los otros sensores. Esto reduce la cantidad de veces que se informan los lotes de eventos. Cuando se debe informar un evento, se informan todos los eventos de todos los sensores.
Por ejemplo, si se activan los siguientes sensores:
- Acelerómetro procesado por lotes con
max_report_latency= 20 s - giroscopio procesado por lotes con
max_report_latency= 5 s
Los lotes del acelerómetro se informan al mismo tiempo que los lotes del giroscopio (cada 5 segundos), incluso si el acelerómetro y el giroscopio no comparten la misma lista FIFO.
Comportamiento en el modo suspendido
El procesamiento por lotes es especialmente beneficioso para recopilar datos de sensores en segundo plano sin mantener el AP activo. Debido a que los controladores de sensores y la implementación de HAL no pueden mantener un bloqueo de activación*, el AP puede ingresar al modo de suspensión incluso mientras se recopilan los datos del sensor.
El comportamiento de los sensores mientras el AP está suspendido depende de si el sensor es un sensor de activación. Para obtener más detalles, consulta Sensores de activación.
Cuando se llena un FIFO que no activa, debe unirse y comportarse como un búfer circular, reemplazando los eventos más antiguos por los nuevos. max_report_latency no tiene ningún impacto en los FIFO que no se activan mientras están en modo suspendido.
Cuando se llena un FIFO de activación o cuando transcurre el max_report_latency de uno de los sensores de activación, el hardware debe activar el AP y notificar los datos.
En ambos casos (activación y no activación), en cuanto el AP sale del modo de suspensión, se produce un lote con el contenido de todos los FIFO, incluso si aún no transcurrió el max_report_latency de algunos sensores. Esto minimiza el riesgo de que el AP tenga que volver a activarse poco después de que vuelva al modo de suspensión y, por lo tanto, minimiza el consumo de energía.
*Una excepción notable de que los controladores no pueden mantener un bloqueo de activación es cuando se activa un sensor de activación con el modo de informes continuos con max_report_latency inferior a 1 segundo. En este caso, el controlador puede mantener un bloqueo de activación porque el AP no tiene tiempo para ingresar al modo de suspensión, ya que un evento de activación lo activaría antes de llegar al modo de suspensión.
Precauciones cuando se agrupan sensores de activación
Según el dispositivo, el AP puede tardar unos pocos milisegundos en salir del modo de suspensión por completo y comenzar a borrar el FIFO. Se debe asignar suficiente espacio en el FIFO para permitir que el dispositivo salga del modo de suspensión sin que se desborde el FIFO de activación. No se deben perder eventos, y se debe respetar max_report_latency.
Precauciones cuando se agrupan sensores que no activan el dispositivo al cambiar
Los sensores de cambio solo generan eventos cuando cambia el valor que miden. Si el valor medido cambia mientras el AP está en modo suspendido, las aplicaciones esperan recibir un evento en cuanto el AP se active. Debido a esto, el procesamiento por lotes de eventos de sensor de cambio sin activación debe realizarse con cuidado si el sensor comparte su FIFO con otros sensores. El último evento que genera cada sensor de cambio siempre se debe guardar fuera del FIFO compartido para que otros eventos nunca lo reemplacen. Cuando el AP se activa, después de que se hayan informado todos los eventos del FIFO, se debe informar el último evento del sensor de cambio.
Esta es una situación que debes evitar:
- Una aplicación se registra en el contador de pasos sin activación (al cambiar) y en el acelerómetro sin activación (continuo), que comparten el mismo FIFO.
- La aplicación recibe un evento del contador de pasos
step_count=1000 stepscode>. - El AP se suspende.
- El usuario camina 20 pasos, lo que hace que los eventos del contador de pasos y del acelerómetro se entrelacen, y el último evento del contador de pasos sea
step_count = 1020 steps. - El usuario no se mueve durante mucho tiempo, lo que hace que los eventos del acelerómetro sigan acumulándose en la FIFO y, en última instancia, reemplacen todos los eventos
step_counten la FIFO compartida. - El AP se activa y todos los eventos de la lista FIFO se envían a la aplicación.
- La aplicación solo recibe eventos del acelerómetro y cree que el usuario no caminó.
Cuando se guarda el último evento del contador de pasos fuera del FIFO, el HAL puede informar este evento cuando se activa el AP, incluso si los eventos del acelerómetro reemplazaron todos los demás eventos del contador de pasos. De esta manera, la aplicación recibe step_count = 1020 steps cuando se activa el AP.
Implementa el procesamiento por lotes
Para ahorrar energía, el procesamiento por lotes se debe implementar sin la ayuda del AP, y se debe permitir que el AP se suspenda durante el procesamiento por lotes.
Si se realiza el procesamiento por lotes en un concentrador de sensores, se debe minimizar el uso de energía del concentrador.
La latencia máxima de los informes se puede modificar en cualquier momento, en particular mientras el sensor especificado ya está habilitado, y esto no debería provocar la pérdida de eventos.
Prioridad de asignación de FIFO
En plataformas en las que el tamaño del búfer del FIFO de hardware o del concentrador de sensores es limitado, los diseñadores de sistemas pueden tener que elegir cuánto FIFO reservar para cada sensor. Para ayudarte con esta elección, aquí tienes una lista de las posibles aplicaciones cuando se implementa el procesamiento por lotes en los diferentes sensores.
Valor alto: Estimación de posición por cálculo de trayectoria de peatones de baja potencia
Tiempo de procesamiento por lotes objetivo: De 1 a 10 minutos
Sensores para lotes:
- Detector de pasos de activación
- Vector de rotación del juego de activación a 5 Hz
- Barómetro de activación a 5 Hz
- Magnetómetro no calibrado de activación a 5 Hz
El procesamiento por lotes de estos datos permite realizar el cálculo de posición por inferencia mientras se permite que el AP entre en suspensión.
Valor alto: Reconocimiento de gestos o actividades intermitentes de energía media
Tiempo de procesamiento por lotes objetivo: 3 segundos
Sensores por lotes: Acelerómetro que no activa el dispositivo a 50 Hz
El procesamiento por lotes de estos datos permite reconocer periódicamente actividades y gestos arbitrarios sin tener que mantener el AP activo mientras se recopilan los datos.
Valor medio: Reconocimiento de actividad o gesto continuo de alta potencia
Tiempo de procesamiento por lotes objetivo: De 1 a 3 minutos
Sensores por lotes: Acelerómetro de activación a 50 Hz
El procesamiento por lotes de estos datos permite reconocer actividades y gestos arbitrarios de forma continua sin tener que mantener el AP activo mientras se recopilan los datos.
Valor medio alto: Reducción de la carga de interrupción
Tiempo de procesamiento por lotes objetivo: Menos de 1 segundo
Sensores para lotes: cualquier sensor de alta frecuencia, por lo general, que no active el dispositivo.
Si el giroscopio está configurado a 240 Hz, incluso agrupar solo 10 eventos de giroscopio puede reducir la cantidad de interrupciones de 240 por segundo a 24 por segundo.
Valor medio: Recopilación continua de datos de baja frecuencia
Tiempo de procesamiento por lotes objetivo: De 1 a 10 minutos
Sensores para lotes:
- Barómetro de activación a 1 Hz
- Sensor de humedad de activación a 1 Hz
- Otros sensores de activación de baja frecuencia con tasas similares
Permite crear aplicaciones de supervisión con poca energía.
Valor medio-bajo: Recopilación continua de todos los sensores
Tiempo de procesamiento por lotes objetivo: De 1 a 10 minutos
Sensores para lotes: Todos los sensores de activación, a frecuencias altas
Permite la recopilación completa de datos del sensor mientras se deja el AP en modo suspendido. Solo considera esta opción si el espacio de FIFO no es un problema.