Разработка мобильных приложений — это комплексная задача, особенно когда работаешь в среде с ограниченными ресурсами. На это накладываются и внешние условия рынка с огромным разнообразием устройств и вендоров, которые ведут постоянную борьбу: создают новые тренды и драйверы. Без кривых прошивок здесь не обходится.
Многие энтузиасты пытаются найти «серебряную пулю», чтобы после проверки приложения можно было заявить, что оно работает на любом устройстве — вне зависимости от характеристик и производительности. И хоть написать приложение под все телефоны в мире невозможно, мы в Selectel нашли способ, как к этому приблизиться.
Классические способы тестирования
Для начала рассмотрим типичные способы тестирования мобильных приложений и выделим их особенности.
- «Покупаешь телефоны, загружаешь свое приложение и тестируешь». Это самый простой подход, но сильно затратный для бюджета. Например, чтобы проверить мобильное приложение дополненной реальности, нужно закупить десятки телефонов с разными камерами и драйверами. И все равно может потом всплыть версия, на которой все «валится». Кроме того, эти устройства нужно утилизировать — об этом мы подробнее рассказали в отдельной статье.
- «Зачем вообще реальные устройства? Установил эмулятор — и в бой!» Это хороший способ, если нужно быстро протестировать базовый функционал и найти явные «мобильные баги». Разработчику не нужны большие средства на покупку телефонов. Кажется, что это оптимальный путь тестирования, но все ли так просто?
Что нужно учитывать
Не для всех тестов релевантны эмуляторы. Когда речь заходит о тестах на производительность, UI или на взаимодействие с «реальным железом» (например, камерой или антенной), лучше вернуться к модели «на столе». Но что делать, если телефонов 5, 10, 15 или еще больше? Если команда находится на разных концах города или даже страны, передача устройств может сильно затянуться.
Кроме того, часто бывают ситуации, когда performance critical-код необходимо писать на C/C++ (или другом компилируемом языке) и подключить к основному JVM-based приложению нативную библиотеку. Или пересобрать существующую под аппаратную платформу смартфона. В таких случаях без нативного кода не обойтись.
«Есть два типа людей. Первые — используют вставки из нативного кода или пишут приложения полностью на нем. Вторые — обходят его стороной».
Однозначно можно сказать, что нативный код используют и будут использовать, притом достаточно часто. Хороший пример — мобильные игры, которые сложно представить без нативного кода. Там он нужен, например, чтобы подключать библиотеки на C/C++ для обработки 3D-графики.
Решение — ферма мобильных устройств
Сегодня для сборки и прогона unit-тестов нативного кода используют эмуляторы целевой архитектуры — например, QEMU. Но они накладывают некоторые ограничения, в том числе из-за скорости трансляции кода под необходимую архитектуру.
Мы решили объединить лучшие практики из классических способов тестирования и создали ферму мобильных устройств. Теперь у клиентов есть возможность тестировать свои приложения на реальном железе и использовать наши инстансы на ARM-процессорах.
Ферма мобильных устройств — это инфраструктурное решение для удаленного тестирования и сборки приложений под Android. Имея доступ к большой базе смартфонов с различными параметрами (версиями OS Android, процессорами, диагоналями, производительностью и оболочкой), пользователь может проводить широкий набор тестов. Тем самым ускорить обнаружение багов и деплой в продакшен.
Входящий в этот бандл ARM-сервер значительно упрощает работу с нативным кодом. По нашим предположениям, мобильные приложения быстрее проходят unit-тестирования именно на целевой архитектуре.
Работа с устройствами из браузера, ферма мобильных устройств.
Функциональность фермы мобильных устройств
Вы можете загружать свои приложения, собирать логи, обрабатывать нажатия клавиш, производить запуск тестов на физических устройствах. Это лишь малая часть функциональности.
Ферма мобильных устройств, как она есть.
На данный момент ферма работает именно с устройствами на Android 4.0 и выше. Реализацию IOS-фермы с телефонами Apple мы решили пока не трогать, у них есть свои особенности и ограничения.
Как устроена ферма мобильных устройств
Схема фермы проста: специальный USB-хаб и «устройство-прослойка» объединяют телефоны в пул и подключают к ARM-серверу через выделенные свитчи. Весь трафик перетекает в рамках локальной сети.
Схема фермы мобильных устройств.
В качестве «прослойки» мы используем специальный софт, запущенный на Raspberry Pi, который объединяет мобильные телефоны в пулы, локальные парки и позволяет управлять ими прямо через браузер.
Ферма мобильных устройств, конфигурации.
Рассмотрим схему фермы мобильных устройств подробнее.
Устройства объединены с помощью USB-хаба
Чтобы физически подключить телефоны к малинке, нужен был специальный USB-хаб. Да не простой, а с дополнительным питанием, чтобы все устройства в бандле были постоянно заряжены и не теряли связь с сервером.
В итоге мы взяли HARPER HUB-10MB, и сейчас эта железка справляется со своей задачей. Она также позволяет легко выводить устройства из бандла. Для этого предусмотрен интерфейс для управления питанием отдельных портов.
Органайзер с USB-хабом |
Сервер с софтом, Raspberry Pi |
Ферма расположена в отдельном помещении
В наших серверных и технологических помещениях соблюдается строгая пожарная безопасность: мы используем проверенные средства пожарной защиты, не экономя на надежности инфраструктуры и качестве ОТВ. Высокий уровень защиты достигается за счет использования автономных центральных станций газового пожаротушения с веществом Хладон 125. Подробнее о противопожарных системах в дата-центрах мы рассказали в отдельной статье.
Не просто так размещение аккумуляторных батарей в серверных запрещено. И так как мы не можем разместить телефоны в общих серверных и сделать прямое подключение к ARM-серверу, нужно было придумать «финт ушами».
Самое очевидное решение проблемы — выделить отдельное изолированное помещение под мобильную часть фермы и подготовить его к нештатным ситуациям с аккумуляторами.
Так мы и сделали: подготовили отдельное помещение и разместили в нем мобильные устройства, а для соединения с ARM-сервером поставили роутер. Через него простирается локальная сеть до машины в серверной.
В серверной — машина на ARM
Мы полагаем, что приложения быстрее тестируются именно на целевой архитектуре. И так как весь мобильный мир построен на ARM, для фермы предлагаем использовать именно эту платформу.
В наших дата-центрах можно арендовать выделенный ARM-сервер с 128-ядерным процессором Ampere Altra. Мы его уже полностью протестировали, машина готова к работе. Но если вам нужен сервер на x86 — можем подобрать другую конфигурацию.
ARM-сервер в стойке.
Кому полезны фермы мобильных устройств
Давайте зарезюмируем и рассмотрим случаи, когда полезны фермы мобильных устройств.
- Вы работаете удаленно или не хотите размещать мобильные устройства в своем офисе. Ферма мобильных устройств расположена в дата-центре: не нужно самостоятельно поднимать и настраивать инсталляцию. Достаточно просто арендовать ферму и подключить свое приложение.
- Хотите тестировать приложения на реальных устройствах без затрат на обслуживание. Вам не нужно приобретать телефоны для единоразового тестирования — достаточно на время арендовать ферму. Это избавляет от лишних затрат на администрирование и проблем с утилизацией ненужных устройств.
- Ваше приложение использует библиотеки C/C++. Софт на базе C++ — это один большой и много маленьких бинарников для решения узких бизнес-задач, которые нужно портировать по отдельности. И gcc --arch=aarch64 работает тут почти никогда, поэтому особенно важно протестировать свое приложение на целевой архитектуре, если оно содержит нативный код. С этим поможет ферма мобильных устройств, в основе которой — ARM.
Возможно, эти тексты тоже вас заинтересуют:
→ Сравнили 80-ядерный ARM-процессор Ampere Altra с AMD EPYC и довольны результатом
→ Почему ARM? Перспективы платформы в серверном применении
→ Кто мощнее в базах данных? Сравниваем производительность БД на серверах с ARM- и x86-процессорами