Оптимизация Android приложений под х86. Опыт 2GIS

Наверное, читателям Хабры не имеет смысла представлять 2ГИС – российский геосервис, ставший важнейшим источником информации для жителей многих городов нашей (и не только) страны. Разработчики сервиса уделяют большое внимание мобильным приложениям — продукт доступен для различных мобильных ОС и входит в число лучших бесплатных приложений в категориях «карты», «навигация» на Google Play и App Store.
Мобильные устройства с ОС Android на базе x86 возможно, пока известны чуть менее, чем 2ГИС, но с постоянным увеличением ассортимента, их известность растет.
Мы пригласили 2ГИС в гости в блог Intel, чтобы задать им несколько вопросов об оптимизации мобильной версии программы под архитектуру х86. Ответы подготовил Сергей Галин — Руководитель команды разработки мобильного 2ГИС.

Как устроено ваше приложение с точки зрения использования нативного кода? Т.е. насколько велик его процент, что именно делается нативно и почему?
Наше приложение для Андроида работает в нативном коде на 99% — т.е. абсолютно всё, кроме процесса старта приложения и работы с API Android. Включая рендеринг всего пользовательского интерфейса «собственными силами», не используя для отрисовки функций операционной системы. Это кроссплатформенное приложение на базе Qt 4.8 (порт на Android — наш собственный). Так получилось исторически, поскольку разработка начиналась для Symbian и Windows Mobile, потом захотелось добавить Android (на тот момент Android 2.2). Впрочем, с учётом «тяжести» нашего приложения, которое в реальном времени рисует 3D-карту и работает с огромной оффлайновой базой данных подход Андроида «по умолчанию» с разработкой на Java просто бы не «вывез» — ни по быстродействию, ни по объёму требуемой оперативной памяти. В нативном же коде мы можем делать практически такое же функциональное приложение, как и на обычном настольном компьютере, и запускать это даже на бюджетом телефоне образца 2011 года.

Устраивает ли вас и ваших пользователей производительность существующих ARM версий приложений? Остается ли запас производительности для расширения функциональности?
Да, устраивает, для современных устройств и топов 2012 года 🙂 Бюджетные телефоны прошлых лет и даже более старые флагманы, к сожалению, работают на грани возможностей, и производительность в некоторых местах, действительно, оставляет желать лучшего. При этом, возможностей для оптимизации при данном функционале приложения для многих устаревших устройств практически нет.
Для нас будет очень хорошо, если Intel реально усилит конкуренцию и ускорит расширение пользовательской аудитории в сторону более мощных устройств!

Почему было принято решение о выпуске x86 версии?
Потому, что это было сделать действительно легко! И было не клёво, что на отличных устройствах с процессорами Intel приложение работает плохо.
Мы сейчас заняты, в числе прочего, планомерным расширением поддержки устройств и платформ, так что это хорошо вписалось в наши планы.
И спасибо Intel за предоставленные устройства, без них бы было сложнее сдвинуть тему с мёртвой точки 🙂

В чем именно состояло добавление поддержки х86 – сколько файлов \ строк кода потребовалось изменить?
Кода в приложении — практически нисколько. Была доработана конфигурация сборки Qt, чтобы она умела поддерживать x86. Пришлось ещё пропатчить макросы в паре третьесторонних библиотек, которые до этого были уверены, что «Андроид — значит, ARM». Потом были модифицированы наши сборочные скрипты для сборки x86 — это и заняло большую часть времени. Proof-of-concept был сделан за 1 день, а в целом на встраивание x86 в процесс затрачена примерно 1 человеко-неделя, не считая тестирования. Для такого огромного проекта это — очень быстро!
Дело ещё в том, что наша кодовая база используется и на десктопах, и на серверах, да и разработка самой мобильной версии в основном производится под обычными десктопными Linux и Windows (не в эмуляторе, а именно в обычной сборке для этих ОС — благодаря Qt, мы это можем делать очень легко), поэтому весь код изначально отлажен для x86.

Как технически реализована поддержка x86 и ARM версий = т.е. у вас отдельные apk или одна общая, как происходит компиляция (автоматически собираются обе версии или есть возможность выбора?) Тот же вопрос про тестирование.
Отдельные APK. Кстати, раз уж мы перешли на такую схему, то заодно мы внедрили пакеты, оптимизированные для ARMv7, итого, у нас стало 3 пакета: ARMv5, ARMv7 и x86.
Система автосборки собирает либо одну версию на выбор (для быстрого получения свежей сборки), либо все три сразу (для приёмочного тестирования и публикации).
Приёмочное тестирование обязательно проводится как минимум на двух платформах, а третья тогда может проверяться ускоренно («смок-тестирование»). Фактически, мы ещё ни разу не столкнулись с тем, чтобы какие-то баги были специфичны для какого-то CPU ABI 🙂 Андроид на x86 ведёт себя так же, как на ARM, никаких несовместимостей пока не обнаружено.

Что показывает сравнение производительности и энергопотребления x86 с ARM-версией, работающей на том же устройстве через бинарный транслятор?
Мы не делали численного сравнения, поскольку разница слишком велика. Поскольку наше приложение даже рисует UI само из нативного кода, то в режиме трансляции всё работало еле-еле, а энергопотребление просто зашкаливало — телефон разогревался, как печка. После компиляции 2ГИС «залетал», как следует — программа «упирается» уже в чтение данных из памяти и кадры экрана (vsync), а по мощности процессора теперь даже есть запас. Выигрыш и по быстродействию, и по расходу энергии по сравнению с транслятором — где-то на порядок.