Запуск фоновых сервисов на PocketPC - PullRequest
5 голосов
/ 11 января 2009

Я недавно купил себе новый мобильный телефон под управлением Windows Mobile 6.1 Professional. И, конечно же, я сейчас занимаюсь разработкой кода для хобби. Мой план состоит в том, чтобы служба работала как DLL, загружаемая Services.exe. Для этого необходимо собирать данные сома и выполнять обработку сома через регулярные промежутки времени (каждые 5-10 минут).

Так как мне нужно запускать это через регулярные промежутки времени, для меня это небольшая проблема, что система обычно переходит в режим ожидания (приостановка) после короткого периода бездействия пользователя.

Я читал всю документацию, которую мог найти на MSDN, и в блогах MSDN на эту тему, и мне кажется, что есть три возможных решения этой проблемы:

  1. Держите систему в состоянии «всегда включено», периодически вызывая SystemIdleTimerReset . Это кажется немного чрезмерным, и поэтому не может быть и речи.

  2. Периодически активируйте систему при помощи CeRunAppAtTime и войдите в необслуживаемое состояние, чтобы выполнить мою обработку.

  3. Используйте состояние без присмотра вместо перехода в режим полной приостановки. Это будет прозрачно для пользователя, но система никогда не перейдет в спящий режим.

Второй подход представляется более предпочтительным, однако для этого требуется, чтобы система вызывала исполняемый файл при пробуждении, и единственной задачей было уведомить мой сервис о том, что он должен начать обработку. Это кажется немного ненужным, и я хотел бы избежать этого дополнительного исполняемого файла. Конечно, я мог бы переместить всю свою обработку в этот дополнительный исполняемый файл, но я хотел бы использовать некоторые из средств, предоставляемых при запуске в качестве службы, а также не иметь всплывающей программы (даже если она находится в фоновом режиме) при запуске обработки.

На первый взгляд, третий подход, похоже, имеет ту же основную проблему, что и первый. Тем не менее, я читал в некоторых блогах MSDN, что при таком подходе можно было бы реально сэкономить заряд батареи, вместо того чтобы часто входить и выходить из режима ожидания (аргументы для этого заключались в том, что природа платформы WM чтобы во время простоя система потребляла очень мало заряда батареи, а для входа и выхода из режима ожидания требуется немало обработки).

Итак, я думаю, мои вопросы следующие:

  • Какой подход вы бы порекомендовали в моей ситуации? Относительно сохранения минимального расхода батареи и хорошей чистой реализации.

  • В случае подхода № 2, возможно ли устранить необходимость в уведомляющем исполняемом файле? Либо через альтернативные функции API, либо через существующие универсальные приложения на платформе?

  • В случае захода на посадку номер три, знаете ли вы какую-либо информацию / статистику, относящуюся к заявке, о том, что можно продлить срок службы батареи при использовании автоматического режима до перехода в режим ожидания. Например. как часто вам нужно вывести систему из режима ожидания, прежде чем предпочтительным будет автоматический режим.

  • Вопрос, связанный с реализацией (бонус): необходимо ли регулярно вызывать SystemIdleTimerReset , чтобы оставаться в автоматическом режиме?

И, наконец, если вы считаете, что я преждевременно исключил подход номер один, скажите, пожалуйста, почему.


Пожалуйста, укажите в своем ответе, основываете ли вы свой ответ на знании или просто гадаете (последнее также очень приветствуется!).

Пожалуйста, оставьте комментарий, если вы считаете, что мне нужно уточнить какие-либо части этого вопроса.

Ответы [ 2 ]

6 голосов
/ 11 января 2009

CERunAppAtTime - это очень неправильно понятый API (в основном из-за ужасного названия). не нужно запускать приложение. Он может просто установить именованное системное событие (см. Описание параметра pwszAppName в документации MSDN ). Если вы хотите знать, когда оно сработало (чтобы завершить работу приложения, переведите устройство в спящий режим после завершения обработки), просто создайте рабочий поток, который выполняет WaitForSingleObject для того же именованного события.

Необслуживаемое состояние часто используется для устройств, которым необходимо поддерживать непрерывную работу приложения (например, MP3-плеер), но экономить электроэнергию, отключая подсветку (возможно, единственную подсистему с наибольшим энергопотреблением).

Очевидно, что в автоматическом режиме используется значительно больше мощности, чем в режиме ожидания, поскольку в режиме ожидания единственным потреблением энергии является самообновление ОЗУ. В автоматическом режиме процессор все еще работает и работает (и некоторые периферийные устройства тоже могут работать - в зависимости от того, как OEM определил их автоматический режим).

SystemIdleTimerReset просто не позволяет диспетчеру питания переводить устройство в режим пониженного энергопотребления из-за неактивности. Этот режим, будь то приостановленный, без присмотра, в полете или другой, определяется OEM. Используйте его экономно, потому что когда вы это делаете, это влияет на энергопотребление устройства. Выполнение этого в автоматическом режиме является особенно проблематичным с точки зрения пользователя, потому что они могут подумать, что устройство выключено (это выглядит так), но теперь их срок службы батареи ушел на юг.

1 голос
/ 15 января 2009

У меня был длинный пост, в котором подробно рассказывалось о том, что вы не должны ожидать приемлемого времени автономной работы, потому что WM не предназначена для поддержки того, что вы пытаетесь сделать, , но - вы могли бы подайте сигнал своему сервису при пробуждении, выполните обработку, а затем используйте методы, описанные в этого сообщения , чтобы немедленно перевести устройство в спящий режим. Таким образом, вы должны иметь возможность поддерживать соотношение времени до сна очень низким - но, как вы говорите, я только догадываюсь.

Смотри также:

Энергоэффективные приложения (MSDN)

Власть людям ( Разработчики 1 , Разработчики 2 , Устройства )

Энергоэффективные приложения WM (запись в блоге)

...