¿Puede el temporizador seguir funcionando después de que el teléfono se despierta del modo de suspensión?

Hace algún tiempo, encontré un problema en el trabajo, que era realizar operaciones dentro de un tiempo establecido durante el tiempo de espera. Al principio no me di cuenta de la gravedad del problema, luego probé muchos métodos sin éxito. En línea, aquí hay un breve resumen, espero que pueda ser útil para todos y espero que puedan corregirme si tengo alguna deficiencia.

1. Los procesadores, temporizadores y subprocesos de Android dejarán de funcionar durante el modo de espera y el tiempo establecido seguirá calculándose cuando finalice el modo de espera. Por lo tanto, si desea ejecutar algo mientras Android está en modo de espera, no es factible utilizar el método anterior.

2Android tiene un objeto Alarmmanager que se puede utilizar para realizar operaciones en espera. Las configuraciones específicas son las siguientes:

2.1 Establecer el tipo de reloj de alarma

AlarmManager.RTC, que es un reloj de alarma de hardware que no activará el teléfono (y posiblemente otros dispositivos) desde estado de suspensión; cuando el teléfono está dormido, no activará la alarma.

AlarmManager.RTC_WAKEUP, despertador de hardware, despierta el teléfono para que se duerma al enviar una alarma.

AlarmManager.ELAPSED_REALTIME, pasa la alarma en tiempo real, no despierta; el teléfono se pone en modo de suspensión; no se activa cuando el teléfono está en suspensión. Despertador.

AlarmManager.ELAPSED_REALTIME_WAKEUP: Despertar el sistema Es una alarma de apagado, lo que significa que el dispositivo puede despertar el sistema incluso cuando está apagado.

La mayor diferencia entre el despertador RTC y ELAPSED_REALTIME es que el primero puede activar el evento de alarma modificando la hora del teléfono móvil, mientras que el segundo debe pasar la hora en tiempo real y calcular la hora en tiempo real incluso en el estado de sueño.

2.2 Establecer la hora de inicio de la alarma

Si usa el tipo ELAPSED_REALTIME o ELAPSED_REALTIME_WAKEUP, debe llamar a SystemClock.elapsedRealtime() para obtener el tiempo relativo y el tiempo de retraso que configuró

Si usa el tipo RTC o RTC_WAKEUP, debe llamar a System.currentTimeMillis() para obtener el tiempo desde 1970.1.1 y el tiempo de retraso que configuró.

Si usa el tipo RTC o tipo RTC_WAKEUP, entonces se debe llamar a System.currentTimeMillis() para obtener la hora desde 1970.1.1. 1 más el tiempo de retraso que establezca

2.3pendingintent

Un objeto PendingIntent representa la operación que se realizará después del tiempo a ejecutar. PendingIntent es similar a Intent en que puede encapsular Activity, BroadcastReceiver y Service.

Llevo varios días en contacto con Android, por lo que no sé mucho al respecto.

Cuando escribí una aplicación por primera vez, descubrí accidentalmente que uno de los subprocesos de la aplicación dejó de ejecutarse mientras estaba en espera.

Este hilo carga datos al servidor cada minuto.

Durante las pruebas no tuve en cuenta lo que sucede en el modo de espera (el botón de encendido/apagado está conectado) y ahora me doy cuenta de que este hilo deja de funcionar cada vez que el teléfono entra en el modo de espera.

Pero hay un fenómeno extraño, porque se inician tres hilos al mismo tiempo en mi aplicación.

Uno de los subprocesos es responsable de cargar datos cada minuto. Cuando el teléfono está en estado de espera, el subproceso se pausará y, una vez que el teléfono no esté en estado de espera, el subproceso comenzará a funcionar nuevamente.

Un subproceso es responsable de recibir paquetes de datos UDP del servidor. Este subproceso no se ve afectado por el modo de espera y puede procesarse normalmente cuando llegan los datos.

¿Es porque datagramSocket.receive(datagramPacket); está bloqueado?

Al conectar el cable USB para depurar, encontrará que todo funciona bien, la interfaz se actualiza cada 5 segundos e incluso cuando se presiona el botón de encendido, se activa cada 5 segundos.

Cuando desconecté el cable de datos USB y presioné el botón de encendido para apagar la pantalla, y luego la volví a encender después de un rato, descubrí que el temporizador obviamente no seguía contando, sino que permanecía en el número cuando se apagó el botón de encendido.

Experimento 2: Uso de AlarmService:

2.1 Enviar una transmisión cada 5 segundos a través de AlarmService, de tipo AlarmManager.ELAPSED_REALTIME cuando esté configurado para repetirse.

Desconecta el cable USB, pulsa el botón de encendido y vuelve a encender la pantalla pasado un tiempo. Después de un rato, abrí la pantalla nuevamente y descubrí que el cronómetro no seguía contando.

El tipo de 2.2setRepeating es AlarmManager.ELAPSED_REALTIME_WAKEUP

Desconecta el cable USB, presiona el botón de encendido, enciende la pantalla nuevamente después de un tiempo y descubre que el temporizador aún está contando. .

Desde este punto de vista, usar WAKEUP es la única forma de garantizar que el temporizador deseado siempre esté funcionando, pero definitivamente resultará en un mayor consumo de energía.

Finalmente, escribí mi propia clase de servicio y usé AlarmService para ejecutarla cada minuto y funcionó bien en modo de espera.