Запуск фоновых служб на PocketPC
https://stackoverflow.com/questions/433325
-
10-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianВопрос
Недавно я купил себе новый мобильный телефон под управлением Windows Mobile 6.1 Professional.И, конечно же, в настоящее время я собираюсь заняться программированием для него в качестве хобби.Мой план состоит в том, чтобы служба работала как DLL, загружаемая с помощью Services.exe.Для этого необходимо собирать данные о сомах и выполнять их обработку через регулярные промежутки времени (каждые 5-10 минут).
Поскольку мне нужно запускать это через регулярные промежутки времени, для меня является некоторой проблемой то, что система обычно переходит в спящий режим (приостанавливается) после короткого периода бездействия пользователя.
Я прочитал всю документацию, которую смог найти в MSDN и блогах MSDN по этому вопросу, и мне кажется, что есть три возможных решения этой проблемы:
Держите систему в состоянии «Всегда включено», вызвав СистемаIdleTimerReset периодически.Это кажется несколько чрезмерным, поэтому об этом не может быть и речи.
Пусть система периодически просыпается с CeRunAppAtTime, и войдите в автоматическое состояние, чтобы выполнить обработку.
Используйте автоматическое состояние вместо полной приостановки.Это будет прозрачно для пользователя, но система никогда не перейдет в режим сна.
Второй подход кажется более предпочтительным, однако для этого потребуется, чтобы система вызывала исполняемый файл при пробуждении, с единственной задачей - уведомить мою службу о том, что она должна начать обработку.Это кажется немного ненужным, и я бы хотел избежать этого дополнительного исполняемого файла.Я, конечно, мог бы переместить всю свою обработку в этот дополнительный исполняемый файл, но мне бы хотелось использовать некоторые возможности, предоставляемые при работе в качестве службы, а также не допускать всплывающего окна программы (даже если она находится в фоновом режиме) при каждом запуске обработки.
На первый взгляд кажется, что третий подход имеет ту же основную проблему, что и первый.Тем не менее, я читал в некоторых блогах MSDN, что с помощью этого подхода можно реально сэкономить заряд батареи вместо того, чтобы часто переходить в режим ожидания и выходить из него (аргументами в пользу этого было то, что природа платформы WM иметь очень небольшой расход заряда батареи, когда система находится в режиме ожидания.И этот вход и выход из режима ожидания требует немалой обработки).
Итак, я думаю, мои вопросы заключаются в следующем:
Какой подход вы бы порекомендовали в моей ситуации?Что касается минимального потребления заряда батареи и хорошей чистой реализации.
В случае подхода номер два можно ли устранить необходимость в уведомляющем исполняемом файле?Либо через альтернативные функции API, либо через существующие универсальные приложения на платформе?
В случае подхода номер три знаете ли вы какую-либо информацию/статистику, имеющую отношение к утверждению о том, что можно продлить срок службы батареи при использовании автоматического режима вместо перехода в режим ожидания.Например.как часто вам нужно выводить систему из режима ожидания, прежде чем отдать предпочтение автоматическому режиму.
Конкретный (бонусный) вопрос по реализации:Нужно ли регулярно звонить СистемаIdleTimerReset оставаться в автоматическом режиме?
И, наконец, если вы думаете, что я преждевременно исключил подход номер один, скажите, пожалуйста, почему.
Пожалуйста, укажите в своем ответе, основываете ли вы свой ответ на знаниях или просто догадываетесь (последнее также очень приветствуется!).
Пожалуйста, оставьте комментарий, если вы считаете, что мне нужно прояснить какие-либо части этого вопроса.
Решение
CERunAppAtTime — API, который часто неправильно понимают (в основном из-за ужасного названия).Это не делает придется запустить приложение.Он может просто установить именованное системное событие (см. описание параметра pwszAppName). в документации MSDN).Если вам интересно узнать, когда он сработал (чтобы ваше приложение снова перевело устройство в спящий режим после завершения обработки), просто создайте рабочий поток, который выполняет WaitForSingleObject для того же самого именованного события.
Автоматическое состояние часто используется для устройств, которым необходимо поддерживать непрерывную работу приложения (например, MP3-плеер), но экономить электроэнергию за счет отключения подсветки (вероятно, это самая энергоемкая подсистема).
Очевидно, что в автоматическом режиме используется значительно больше энергии, чем в режиме ожидания, поскольку в режиме ожидания единственное потребление энергии приходится на самообновление ОЗУ.В автоматическом режиме процессор все еще включен и работает (и некоторые периферийные устройства тоже могут работать - зависит от того, как OEM-производитель определил свой автоматический режим).
SystemIdleTimerReset просто не позволяет диспетчеру питания перевести устройство в режим пониженного энергопотребления из-за бездействия.Этот режим, будь то приостановленный, автоматический, полетный или другой, определяется OEM-производителем.Используйте его экономно, потому что это влияет на энергопотребление устройства.Выполнение этого в автоматическом режиме особенно проблематично с точки зрения пользователя, поскольку он может подумать, что устройство выключено (так оно и выглядит), но теперь время автономной работы у него сократилось.
Другие советы
У меня был целый длинный пост, в котором подробно описывалось, что не следует рассчитывать на приемлемое время автономной работы, потому что WM не предназначен для поддержки того, что вы пытаетесь сделать, но -- вы можете сигнализировать службе о пробуждении, выполнить обработку, а затем использовать методы из эта почта чтобы немедленно перевести устройство обратно в спящий режим.Ты должен Таким образом, я смогу поддерживать очень низкое соотношение времени работы и времени сна - но, как вы говорите, я только предполагаю.
Смотрите также:
Энергоэффективные приложения (MSDN)
