Ejecutar servicios en segundo plano en un PocketPC

Question

Recientemente me compré un nuevo teléfono celular con Windows Mobile 6.1 Professional. Y, por supuesto, actualmente estoy buscando codificarlo, por hobby. Mi plan es tener un servicio que se ejecute como una DLL, cargado por Services.exe. Esto necesita recopilar datos som y hacer el procesamiento som a intervalos regulares (cada 5-10 minutos).

Como necesito ejecutar esto a intervalos regulares, es un problema para mí, ya que el sistema normalmente se pone en suspensión (suspensión) después de un corto período de inactividad por parte del usuario.

He estado leyendo toda la documentación que pude encontrar en MSDN y blogs de MSDN sobre este tema, y ??me parece que hay tres posibles soluciones a este problema:

1. Mantenga el sistema en un estado "Siempre encendido", llamando a SystemIdleTimerReset periódicamente. Esto parece un poco excesivo y, por lo tanto, está fuera de discusión.

2. Haga que el sistema se active periódicamente con CeRunAppAtTime e ingrese el estado desatendido para realizar mi procesamiento.

3. Use el estado desatendido en lugar de suspenderlo por completo. Esto sería transparente para el usuario, pero el sistema nunca entraría en suspensión.

Parece preferible el segundo enfoque, sin embargo, esto requeriría que el sistema llamara a un ejecutable al despertar, con la única tarea de notificar a mi servicio que debería comenzar el procesamiento. Esto parece un poco innecesario y me gustaría evitar este ejecutable adicional. Por supuesto, podría mover todo mi procesamiento a este ejecutable adicional, pero me gustaría usar algunas de las facilidades proporcionadas cuando se ejecuta como un servicio, y tampoco tener un programa emergente (incluso si está en segundo plano) cada vez que comienza el procesamiento.

A primera vista, el tercer enfoque parece tener el mismo problema básico que el primero. Sin embargo, he leído en algunos de los blogs de MSDN que podría ser posible conservar el consumo de batería con este enfoque, en lugar de entrar y salir del modo de suspensión a menudo (los argumentos a favor eran que la naturaleza de la plataforma WM es tener un consumo de batería muy pequeño, cuando el sistema está inactivo. Y que entrar y salir de la suspensión requiere bastante procesamiento).

Entonces supongo que mis preguntas son las siguientes:

• ¿Qué enfoque recomendarías en mi situación? Con respecto a mantener un consumo mínimo de batería y una implementación agradable y limpia.

• En el caso del enfoque número dos, ¿es posible eliminar la necesidad de un ejecutable de notificación? ¿A través de funciones API alternativas o aplicaciones genéricas existentes en la plataforma?

• En el caso del enfoque número tres, ¿conoce alguna información / estadística relevante para el reclamo, de que es posible extender la vida útil de la batería cuando se utiliza el modo desatendido en caso de suspensión? P.ej. ¿con qué frecuencia necesita sacar el sistema de la suspensión, antes de que se prefiera el modo desatendido?

• Pregunta específica de implementación (bonificación): ¿es necesario llamar regularmente a SystemIdleTimerReset para permanecer en modo desatendido?

Y finalmente, si cree que eliminé prematuramente el enfoque número uno, dígame por qué.

---

Incluya en su respuesta si basa su respuesta en conocimiento o simplemente está adivinando (¡esto último también es muy bienvenido!).

Por favor, deje un comentario, si cree que necesito aclarar alguna parte de esta pregunta.

Answer 1

CERunAppAtTime es una API muy mal entendida (en gran parte debido al terrible nombre). no tiene que ejecutar una aplicación. Simplemente puede establecer un evento del sistema con nombre (consulte la descripción del parámetro pwszAppName en el MSDN docs ). Si le interesa saber cuándo se disparó (para que su aplicación vuelva a poner el dispositivo en suspensión cuando termine de procesar), simplemente tenga un hilo de trabajo que esté haciendo un WaitForSingleObject en ese mismo evento con nombre.

El estado desatendido a menudo se usa para dispositivos que necesitan mantener una aplicación funcionando continuamente (como un reproductor de MP3) pero conservan energía apagando la luz de fondo (probablemente el subsistema más consumidor de energía).

Obviamente, el modo desatendido usa significativamente más potencia que suspender, ya que en la suspensión el único consumo de energía es para la actualización automática de RAM. En modo desatendido, el procesador funciona de manera excelente y funciona (y varios periféricos también pueden estarlo, depende de cómo el OEM definió su modo desatendido).

SystemIdleTimerReset simplemente evita que el administrador de energía ponga el dispositivo en modo de bajo consumo debido a la inactividad. El OEM define este modo, ya sea suspendido, desatendido, de vuelo u otro. Úselo con moderación porque cuando lo hace afecta el consumo de energía del dispositivo. Hacerlo en modo desatendido es especialmente problemático desde la perspectiva del usuario porque podrían pensar que el dispositivo está apagado (se ve así) pero ahora la duración de la batería se ha agotado.

Answer 2

Tuve una publicación larga y detallada que detallaba cómo no esperarías poder tener una duración de batería aceptable porque WM no está diseñado para soportar lo que estás tratando de hacer, pero - tú podría indicar su servicio al despertar, hacer su procesamiento y luego usar los métodos en esta publicación para volver a poner el dispositivo en modo de suspensión inmediatamente. De esta manera, debería ser capaz de mantener la proporción de tiempo de sueño a tiempo muy bajo, pero, como usted dice, solo estoy adivinando.

Ver también:

Aplicaciones energéticamente eficientes (MSDN)

Poder para la gente ( Desarrolladores 1 , Desarrolladores 2 , Dispositivos )

Poder - Aplicaciones WM eficientes (publicación de blog)