monobogdan

Размер экрана — краеугольный камень мира современных смартфонов. Кто-то считает, что дисплеи должны становиться только больше, а рамки — меньше, кто-то любит «средние» дисплеи диагональю в 5+", ну а кто-то остаётся ярым поклонником и приверженцем компактных смартфонов с крошечными дисплейчиками. В наше время, купить новый смартфон с относительно небольшим дисплеем за приемлемые деньги почти нереально — самые бюджетные модели будут слишком тормозными для современного пользователя. Некоторое время назад, я купил себе бюджетный крошечный смартфон 2012 года выпуска — Samsung Galaxy Pocket, причём всего за 100 рублей. Конечно же мне захотелось довести его до ума — а доводить пришлось руками и навыками прожженного программера! Какой смартфон можно получить за 100 рублей? Читаем в статье!

Минутка предыстории

С самого появления смартфонов на рынке, весь мир шагал к тотальному увеличению дисплеев и уменьшению рамок. В какой-то момент, большие смартфоны даже получили отдельное название — падфоны или смартпэды. Такой ход событий было не трудно предугадать: ведь производители дисплейных матриц осваивали всё более и более высокие разрешения и предлагали больше вариантов производителям смартфонов.

Однако несмотря на всеобщее засилие больших «лопат», в мире всё ещё оставались поклонники маленьких и компактных телефонов, которыми очень удобно пользоваться одной рукой. Сейчас подобные устройства представляют только небольшие бренды, известные достаточно в узких кругах — в основном, их можно купить на маркетплейсах, в обычных салонах связи их не найти. Мне известно о нескольких подобных устройствах, которые сейчас присутствуют на рынке. Первый из них «закос» под iPhone — Soyes XS11:

Но тут уж, если честно, хочется назвать такой смартфон не просто компактным, а совсем малюсеньким. На нём вполне удобно выполнять задачи звонилки, но совсем неудобно набирать текст — поэтому под наши задачи, он не особо подходит. Кроме того, эти девайсы работают на базе бюджетного смартфонного железа 6-7 летней давности, поэтому их производительность будет достаточно невысокой по меркам современного пользователя. Конечно же есть и более серьёзные варианты — например, компания Unihertz (да, тот самый продолжатель идей BlackBerry) делает смартфоны Jelly 2: дисплей с диагональю 3", Helio P61 под капотом и Android 11 на борту. Вот только цена, мягко говоря, кусачая — 18 тысяч рублей на момент написания статьи. Это слишком дорого!

Но если душа прямо таки лежит к компактным смартфонам, почему бы не обратиться к рынку Б/У устройств и не присмотреть что-то из… прошлого десятилетия? А вариантов ведь реально много — тут и LG Optimus L3 (3.2"), и Samsung Galaxy Pocket Neo (2.8"), Samsung Galaxy Star (3"), Samsung Galaxy Fame (3.5"), Samsung Galaxy Young. Все перечисленные девайсы стоят реально копейки — можно купить живой вариант до 400-500 рублей!

Я решил взять себе целых два смартфона: Samsung Galaxy Mini и Samsung Galaxy Pocket первого поколения. Оба достались мне в одном лоте за 2.000 рублей (с 20 телефонами) и обошлись мне по сто рублей, причём оба смартфона были рабочими! Чуть позже я докупил отдельно Galaxy Star (250 рублей), Galaxy Fame (250 рублей) и Galaxy Pocket Neo (~400 рублей) для полноты коллекции — вышло совсем недорого. Итак, что за характеристики мы получаем в смартфоне за 100 рублей:

• Android: 2.3 Gingerbread.

• Чипсет: Broadcom BCM21553 с одним ядром Cortex-A5 на частоте 832мгц. Видеочип: VideoCore IV, он же использовался в Raspberry Pi.

• ОЗУ: 256 мегабайт (предположительно — DDR1).

• Встроенная память: 3 гигабайта + слот для SD.

• Дисплей: 2.8", 240x320, емкостной тачскрин.

• Сеть: Поддержка 2G/3G. Об LTE и речи не идёт.

Выглядит не особо густо, да? И разрешение весьма низкое — большинство софта не запустится, а о клиентах современных сервисов и мечтать не приходится… или приходится?

Конечно же шаловливым ручкам захотелось вернуть жизнь этому миниатюрному красавцу и я решил использовать его как второй смартфон — при этом с клиентом ВК и музыкой, которые я запилил сам.

Разработка под старые версии Android

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

Даже сейчас нет никакой проблемы скачать последнюю версию Android Studio, подключить смартфон с включенной отладкой и отлаживать приложение прямо на девайсе — logcat тоже есть. Единственный нюанс — поиск драйверов и ручное закрытие приложений в таскменеджере, если вы деплоите под Android 2.x (Android Studio не умеет сам закрывать приложение, чтобы переустановить пакет).

В целом, за всё время разработки под старые устройства, я пришёл к следующим выводам:

• Поскольку большинство устройств имеет одно ядро, для плавности интерфейса нужно минимизировать любую работу в фоне.

• Взаимодействие с современными веб-сервисами может быть осложнено из-за отсутствия поддержки TLS1.2 и устаревших сертификатов (проверка сертификатов легко обходится специальным костылем, а вот TLS — нет).

• У Android до 3.0 вся отрисовка интерфейса программная и она опять же, будет сказываться на скорости работы фоновых служб. Чем менее интерфейс комплексный, тем лучше.

• Пушей нет — да, вообще. Однако это ничуть не помешает нам сделать уведомления практически в реальном времени с помощью… очередного костыля!

Допиливаем ВК

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

Честно сказать, вся концепция интерфейса требовала полной переработки — боковое меню банально очень неудобно использовать на подобных устройствах из-за малых размеров каждой строчки. Поэтому я решил не изобретать велосипед, а обратился к дизайнерам Apple и первоисточнику: официальному клиенту ВК для iOS 6, родом из 2012 года!

Приложение для Android выглядело +- также в те годы. Видите вкладки с разделами снизу? Они то нам и нужны — это самый удобный способ навигации на таких смартфонах! Накидав макет в layout'е, я приступил к реализации:

Изначально мне хотелось, чтобы всё приложение было плавным и анимированным: для этого я обратился к фреймворку анимаций Android. Суть очень простая — это обычный интерполятор значений от a до b за определенный промежуток времени. При этом мы не можем анимировать произвольное свойство — только те, который уже реализованы в системе (переход, поворот, масштабирование, альфа-канал). Более наглядно это можно представить вот так:

Да, это всё анимация :) Получаем примерно такой результат:

Обратите внимание, что запуск большого количества анимаций будет вызывать перерисовку даже в том случае, если элемент не видно на экране — от чего у нас будут дикие тормоза! Осторожнее с этим.

После этого, я решил доработать раздел с музыкой: я все еще пользуюсь грязными хаками для получения доступа к API музыки, поскольку «левым» клиентам такой возможности не дают. Публично его расписывать не буду, поскольку это скорее всего нелегально, да и сами ребята из ВК об этом знают (но не думаю, что будут применять какие-то санкции по отношению к «маленьким» разработчикам) — но если нужно, пишите в личку, расскажу всю концепцию.

Во первых, мне хотелось добавить возможность скачивать треки на внутреннюю память/флэшку. А во вторых, мне хотелось добавить фоновое воспроизведение — до этого возможность свернуть приложение и послушать музыку уже была, однако Android мог в любой момент прибить окно с музыкой и оставить нас с носом, остаётся только реализация в виде foreground-сервиса:

В Android есть два типа служб: background (фоновые) и foreground (видимые пользователю). Первый тип служб система может прибить когда угодно — например мало памяти или экономия заряда АКБ. А вот второй тип служб система не прибивает практически никогда, поскольку они обозначают выполнение важной операции в фоне — например скачивание файла или обновление системы. Однако у них есть одно ограничение — они должны быть привязаны к собственному уведомлению, которое нельзя закрыть. В процессе реализации возникло еще пару проблем — Wakelock'и (механизм, предотвращающий уход девайса в «сон») и WiFiLock'и (тоже самое, но для WiFi).

Точно таким же способом я реализовал механизм уведомлений — как я уже говорил раньше, пушей на старых смартфонах нет вообще ни в каком виде, поэтому пришлось реализовывать свой механизм «обновления»: каждые 3-5 секунд запрашиваем список последних 5 диалогов с сервера и сравниваем с предыдущим результатом, если есть новые сообщения — создаём нотификацию (листинг слишком длинный - пришлось перезалить на pastebin):

private NotificationCompat.Builder createMessageNotification(String sender, Stri - Pastebin.com

После этого, я начал рутинную работу по реализации интерфейса для данных с сервера — паблики, друзья, профили, лента и.т.п. В некотором смысле, реализация лента весьма занимательна: вообще, для очень больших списков существуют т.н виртуализация ListView — это когда ListView отображает только видимый пользователю кусок датасета (набора данных — например, список записей на стене) и на старых версиях Android она доступна. Однако мне было интересно реализовать вариант, который потреблял бы минимальное количество ОЗУ и где я точно знал бы, когда пользователь видит тот или иной фрагмент приложения. Поэтому я реализовал… пагинацию свайпами! Вот так привет из нулевых!

Для этого я использовал GestureDetector — встроенный в систему класс для обнаружения простых жестов — свайпов и.т.п. ВК при запросе ленты отдаёт специальную метку для получения следующей страницы новостей (поскольку она может динамически меняться и нужно хранить её стейт), мы эти метки просто сохраняем и переключаемся по странницам новостей с помощью обычных свайпов вправо-влево:

Выглядит весьма забавно.

Юзабельно ли всё это на деле?

Давайте смотреть, может ли юзать такой смартфон в наши дни. Берём наш девайс в руки, логинимся и оцениваем его производительность «вхолостую».

Работает весьма шустренько, учитывая что это бюджетник 2012 года. Как насчет нашего самопального клиента ВК? Смотрим:

Работает весьма бодро. Не сказать что также плавно, как последний айфон, но и совсем плохим результат явно не назвать!

Смартфонный функционал у девайса тоже вполне ничего: 1-2 SIM (в зависимости от версии), нормальная синхронизация контактов с ПК (однако Kies вроде-бы не работает на Windows 10, но есть vcf):

Встроенный почтовый клиент продолжает работать без каких либо проблем. Однако настраивать некоторые почтовые сервисы нужно вручную и с помощью «паролей приложений» — напрямую залогинится возможности нет. В случае «покета», придется поставить стоковый клиент из Android 2.3 вручную.
Мультимедийные возможности тоже радуют: встроенный плеер тачвиза мне всегда очень нравился. Есть и настройки эквалайзера.

Единственное, что откровенно подводит — браузер. Последним вариантом осталась Opera Mini 7 — она позволяет смотреть сайты, но не поддерживает динамический контент, только статику. Ну, зайти на википедию или почитать статью на Хабре хватит. Родной браузер уже не в состоянии что либо загрузить :(

Ну а в общем, производителньость смартфона весьма радует, согласитесь? Нельзя сказать, что он уж слишком тормозной — по крайней мере, современные ультрабюджетные смартфоны (до 4-5 тысяч рублей) зачастую показывают себя гораздо хуже чем и флагманы прошлых лет, и даже бюджетники!

Заключение

И всё таки, я считаю что мне удалось в каком-то смысле вдохнуть новую жизнь в старенький девайс. Если использовать подобный девайс как второй — на случай, если сел основной смартфон, то такой миниатюрный красаввчик может неождианно выручить даже в довольно сложной ситуации. Кроме того, эти смартфоны всеядны к аккумуляторам — достаточно подпаять + и — и они будут работать хоть от BL-4C.

Главная ценность Galaxy Pocket — в его компактных размерах. А поскольку по настоящему дешевых, маленьких и шустрых смартфонов становится всё меньше и меньше, то нам остаётся лишь продлять жизнь моделям прошлых лет! Есть ли в этом смысл и получил ли смартфон новую жизнь? Пишите в комментариях!

Клиент ВК можно сказать на 4pda. Там лежит самая последняя версия (для скачивания нужна регистрация на форуме). Если по каким-то причинам не хотите регистрироваться на форуме — я выложил актуальную версию в комментариях.

Эта статья поддерживается командой ITGLOBAL.COM

Мы — первый облачный провайдер в России, а также интегратор, поставщик ИТ-услуг, продуктов, сервисов и разработчик собственного ПО.

• Наш сайт
• Наш блог про виртуализацию и Enterprise IT
• Истории успеха наших клиентов

Многие программисты так или иначе имеют тягу и интерес к разработке игр. Немалое количество спецов было замечено за написанием маленьких и миленьких игрушек, которые были разработаны за короткое время «just for fun». Большинству разработчиков за счастье взять готовый игровой движок по типу Unity/UE и попытаться создать что-то своё с их помощью, особенно упорные изучают и пытаются что-то сделать в экзотических движках типа Godot/Urho, а совсем прожжённые ребята любят писать игрушки… с нуля. Таковым любителем писать все сам оказался и я. И в один день мне просто захотелось написать что-нибудь прикольное, мобильное и обязательно — двадэшное! В этой статье вы узнаете про: написание производительного 2D-рендерера с нуля на базе OpenGL ES, обработку «сырого» ввода в мобильных играх, организацию архитектуры и игровой логики и адаптация игры под любые устройства. Интересно? Тогда жду вас в статье!

❯ Как это работает?

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

Один из прошлых проектов — 3D шутэмап под… коммуникаторы с Windows Mobile без видеоускорителей! Игра отлично работала и на HTC Gene, и на QTek S110!

В больших студиях принято всю нагрузку распределять на целые команды разработчиков. Артовики занимаются графикой, звуковики — музыкой и звуковыми эффектами, геймдизайнеры — продумывают мир и геймплей будущей игры, а программисты — воплощают всё это в жизнь. Однако, за последние 20 лет появилось довольно большое количествобесплатныхинструментов, благодаря которым маленькие команды или даже разработчики-одиночки могут разрабатывать собственные игры сами!

Подобные инструменты включают в себя как довольно функциональныеконструкторы игр, которые обычно не требуют серьёзных навыков программирования и позволяют собирать игру из логических блоков, так и полноценных игровых движков на манер Unity или Unreal Engine, которые позволяют разработчикам писать игры и продумывать их архитектуру самим. Можно сказать что именно «благодаря» доступности подобных инструментов мы можем видеть текущую ситуацию на рынке мобильных игр, где балом правят очень простые и маленькие донатные игрушки, называемыегиперкежуалом.

Но у подобных инструментов есть несколько минусов, которые банально не позволяют их использовать в реализации некоторых проектов:

• Большой вес приложения: При сборке, Unity и UE создают достаточно объёмные пакеты из-за большого количества зависимостей. Таким образом, даже пустой проект может спокойно весить 50-100 мегабайт.

• Неоптимальная производительность: И у Unity, и у UE очень комплексные и сложные рендереры «под капотом». Если сейчас купить дешевый смартфон за 3-4 тысячи рублей и попытаться на него накатить какой-нибудь 3 в ряд, то нас ждут либо вылеты, либо дикие тормоза.

Лично я для себя приметил ещё один минус — невозможность деплоить игры на устройства с старыми версиями Android, но это, опять же, моя личная хотелка.

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

❯ Определяемся с задачами

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

Игра будет написана полностью на Java — родном языке для Android-приложений. Пустые пакеты без зависимостей весят всего около 20 килобайт — что только нам на руку! Ни AppCompat, ни какие либо ещё библиотеки мы использовать не будем — нам нужен минимальный размер из возможных!

Итак, что должно быть в нашей игре:

• Основная суть: Вид сверху, человечком по центру экрана можно управлять и стрелять во вражин. Цель заключается в том, чтобы набрать как можно больше очков перед тем, как игрока загрызут. За каждого поверженного врага начисляются баксы, за которые можно купить новые пушки!

• Оружие: Несколько видов вооружения, в том числе пистолеты, дробовики, автоматы и даже пулеметы! Всё оружие можно купить в внутриигровом магазине за валюту, которую игрок заработал во время игры

• Враги: Два типа врагов — обычный зомби и «шустрик». Враги спавнятся в заранее предусмотренных точках и начинают идти (или бежать) в сторону игрока с целью побить его.

• Уровни: Можно сказать, простые декорации — на момент написания статьи без какого либо интерактива.

Поскольку игра пишется с нуля, необходимо сразу продумать необходимые для реализации модули:

• Графика: Аппаратно-ускоренный рендерер полупрозрачных 2D-спрайтов с возможность аффинных трансформаций (поворот/масштаб/искривление и.т.п). На мобильных устройствах нужно поддерживать число DIP'ов (вызовов отрисовки) как можно ниже — для этого используется техника батчинга. Сам рендерер работает на базе OpenGLES 1.1 — т.е чистый FFP.

• Ввод: Обработка тачскрина и геймпадов. Оба способа ввода очень легко реализовать на Android — для тачскрина нам достаточно повесить onTouchListener на окно нашей игры, а для обработки кнопок — ловить события onKeyListener и сопоставлять коды кнопок с кнопками нашего виртуального геймпада.

• Звук: Воспроизведение как «маленьких» звуков, которые можно загрузить целиком в память (выстрелы, звуки шагов и… т.п), так и музыки/эмбиента, которые нужно стримить из физического носителя. Тут практически всю работу делает за нас сам Android, для звуков есть класс — SoundPool (который, тем не менее, не умеет сообщать о статусе проигрывания звука), для музыки — MediaPlayer. Есть возможность проигрывать PCM-сэмплы напрямую, чем я и воспользовался изначально, но с ним есть проблемы.

• «Физика»: Я не зря взял этот пункт в кавычки :) По сути, вся физика у нас — это один метод для определения AABB (пересечения прямоугольник с прямоугольником). Всё, ни о какой настоящей физике и речи не идет :)

Поэтому, с учетом требований описанных выше, наша игра будет работать практически на любых смартфонах/планшетах/тв-приставках кроме китайских смартфонов на базе чипсета MT6516 без GPU из 2010-2011 годов. На всех остальных устройствах, включая самый первый Android-смартфон, игра должна работать без проблем. А вот и парк устройств, на которых мы будем тестировать нашу игру:

С целями определились, самое время переходить к практической реализации игры! По сути, её разработка заняла у меня около дву-трех дней — это с учетом написания фреймворка. Но и сама игра совсем несложная :)

❯ Рендерер

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

По сути, в современном мире, 2D — это частный случай 3D, когда рисуются всё те же примитивы в виде треугольников, но вместо перспективной матрицы, используется ортографическая матрица определенных размеров. Во времена актуальности DirectDraw (середина-конец 90х) и Java-телефонов, графику обычно не делали адаптивной, из-за чего при смене разрешения, игровое поле могло растягиваться на всю площадь дисплея. Сейчас же, когда разброс разрешений стал колоссальным, чаще всего можно встретить два подхода к организацию проекции:

• Установка ортографической матрицы в фиксированные размеры: Если координатная система уже была завязана на пиксели, или по какой-то причине хочется использовать именно её, то можно просто завязать игру на определенном разрешении (например, 480x320, или 480x800). Растеризатор формально не оперирует с пикселями — у него есть нормализованные координаты -1..1 (где -1 — начало экрана, 0 — середина, 1 — конец, это называется clip-space), а матрица проекции как раз и переводит координаты геометрии в camera-space координатах в clip-space — т.е в нашем случае, автоматически подгоняет размеры спрайтов из желаемого нами размера в физический. Обратите внимание, физические движки обычно рассчитаны на работу в метрических координатных системах. Попытки задавать ускорения в пикселях вызывают рывки и баги.

• Перевод координатной системы с пиксельной на метрическую/абстрактную:
  Сейчас этот способ используется чаще всего, поскольку именно его используют самые популярные движки и фреймворки. Если говорить совсем просто — то мы задаем координаты объектов и их размеры не относительно пикселей, а относительно размеров этих объектов в метрах, или ещё какой-либо абстрактной системы координат. Этот подход близок к обычной 3D-графике и имеет свои плюшки: например, можно выпустить HD-пак для вашей игры и заменить все спрайты на варианты с более высоким разрешением, не переделывая половину игры.

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

Всё более чем понятно — преобразуем координаты спрайта из world-space в camera-space, отсекаем спрайт, если он находится за пределами экрана, задаем стейты для GAPI (на данный момент, их всего два), заполняем вершинный буфер геометрией и рисуем на экран. Никакого смысла использовать VBO здесь нет, а на nio-буфферы можно получить прямой указатель без лишних копирований, так что никаких проблем с производительностью не будет. Обратите внимание — вершинный буфер выделяется заранее — аллокации каждый дравколл нам не нужны и вредны.

Обратите внимание на вызовы ByteBuffer.order — это важно, по умолчанию, Java создаёт все буферы в BIG_ENDIAN, в то время как большинство Android-устройств — LITTLE_ENDIAN, из-за этого можно запросто накосячить и долго думать «а почему у меня буферы заполнены правильно, но геометрии на экране нет!?».

В процессе разработки игры, при отрисовке относительно небольшой карты с большим количеством тайлов, количество вызовов отрисовки возросло аж до 600, из-за чего FPS в игре очень сильно просел. Связано это с тем, что на старых мобильных GPU каждый вызов отрисовки означал пересылку состояния сцены видеочипу, из-за чего мы получали лаги. Фиксится это довольно просто: реализацией батчинга — специальной техники, которая «сшивает» большое количество спрайтов с одной текстурой в один и позволяет отрисовать хоть 1000, хоть 100000 спрайтов в один проход! Есть два вида батчинга, статический — когда объекты «сшиваются» при загрузке карты/в процессе компиляции игры (привет Unity) и динамический — когда объекты сшиваются прямо на лету (тоже привет Unity). На более современных мобильных GPU с поддержкой GLES 3.0 есть также инстансинг — схожая технология, но реализуемая прямо на GPU. Суть её в том, что мы передаём в шейдер параметры объектов, которые мы хотим отрисовать (матрицу, настройки материала и.т.п) и просим видеочип отрисовать одну и ту же геометрию, допустим, 15 раз. Каждая итерация отрисовки геометрии будет увеличивать счетчик gl_InstanceID на один, благодаря чему мы сможем расставить все модельки на свои места! Но тут уж справедливости ради стоит сказать, что в D3D10+ можно вообще стейты передавать на видеокарту «пачками», что здорово снижает оверхед одного вызова отрисовки.

Для загрузки спрайтов используется встроенный в Android декодер изображений. Он умеет работать в нескольких режимах (ARGB/RGB565 и.т.п), декодировать кучу форматов — в том числе и jpeg, что положительно скажется на финальном размере игры.

На этом реализация рендерера закончена. Да, все вот так просто :)
Переходим к двум остальным модулям — звук и ввод.

❯ Звук и ввод

Как я уже говорил, звук я решитл реализовать на базе уже существующей звуковой подсистемы Android. Ничего сложного в её реализацир нет, можно сказать, нам остаётся лишь написать обёртку, необходимую для работы. Изначально я написал собственный загрузчик wav-файлов и хотел использовать AudioTrack — класс для воспрозизведения PCM-звука напрямую, но мне не понравилось, что в нём нет разделения на источники звука и буферы, из-за чего каждый источник вынужден заниматься копированием PCM-потока в новый и новый буфер…

Полная реализация звукового потока выглядит так. И да, с SoundPool нет возможности получить позицию проигрывания звука или узнать, когда проигрывание закончилось. Увы.

Да будет звук! Ну и про ввод не забываем (листинг получился слишком длинный, а на Пикабу нет тега для кода - так что как-то так):

public static final int TOUCH_IDLE = 0; public static final int TOUCH_PRESS - Pastebin.com

Сама реализация джойстика крайне простая — запоминаем координаты, куда пользователь поставил палец и затем считаем дистанцию положения пальца относительно центральной точки, параллельно нормализововая их относительно максимальной дистанции:

public class Joystick { private Sprite joySprite; public float Veloc - Pastebin.com

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

Основа для игры есть, теперь переходим к её реализации!

❯ Пишем игру

Писать игру я начал с создания первого уровня и реализации загрузчика уровней. В качестве редактора, я выбрал популярный и широко-известный TileEd — удобный редактор с возможностью экспорта карт в несколько разных форматов. Я лично выбрал Json, поскольку в Android уже есть удобный пакет для работы с этим форматом данных.

Карта делится на 3 базовые понятия: тайлы — фон, с изображением травы/асфальта/земли и.т.п, пропы — статичные объекты по типу деревьев и кустов и сущности — объекты, участвующие в игровом процессе, т.е игрок, зомби и летящие пули. Система сущностей реализована в виде абстрактного базового класса, который реализовывает логику апдейтов, просчитывает Forward-вектор и выполняет другие необходимые задачи:

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

@Override public void update() { super.update(); joyInp - Pastebin.com

Ну и не забываем про реализацию зомби. Она тоже очень простая: есть базовый класс Zombie, от которого наследуются все монстры и который реализует несколько необходимых методов — повернуться в сторону игрока, идти вперед и конечно же атака!

❯ Что у нас есть на данный момент?

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

Как мы видим, игра (а пока что — proof of concept) работает довольно неплохо на всех устройствах, которые были выбраны для тестирования. Однако это ещё не всё — предстоит добавить конечную цель игры (набор очков), магазин стволов и разные типы мобов. Благо, это всё реализовать уже совсем несложно :)

❯ Заключение

Написать небольшую игрушку с нуля в одиночку вполне реально. Разработка достаточно больших проектов конечно же требует довольно больших человекочасов, однако реализовать что-то своё, маленькое может и самому!

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

Статья подготовлена при поддержке компании TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропускать новые статьи каждую неделю!
Но тут я даже чутка навру - на этой неделе вас ждёт сразу две статьи :) Следующая - в четверг, прошлую неделю я отдыхал и работал.

Windows Phone… услышав название этой мобильной системы, поневоле начинаешь с теплотой вспоминать своего недавнего, такого необычного мобильного друга, как будто прошло всего пару месяцев с момента смены смартфона на iPhone/Android. А ведь с момента фактической смерти Windows Phone прошло уже почти 10 лет! Увы, время вспять уже не повернуть, а мобильное подразделение Nokia не спасти, однако при наличии навыков разработки мобильных приложений, большом энтузиазме и фанатизме, есть шанс вернуть жизнь своему старому другу! Недавно я снова загорелся диким энтузиазмом и смог вернуть жизнь старенькой «люмии», написав собственные клиенты нужных мне сервисов с нуля — и готов поделиться этим с вами во всех подробностях!

Сегодня вы узнаете о моей мотивации привносить жизнь старым смартфонам, о тонкостях разработки мобильных приложений, чем Windiows Phone был на голову выше Android в техническом плане и о том, почему провал Windows Phone — одна из самых больших потерь мобильного рынка. Интересно? Тогда добро пожаловать в статью!

❯ Предыстория

Пожалуй, довольно большой процент моих читателей и подписчиков когда-либо владел и пользовался смартфонами на Windows Phone. Мнение пользователей этой мобильной платформы во многом разнится — кто-то восхваляет по настоящему продуманный и плавный интерфейс, кто-то ругает Microsoft за «кидалово» с обновлениями, но большинство людей сходится во мнении, что Windows Phone — была действительно необычной и имела собственную изюминку.

Конечно же, Windows Phone была далеко не первым опытом Microsoft на мобильном рынке. До этого, Редмондская компания поддерживала очень крутую платформу для коммуникаторов и КПК под названием Windows Mobile. Фактически, это был полноценный компьютер в кармане — большинство кнопочных телефонов могли максимум запускать простенькие J2ME-приложения, в то время как WM позволял запускать множество самых разных программ — как написанных на C++/Pascal, так и написанных на C#/VB.Net. Мобильная платформа во всём пыталась подражать своему старшему брату — API системы было очень похоже на то, что мы видим в обычной Windows — тут и полноценная оконная система, и waveout для вывода звука, и GDI для вывода графики.

Windows Mobile прочно занимал свою нишу на мобильном рынке: HTC постоянно представляла новые модели коммуникаторов, которые довольно хорошо продавались. Но тут пришёл первый iPhone, который перевернул всё с ног на голову. Оказывается смартфоном можно управлять полностью пальцами, нажимая на красивые, анимированные элементы интерфейса! Это перевернуло всю индустрию — даже Nokia с её Symbian было тяжело конкурировать с продуктом от Apple. Microsoft видела, что пользователи хотят не столько свободы и кастомизации в системе, сколько плавности интерфейса, стабильности и простоты использования.

Плеер Zune HD стал дебютом свежего подхода к созданию интерфейсов — Metro UI. И хотя сам девайс не сыскал особой популярности, став в некоторой степени провальным, Microsoft взяла на вооружение концепцию этого интерфейса, дабы реализовать её уже в полноценной мобильной ОС. В октябре 2010 года выходит первая версия новой мобильной платформы Microsoft — Windows Phone 7, заложившая фундамент той самой системы, которую мы с вами до сих пор вспоминаем с теплотой!

На WP7 вышло весьма много устройств: тут и девайсы от HTC, и смартфоны Lumia от Nokia, и даже продолжение линейки Omnia от Samsung! Но были у этой платформы и серьезные минусы: она базировалась на ядре обычной Windows CE (оно же использовалось в Windows Mobile) и из-за желания повысить безопасность системы, Microsoft отключила возможность использовать код на нативных языках в своих приложениях. Кроме того, во многих аспектах WP7 была достаточно сырая — хотя для неё регулярно выходили обновления.

❯ Почему провал WP — трагедия для мобильного рынка?

Конечно же параллельно с доработкой WP7, Microsoft разрабатывала новую версию ОС, которая должна была объединить мобильные и десктопные приложения в одну общую концепцию. Кроме того, разработчики решили отказаться от лёгкого ядра Windows CE в пользу более тяжелого и продвинутого ядра Windows NT, которое используется в полноценных версиях Windows.

К сожалению, апгрейда с WP7 на WP8 предусмотрено не было, что многие пользователи считают «кидаловом» со стороны Microsoft. Отчасти это так, но проблема была в том, что даже флагманские устройства на WP7 имели 512мб ОЗУ, чего было недостаточно для первой версии WP8. Думаю, в какой-то степени Microsoft просто не хотели портить имидж максимально плавных смартфонов тормозами обновленной системы, хотя примеры шустрой работы на 512мб ОЗУ есть — например, Lumia 520.

Но вот где WP8 была передовой, так это «под капотом». Microsoft смогли сделать что-то невообразимое для мира ARM-устройств: они реализовали нормальный слой абстракции от «железа» и ввели концепцию ACPI, знакомую нам из обычных десктопных ПК. Вкратце, ACPI — это что-то типа списка железа в устройстве, под которое ОС должна найти и загрузить драйверы, не забыв под это всё выделить ресурсы (devicetree в Linux реализует похожую концепцию). Кроме того, Microsoft реализовала полноценный UEFI в своих смартфонах, что позволяло, например, сделать дуалбут в будущем. На практике это всё означает то, что даже неподдерживаемые No-Name смартфоны можно было обновить до Windows 10, банально поменяв пару ключей в реестре: на Android-устройствах такое невообразимо. Фактически, это стандартизация ARM-железа.

На этом технические фишки Windows Phone не заканчиваются. Переходя к пользовательской части, стоит упомянуть фреймворк для построения интерфейса (WPF/Silverlight), который из коробки работает очень шустро, отлично масштабируется под разные размер экрана и предлагает мощные возможности по анимации и кастомизации интерфейса под стиль приложения. Да и само SDK навязывало изначально правильную концепцию программирования, заставляя выделять все задачи в отдельные потоки, не только задействуя дополнительные ядра процессора, но и улучшая пользовательский опыт от приложения (неправильно написанные Android-приложения легко могут подвисать при выполнении какой-то работы).

И третья классная фишка, про которую почему-то все забыли — это поддержка DirectX 11. Конечно в WP7 уже была поддержка Xna (именно на его базе написана Terraria), что позволяло писать игры одновременно для Windows, Xbox 360 и собственно мобилок, но он имел некоторые ограничения и был прослойкой между графическим API (как Direct3D или OpenGL) и самой игрой. Windows Phone 8 же давал настоящий, полноценный DirectX 11 — хотя и поддерживал максимум вторые шейдеры, но при этом умел те фишки, которые не умел Android — инстансинг для оптимальной отрисовки геометрии, установка стейтов «пачками» и эффективное «bindless» управление ресурсами шейдеров. Теоретически, это давало возможность портировать полноценные игры с ПК/Xbox на Windows Phone, хотя на практике не так много кто этим пользовался.

Ну и вспоминая аргумент про кидалово Microsoft с обновлениями, нужно помнить, что обратная совместимость с приложениями для более ранних версий системы была: на Windows Phone 8 можно было играть в годноту с Windows Phone 7 (NFS Undercover, NFS Hot Pursuit, Mirrors Edge и ещё некоторые классные мобильные игры), а на Windows 10 Mobile можно было запускать почти любое приложение для Windows Phone 8.

Так в чём же потеря WP — трагедия для мобильного рынка? А вы посмотрите на свой Android-смартфон сейчас. Сколько в нём ОЗУ? 4гб? 8гб? 12гб? Смущает ли вас то, что Android умудряется неприятно подтормаживать даже с такими ресурсами? А теперь вспомните Lumia 520: Snapdragon 200, 512 мегабайт оперативной памяти. Вот так она работает из коробки:

Думаю, это всё красноречиво объясняет то, что без WP случилась дуополия на рынке — Android продолжает жиреть, впустую жрать ресурсы и при этом практически не получать новых фишек из года в год, а iPhone хоть и остаётся всё такой же плавной и шустрой, ребята из Apple явно не чувствуют конкуренции и их смартфоны стагнируют в плане дизайна и в некоторой степени интерфейса…

❯ Мотивация

Мои давние читатели знают мою любовь к смартфонам прошлых лет. Для меня нет понятия запланированного устаревания: если под устройство есть комплект разработки и документация, то при большом желании я могу дописать нужные мне приложения сам.
Мой проект SelfEco (сам себе экосистема) как раз об этом — почти полгода назад я написал клиент YouTube и ВК для Android 2.2+. Фактически это означает, что мои приложения работали на ВСЕХ Android смартфонах от 2010 года и новее.

Исходным кодом своих приложений я свободно делюсь — как в качестве примера читателям, так и для возможности каких-то фиксов в будущем или даже модов. В 2021-2022 году я ходил с Lumia 640XL с Win10 Mobile на борту, как с основным смартфоном. И в целом, меня все устраивало и всё нравилось: там и годный клиент ВК был (LunaVK), и клиент телеги нормальный, и браузер кое-какие страницы всё ещё нормально переваривал. Но больше всего мне нравится Windows Phone 8 — она работает ещё шустрее и несколько более строгая в плане дизайна. Да и «люмии» сейчас стоят сущие копейки — моя 640XL обошлась мне в100 российских рублей(~1.5$ по тому курсу), я не шучу. А на онлайн-барахолках можно найтиживые, целыеаппараты с нормальными аккумуляторами по 200-500 рублей, иногда даже в родных коробочках!

Lumia 1320 и Lumia 640XL — подарки читателя Kotenilla!
Дак почему бы не применить всю эту круть и мощь во благо, учитывая дешевизну смартфонов? Решено: Качаем SDK и пишем собственный клиент ВК и YouTube — это минимально-необходимые для меня приложения!

❯ Подготовка

Для того, чтобы отлаживать и устанавливать сторонние приложения на смартфоны с Windows Phone, их нужно предварительно разблокировать и сделать «Interop Unlock». Процедура несложная и занимает немного времени на большинстве люмий. Дабы сильно не затягивать статью, я не буду описывать процесс разлочки здесь — его можно найти на 4pda для разных поколений устройств.

❯ YouTube

Начинаем с клиента ютуба. Собственно, концепция отнюдь не поменялась с прошлой статьи — мы всё так же используем API Invidous для получения информации о видео. Нативное API YouTube — полная дичь, да ещё и с ограничениями на один токен, в то время как Invidous сам распоряжается токенами и распределяет их как нужно. Нам лишь остаётся написать «морду», которая будет отображать полученные с сервера данные и передавать ссылку на видео в встроенный плеер.

В отличии от Android, никаких проблем с TLS не возникло: смартфон смог без проблем связаться с инстансом Invidous и получить данные о видео в трендах. Сам по себе, формат ответов очень простой и возвращается в виде JSON, который можно описать такой иерархией:

Практически сразу система нам навязывает распараллелленую парадигму написания кода — часть API банально не имеет синхронных аналогов! Например, из WebRequest убрали GetResponse, дабы неопытные разработчики не делали ошибок и не пытались вызывать долгие I/O операции в главном потоке (что вызывает подвисания приложения). .NET сам по себе имеет крутой механизм тасков (многопоточных задач) и реализацию концепции async/await, которая позволяет подождать выполнение операции, не блокируя остальное приложение.

Я решил придержаться более привычной мне концепции на коллбэках, которая позволяет более четко обрабатывать ошибки в подобных кейсах, да и в целом я не очень люблю подобный синтаксический сахар (а async/await и есть «сахар», поскольку разворачивается в стейт-машину). В качестве десериализатора (механизма парсинга JSON напрямую в экземпляры классов, используя рефлексию) я использовал классический Newtonsoft.Json.

После того, как механизм получения и обработки данных с сервера был готов, я начал реализовывать интерфейс приложения. И вот тут WP показал себя во всей красе. ListView? RecycleView? Нафиг эти костыли, винфон умеет нормально рисовать элементы интерфейса, которые вы выделили в ScrollView. И что забавно: в Android даже реализация с ScrollView при активной подгрузке данных вызывала лаги — на WP такого нет вообще! Тут всё просто работает из коробки!

Механизм анимаций здесь тоже декларативный и реализован в концепции т.н «сторибордов» — наборов действий, которые позволяют создавать достаточно сложные анимации вручную.

Буквально через пару часов после создания проекта, у меня уже была готова загрузка и отображение списка трендов:

А затем и логика воспроизведения видео, которая запускает встроенный плеер и передаёт в него ссылку на видео — которая выбирается относительно кодека (только mp4), разрешения устройства и предпочтений пользователя:

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

WP предоставляет специальное изолированное хранилище для пользовательских программ — IsolatedStorage, в которое нельзя добраться из остальной системы (без разблокированного загрузчика и режима Mass Storage). Там же можно хранить и конфиги — правда с некоторым API для файлов сильно перемудрили — навязывать распараллеливание чтения обычно маленьких файлов — это совсем уже.

Итак, буквально за сутки разработки у меня получилось реализовать приложение, которое может выводить списки ютуба по региону (тренды/популярное), может искать видео и воспроизводить ролики с различными разрешениями. Кроме того, приложение умеет подгружать превьюшки и имеет собственный раздел истории. Неплохо за 24 часа для программиста, который фактически не имел опыта с платформой UWP/WinRT в прошлом, да? :)

❯ ВК

Теперь пришло время реализовать клиент ВК! Фактически, ничего сложного в реализации клиента с базовым функционалом нет — это всё такая же «морда» к данным с сервера, к которым добавляется необходимость получать уведомления и реализовывать логику обновления данных.
На этот раз, я решил выбрать API WP8.1: оно гораздо более богатое на возможности и ближе к современному UWP, чем Silverlight из WP8. Так уж сложилось, что API обычного WP8 ближе к WP7 и совместимо с WP8.1 только с помощью специальной прослойки.

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

• Мессенджер: Конечно же, самое важное в нашем клиенте — это мессенджер.

• Музыка: Куда ж без удобной ВК музыки? Её реализация в кастомных клиентах отнюдь несложная, но достаточно костыльная из-за политики ВК в отношении лицензирования аудио. Снова будем идти на хаки, дабы получить работающее приложение!

• Новости: Помимо общения и прослушивания музыки, бывает потребность полистать ленту — дабы узнать новости, или посмотреть свежие мемчики.

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

Класс-менеджер для общения с API ВК я решил реализовать по тому же принципу, что и для клиента YouTube: у нас есть два метода на всё-про всё, один сразу десериализовывает ответ в виде объекта Root (для каждого типа ответа — он свой, все они описаны в Data.Packet.Root):

До async/await я не дозрел и здесь :)
Спустя достаточно короткое время, у меня уже была готова подгрузка диалогов:

Реализация обновления во всех разделах одинаковая: есть метод RequestUpdate, который начинает процедуру обновления и получает данные с сервера, а затем ставит в очередь задачу на обновление UI из основного потока с помощью UpdateUI:

И механизма загрузки/отправки сообщений.
В целом, с этим ничего сложного нет, однако теперь самое время разобраться с нотификациями. Пуши я пока-что поднять не смог, вместо них пока что лонгполлинг — достаточно для нотификаций пока приложение находится в фоне, но система со временем «прибивает» неактивные задачи, а сделать «бесконечный» фоновый таск как в Android не выйдет — система очень строго относится к любой фоновой работе.

Пришло время заняться музыкой — вот это действительно важный функционал! Для работы с аудио, я использовал довольно старый, но известный способ, который ВК пока что не пофиксил. Не то чтобы это из вредности, просто сами ВК особо не идут на контакт для интеграции аудио в своё приложение — исключением стали лишь очень крупные клиенты, как Kate Mobile — а значит можно реализовать действительно важные штуки: например, скачивание треков напрямую в музыкальную библиотеку, дабы их можно было послушать оффлайн! Вся работа с музыкой производится через прокси-сервер, поэтому аудио должно быть открыто.

Реализация фонового прослушивания музыки достаточно похожа на другие платформы, но в то же время заметно отличается. Само приложение может воспроизводить звуки с помощью MediaElement или BackgroundMediaPlayer, однако при сворачивании звук будет приостановлен (в отличии от MediaPlayer на Android). Для фонового прослушивания музыки, Microsoft решили сделать отдельный сервис BackgroundMusicPlayer, который запускается при попытке получить доступ к плееру из программы. Общаться с этим сервисом можно через межпроцессные вызовы — RPC и система предоставляет для него API. Вкратце: нам нужно создать фоновую задачу в виде отдельного модуля WinRT, который будет получать RPC-посылки от Foreground приложения и если нужно — отсылать ответы обратно. Ничего сложного!

Отдельного внимания заслуживает механизм скачивания музыки в библиотеку. В WP, программы не могут просто так «вторгнуться» в личное пространство пользователя — им обязательно нужны разрешения. Но это ладно, запросить разрешение — совсем не проблема. Зато настоящая проблема — ПОЛНОСТЬЮ асинхронный API. Захотел найти дескриптор файла в ФС — асинхронно, захотел его открыть — снова асинхронно. Поскольку у меня вся работа по скачиванию ведется в отдельном воркере и я не боюсь за дедлоки, пришлось лепить костыли с Task.Wait() :)

А ещё ВК возвращает mp3 без ID3-тегов, поэтому мне пришлось вручную их дописывать, дабы музыка в плеере удобно сортировалась:

Кроме того, дабы иметь возможность управлять музыкой из других приложений и экрана блокировки, Microsoft предоставляет т.н интерфейс SMTC — общий оверлей окна регулировки громкости, который позволяет управлять воспроизведением музыки. Его реализация простая до жути — просто включаем нужные кнопки (IsPlayEnabled, IsPauseEnabled и.т.п), добавляем обработчик события нажатия кнопки и обновляем информацию и обложку с помощью DisplayUpdater.

❯ Заключение

Вот таким образом, буквально за несколько дней мы реализовали клиенты нужных нам приложений с базовым функционалом. Разработка клиента YT заняла ровно сутки, разработка клиента ВК — двое суток. Но можно ли всем этим добром по настоящему пользоваться и как оно работает на настоящем устройстве? Смотрите ниже:

Весьма достойно, да? Ещё до публикации статьи, я выложил клиент YT на 4pda и в профильный Telegram-чатик — люди благодарны и действительно довольны. Только в англоязычном чате о WP8.1 (не вклюая WM10 и WP7/WP8) более 2х тысяч человек! Так что да, девайсы прошлых лет действительно нужны достаточно большому числу пользователей.

Ну а разработка клиентов для меня была эдаким челленджом — пилить что-то полезное под новым API всегда интересно, дак ещё и сами девайсы очень крутые с точки зрения UX и скорости работы. А вы как считаете? Жду ваше мнение в комментариях!

Статья подготовлена при поддержке TimeWeb Cloud. Подписывайтесь на меня и @Timeweb.Cloud, чтобы не пропустить новые статьи каждую неделю!

Мы с вами уже давно привыкли, что при покупке нового смартфона приходится выбирать всего из двух программных платформ — Android и iOS. Большинство читателей едва ли помнит, что дуополия на рынке была далеко не всегда: на заре развития смартфонов как повседневных устройств для всех и каждого, некоторые производители представляли свои собственные платформы. Но если Windows Phone всё ещё вспоминают с теплотой, то о другой системе, которая позиционировалась как конкурент Android, забыли практически полностью. И имя этой системе — bada! Недавно я купил себе парочку полностью рабочих bada-фонов с AMOLED-дисплеями по 300 рублей. Были ли у bada шансы в сравнении с Android и что из себя представляла эта система «под капотом»? Узнаете в статье!

❯ Текст

По сравнению с обычными кнопочными телефонами, современный рынок смартфонов зародился не так уж и давно — всего около 13 лет назад. На стыке нулевых и десятых шла активная борьба за карман и предпочтения пользователя: Android 1.6 потихоньку заменял современный Android 2.0/2.1 Eclair, первые три модели iPhone шли победоносной поступью благодаря наличию джейлбрейка и полной кастомизации системы, да и практически каждый крупный производитель мобильных устройств имел собственную платформу, на которой базировались её устройства.

В середине-конце нулевых, большинство пользователей были не искушены фишками полноценных операционных систем — они привыкли жить без многозадачности (за исключением пользователей Sony Ericsson и S60), без нативных приложений, без плавных анимаций и ускорения 3D-графики. Людей подкупал встроенный функционал телефонов: если там была встроенная читалка RSS и предустановлен клиент популярных в то время соц. сетей (мой мир :)), то обладатель устройства обычно пользовался именно ими. Конечно же, уже тогда были смартфоны, напоминающие нам современные устройства: помимо Apple, свои устройства предлагали Nokia (Symbian), Sony Ericsson (Symbian/Windows Mobile), HTC (Windows Mobile), но цены на них действительно очень «кусались».

Huawei U8500, или Билайн E300 — один из первых реально доступных Android-смартфонов в РФ. Ценник был около 6-7 тысяч рублей в конце 2010 года.

После выхода iPhone, производители потихоньку начинали отказываться от привычных кнопок и выпускать всё больше моделей с тачскрином. А поскольку попробовать новый способ управления хотелось всем, начали появляться относительно недорогиетачфоны— обычные телефоны, обладающие сенсорным дисплеем и кучей сетевых возможностей. Примеры одних из самых популярных тачфонов своих лет, это конечно же Samsung S5230 Star, Samsung S3650 Corby, LG Cookie и LG Cookie Fresh. В те времена, встретить человека с таким телефонов было не просто, а очень просто и в каких-то отдаленных местах это даже был предмет для хвастовства!

Когда уже было очевидно, что полноценные смартфоны в ближайшем будущем станут основным портативным устройством, Samsung решили взять предыдущий опыт и наработки SHP (Samsung Handset Platform — платформы S5230) и влить их в разработку совершенно новой смартфонной платформы, имя которой была —bada(с корейского — море). Новую платформу представили с свежей линейкой смартфонов Samsung Wave, а первым устройством был S8500 — смартфон на базе bada 1.0 с ёмкостным тачскрином и AMOLED-дисплеем. Вышел девайс в том же году, что и первый Android-флагман S-серии — Samsung Galaxy S…

И с этим связан очень интересный казус, ведь «под капотом», S8500 был очень похож на своего Android-собрата: использовался тот же чипсет Exynos 3110 «Hummingbird» (он же использовался и в iPhone 4 как Apple A4 с некоторыми доработками) с тем же радиомодулем. Конечно остальные характеристики были немного скромнее Galaxy S (384мб ОЗУ против 512мб, 8гб ПЗУ вместо 16, AMOLED-матрица немного меньше по диагонали), но и сам смартфон стоил ощутимо дешевле Android-собрата. Немудрено, что энтузиасты начали пытаться портировать Android на S8500 — и у них это получилось, хоть полноценный порт появился примерно через 2 года после выхода устройства на рынок.

Но почему большинство пользователей хотели перепрошить своё устройство на Android и чем была bada? Предлагаю узнать в практической части!

❯ Сегодняшние герои

Недавно я листал онлайн-барахолки в поисках интересных и несколько диковинных смартфонов для будущих статей. Выборка, как обычно для моего блога, стандартная: чем дешевле, тем лучше. И тут я вспомнил, что были когда-то смартфоны на базе bada — я будучи школьников даже успел потыкать Wave 525 у знакомого.

E300 я тоже решил прихватить — за 300 рублей предлагался девайс с родной коробочкой!

Однако не все бадафоны представляли для меня интерес. В первую очередь, меня интересовали смартфоны с GPU, которых не было у самых бюджетных устройств (Wave 525) и одной из главных хотелок был крутейший SuperAMOLED дисплей. После недолгих поисков, я нашёл на юлито интересующие меня девайсы за… 300 и 500 рублей.

«Дефект» первого смартфона заключался в забытом пароле. Это всё обходится буквально за 5 минут установкой свежей прошивки, но мне даже этого делать не пришлось: паролем оказался «1111» :) S7250 работает на базе bada 2.0 — последней версии этой платформы от Samsung, до слияния с Tizen.

Второй смартфон был полностью рабочим и исправным. Ему не требовалось никакого обслуживания совсем, хотя можно найти целые варианты на пароле из 200-300 рублей. Что занимательно — S8500 работал на базе bada 1.0, что даёт нам возможность напрямую сравнить их!

❯ Что у них под капотом?

Я намеренно не называю bada операционной системой. По сути, это лишь программная платформа (если очень условно — лаунчер), которая предоставляет набор API и интерфейс смартфона, но при этом сама может быть запущена на любой ОС — будь это Linux, или собственная RTOS, которая применялась во всех устройствах на базе bada 1.0.

После адаптации ядра Galaxy S к S5800, многие люди переходили именно на Android, несмотря на то, что система от Google была ощутимо прожорливее. Под первый Wave выходили разные прошивки — от 4.1 JellyBean, до 4.4 KitKat, старичок долгое время оставался достаточно актуальным.

Требования платформы были отнюдь невысокими, гораздо ниже оных у Android: bada могла легко работать на смартфонах с <128мб ОЗУ (у Wave 525 завялено 80мб, по факту скорее всего 128, где 48 зарезервировано системой), чипсетом с частотой ~200мгц и весьма небольшим объёмом ПЗУ. При этом в отличии от тачфонов, bada предоставляла механизм пакетов и предлагала разрабатывать приложения аж на трёх языках:

• Java — в платформе была реализована полноценная поддержка J2ME приложений, что в те годы сразу устраняло недостаток приложений в магазине. При этом, Java-приложения не умели одни из самых важных фишек новой системы: уведомления и (возможно) ускорение 3D-графики. Кроме того, у Samsung не очень удобный джойстик для «кнопочных» игр.

• C++ — основным языком для разработки приложений под bada были «плюсы». Платформа сразу выбрала «нативные» рельсы — что само по себе очень хорошо, однако из-за некоторых казусов, это обернулось проблемами. Найти SDK и эмулятор для разработки под bada можно и сейчас — я уже успел немного почитать документацию и посмотреть на сэмплы. И в целом, именно с точки зрения разработки, bada была весьма интересной — эдакой смесью костылей Symbian (нет исключений, полное отсутствие RAII и инициализация отдельно от аллокации) и простоты Java (приятная и удобная библиотека собственных дженериков, абстракций над базовыми типами и приятное API для построения интерфейса с конструктором форм). При этом, поддерживались все остальные фишки плюсов — в том числе и STL.

• JavaScript — да, bada решила выбрать концепцию PWA, как одну из основных. При этом в JS было экспортировано часть API самой системы — что позволяло делать интерфейс как на JS, так и с использованием нативного фреймворка.

И с виду всё звучит просто замечательно, просто и понятно. Однако, серьёзные проблемы тянулись с самой первой версии платформы:

• Отсутствие многозадачности — ядро, на которой работала bada, само по себе было многозадачным: в приложениях поддерживались потоки. Однако сами программы, за исключением предустановленных, всегда работали в однозадачном режиме. Почему так — неизвестно, возможно часть оптимизации под совсем слабые устройства типа Wave 525. Полноценная многозадачность появилась уже в bada 2.0.

• Отсутствие адаптивности интерфейса — да, это не шутка. Samsung предлагали адаптировать приложение под каждое разрешение экрана отдельно, а всё позиционирование велось в пикселях. Если честно, именно этот шаг мне понятен меньше всего — Android с самого выхода предоставлял очень крутой механизм позиционирования интерфейса, да и в iOS тоже были какие-то инструменты для адаптивного UI. Это была одна из самых главных проблем bada — по сути, мы возвращались в эпоху Java-приложений а-ля 240x320/320x480.

• Нестабильность системы — не на всех телефонах фирменная прошивка работала максимально стабильно. На некоторых моторолах ребут не был таким уж редким явлением, а некоторые китайчики могли начать перезагружаться после манипуляций в инженерном меню. Однако ожидать этого от смартфона в 2010 было странно — по некоторым слухам, даже если сторонняя программа вывалится с Access Violation (SIGSEGV), то в ребут уйдет вся система! Возможно, RTOS не умела нормально работать с MMU, однако если все программы действительно работают в «flat»-адресном пространстве, а не с виртуальной памятью, то это создаёт очень серьёзные уязвимости (и потенциал для моддинга прошивки).

Но были у системы и очень вкусные «плюшки», например — из коробки полностью поддерживалось хардварное ускорение 3D-графики (при наличии GPU), причём сразу свежий OpenGLES 2.0 — с поддержкой шейдеров! Благодаря этому, перспективы в новой платформе были и для разработчиков игр — я знаю как минимум несколько полноценных 3D-игр с iOS и Android для ОС от Samsung. Добавляем к этому потенциал реализации 3D-ускорения Java-приложений и получаем действительно годное устройство для прохождения такой годноты, как Galaxy On Fire 2 в 60 FPS! Кроме GPU, bada поддерживала виджеты и т.н «Хаб» — приложение-агрегатор событий из соц. сетей.

Именно на «болячки» жаловались пользователи чаще всего, забывая про положительные стороны устройства. И да, даже во время собственного использования, я встречал баги и сам — но всё ли так плохо, учитывая то, что Samsung действительно работала над своими ошибками и пыталась привлечь как можно сторонних разработчиков к своей платформе? Предлагаю узнать, взяв смартфон в руки самому!

❯ Смотрим на устройства

Первое, на что обращаешь внимание, когда берешь смартфоны начала 2010х в руки — это их компактный размер. Причём компактность здесь отнюдь не в ущерб юзабилити: в своё время, размер дисплея Wave был типичным среднячком — на уровне как 5.5" сейчас. Но при этом дисплей смартфона действительно очень классный и приятно удивляет и сейчас. Однако, здесь есть нюанс — помимо S8500, выходил так-же S8530 — практически такой же смартфон, но с SC-LCD (Samsung IPS) матрицей. В те годы, корейская компания часто давала выбор между различными типами матриц в пределах одной модели. Да что там говорить, иногда даже серьезные различия в чипсетах были!

На моем экземпляре, к сожалению матрица немного выгорела, в самом проблемно месте — верхней шторке. Увы и ах, но заметно это не так сильно, поэтому я лично обратил на это внимание только на второй день использования. Во всём остальном, я не чувствую никакого дискомфорта от «старых» OLED-дисплеев — могу без проблем юзать их часами. Wave M — устройство попроще и там используется обычная TN-матрица. Но тем не менее, её размер в 2010-2011 году был весьма впечатляющим.

Сам интерфейс системы здесь напоминает Symbian и Android одновременно. Оно в целом и не удивительно: Samsung долгое время была участником Symbian Foundation и разрабатывала обновления для этой ОС, а также выпускала свои смартфоны на базе этой системы. Ко второй версии bada, концепцию UI сильно поменяли в сторону Android, из-за чего Wave M больше похож на смартфон с Android 2.x на борту — и лично по мне, этот интерфейс около-идеален!

Сам девайс работает достаточно плавно. Здесь практически нет 60, или хотя-бы 30 FPS анимаций, но зато сама платформа отнюдь не «лагучая» в отличии от ранних версий Android.

Весьма занимательный способ установки приложений придумали пользователи бадафонов в своё время: система проверяет сертификаты и покупку только во время установки приложения, при этом вся установка заключается в распаковке zip-архива в специальную директорию на SD-карточку. По итогу очень скоро обнаружилось, что можно просто скопировать уже готовую купленную игру, скачать какое-нибудь бесплатное приложение, подменить файлы в его папке на файлы игры — и получить приложение бесплатно! В bada 2.0 этот баг поправили, но всё равно это выглядело весьма забавно для компании такого уровня.

Что насчёт юзабилити бадафонов в наше время? Ну, базовые функции они точно смогут выполнять достаточно достойно. С основной функцией «звонилки» корейцы справлялись всегда хорошо — тут и удобная синхронизация контактов с Kies (программа для синхронизации с ПК), и возможность передавать контакты через BT.

Здесь, само собой, есть Wi-Fi и 3G, но ни о каком сёрфинге речи практически не идёт. Почему практически? Потому что Opera Mini 7 всё ещё работает и уходить на покой явно не собирается — а значит прочесть материал или зайти на википедию в экстренной ситуации точно получится. bada 2.0 уже поддерживала в том числе и HTML5, но судя по всему, частично (CSS3 анимации у меня не работали). В целом, если у вас есть большое желание поставить «бадафон» в строй — то можете запилить для себя PWA-приложения, которые реализуют необходимый вам функционал. Так и клиент ВКшечки можно реализовать, и почту листать, и СМСки от банков обрабатывать.

Зато почтовый клиент работает!

Один из самых важных критериев для меня — это наличие в смартфоне годного аудиотракта. У моего BlackBerry Priv качество звука просто отменное, притом что используется встроенный ЦАП в Snapdragon 810. И плеер, и качество звука здесь очень даже ничего. Плеер удобный, есть DLNA для трансляции мультимедиа на телевизор.

Лично у меня сложилось впечатление, что в середине десятых, качество звука через 3.5мм джек заметно просело у смартфонов, по сравнению с народными музыкальными Nokia — как например 5310.

Ну и не забывая про мультимедийную часть смартфона, я проверил камеру — когда-то, у Galaxy S была весьма достойная камера, учитывая его ценовой сегмент. У Wave камера тоже вполне ничего, правда с теми же «болячками», что и у других мобильных камер прошлых лет — крайне плохое качество при съемке в темноте. Ну и автофокус забрали. :(

Поскольку у смартфонов был GPU и Samsung всерьез старались привлечь разработчиков игр под свою платформу, на bada выходили и 3D-игры с очень годной, по тем временам, графикой.

В целом, недостаток нативных приложений в какой-то степени компенсируется наличием J2ME, но именно отсутствие нормально поддержки от Samsung и странная политика в отношении безопасности, в конечном итоге добили bada. После того, как превосходство Android стало очевидным, Samsung решили сделать упор в Tizen — идеологическом продолжении MeeGo, мобильной ОС, которая разрабатывалась Intel и Nokia. Компания выпустила сразу несколько устройств на новой платформе — Samsung Z (без Galaxy), после которого вышло ещё несколько смартфонов и Tizen окончательно обосновался на холодильниках/часах/телевизорах. Мобилок на Tizen я пока ещё не видел, хотя покопать их с технической точки зрения и сравнить с N9 было бы интересно — но в РФ они достаточно редкие.

Ну а несколько лет назад, Samsung закрыла магазин приложений Tizen, что формально означает полный провал «вертушки» :(

❯ Заключение

Samsung в плане самопальных платформ напоминает Microsoft — те тоже умудрились сделать действительно крутую и необычную Windows Phone, отвоевать какой-то процент рынка и заполучить фанов своей системы, но затем пришли эффективные менеджеры и решили рубить всё на корню.

И даже если команды разработчиков самих этих платформ горят идеей запилить что-то крутое, бабло и желание улучшить отчетность делают своё дело. Но раз в год и палка стреляет — не зря ведь инженеры Nokia основали свою компанию Jolla, которая пилит Sailfish OS. А ведь «Аврора» — прямой наследник Sailfish! :)

Но если говорить конкретно о бадафонах — то несмотря на баги и некоторые глупые решения, это были весьма годные девайсы, учитывая действительно низкую цену. Настоящим конкурентом бюджетных бадафонов была лишь Nokia 5228/5230, которая хоть и имела настоящий Symbian, но не была оснащена Wi-Fi, GPS и даже 3G. Но вот с кем bada могла конкурировать в верхнем сегменте рынка?

Для многих разработчиков приложений далеко не секрет, что экосистема Android не предполагает написание полностью нативных приложений: в этой платформе очень многое завязано на Java и без ART можно запустить только простые службы без какого-либо интерфейса. Однако, есть один способ писать практически под «голый» Linux, не перекомпилируя ядро и при этом пользоваться самыми интересными фишками устройства без оверхеда в виде тяжелого Android: ускорение 3D-графики (OpenGLES), микшер звука, ввод с различных устройств, OTG, Wi-Fi и если очень постараться — даже 3G. Это открывает множество разных интересных применений старым устройствам: «железо» смартфонов зачастую гораздо мощнее современных недорогих одноплатников. Сегодня я покажу вам, как написать и запустить программу, которая полностью написанное на C без Android, на No-Name Android-смартфоне практически без модификаций. Интересно? Жду вас в статье!

❯ Что нам нужно знать?

Даже относительно старые устройства флагманского сегмента обладают весьма неплохими характеристиками. Зачастую они гораздо мощнее современных дешевых одноплатников и могут выполнять самые разные задачи: эмуляция консолей, работа в качестве плееров, да даже просто сделать настольные часики самому было бы здорово. Но есть одно но — это Android. Платформа от Google может тормозить даже на достаточно мощном железе, что резко ограничивает потенциально возможные применения подобных гаджетов. Да и многие программисты не особо хотят заморачиваться и учить API Android для реализации каких-то своих проектов.

Но конечно же, есть один способ писать нативные программы, при этом используя все ресурсы смартфона/планшета. Для этого нужно понимание, как работает процесс загрузки на многих Android-гаджетах:

1. Первичный загрузчик (BootROM) инициализирует какую-то часть периферии и загружает вторичный загрузчик (U-boot/LK).

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

3. После загрузки ядра Linux и подключения ramdisk начинается выполнение процессов системы.

Как раз в третьем пункте и лежит ключ к способу, который будем использовать мы. Дело в том, что в смартфоне обычно есть несколько boot-разделов и у каждого свой образ ядра Linux со своим ramdisk. Первый из них — это знакомый моддерамboot.img, который отвечает за загрузку системы и инициализирует железо/монтирует разделы/подготавливает окружение к работе (.rc файлы) и запускает главный процесс Android —zygote. При этом используется собственная реализация init от Android.

Второй, не менее знакомый многим раздел —recovery, отвечает за так называемый режим восстановления, в котором мы можем сбросить данные до заводских настроек/очистить кэши или прошить кастомную прошивку. Вероятно, многие из вас замечали, насколько быстро ваш девайс загружает этот режим, гораздо быстрее, чем загрузка обычного Android. И именно в его реализацию нам нужнозаглянуть(я намеренно выбрал бранч версии 2.3 — т.е Gingerbread для простоты):

А recovery оказывается самой обычной нативной программой, написанной на C со своим небольшим фреймворком для работы с графикой и вводом. В процессе загрузки режима recovery, скрипт запускает одноименную программу в /sbin/, благодаря которому мы видим простую и понятную менюшку. Так почему бы не использовать этот раздел в своих целях и не написать какую-нибудь нативную программу самому?

Как я уже говорил выше, в этом режиме доступны многие аппаратные возможности вашего смартфона, за исключением модема. Используя полученную информацию, предлагаю написать наше небольшое приложение под Android-смартфон без Android сами!

❯ Подготавливаем окружение

В первую очередь, хотелось бы отметить, что программы под «голый» смартфон можно писать не только на C/C++. Нам доступен как минимум FPC, который довольно давно умеет компилировать голые бинарники под Android. Кроме того, мы можем портировать маленькие embedded-версии интерпретаторов таких языков, как lua, micropython и duktape (JS).

Однако в случае нативных программ, есть два важных правила, которые необходимо понимать. Во-первых, в Android используется собственную реализацию стандартной библиотеки libc — bionic, в то время как на десктопных дистрибутивах используется glibc. Между собой они не совместимы — именно поэтому вы не можете просто взять и запустить консольную программу для Raspberry Pi, например.

А второе правило заключается в том, что начиная с версии 4.1, Androidтребует, чтобы все нативные программы были скомпилированы в режиме -fPIE — т. е. выходной код должен не зависеть от адреса загрузки программы в виртуальную память. Для этого достаточно добавить ключ -fPIE, однако учтите, что если вы разрабатываете программу под Android 4.0 и ниже, то fPIE наоборот необходимо убрать — старые версии Androidнеподдерживают такой способ генерации кода и будут вылетать с Segmentation fault.

Для разработки нам понадобится ndk — там есть все необходимые заголовочники и компиляторы для нашей работы. Я используюndk r9c, поскольку в свежих версиях Google регулярно может что-то сломать.
ndk-build, к сожалению, здесь работать не будет, поэтому Makefile придется написать самому. Я составил полностью рабочий Makefile, который без проблем скомпилирует валидную программу, вам остаётся лишь поменять NDK_DIR.

NDK_DIR = D:/android-ndk-r11c/

TOOLCHAIN_DIR = $(NDK_DIR)toolchains/arm-linux-androideabi-4.9/prebuilt/windows-x86_64/bin/

GCC = $(TOOLCHAIN_DIR)arm-linux-androideabi-g++

PLAT_DIR = $(NDK_DIR)platforms/android-17/arch-arm/usr/

LINK_LIBS = -l:libEGL.so -l:libGLESv1_CM.so

OUTPUT_NAME = cmdprog

build:

$(GCC) -I $(PLAT_DIR)include/ -L $(PLAT_DIR)lib/ -fPIE -Wl,-dynamic-linker=/sbin/linker $(LINK_LIBS) -static -o $(OUTPUT_NAME) main.cpp micro2d.cpp

После этого пишем простенькую программу, которая должна вывести «Test» и компилируем её.

❯ Деплоим на устройство

Несмотря на то, что грузиться мы будем в режим recovery, нам всё равно будет доступен adb, через который мы сможем запускать и отлаживать нашу программу. Это очень удобно, однако по умолчанию adb включен только в TWRP, который нужно сначала найти или портировать под ваш девайс (на большинство старых брендовых устройств порты есть, на нонейм придется портировать самому — гайды есть в интернете). Под ваше устройство есть TWRP? Отлично, распаковываете recovery.img с помощью так называемой «кухни» (MTKImgTools как вариант):

Открываете init.recovery.service.rc и убираете оттуда запуск одноименной службы (можно просто оставить файл пустым).

Запаковываем образ обратно тем же MTKImgTools и прошиваем флэшером для вашего устройства — в моём случае, это SP Flash Tool (MediaTek):

Заходим в режим рекавери и видим зависшую заставку устройства и звук подключения устройства к ПК. Если у вас установлены драйвера, то вы сможете без проблем зайти в adb shell и попасть в терминал для управления устройством. Теперь можно закинуть программу — прямо в корень рамдиска (записывается программа в ОЗУ, но при переполнении, телефон уйдет в ребут — осторожнее с этим). Пишем:

adb push cmdprog /: adb shell chmod 777 cmdprog ./cmdprog

И видим результат. Наша программа запускается и работает!

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

❯ Выводим графику

Для вывода графики без оконных систем, мы будем использовать API фреймбуфера Linux, которое позволяет нам получить прямой доступ к массиву пикселей на экране. Однако учтите, что этот способ полностью программный и может оказаться тормозным для вашего приложения: скорость работы прямо-пропорциональна разрешению дисплея вашего устройства. Чем выше разрешение, тем ниже филлрейт. В моём случае, матрица была с разрешением 960x540, 32млн цветов, IPS — очень недурно, согласны?

Фреймбуфер Linux может работать с самыми разными форматами пикселя, имейте это ввиду. На некоторых устройствах может быть 16-битный формат (262 тысячи цветов, RGB565), на моём же оказался 32х-битный с выравниванием по строкам (имейте это также ввиду). 32х битный формат. Работать с ним легко: открываем устройство /dev/graphics/fb0, получаем параметры (разрешение, формат пикселя), делаем mmap для отображения буфера с пикселями на экране в память нашего процесса и выделяем второй буфер для двойной буферизации дабы избежать неприятных мерцаний.

void m2dAllocFrameBuffer()

{

fbDev = open(PRIMARY_FB, O_RDWR);

fb_var_screeninfo vInfo; fb_fix_screeninfo fInfo;

ioctl(fbDev, FBIOGET_VSCREENINFO, &vInfo);

ioctl(fbDev, FBIOGET_FSCREENINFO, &fInfo); fbDesc.width = vInfo.xres;

fbDesc.height = vInfo.yres;

fbDesc.pixels = (unsigned char*)mmap(0, fInfo.smem_len, PROT_WRITE, MAP_SHARED, fbDev, 0); f

bDesc.length = fInfo.smem_len; fbDesc.lineLength = fInfo.line_length;

backBuffer = (unsigned char*)malloc(fInfo.smem_len); memset(backBuffer, 128, fInfo.smem_len);

printf("Framebuffer is %s %ix%ix%i\n", (char*)&fInfo.id, fbDesc.width, fbDesc.height, vInfo.bits_per_pixel, fInfo.type);

}

Если не сделать предыдущий шаг и запускать нашу программу параллельно с recovery, то они обе будут пытаться друг друга «перекрыть» — эдакий race condition:

После этого пишем простенькие функции для блиттинга картинок (в том числе с альфа-блендингом). В инлайнах и критичных к скорости функциям лучше не делать условия на проверку границ нашего буфера — лучше «отрезать» ненужное еще на этапе просчета ширины/высоты:

__inline void pixelAt(int x, int y, byte r, byte g, byte b, float alpha)

{

if(x < 0 || y < 0 || x >= fbDesc.width || y >= fbDesc.height) return;

unsigned char* absPtr = &backBuffer[(y * fbDesc.lineLength) + (x * 4)];

if(alpha >= 0.99f)

{

absPtr[0] = b;

absPtr[1] = g;

absPtr[2] = r;

}

else {

absPtr[0] = (byte)(b * alpha + absPtr[0] * (1.0f - alpha));

absPtr[1] = (byte)(g * alpha + absPtr[1] * (1.0f - alpha));

absPtr[2] = (byte)(r * alpha + absPtr[2] * (1.0f - alpha));

} absPtr[3] = 255; }

for(int i = 0; i < image->height; i++)

{

for(int j = 0; j < image->width; j++)

{

byte* ptr = &image->pixels[((image->height - i) * image->width + j) * 3]; pixelAt(x + j, y + i, ptr[0], ptr[1], ptr[2], alpha);

}

}

И загрузчик TGA:

CImage* m2dLoadImage(char* fileName) {

FILE* f = fopen(fileName, "r");

printf("m2dLoadImage: Loading %s\n", fileName);

if(!f)

{

printf("m2dLoadImage: Failed to load %s\n", fileName);

return 0;

}

CTgaHeader hdr;

fread(&hdr, sizeof(hdr), 1, f);

if(hdr.paletteType)

{

printf("m2dLoadImage: Palette images are unsupported\n");

return 0;

}

if(hdr.bpp != 24) {

printf("m2dLoadImage: Unsupported BPP\n");

return 0;

}

byte* buf = (byte*)malloc(hdr.width * hdr.height * (hdr.bpp / 8));

assert(buf);

fread(buf, hdr.width * hdr.height * (hdr.bpp / 8), 1, f);

fclose(f);

CImage* ret = (CImage*)malloc(sizeof(CImage));

ret->width = hdr.width;

ret->height = hdr.height;

ret->pixels = buf;

printf("m2dLoadImage: Loaded %s %ix%i\n", fileName, ret->width, ret->height);

return ret;

}

И попробуем вывести картинку:

m2dInit();

test = m2dLoadImage("test.tga");

test2 = m2dLoadImage("habr.tga");

while(1)

{

m2dClear();

m2dDrawImage(test, 0, 0, 1.0f);

m2dDrawImage(test2, tsX - (test2->width / 2), tsY - (test2->height / 2), 0.5f);

m2dFlush();

}

Не забываем про порядок пикселей в TGA (BGR, вместо RGB), меняем канали b и r местами в pixelAt и наслаждаемся картинкой на большом и классном IPS-дисплее:

Производительность отрисовки не очень высокая, однако если оптимизировать код (копировать непрозрачные картинки сразу сканлайнами и убрать проверки в инлайнах), то будет немного шустрее. Google для подобных целей сделали собственный простенький софтрендер —libpixelflinger.

Есть вариант для быстрой и динамичной графики: использовать GLES, который без проблем доступен и из recovery. Однако, насколько мне известно (в исходники драйверов посмотреть не могу), указать фреймбуфер в качестве окна не получится, поэтому в качестве Surface для рендертаргета у нас будет служить Pixmap (так называемый off-screen rendering), которому нужно задать правильный формат пикселя (см. документацию EGL). Рисуем туда картинку с аппаратным ускорением и затем просто копируем в фреймбуфер с помощью memcpy.

❯ Обработка нажатий

Однако, ни о каких GUI-программах не идёт речь, если мы не умеет обрабатывать нажатия на экране с полноценным мультитачем! Благо, даже механизм обработки событий в Linux очень простой и приятный: мы точно также открываем устройство и просто читаем из него события в фиксированную структуру. Эта черта мне очень нравится в архитектуре Linux!

Каждое устройство, которое может передавать данные о нажатиях, находится в папке /dev/input/ и имеет имя вида event. Как узнать нужный нам event? Нам нужен mtk-tpd — реализация драйвера тачскрина от MediaTek (у вашего чипсета может быть по своему), для этого загружаемся в Android и пишем getevent. Он покажет доступные в системе устройства ввода — в моём случае, это event2:

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

// Open input device evDev = open(INPUT_EVENT_TPD, O_RDWR | O_NONBLOCK);

После этого, читаем события с помощью read и обрабатываем их. На устройствах с резистивным тачскрином, передается просто ABS_POSITION_X, на устройствах с поддержкой нескольких касаний — используетсяпротокол MT. Когда пользователь нажал на экран, посылается нажатие BTN_TOUCH с значением 1, а когда отпускает — соответственно BTN_TOUCH с значением 0. Разные драйверы тачскрина используют разные координатные системы (насколько я понял), в случае MediaTek — это абсолютные координаты на дисплее (вплоть до ширины и высоты). На данный момент, я реализовал поддержку только одного касания, но при желании можно добавить трекинг нескольких нажатий:

void m2dUpdateInput()

{

input_event ev;

int ret = 0;

while((ret = read(evDev, &ev, sizeof(input_event)) != -1))

{

if(ev.code == ABS_MT_POSITION_X) tsState.x = ev.value;

if(ev.code == ABS_MT_POSITION_Y) tsState.y = ev.value;

if(ev.code == BTN_TOUCH) tsState.isPressed = ev.value == 1;

}

tsState.cb(tsState.isPressed, tsState.x, tsState.y); }

Теперь мы можем «возить» логотип Хабра по всему экрану:

void onTouchUpdate(bool isTouching, int x, int y) {

if(isTouching)

{

tsX = x;

tsY = y;

}

}

int main(int argc, char** argv) {

printf("Test\n");

m2dInit();

test = m2dLoadImage("test.tga");

test2 = m2dLoadImage("habr.tga");

printf("Volume: %i %i\n", vol, muteState);

m2dAttachTouchCallback(&onTouchUpdate);

while(1) {

m2dUpdateInput();

m2dClear();

m2dDrawImage(test, 0, 0, 1.0f);

m2dDrawImage(test2, tsX - (test2->width / 2), tsY - (test2->height / 2), 0.5f);

m2dFlush();

}

return 0;

}

В целом, это уже можно назвать минимально-необходимым минимумом для взаимодействия с устройством и использованию всех его возможностей на максимум без Android. Более того, такой метод заработает почти на любом устройстве, в том числе и китайских NoName, где ни о каких исходниках ядра и речи нет. Теперь вы можете попытаться использовать ваше старое Android-устройство для чего-нибудь полезного без необходимости изучать API Android.

❯ Звук, модем и другие возможности

Для звука нам придётся использовать ALSA — поскольку эта подсистема звука сейчас используется в большинстве устройств на Linux. Судя по всему, тут есть режим эмуляции старого и удобного OSS, поскольку устройства /dev/snd/dsp присутствует. Однако, вывод в него какого либо PCM-потока не даёт ничего, поэтому нам пригодится ALSA-lib.

Другой вопрос касается модема и сети. И если Wi-Fi ещё можно поднять (wpa_supplicant можно взять из раздела /system/), то с модемом будут проблемы — нет единого протокола по общению с ним и кое-где, чтобы его заставить работать, нужно будет немного попотеть. Не стесняйтесь изучать исходники ядра (MediaTek охотно делится реализацией вообще всего — там и RIL, и драйвер общения с модемом) и смотреть интересующие вас фишки!

❯ Заключение

Как мы с вами видим, у старых девайсов все еще есть перспективы стать полезными в какой-либо сфере даже без Android на борту. На тех устройствах, где нет порта Ubuntu или обычного десктопного Linux, всё равно сохраняется возможность писать нативные программы и попытаться приносить пользу.

Не стесняйтесь лезть и изучать вендорские исходники — это даёт понимание, как работают устройства изнутри. Собственно, благодаря такому ежедневному копанию исходников системы и появилась данная статья! :)