Тестирование геолокации в Badoo: шишки, камни, костыли и селфи-палка
Вроде бы о тестировании мобильных приложений есть уже тысячи материалов, так что удивить тут сложно. Но пока аспекты вроде UI уже затёрты до дыр, про тестирование геолокации рассказывают гораздо реже. И когда на нашей конференции Heisenbug Николай lamamer Козлов и Александр z3us Хозя (Badoo) поделились своим опытом, зрителей конференции доклад очень заинтересовал. Как и геолокацию получить, и телефон пользователю не разрядить? Зачем в этом тестировании селфи-палка? Насколько близко расположены лондонские пабы и что из этого следует?
Мы решили, что аудитории Хабра он тоже может быть интересен, и выкладываем его сразу в двух версиях: для любителей посмотреть видеозапись, а для любителей читать под катом текстовая версия.
Вступление
Александр Хозя:
Давайте сначала познакомимся. Меня зовут Александр Хозя, в компании все называют по фамилии «Хозя», я к этому привык, можете тоже ко мне так обращаться. Я заведую всем ручным мобильным тестированием в компании Badoo, не люблю все мобильные операционные системы примерно одинаково, и сегодня буду говорить про iOS.
Николай Козлов:
Меня в компании по фамилии зовут «Козя», я тоже к этому привык. Обожаю гаджеты, особенно на операционной системе Android и вообще Unix-подобные. Не люблю iOS: имею Apple Watch и iPhone только чтобы понимать, насколько ненавижу их хороший сервис и качество обслуживания.
Немного о нас. Наверное, вы уже знаете, что Badoo — это сервис для поиска новых знакомств. У нас более 360 миллионов пользователей (из них 60 миллионов активных в месяц), и порядка 300 000 регистраций в день. Они генерируют 350 миллионов сообщений в день.
Что касается непосредственно нашего доклада. Чтобы вы понимали объем данных, который приходится обрабатывать нашим бедным серверам: наши пользователи в день генерируют порядка двух миллиардов координат. Эти два миллиарда генерируют около 10 миллионов «пересечений» — о том, что такое пересечения, расскажем чуть-чуть позже.
При этом все, что мы описываем далее, возможно только с тестовыми пользователями. Доступа к данным реального пользователя у нас нет, за исключением случая проверки какой-то аномалии или бага, и даже в этом случае нужно разрешение самого пользователя на данное действие.
Так вот, о чем сегодня мы поговорим:
- Чем полезна геолокация
- Об инструментах, которые позволяют сохранить семь килограммов нервных клеток (как видите по мне, экономятся хорошо)
- Об энергопотреблении при использовании геолокации и его оптимизации
- О том, почему необходимо работать в поле и выходить туда
- Ну и поскольку конференция о тестировании, конечно же, поговорим о багах
Чем полезна геолокация
Давайте для начала вспомним, что вообще такое геолокация, с чем ее едят, и как она работает в современных девайсах.
Исторически она появилась в iOS с релизом версии 2.0 в 2008-м, и тогда ваш телефон научился «вычислять по IP». Проблема была в то, что Geo IP дает низкую точность: в лучшем случае это будет улица, а в случае с мобильным девайсом обычно страна, потому что IP-адреса в большинстве случаев плавающие (у оператора в каждом регионе свой диапазон адресов, который зачастую никак не привязан географически).
В дальнейшем инженеры решили воспользоваться так называемым Cell ID. Принцип работы достаточно прост: мы знаем местоположение базовых точек в пространстве, и зная уровень сигнала от этих точек, можем примерно определить расстояние до них. Дальше рисуем большое количество кругляшков, и где-то в области наложения всех окружностей оказывается пользователь. Точность уже возросла: в небольших городах это 1000 метров, а в городах вроде Москвы, где базовых станций намного больше — это 60 метров. А при использовании Wi-Fi, Bluetooth и других beacon можно повысить точность до 10 метров, что очень удобно: не надо использовать следующую систему, которая называется GNSS, или глобальная навигационная спутниковая система.
Почему я говорю не «GPS»? Потому что на рынке навигационных систем существует несколько игроков. Основные — это GPS, GLONASS, китайская BeiDou и европейская Galileo. Кроме того, существуют две региональные навигационные системы — индийская IRNSS и японская QZSS («Квази-зенитная навигационная система»). Почему систем так много? Все системы двойного назначения, при необходимости в определенных случаях можно их отключить. Также некоторые системы нужны, чтобы уточнять местоположение, потому что в Индии и Японии есть известное смещение спутников GPS, которое нужно все время высчитывать, это лишняя головная боль. Японцы любят точность, и после введения QZSS достаточно всего лишь двух спутников, чтобы точность составила в худшем случае 10 сантиметров, а в лучшем случае один сантиметр.
При этом главная проблема всех навигационных систем — это холодный старт. У девайса, который только что был выпущен с завода и еще ни разу не получал геолокацию, при самом первом запуске холодный старт без A-GPS составит 15 минут: 12 с половиной минут он будет качать атлас звездного неба, и еще две с половиной минуты уйдут, чтобы получить сигналы со спутников. Это большая проблема, и поэтому придумали систему A-GPS: используя Geo IP и Cell ID, телефон быстренько определяет примерное местоположение и посылает это на специальный сервер, который отдает атлас. А через 2–3 минуты (в большинстве случаев даже меньше) телефон быстро находит спутники, и показывает вам, где вы находитесь, очень удобно.
Теперь давайте поговорим, для чего вообще нужна геолокация. Прежде всего — для персонализации контента.
Если ваш продукт — система навигации, и вы не используете геолокацию, скорее всего, пользователи его использовать не будут. Если вы делаете какое-то рекламное приложение, тоже возможна персонализация: вы проходите мимо какого-то магазина, телефон это понял, и срабатывает push-уведомление, что именно сейчас в этом магазине для вас скидка 50%. В дейтинге геолокация тоже очень важна. Наши пользователи хотят видеть тех, кто находится в их городе, а желательно вообще как можно ближе. И не хотят видеть пользователей из других стран. При помощи геолокации мы решаем эту и много других задач.
Все улучшения, связанные с геолокацией, мы разрабатывали для сервиса «Пересечения», о котором Саша расскажет чуть позже. Я скажу лишь, чтобы было понятно, как это должно работать с точки зрения пользователей, логики. Но было совершенно непонятно, как получать как можно большее количество координат и геоданных при как можно меньшем энергопотреблении. Это был 2014 год, было много информации о том, как это все реализовывать на стороне клиента, но абсолютно не было информации о том, как это нужно тестировать. К сожалению, все приходилось находить самому, и самому создавать документацию с нуля. А теперь давайте поговорим, где и как мы пользуемся геолокацией.
Хозя:
Самый первый наш главный экран — это знакомства, где пользователя голосуют друг за друга. Как Коля уже говорил ранее, значительно интересней находить людей и общаться, когда они находятся рядом с вами, поэтому геолокация — это один из самых главных весов, по которому наш сервер выдает пользователей друг другу.
У нашего следующего экрана говорящее название «Люди рядом», где в самой первой секции вы видите людей, которые находятся максимально близко к вам. Если, конечно, вы дали нам доступ к нашим сервисам геолокации. Если не дали, то мы вас попросим ввести хотя бы город. Открываете профили пользователей и видите, что они находятся рядом с вами: допустим, Алена была на расстоянии 300 метров от нас.
На этом же экране мы как раз показываем пересечения, и настало время рассказать, как же это все работает. В теории не очень сложно: вы двигались и в определенный момент траектории движения вас и других пользователей либо пересеклись в конкретной точке, либо вы были максимально близко друг от друга (например в 20 метрах). Если вы пересеклись с одним пользователем, то мы генерируем персонализированный push. Проверяем, общались ли вы с этим пользователем, допустим, вы его лайкнули или переписывались, он вас добавил в избранное, и т.д. Отправляем персонализированный push, можно открыть его профиль, увидеть, что пересеклись примерно в таком-то местоположении (примерно для того, чтобы избавиться от всяких злобных редисок, которые захотят вас встретить в подворотне). Если вы пересеклись сразу с 3–4 людьми, мы вас приземляем на экран «люди рядом», и пользователи, с которыми вы пересеклись, помечены там специальной галочкой.
Также геолокацией можно поделиться в чате либо запросить ее, допустим, чтобы пользователь подошел к вам: вы находитесь в какой-то кафешке, отправили геолокацию, очень удобно.
А также в одном из наших побочных продуктов геолокация используется для чекинов. В принципе, плюс-минус Swarm, но про дейтинг. Допустим, вы ходите в один и тот же стейк-хаус, и вам интересно, кто еще туда ходит, чтобы пообщаться о стейках. Либо вы пришли в клуб, запустили приложение и видите, что в данный момент в клубе 24 человека. Как показывают наши данные, нахождение общего места повышает шанс получения сообщения примерно на 40%, что очень много. Также мы используем геолокацию в антиспаме.
Козя:
В первую очередь, мы затрудняем триангуляцию нашими пользователями других пользователей. Дальше мы, используя геолокацию, можем определить, что пользователей резко сменил свое местоположение, и тут может быть два случая. Либо сработал антиспам, пользователь решил переместиться в другую страну, и докучать других пользователей, либо у пользователя угнали аккаунт в хакеры из другой страны. Мы в таких случаях принимаем меры.
Помимо этого, для сервиса пересечений мы разработали так называемый «Режим таксиста». Люди, которые постоянно двигаются по городу с включенным навигатором, генерируют очень много точных геоданных. Понятное дело, что у них будет много пересечений. Чтобы эти пользователи не примелькались и не докучали другим пользователям, у них пересечения генерируются по специальному алгоритмам с более жестокой фильтрацией.
Мы поговорили, чем хороша геолокация, где мы ее используем, давайте поговорим о другой проблеме, а именно проблеме сбора геоданных.
Сбор геоданных
Это временной график, и от момента старта вашего приложения до момента получения геолокации с заданной точностью может пройти время. Чтобы получать геолокацию быстрее, придется дополнительно использовать неэкономичные с точки зрения аккумулятора датчики — барометр, гироскоп и т.д. Но даже при использовании всех возможных датчиков, которые есть на девайсе, нет гарантии получения точности заданных координат.
Давайте почитаем определение точности непосредственно в документации Google: «Точность — это радиус вокруг точки, внутри которого с вероятностью 68% находится пользователь».
Или, проще говоря, с вероятностью 68% мы находимся прямо сейчас где-то здесь.
А можем и не находиться. Как вы видите, пришло две точки, и расстояние между ними намного меньше, чем точность, которую они выдают. С такими геоданными тоже необходимо уметь работать.
Так вот, геоданные зависят от времени, и могут не прийти вообще, это нужно уметь обрабатывать. Давайте поговорим, как тестировать сборку и отсылку локаций, не выходя из офиса, на самых ранних этапах: когда нужно проверить, что ваша система вообще умеет хотя бы как-то принимать геолокацию.
Для этого разумно использовать простейшие средства, например, эмулятор Android очень простой. В режиме эмуляции локации содержит простейшие вещи, такие как эмуляции самой локации, и загрузка GPX-маршрута, о которой Саша попозже расскажет.
Любопытно, что дефолтная локация Android-эмулятора — деревня Далвик в Исландии. Dalvik — это виртуальная машина в Android до версии 5.0.
С другой стороны, на iOS почему-то, я сам не понимаю почему, симулятор намного богаче.
Хозя:
Да, действительно так. Обычно Apple очень дружественен к пользователям, но у инженеров вызывает огромную попаболь. Однако в этом случае в Apple подумали о нас, и нам доступны целых 3 варианта движения: пробежка, поездка на велосипеде и езда по трассе.
Удобно это тем, что система возвращает нам все необходимые данные о самой координате, скорость, вектор движения, горизонтальную и вертикальную скорость, а в некоторых случаях даже этаж. Видите, нулевой. Очень удобно для тестирования геолокации, не выходя из офиса.
Единственное, что иногда, если вы свернете приложение в бэкграунд, система не будет присылать вам координат вообще. Это баг либо Xcode, либо симулятора, либо самой macOS. Чтобы это победить, нужно будет либо убить Xcode, либо симулятор, а если ничего из этого не помогло, то перезагрузиться. Но если вы запустили симулятор и у вас все работало, а потом после каких-то манипуляций перестало, скорее всего, это все-таки баг в вашем приложении.
Следующее, что мы используем — наша «любимая» среда разработки Xcode. Подключаемся дебаггером либо к симулятору, либо к реальному девайсу (это важно, немногие знают, что на реальном iOS-девайсе можно симулировать геолокацию), нажимаем на синюю стрелку, либо в меню выбираем Debug > Simulate locations, и видим выпадающий список с точками, которая Apple добавила — Москва, Лондон и т.д. Но нас интересует кнопка «Add GPX File to Workplace» в самом низу, которая позволяет добавить GPX маршрут.
Чтобы его сгенерировать, я рекомендую пользоваться Maps to GPX converter. На вход он принимает трассу из Google Maps — как полную URL, так и сокращенную. На выходе генерирует вам GPX-файл: на самом деле, это просто подмножество XML со временем и точкой в пространстве, дальше система сама интерполирует все это дело. Этот GPX-файл совместим с Android, iOS и Windows Phone, GPS-трекерами и т.д.
На самом деле этот инструмент был создан во времена бума Pokemon Go, спасибо им за это, очень сильно облегчило нам тестирование. Единственное, что если мы сгенерируем этим инструментом GPX-файл, система не будет определять скорость движения на iOS, поэтому, если вам нужно знать именно скорость, лучше использовать симулятор.
Давайте теперь поговорим про зеленое ведерко.
Козя:
Так как мы заметили, что эмулятор не такой богатый, как симулятор iOS, мы воспользовались тем, что мы можем поставить любое приложение без ограничений.
Первое приложение, которым я рекомендую воспользоваться — это Lockito, очень удобное, фактически заменяет вам симуляцию тех трасс, которые есть у Apple. Смысл в чем: вы запускаете приложение, указываете точки в пространстве, тип перемещения между этими точками (будь то по прямой или каким-то видом транспорта) и параметры выдачи координат, скорости и т.д. Запускаете симуляцию, после чего просто смотрите в вашем приложении, как вы вроде бы двигаетесь в пространстве.
Второе приложение — GPS Status & Toolbox. Чем удобен: его можно запустить в многооконном режиме, и посмотреть, как ваше приложение выглядит на маленьких девайсах, непосредственно на вашем большом девайсе. Ну и показать, что выдает система геоданных вашего девайса, что получает ваше приложение, и сравнить это. Если вы попали в какую-то аномальную зону, когда ваше местоположение не соответствует реальному местоположению (например, вас вдруг перебросило во Внуково), можете использовать GPS Test, чтобы понять, почему так произошло.
Учтите, что при использовании Lockito надо уметь пользоваться Location Mock, если ваше приложение пользуется библиотеками, которые решают за вас задачу использования каких-либо источников геоданных, о которых я говорил дальше. И если у вас в Android по умолчанию включены все источники геоданных, то вас будет часто перебрасывать при симуляции обратно в точку, где вы находитесь на данный момент. С чем это связано: любое приложение, которое эмулирует локацию, эмулирует только подсистему GPS, поэтому в настройках надо переключить такие источники данных, как GPS-данные, и все будет хорошо.
Давайте немножко резюмируем: мы поняли, что Maps to GPX-конвертер — это очень хорошо, можно загрузить одновременно GPX-файл на разные девайсы, и посмотреть, как различные операционные системы будут обрабатывать одинаковые маршруты. Ну и из коробки iOS, к сожалению, побогаче Android, зато Android зеленый, красивый и вообще лучше!
Теперь мы поняли, что наша система принимает данные. Теперь надо понять, что что-то хоть как-то работает, то есть начинать тестировать бизнес-логику.
Тестирование бизнес-логики
Для начала мы столкнулись с тем, что наша бизнес-логика была слишком большая, и мы не могли удержать все в голове. В чем была проблема: у нас было большое количество файлов, фич и классов, отвечающих за ту или иную систему обработки локаций. Чтобы снизить интервалы обработки геоданных или расстояние между получением координат, нужно было это все искать, менять, собирать приложение, и мы могли что-то пропустить, потому что в голове все не удержишь.
Для этого мы создали удобный файл конфигурации. Вот пример файла конфигурации на iOS, где вы просто можете поменять все необходимые данные, с вашим любимым Xcode собрать приложение и начать им пользоваться.
Хозя:
Следующая проблема, с которой мы столкнулись — это информационный шум, потому что без доказательств существования багов (допустим, скриншотов и логов), разработчик зачастую может даже не понять, в какую сторону начинать копать. При тестировании геолокации это усугубляется тем, что в уравнении очень много переменных. Там не то что баг сложно воспроизвести, там иногда получить дважды подряд тот же самый набор координат с заданной точностью не представляется возможным. Поэтому без этих логов тестирование может создать больше информационного шума, чем реальной пользы, вы будете просто отвлекать ваших девелоперов.
Также, будем реалистами, зачастую разработчики добавляют логи для себя. Но даже если они добавляют логи для тестирования, зачастую они не знают, что нам нужно. Поэтому в нашем случае мы видели только координаты, которые отправляли на сервер. Поговорили с командой и решили, что же нам нужно от хороших логов, давайте с вами об этом тоже поговорим.
Для начала нужно понять, в каком режиме была зарегистрирована координата, Это может быть либо background, когда приложение в фоне или убито, либо foreground, когда вы видите UI приложения.
Дальше нам нужно понять, как она была получена: напрямую от GPS, или от каких-то других провайдеров, о которых мы поговорим немножко позже, или система могла сама запушить нам координаты, если мы используем то или иное API (допустим, geofencing, visits API или significant location change API на iOS).
Дальше нужно залогировать все, что можно о координате: точность, высота, скорость, вектор движения, время получения вплоть до миллисекунд. Это тоже очень важно, зачастую координаты измеряют свою точность скачкообразно с разницей в несколько миллисекунд. И любая другая информация, которая облегчит вам жизнь: например, как пользователь двигался (прыгал, бегал, ехал на велосипеде, плыл на лодке), включен или выключен Wi-Fi и т.д.
Ну и, наконец, нам нужно понять, по какому принципу мы будем все эти координаты отправлять.
Если у вас простая бизнес-логика, то это будет просто по таймеру, допустим, каждые 30 минут. Иначе это могут быть какие-то другие условия: либо описанная вами бизнес-логика, либо приложение было убито и затем оживлено. Оно может быть убито out of memory killer, вы могли сами его убить, или оно могло просто закрашиться. Оживить его может пуш-нотификация или какой-то API. Раз уж вы умерли и оживились, то будьте добры зарегистрировать и отправить координату на сервер.
Ок, мы собрали эти координаты и отправили на сервер, но почему-то не получили ожидаемого результата: или не пересеклись, или не зачекинились где-то. Идем ногами к нашим разработчикам, спрашиваем, что же не так. Клиентские разработчики говорят, не знаем, давайте пойдем к серверным разработчикам. Идем к ним, они помедитировали на PHP-код, поселектили в базе, сказали в чем проблема. В общем, мы сходили к ним пару раз и очень быстро их этим утомили, поэтому они сделали нам на основе собираемых логов очень удобную веб-страничку, где видим все наши передвижения, наложенные на гугл-карту:
Можно рассматривать с увеличенным уровнем зума на большом мониторе, вместо того, чтобы делать это на девайсе. Это помогло нам найти объяснения всяким странным ситуациям, происходящим в реальной жизни, когда мы думали «мы здесь», система определила, что мы находимся в другом месте. Иногда это делаем мы сами по какой-то ошибке, а иногда так находили баги на сервере, когда он неправомерно те или иные координаты отфильтровывал. В этом инструменте удобно, что отметки на карте закодированы цветами, и они показывают, почему та или иная локация невалидная (слишком часто регистрировалась/отправлялась, точность у нее низкая, либо что-то с ней не так). В общем, логи — это сила, рекомендую.
Козя:
Логи — это сила, мы поняли, что с хорошими логами можно доказать, что это реально баг, а не фича, или же она воспроизводится, и взять девелопера за… c поличным :) Давайте поговорим, как сэкономить 7 кг нервных клеток. Мы с Сашей любим экономить нервные клетки, поэтому такие большие и красивые, кто из нас большой, а кто красивый — решать вам.
Именно debug menu сэкономило нам дополнительно семь килограммов нервных клеток. На Android меню простое. А если вдруг вам нужна более подробная информация, можете установить инструмент GNSSLogger от Google и получить еще больше дополнительной информации о том, как работает спутниковая навигационная система, вплоть до значений интерференции атмосферы в данной точке пространства. Я не знаю, зачем вам это надо может быть, нам это не надо, поэтому мы сделали простейшее меню. Вы можете видеть все о текущей локации, посмотреть карту перемещений, того, как вы перемещались. Очень удобный инструмент в субботу с утра, чтобы понять, что вы делали в пятницу вечером! Также есть система логирования, где записаны логи, ну и какие-то дополнительные инструменты: например, переключить систему геолокации с фейковой на настоящую, отправить логи на компьютер для дальнейшего их изучения, очень удобно, очень просто.
На iOS меню поприкольнее, но это же iOS.
Хозя:
У нас немножко посложнее, и мы его делали в один заход, в отличие от Android, где делали итерациями. Потому что мы сразу знали, что на iOS все плохо, и нам нужна вся эта информация! Самая первая переключалка, которой мы особенно гордимся — это локальные уведомления о работе location manager.
То есть вы можете свернуть приложение, убить, залочить девайс, но как только что-то изменится, вы получаете уведомление. Не то что не надо заходить в debug-меню и смотреть логи, а даже приложение не нужно запускать: девайс автоматически включает экран, когда вам приходит уведомление, это очень удобно. Так же чуть ниже у нас есть два набора координат: это последняя известная локация, и последняя отправленная, тоже для нашего удобства.
А также есть вьюшка с Apple-картами, на которых мы строим наши трассы движения, по той же причине, что и объяснял Коля: соединяем две точки и смотрим, были ли мы там. На ней есть интересный пин, который показывает временной промежуток. Чтобы его увидеть, необходимо воспользоваться Visits API, которая доступна с версии iOS 8, то есть уже достаточно долго. С точки зрения системы это работает достаточно хитро, потому что система за нас определяет, зашли мы в какую-то точку или вышли. Мы зашли куда-то, и примерно через пять минут нахождения там система понимает: «ага, мы, наверное, куда-то зашли», посылает нашему приложению уведомление, что в такое-то время вы зашли в точку с такими координатами. После того, как мы вышли, тоже примерно через пять минут она посылает точно такое же уведомление про выход. Соответственно, мы знаем, что провели там, допустим, 45 минут. Для функционала пересечения просто великолепно: вы сидите и пьете кофе, мимо вас проходит огромное количество людей, вы с ними пересекаетесь. Просто великолепная API, жаль, что она не появилась с самой первой версии нашего сервиса. Мы его делали еще под iOS 7.
Все наши координаты, которые мы записываем, закодированы цветами, чтобы можно было быстро глазами пробежаться и понять, как она была зарегистрирована: белым цветом координаты в foreground, серым background, фиолетовым visit.
Мобильный тестировщик, поэтому и мобильный, потому что мы все свое носим с собой. В большинстве случаев нам этого debug-меню было достаточно, но основная проблема мобильных девайсов — это наличие аккумулятора.
Энергоэффективность
Козя:
И чем более энергоэффективно ваше приложение, тем дальше от розетки вы можете отойти. Напомню, это был 2014 год, было мало информации и о том, как тестировать энергопотребление, и о том, как правильно тестировать геолокационные сервисы.
Давайте поговорим об общих методах, которые мы нашли в первую очередь. Для начала мы воспользовались Power Meter. Это простейший девайс: с одной стороны он подключается к источнику энергии, с другой стороны подключается дата-кабель, к нему — ваш девайс, и показывает ток. А вот то, какой ток он показывает — это проблема.
Есть два случая. Первый: если ваш аккумулятор не заряжен, он показывает ток заряда, который потребляет ваш телефон, чтобы зарядить ваш аккумулятор. Это не совсем репрезентативные данные.
А если ваш телефон все же заряжен, то вы опять же не видите реального тока (за исключением Android, попозже расскажу). Потому что телефоны настроены таким образом, что если есть внешний источник подключенной энергии, то они выполняют еще синхронизацию, обновления приложений, а в последней версии Android еще и код компилируют за вас. Тоже нерепрезентативно.
На андроиде вы можете отключить внешнее питание программно, тогда Power Meter будет, возможно, показывать верные данные. На iOS это невозможно.
Также существует специальный метод Яндекса, о котором здесь, на Heisenbug, тоже есть доклад от парней из Яндекса. Но нам, к сожалению, этот метод не подошел, потому что мы не измеряем энергопотребление после каждого коммита, а двигаемся в разных режимах. Парни, простите, реально неудобно ходить на улицу с девайсом, у которого раскурочена задняя крышка, и подключена коробочка с Arduino, которая подключена к ноутбуку. Меня на улице, по меньшей мере, не поймут!
Давайте поговорим о методах измерений непосредственно на девайсах. Первым делом поговорим об Android, потому что он на букву А.
Самое первое, что можно сделать на Android — это зайти в настройки энергопотребления, и посмотреть, что вообще творится. Если вам жутко не повезет, то вы увидите ваше приложение в месте, которое называется «топ», где видно самое энергопотребляемое приложение. Хотя, понятное дело, если вы постоянно пользуетесь вашим приложением, то оно появится в топе в любом случае, просто потому что вы им так много пользуетесь.
Зайдя в расширенную информацию энергопотребления на последних версиях Android, вы можете видеть очень много полезной информации: использование CPU в foreground, в background, использование датчиков (например, GPS), и т.д.
Почему здесь дополнительно есть Google Play Services? Одно и то же приложение на разных версиях Android будет иметь различное энергопотребление: до Android 8.0 ваше приложение при использовании Google Play Services вызывало энергопотребление этих «сервисов», а не ваше энергопотребление. К восьмой версии Google понял, что пользователи слишком много жаловались на «выжирающие батарейку Google Play Services» и сказал: «Хорошо, теперь любое энергопотребление, которые было вызвано вашим приложением, идет обратно к вам». И вы видите свое реальное энергопотребление, поэтому поставьте восьмерку и ужаснитесь или обрадуйтесь.
Следующий метод, который мы начали использовать — это Test Fairy, библиотека-sandbox, встраиваемая в ваше приложение и записывающая большое количество данных. Мы используем ее в случае с бета-пользователями, они получают за это всяческие плюшки вроде бесплатных кредитов, а мы получаем от них большое количество данных.
Одни из этих данных — это энергопотребление, но и здесь не все гладко. У пользователя сессия в основном 1–2 минуты, потом она закрывается, начинается новая, и изменение аккумулятора за этот период не такое уж интересное, оно вообще может равняться нулю (шкала там не в мАч, а в процентах, и на современных девайсах с аккумуляторами 3000+ мАч один процент довольно велик). Или же у пользователя может быть длинная сессия, как этот пользователь с 22-минутной сессией, но его телефон был подключен к источнику энергии, поэтому мы ничего не видели. Остальных пользователей, у которых реально происходит разряд, настолько мало, что данные просто не поддаются толковому анализу.
Следующий инструмент, который я начал использовать сразу же, как только он вышел — это Battery Historian. Спасибо компании Google, уникальный инструмент, является фактически «дактилоскопом» для определения, кто все-таки и когда жрал батарейку. Даже если вы не исследуете свое приложение, вы можете увидеть, какие другие приложение и почему ели батарейку.
Здесь видите, что я выбрал момент времени, кликнув на график, вижу, что наше приложение было активным 3 минуты. Вижу, какие сенсоры использовало, какие сервисы, и особенно это помогает при исследованиях энергопотребления: позволяет понять, геолокация ли жрет приложение. Бывает, что developer просто создал infinite loop и забыл сделать из него выход. Всякое бывает.
Для того, чтобы дополнительно прикрыться с тыла, мы используем мониторинг. У нас очень сильная команда мониторинга, и помимо всех метрик, они по нашей просьбе еще мониторят энергопотребление наших пользователей, и после релиза мы можем видеть тренд и оперативно реагировать на него.
Система работает очень просто, мы два раза посылаем ивенты о заряде аккумулятора: один раз, когда приложение стартует, а второй раз, когда приложение сворачивается или убивается. Мы на основе этого строим тренды, очень удобно, очень полезно, и мы хорошо прикрыты. А на iOS все боль.
Хозя:
Как обычно, на iOS все классно для пользователей (не так легко выжрать батарейку, как на ранних версиях Android), но для инженеров большая печаль.
Мы начали с самого первого инструмента, то же самое: «Настройки» — «Аккумулятор». Инструмент в целом очень плохой, у него есть всего один плюс: показывает, сколько ваше приложение работает в бэкграунде. Для нас это важно, потому что мы собираем и отправляем геолокацию в том числе в фоновом режиме.
А дальше начинаются боль и страдания. Инструмент очень инерционен, обновляется примерно раз в час. Поэтому, если ваше приложение 5 минут работает нормально, а 55 жрет батарейку, как не в себя, вы этого не видите. А если вы захотели заресетить два девайса, поставить на них два разных билда и сравнить их по энергопотреблению, то мало того, что первый результат увидите через час, так если не запустите три или более приложения, вы вообще ничего не увидите, и еще раз отложите все на час.
Следующий инструмент — это Energy impact шкала в Xcode. Подключаетесь дебагером к вашему приложению, нажимаете третью ячейку сверху и видите шкалу, которая изменяется в реальном времени: от зеленой зоны, где не потребляете энергии, до красной, где жрете, как не в себя.
Чуть ниже показано, почему потребляется: допустим, CPU загружен на 100%, или вы не даете системе заснуть, или все время ее будите, или забыли погасить GPS после того, как он не нужен. Но без разработчика с этим разобраться достаточно сложно: например, потому что при запуске вы будете жрать CPU потому что надо запустить приложение и прогрузить данные, у вас будет включен GPS, чтобы отправить локацию на сервер и получить людей рядом с вами, и еще будете скидывать кэш на диск. Нормально это или ненормально, черт его знает. Поэтому мы разработали сет кейсов и прогоняем с разработчиками после каждого большого рефакторинга.
Следующий инструмент — это настройки энергопотребления в вашем айфоне: заходите в «Settings — Developer — Instruments», включаете запись энергопотребления и работы с сетью. Работа с сетью опять нам пригодилась, потому что мы отсылаем эти координаты на сервер.
Но инструмент, опять же, не очень, потому что он пишет данные обо всей системе, между приложениями что-то сра
