Причем, данные модели не просто концептуальный дизайн, они являются образцами реальных устройств, которые начнут появляться на рынке в ближайшее время. С их появлением и широким распространением сенсоры больше не будут считаться диковинкой, а станут неотъемлемой частью любого ультрабука.

Виды сенсоров

Не берусь говорить точно о том, какие именно датчики будут устанавливаться, но скорее всего в стандартный набор будут входить:

• Датчик освещенности
• Акселерометр
• Компас
• Датчик ориентации
• GPS

Зачем они нужны

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

Благо предпосылки к созданию программ, работающих с сенсорами, появились еще в Windows 7 - Sensor and Location Platform. Это унифицированный интерфейс взаимодействия с сенсорами, который позволяет избежать неразберихи, когда каждый датчик поставлялся со своими драйверами и своим API.

Как начать использовать сенсоры уже сейчас

С софтом разобрались, теперь про железо - ультрабуков с сенсорами на борту на рынке пока нет. Что делать, если уже чешутся руки попрактиковаться и создать что-то новое, уникальное?

Существуют два варианта:

• Использовать сторонний датчик (набор сенсоров), например, от Freescale или STMicroelectronics
• Использовать датчики, которые уже есть, практически у каждого - сенсоры смартфона

Далее я как раз и хочу рассказать о втором пункте, на примере использования смартфона на базе ОС Android в качестве «донора» данных.

Однажды, в поисках подобного решения я наткнулся на интересное приложение - PCRemote, которое представляет из себя программу для удаленного управления компьютером с помощью устройств, работающих под Android. В сети полно подобных проектов, но этот оказался интересным потому, что предлагал использовать не только сенсорный экран (как множество других проектов) для управления компьютером, но и акселерометр, компас, гироскоп. Причем поддержка сенсоров организована таким образом, что после установки всего необходимого софта в системе появляются реальные "виртуальные" сенсоры. Windows их "видит" как обычные датчики, подключенные (интегрированные) к компьютеру, благодаря этому работа с ними возможна посредством стандартного API из состава Sensor and Location Platform.

Данное решение поддерживает:

• GPS
• Акселерометр
• Датчик ориентации
• Датчик освещенности

Огромным плюсом использования этого решения является то, что после того как на замену "виртуальным" сенсорам придут "реальные, железные", разработчику не нужно будет ничего менять, т.к. взаимодействие с датчиками останется прежним, на уровне Sensor and Location Platform API.

Как установить

Первое, что необходимо сделать, это перейти на страницу RemoteSensors и скачать RemoteSensors driver for Windows 7. На сайте представлены драйвера для 32-х и 64-х систем. Скачиваем, запускаем установку, следуем подсказкам.

После завершения установки идем в панель управления, раздел Hardware and Sound, далее Location and Other Sensors.

Ставим галочку (Enabled) напротив PcRemote Sensors Device и нажимаем Apply.

В системе появились сенсоры. Осталось привязать их показания к показаниям сенсоров смартфона. Для этого скачиваем приложение PCRemoteServer и запускаем его.

Последний шаг - через Google Play скачиваем и устанавливаем приложение PcRemote Advance.

Запускаем, выбираем пункт Discovery Server, после того, как сервер обнаружен и произошло подключение - выбираем пункт - Sensors to PC.

Готово! Наш ПК (ноутбук, ультрабук, нетбук) теперь имеет сенсоры!

Как проверить работоспособность данного решения? Для этого я написал простое приложение, которое при запуске инициализирует Sensor and Location Platform, перечисляет все сенсоры, доступные в системе и выводит их в виде списка (Sensors). При выборе сенсора в списке в нижней части окна (Values) можно видеть текущие показания сенсоров.

Если все было сделано правильно, то при запуске приложения вы увидите список как на картинке.

Теперь можно смело приступать к разработке сенсоро-ориентированного приложения для новых мобильных платформ.

Если у вас остались вопросы о том как использовать сенсоры в своих приложениях - приходите послушать доклады, посвященные сенсорам на КРИ и DevCon 12.

Но сначала немного о планах и серьезности намерений производителей "железа".

В этом году на всемирной выставке CES 2012 компания Intel продемонстрировала первый Android-смартфон работающий на базе x86 архитектуры. Данный смартфон является «атомным», т.к. работает на мобильной платформе Medfield и использует чип Atom Z2460.

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

На верхних графиках результаты тестов на энерго-эффективность при использовании 3G, воспроизведении аудио и видео. Синим отмечены результаты работы смартфона на базе Medfield. В нижней части – результаты тестов на производительность. Как видно из графиков Medfield имеет лучшие показатели во всех тестах.

Прототип-прототипом, но а как же реальные устройства? Там же на CES компания Lenovo показала первый Android-смартфон на базе x86 архитектуры - Lenovo K800. Данный аппарат работает на платформе Medfield, тактовая частота процессора - 1,6 ГГц, имеет 4.5-й дюймовый дисплей и 8-ми мегапиксельную камеру. Продемонстрированная модель работает на базе Android версии 2.3, но производитель обещает, что к моменту выпуска аппарат будет работать на Android 4.0.

Первые Android-смартфоны К800 от компании Lenovo появятся на рынке во втором квартале 2012 года.

О своих планах по выпуску Android устройств на базе х86-й архитектуры так же заявила компании Motorola, заключившая с компанией Intel многогодичное соглашение о партнерстве. Компания Motorola собирается представить первое устройство на базе Atom так же во втором квартале 2012 года.

Помимо производительности мобильные устройства на базе платформы Medfield будет отличать наличие технологий NFC и WiDi. Если первая технология уже проникает на рынок смартфонов, то вторая является уникальной для устройств на базе Android.

WiDi уже используется в современных ноутбуках и ультрабуках и даст возможность новым смартфонам просматривать изображения, видео, играть в игры на больших экранах, без использования проводов. Например на телевизорах, так же использующих технологию WiDi, либо подключенных к WiDi адаптерам.

Первая волна устройств, судя по озвученным планам, появится уже во втором квартале 2012 года. С точки зрения потребителей это будут новые устройства, обладающие рядом отличительных особенностей таких как производительность, энерго-эффективность, наличие WiDi. С точки зрения разработчика - добавится новая аппаратная платформа, и, в некоторых случая, возникнет необходимость адаптации существующих приложений под новую платформу.

В каких случаях может потребоваться адаптация? Прежде чем ответить на этот вопрос давайте вкратце рассмотрим способы создания приложения для Android.

Все приложения для Android можно условно разделить на два типа - Dalvik приложения и приложения использующие NDK

Dalvik это виртуальная машина, являющаяся чатью платформы Android. Dalvik позволяет запускать и исполнять приложения написанные на Java.

NDK это набор инструментов позволяющий создавать и использовать в своем приложении библиотеки написанные на C \ C++. Прибегать к помощи NDK приходится в тех случаях когда есть необходимость, например, использовать готовый С++ код написанный под другую платформу (чтобы не терять готовые наработки), когда необходимо повысить производительность приложения (как бы не был хорош Dalvik но проигрывает "нативному" коду в вопросах производительности).

Если Вы являетесь разработчиком приложение, то для Вас не составит труда определить использует ли приложение NDK библиотеки или нет. Если приложение Вам досталось со стороны, то для того, чтобы определить - использует ли приложение NDK библиотеки или нет необходимо открыть APK файл (который по сути является ZIP архивом) приложения с помощью любого архиватора (например 7-Zip) и проверить наличие подкаталога lib.

Если таковой имеется, то название внутренних подкаталогов укажет на наличие NDK библиотек для различных аппаратных платформ.

Так же можно воспользоваться утилитой APK Info, доступной в Android Market. С помощью данной утилиты можно посмотреть список установленных приложений и получить, в том числе, информацию о наличие NDK библиотек.

Что произойдет с появлением новой платформы? Для Dalvik приложений ничего не изменится, т.к. они работают поверх виртуальной машины, и обеспечение совместимости и работоспособности этой машины на новой аппаратной архитектуре задача разработчиков Dalvik.

Для многих NDK приложений, по сути, тоже ничего не изменится. Не смотря на то, что архитектура будет новой большинство NDK приложений не заметят разницы. Причина - бинарный транслятор, так же анонсированный и продемонстрированный компанией Intel на CES 2010. Смысл работы транслятора простой - он интерпретирует ARM код в x86 код, что обеспечивает совместимость приложений с новой архитектурой.

Транслятор решит проблемы совместимости приложений с х86 и разработчику NDK приложение не придется думать о добавлении поддержки новой аппаратной платформы.С одной стороны. С другой - если разработчик заинтересован в том чтобы "выжать" все, что можно из новой платформы и создать эффективное в плане производительности и энерго-потребления приложение, то ему необходимо будет добавить поддержку новой архитектуры в свое приложение.

К счастью сделать это очень просто. Поддержка x86 платформы появилась в NDK еще в прошлом году с выходом Android NDK 6.

Первое, что необходимо сделать это убедится, что у Вас установлен Android NDK версии 6 или выше. Скачать последнюю версию Android NDK можно на официальной странице.

Далее необходимо добавить новый target для сборки в make файл для сборки библиотек. Обычно в этом файле прописано что-то вроде:

APP_ABI := armeabi armeabi-v7a

К данной строке необходимо добавить x86:

APP_ABI := armeabi armeabi-v7a x86

В последней, на данный момент, версии Android NDK 7 добавился новый параметр – all.

Указав его можно собирать приложение под все поддерживаемые аппаратные платформы:

APP_ABI := all

После сборки библиотек их необхоимо включить в APK файл и "перезалить" пакет приложения в Android Market.

Разработчику не придется создавать отдельную версию приложения для x86-й платформы. Он может включить библиотеки для x86 в уже существующий установочный пакет и обеспечить, тем самым, совместимость одного пакета со всеми аппаратными платформами.

В панели управления приложениями Android Market так же не придется вносить каких-либо изменений, т.к. Android Market сам позаботится о проверке совместимости приложения и целевой платформы.

Если рассмотреть укрупненую модель любой мобильной платформы то она состоит и 3-х основных частей.

Аккумулятор

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

Железо

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

Софт

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

Как именно софт влияет на потребление энергии? Если в двух словах - он не дает железу "спать".

Рассмотрим одного из крупных потребителей энергии в системе - процессор.

Процессор может управлять своим энергопотреблением с помощью, так называемых, C-State. Для тех, кто не знаком с этими режимами, привожу короткую справку:

• С0 - рабочее состояние процессора, подразделяется на различные P-States.
• C1 - состояние, когда процессор ничего не делает, но готов приступить к работе, правда с небольшой задержкой. Многие процессоры имеют различные вариации этого состояния.
• С2 - почти тоже самое, что и С1, но в этом состоянии процессор потребляет меньше энергии, и имеет большую задержку для перехода в рабочее состояние.
• С3 - состояние "сна", переходя в это состояние процессор очищает кэш второго уровня. Характеризуется меньшим энергопотреблением, и более долгим временем перехода в рабочее состояние.
• ...и так далее в зависимости от процессора.

Для того чтобы было более наглядно приведу иллюстрацию:

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

Особенно это касается программ, которые выполняют какие-либо действия в фоновом режиме. Эти программы должны спать всегда и просыпаться только при наступлении какого-либо события.

События рулят или Event-driven подход

Приведу пример "неправильного" кода (к сожалению, такой подход к написанию кода используется гораздо чаще, чем вы думаете). Данный пример кода служит для получения и данных из сокета, например, в каком-нибудь серверном приложении.

while(true)
{
	// Получаем данные
	result = recv(serverSocket, buffer, bufferLen, 0);

	// Обработка полученных данных
	if(result != 0)
	{
		HandleData(buffer);
	}

	// Спим секунду и повторяем
	Sleep(1000);
}

Что же здесь "неправильного"? Есть данные или нет данных, код будет "будить" процессор каждые 1000 мс. Поведение кода напоминает осла из Шрека: "Уже приехали? А теперь приехали? А сейчас приехали?".

"Правильный" код, для данной задачи, не будет ни кого спрашивать, он уснет у будет ждать когда разбудят его. Для этого, во многих операционных системах, существуют объекты синхронизации, такие как события. С учетом сказанного код должен выглядеть так (код не полный, опущена обработка ошибок и кодов возврата, моя задача просто проиллюстрировать принцип):

WSANETWORKEVENTS NetworkEvents;
WSAEVENT	 wsaSocketEvent;
wsaSocketEvent = WSACreateEvent();

WSAEventSelect(serverSocket, wsaSocketEvent, FD_READ|FD_CLOSE);

while(true)
{
	// Ждем наступления одного из событий - получения данных или закрытия сокета
	WaitForSingleObject(wsaSocketEvent, INFINITE);

	// Что произошло?
	WSAEnumNetworkEvents(m_hServerSocket, wsaSocketEvent, &NetworkEvents);

	// Пришли новые данные
	if(NetworkEvents.lNetworkEvents & FD_READ)
	{
		// Читаем, обрабатываем
		WSARecvFrom(serverSocket, &buffer, ...);
	}
}

В чем прелесть примера выше? Он будет спать тогда, когда ему нечего делать.

Таймеры, будильники нашего кода

Иногда без таймеров не обойтись, примеров масса - проигрывание аудио, видео, анимация.

Немного о таймерах. Интервал системного таймера Windows, по умолчанию, равен 15,6 мс. Что это означает для программ? Допустим вы хотите, чтобы выше приложение выполняло какое-то действие каждые 40 мс. Проходит первый интервал в 15,6 мс, слишком мало, проходит второй 31,1, опять рано, третий 46,8 - попали, таймер сработает. В большинстве случаев лишние 6,8 мс не имеют значения.

Так же прямое влияние на Sleep, если вы вызовете Sleep(1), при установленном интервале в 15,6 мс, то спать код будет не 1 мс, а все 15,6 мс.

Но если дело касается проигрывания видео - тогда это поведение не приемлемо. В этих случаях разработчик может изменить дискретность системного таймера вызвав функцию из Windows Multimedia API - timeBeginPeriod. Данная функция позволяет изменить период таймера вплоть до 1мс. Для кода это хорошо, но сильно сокращает жизнь батареи (вплоть до 25%).

Как найти компромисс? Все просто изменяйте период системного таймера только тогда, когда это действительно необходимо. Например, если вы разрабатываете приложение, использующее анимацию и вам нужна меньшая дискретность таймера меняйте таймер тогда, когда анимация отображается и происходит, и возвращайте если, например, окно свернуто или анимация остановлена.

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

Объединение таймеров

В Windows 7 появилась замечательная возможность объединять таймеры. Что это такое и как это работает представлено на рисунке ниже:

Т.е. Windows "подстраивает" таймеры приложений таким образом, чтобы они совпадали со срабатываниями таймера самой операционной системы.

Для того, чтобы использовать эту возможность необходимо вызвать

BOOL WINAPI
SetWaitableTimerEx(
__in HANDLE hTimer,
__in const LARGE_INTEGER *lpDueTime,
__in LONG lPeriod,
__in_opt PTIMERAPCROUTINE pfnCompletionRoutine,
__in_opt LPVOID lpArgToCompletionRoutine,
__in_opt PREASON_CONTEXT WakeContext,
__in ULONG TolerableDelay
);

Полное описание функции вы можете найти в MSDN. В рамках данной статьи нас интересуют только параметр TolerableDelay, который определяет максимальное допустимое отклюнение от заданного интервала.

Более подробно о таймерах в Windows можно прочитать в статье Timers, Timer Resolution, and Development of Efficient Code

Сделай это быстро

Еще один способ сделать программу более энерго-эффективной это научить ее делать нужные вещи быстро, на сколько это возможно. Добиться этого можно, например, оптимизировав код, путем использования SSE, AVX и других аппаратных возможностей платформы. В качестве примера хочу привести использование Quick Sync в Sandy Bridge для кодирования и декодирования видео. На сайте Tom's Hardware можно посмотреть результаты.

Допустим мы оптимизировали нашу программу, но насколько она теперь более энерго-эффективна, как это оценить? Очень просто - с помощью специальных программ и инструментов.

Инструменты для анализа энерго-эффективности

1. Intel Power Checker. Пожалуй самый простой и быстрый способ оценить энерго-эффективность своей программы.



Обзор и описание программы можно найти в блоге ISN

2. Intel Battery Life analyzer



Более сложный, но вместе с тем более информативный инструмент, служит для отслеживания различных активностей железа и софта, которые влияют на время работы от батареи.

3. Joulemeter от Microsoft



Тоже достаточно интересный инструмент, определяющий энергопотребление различных компонентов платформы. Может работать в связке с ваттметром WattsUp.

Где узнать больше

• Intel Power Efficiency Community статьи, практические рекомендацие и советы по созданию энерго-эффективного программного обеспечения.
• Battery Life and Energy Efficiency сборник статей и рецептов от Microsoft
• Timers, Timer Resolution, and Development of Efficient Code ссылка уже приведена выше, для тех, кто начинает читать статью с конца.
• Так же на данную тему мы провели вебинар, запись которого доступна здесь