Esecuzione di servizi in background su un PocketPC

Question

Di recente mi sono comprato un nuovo cellulare con Windows Mobile 6.1 Professional. E ovviamente sto attualmente cercando di scrivere un po 'di codice, su base hobby. Il mio piano è di avere un servizio in esecuzione come DLL, caricato da Services.exe. Questo ha bisogno di raccogliere dati e di elaborarli a intervalli regolari (ogni 5-10 minuti).

Dato che devo eseguirlo a intervalli regolari, è un po 'un problema per me che il sistema in genere vada in sospensione (sospensione) dopo un breve periodo di inattività da parte dell'utente.

Ho letto tutta la documentazione che ho trovato su MSDN e i blog MSDN su questo argomento, e mi sembra che ci siano tre possibili soluzioni a questo problema:

1. Mantieni il sistema in uno stato " Sempre attivo ", chiamando periodicamente SystemIdleTimerReset . Questo sembra un po 'eccessivo ed è quindi fuori discussione.

2. Il sistema si sveglia periodicamente con CeRunAppAtTime e accede allo stato non presidiato per eseguire la mia elaborazione.

3. Usa lo stato incustodito invece di andare in una sospensione completa. Ciò sarebbe trasparente per l'utente, ma il sistema non andrebbe mai in modalità di sospensione.

Il secondo approccio sembra essere preferito, tuttavia, ciò richiederebbe che un sistema eseguibile venga chiamato dal sistema al risveglio, con l'unico compito di notificare al mio servizio che dovrebbe iniziare l'elaborazione. Questo sembra un po 'inutile e vorrei evitare questo eseguibile aggiuntivo. Ovviamente potrei spostare tutta la mia elaborazione in questo eseguibile aggiuntivo, ma vorrei utilizzare alcune delle funzionalità fornite durante l'esecuzione come servizio e inoltre non avere un programma pop-up (anche se è in background) ogni volta che inizia l'elaborazione.

A prima vista, il terzo approccio sembra avere lo stesso problema di base del primo. Tuttavia, ho letto su alcuni dei blog di MSDN che potrebbe essere possibile effettivamente risparmiare il consumo della batteria con questo approccio, invece di entrare e uscire spesso dalla modalità di sospensione (l'argomento per questo era che la natura della piattaforma WM è avere un consumo di batteria molto ridotto, quando il sistema è inattivo. E che entrare e uscire dalla sospensione richiede un bel po 'di elaborazione).

Quindi immagino che le mie domande siano le seguenti:

• Quale approccio mi consiglieresti nella mia situazione? Per quanto riguarda il mantenimento di un consumo minimo della batteria e una buona implementazione pulita.

• Nel caso dell'approccio numero due, è possibile eliminare la necessità di un eseguibile di notifica? O tramite funzioni API alternative o applicazioni generiche esistenti sulla piattaforma?

• Nel caso dell'approccio numero tre, siete a conoscenza di informazioni / statistiche rilevanti per l'affermazione, che è possibile prolungare la durata della batteria quando si utilizza la modalità automatica per andare in sospensione. Per esempio. quanto spesso è necessario estrarre il sistema dalla sospensione, prima di preferire la modalità automatica.

• Domanda specifica (bonus) sull'implementazione: è necessario chiamare regolarmente SystemIdleTimerReset per rimanere in modalità automatica?

E infine, se pensi che abbia eliminato prematuramente l'approccio numero uno, per favore dimmi perché.

---

Includi nella tua risposta se basi la tua risposta sulla conoscenza o se stai semplicemente indovinando (anche quest'ultima è molto gradita!).

Per favore, lascia un commento, se pensi che debba chiarire alcune parti di questa domanda.

Answer 1

CERunAppAtTime è un'API molto fraintesa (in gran parte a causa del nome terribile). non deve eseguire un'app. Può semplicemente impostare un evento di sistema denominato (vedere la descrizione del parametro pwszAppName in MSDN docs ). Se ti interessa sapere quando è stato attivato (al momento la tua app reimposta il dispositivo al termine dell'elaborazione), devi semplicemente avere un thread di lavoro che sta eseguendo un WaitForSingleObject sullo stesso evento con nome.

Lo stato non presidiato viene spesso utilizzato per dispositivi che devono mantenere un'app in esecuzione ininterrottamente (come un lettore MP3) ma che risparmiano energia spegnendo la retroilluminazione (probabilmente il singolo sottosistema che consuma più energia).

Ovviamente la modalità automatica è molto più potente della sospensione, dato che in sospensione l'unica alimentazione è per l'auto-aggiornamento della RAM. In modalità automatica, il processore è alimentato e funzionante (e possono essere anche diverse periferiche - dipende da come l'OEM ha definito la modalità automatica).

SystemIdleTimerReset impedisce semplicemente al power manager di mettere il dispositivo in modalità a basso consumo a causa di inattività. Questa modalità, sospesa, incustodita, in volo o altro, è definita dall'OEM. Usalo con parsimonia perché quando lo fai influisce sul consumo di energia del dispositivo. Farlo in modalità automatica è particolarmente problematico dal punto di vista dell'utente perché potrebbero pensare che il dispositivo sia spento (sembra così) ma ora la durata della batteria è andata a sud.

Answer 2

Ho avuto un lungo post che descriveva in dettaglio come non dovresti aspettarti di ottenere una durata della batteria accettabile perché WM non è progettato per supportare ciò che stai cercando di fare, ma - tu potrebbe segnalare il tuo servizio al risveglio, eseguire l'elaborazione, quindi utilizzare i metodi in questo post per ripristinare immediatamente la sospensione del dispositivo. dovresti essere in grado di mantenere molto basso il rapporto tra tempo di sonno e tempo di sonno in questo modo - ma come dici tu, sto solo indovinando.

Vedi anche:

App di efficienza energetica (MSDN)

Power To The People ( Developers 1 , Developers 2 , Dispositivi )

Potenza -Efficienti app WM (post di blog)