Correndo serviços em segundo plano em um PocketPC

Question

Eu recentemente me comprou um novo celular, executando o Windows Mobile 6.1 Professional. E é claro que eu atualmente estou olhando para fazer alguma codificação para ele, em uma base hobby. Meu plano é ter um serviço executado como um DLL, carregado pelo Services.exe. Isso precisa coletar dados SOM, e fazer o processamento som em intervalos regulares (a cada 5-10 minutos).

Uma vez que eu preciso para executar isso em intervalos regulares, é um pouco de um problema para mim, que o sistema normalmente vai para sleep (suspensão) depois de um curto período de inatividade pelo usuário.

Eu tenho lido toda a documentação que eu poderia encontrar no MSDN e blogs MSDN sobre este assunto, e parece-me, que há três soluções possíveis para este problema:

1. Mantenha o sistema em um -state "Always On", chamando SystemIdleTimerReset periodicamente. Isto parece um pouco excessiva, e é, portanto, fora de questão.

2. Ter o sistema periodicamente despertar com CeRunAppAtTime , e entrar no estado autônoma, para fazer o meu processamento.

3. Use o estado autônoma em vez de ir para uma completa suspensão. Isto seria transparente para o usuário, mas o sistema nunca iria entrar em sono.

A segunda abordagem parece ser preferido, no entanto, isso exigiria um executável para ser chamado pelo sistema de acordar, com a única tarefa de notificar o meu serviço que deve começar o processamento. Isto parece um pouco desnecessário e eu gostaria de evitar este executável extra. Eu poderia, naturalmente, passar toda a minha transformação em este executável extra, mas eu gostaria de usar algumas das facilidades oferecidas durante a execução como um serviço, e também não tem um programa de pop-up (mesmo que o seu no fundo) sempre que o processamento é iniciado.

À primeira vista, a terceira abordagem parece ter o mesmo problema básico como o primeiro. No entanto, eu li em alguns dos blogs do MSDN, que poderia ser possível o consumo de bateria realmente conservar com esta abordagem, em vez de ir dentro e fora do modo de suspensão, muitas vezes (Os argumentos para isso foi que a natureza da plataforma WM é para ter uma muito pouco consumo de bateria, quando o sistema estiver ocioso. e que vai dentro e fora de suspender exigir um pouco de processamento).

Então eu acho que minhas perguntas são as seguintes:

• Que abordagem você recomendaria na minha situação? Com respeito a manter um consumo de bateria mínima e uma implementação limpa agradável.

• No caso da abordagem número dois, é possível eliminar a necessidade de um executável notificação? Seja através de funções da API alternativos ou aplicações genéricas existentes na plataforma?

• No caso da abordagem número três, você sabe de quaisquer informações / estatísticas relevantes para a alegação, de que é possível estender a vida útil da bateria ao usar o modo autônomo sobre entrar em suspensão. Por exemplo. quantas vezes você precisa puxar o sistema de suspensão, antes de modo autônomo deve ser preferida.

• A implementação específica (bônus) pergunta:? É necessário chamar regularmente SystemIdleTimerReset para ficar em modo automático

E finalmente, se você acha que eu ter eliminado prematuramente número abordagem um, por favor me diga o porquê.

---

Por favor, inclua na sua resposta se você basear sua resposta no conhecimento, ou são apenas adivinhando (este último também é muito bem-vindo!).

Por favor, deixe um comentário, se você acha que eu preciso para esclarecer quaisquer partes desta questão.

Answer 1

CERunAppAtTime é uma API muito incompreendido (em grande parte por causa do nome terrível). É não tem que executar um aplicativo. Ele pode simplesmente definir um evento do sistema nomeado (ver a descrição do pwszAppName parâmetro no MSDN docs ). Se o cuidado de saber quando foi acionado (para lat seu aplicativo colocar o aparelho para dormir novamente quando é o processamento feito) simplesmente tem um segmento de trabalho que está fazendo um WaitForSingleObject no mesmo evento chamado.

estado autônoma é muitas vezes usado para dispositivos que precisam manter um aplicativo funcionando continuamente (como um leitor de MP3), mas poder conservar por desligar a luz de fundo (provavelmente o subsistema mais poder de consumo individual).

Modo Obviamente autônoma usa significativamente mais powr de suspender, becasue em suspender o único consumo de energia é de RAM auto-refresh. Em modo automático o processador está stuill alimentado e funcionando (e vários periféricos pode ser muito - depende de como o OEM definido seu modo autônomo).

SystemIdleTimerReset simplesmente impede que o gerenciador de energia de colocar o dispositivo em modo de baixa energia devido à inatividade. Este modo, se suspenso, sem vigilância, fuga ou outra, é definida pelo fabricante. Use com moderação, porque quando o seu fazer isso impacta o consumo de energia do dispositivo. Fazê-lo em modo automático é especialmente problemático do ponto de vista do usuário, porque eles podem pensar que o dispositivo está desligado (assim parece), mas agora a sua vida útil da bateria possui sul ido.

Answer 2

Eu tive um post inteiro longo detalhando como você não deve esperar para ser capaz de obter a vida da bateria aceitável porque WM não é projetado para suportar o que você está tentando fazer, e - você poderia sinalizar seu serviço ao despertar, fazer o seu processamento, em seguida, usar os métodos em este post para colocar a parte de trás do dispositivo para dormir imediatamente. Você deve ser capaz de manter a relação entre on-time-to-sleep-time muito baixo desta maneira -., Mas como você diz, eu só estou supondo

Veja também:

Power-Efficient Apps (MSDN)

Power To The People ( Desenvolvedores 1 , Desenvolvedores 2 , Dispositivos )

Poder -Efficient WM Apps (blog post)