Фейсбук мобильная: Справочный центр Facebook

Интеграция событий для iOS 14+ и запуск кампаний в Facebook для мобильных приложений — Маркетинг на vc.ru

2122 просмотров

Хочу поделиться очередным советом для User Acquisition менеджеров и владельцев приложений в рамках канала UA Insight.

Создание рекламных кампаний и настройка событий в приложении на iOS напоминает эстафету с кучей препятствий, которые так и нависают на каждом шагу. Если воронки web to app нет, приходится запускать стандартные iOS14+ кампании. Часто возникают различные проблемы, такие как «приложение уже откручивается с другого аккаунта», «не работает Value оптимизация», «не падают установки в статистику» и многое другое.

Начнем с первостепенной вещи, без чего невозможна никакая закупка — интеграция MMP (мобильной аналитики). Разберу на примере AppsFlyer, так как он чаще всего используются для iOS приложений.

1. Нужно установить SDK Facebook последней версии и добавить приложение в Events Manager. Почитать справку об этом можно тут.

2. В Appsflyer в разделе Integrated partners нужно добавить Facebook, далее в настройках ниже вписать App ID, который можно найти в разделе Settings в Event Manager.

3. В Appsflyer в том же разделе задайте соответствие ивентов. Советую все «денежные» события как покупка, подписка, триал прикинуть в fb_mobile_purchase, включая af_skad_revenue. Также включить передачу Value и Revenue для этих событий.

4. Задайте конфигурацию для SKAD. Раздел Configure App Events for SKAdNetwork в настройках ивент менеджера фэйсбука. Жмёте Edit Events и выбираете интеграцию с помощью трекера (AppsFlyer), из AF копируете URL для того, чтобы установить связь (в самом низу раздела Facebook).

5. Далее задайте приоритет событиям. Если основное событие покупка — можно разделить ее на 63 диапазона с различной ценностью, как на скрине ниже.

То есть максимальная покупка занимает самый высокий приоритет.

Это позволит нам запускать кампании с Value оптимизацией.

А теперь приступим непосредственно к запуску рекламных кампаний.

Их настройка осталась примерно такой же, как и до iOS14.5, но всё же есть кое-какие новшества, которые сложно не заметить:

• Максимальное количество рекламных кампаний — 9. В каждой до 5 групп объявлений.
• Возможен одновременный запуск только с 1 рекламного аккаунта
• Установки падают не сразу, а обычно на 3ий день работы рекламной кампании
• Фэйсбук рекомендует ставить бюджет такой, чтобы достигать 128 установок в сутки на рекламную кампанию. Якобы он быстрее обучится благодаря этому. Частично согласен, чем больше бюджета на кампанию, тем больше шансов на успех, если уверены в креативах.
• Если лишь 8 слотов для приоритизация ивентов. Value занимает до 4 слотов.
• Практически после любых серьёзных изменений нужно ждать 72 часа для запуска рк (в частности касается лимита на кампании, после остановки 9ой кампании подождите 72 часа и потом фб даст залить новую)
• В 9 из 10 проектов, где пробовал iOS14+ кампании, они работали хуже самого простенького Web2App лендинга (одностраничный сайт, созданный для рекламы приложения)

Какие кампании стоит попробовать запустить:

1. AAA (Automated App Campaigns)

Если еще не пробовали (ха-ха, конечно не пробовали) — обязательнопопробуйте запустить кампании с оптимизацией на Purchase, а так же Event+Purchase. Это применимо к любому продукту, так как только вы выбираете, что отправлять в это событие (речь про рекламную монетизацию, намёк на watched rewarded videos).
В ААА кампании выбирайте свое топовое ГЕО, либо Tier1 для большинства продуктов, загружайте все лучшей рекламные креативы и 5 заголовков и 5 текстовок обязательно. Работает по принципу Google UAC, иногда везёт и у вас заходит.

Бюджет для старта зависит от страны и оптимизации. Нужно рассчитывать хотя бы на 50 установок в день на кампанию, примерно 150 link clicks.
Для US это минимум $100 в день, для Tier12 может быть и $50. Опять же напомню, что эти кампании любят бюджеты, так что если можете позволить заложить больше — сделайте это, иначе тест растянется на месяца.

2. СBO кампании — App Event Optimization

Я очень люблю CBO кампании и на всех своих проектах их использую с момента появления. Кампания с оптимизацией бюджета на campaign level позволяет Facebook’у оптимизировать за вас и распределять бюджет на лучшую группу объявлений. Вам же это позволит в рамках 1 кампании протестировать несколько аудиторий/креативов/стран, при этом выполнить рекомендацию Facebook по достижению 128 установок в день.

Внутри CBO кампании я обычно делаю 3-4 адсета, загружаю в каждый 5-10 лучших креативов и делаю разные настройки аудиторий. Например так:

Adset 1: US,CA,AU,CA,NZ — ALL GENDER — WIDE — APL (All placements)

Adset 2: US,CA,AU,CA,NZ — ALL GENDER — LAL1% (Look-a-like) — APL (All placements)

Adset 3: US,CA,AU,CA,NZ — ALL GENDER — LAL3% (Look-a-like) — APL (All placements)

Adset 4: US,CA,AU,CA,NZ — ALL GENDER — Interests — APL (All placements)

Бюджет для старта опять же рекомендую от $100 для такого сетапа, как в примере. В идеале $300-500 в день. Если берете страны с низким CPM, то можно и меньше.

Все описанное выше это лично моя тактика работы с iOS14+ кампаниями на Facebook и ваш опыт может быть совершенно другим.

Интересно услышать в комментариях, что как у вас успехи с этими кампаниями и как вы их запускаете.
P.S. Все началось с ответа на вопросы по консультации и я понял, что полезным для многих будет ответить на это на VC. Еще больше инсайтов про UA тут.

Количество скачиваний мобильного клиента Facebook сократилось почти на треть

3DNews Новости Software Социальные сети Количество скачиваний мобильного клиента… Самое интересное в обзорах 14.05.2021 [09:19], Артур Хамзин Популярность приложения Facebook* сильно снизилась среди пользователей мобильных устройств. По данным аналитической компании AppFigures, количество загрузок клиентской программы сервиса в App Store и Google Play сократилось на 30 %. Эксперты связывают это с растущей популярностью TikTok и проблемами Facebook* с конфиденциальностью. Рамиль Ситдиков, РИА Новости По данным аналитиков, в мае 2021 года еженедельные загрузки приложения составили 11 миллионов скачиваний, в то время как годом ранее этот показатель составлял 15 миллионов. По их словам, Facebook* и раньше сталкивалась с сокращением загрузок, но это первый раз, когда падение продолжается в течение более чем года. Оно началось в апреле 2020 года, когда Apple анонсировала iOS 14 с изменениями в политике конфиденциальности. Тогда загрузки резко снизились с 15 до 13 миллионов еженедельно. 9to5mac Специалисты связывают это с растущей популярностью TikTok и проблемами компании с конфиденциальностью. Сервис коротких видеороликов остаётся самым популярным приложением в App Store и Google Play. Для сравнения, Facebook* набрала 9,9 млн загрузок в апреле (в App Store), в то время как TikTok — 15,9 млн. Кроме этого, в последние несколько лет Facebook* стала участником нескольких скандалов, касающихся конфиденциальности пользователей. Одним из самых громких стало разбирательство с участием Cambridge Analytica — аналитической компании, связанной с американскими выборами. Из-за этого Марку Цукербергу (Mark Zuckerberg) даже пришлось давать показания в Сенате США. В 2020 году Facebook* открыто выступила против изменения правил конфиденциальности iOS. Компания раскритиковала нововведения, призванные дать пользователям больше контроля над отслеживанием их информации для таргетированной рекламы. Из-за этого соцсеть даже пригрозила Apple судом. * Внесена в перечень общественных объединений и религиозных организаций, в отношении которых судом принято вступившее в законную силу решение о ликвидации или запрете деятельности по основаниям, предусмотренным Федеральным законом от 25.07.2002 № 114-ФЗ «О противодействии экстремистской деятельности». Источник: Если вы заметили ошибку — выделите ее мышью и нажмите CTRL+ENTER. Материалы по теме Постоянный URL: https://3dnews.ru/1039586/kolichestvo-skachivaniy-mobilnogo-klienta-facebook-sokratilos-pochti-na-tret Рубрики: Новости Software, ПО для мобильных устройств, Социальные сети, Приложения для Android, Приложения для iOS, Теги: ff, ios, app store, google play, социальные сети ← В прошлое В будущее →

React Native: перенос современных веб-технологий на мобильные устройства

Если вы новичок в React, вы можете узнать больше об этом на веб-сайте React. Вы также можете начать работу с React Native для iOS, который был выпущен на F8 2015 на веб-сайте React Native.

Все началось с React

Мы представили React миру два года назад, и с тех пор наблюдается впечатляющий рост как внутри, так и за пределами Facebook. Сегодня, хотя никто не принуждает его использовать, новые веб-проекты в Facebook обычно создаются с использованием React в той или иной форме, и он широко применяется в отрасли. Инженеры предпочитают использовать React каждый день, потому что это позволяет им уделять больше времени своим продуктам и меньше времени бороться с их фреймворком. Однако только после того, как мы некоторое время работали с React, мы начали понимать, что делает его таким мощным.

React заставляет нас разбивать наши приложения на отдельные компоненты, каждый из которых представляет одно представление. Эти компоненты облегчают итерацию наших продуктов, поскольку нам не нужно держать в голове всю систему, чтобы внести изменения в одну ее часть. Однако, что более важно, React объединяет мутативный императивный API DOM с декларативным, что повышает уровень абстракции и упрощает модель программирования. Мы обнаружили, что когда мы строим с помощью React, наш код становится намного более предсказуемым. Эта предсказуемость позволяет нам уверенно выполнять итерации быстрее, и в результате наши приложения становятся намного надежнее. Кроме того, не только легче масштабировать наши приложения, когда они созданы с помощью React, но мы также обнаружили, что легче масштабировать размер самих наших команд.

Благодаря быстрому циклу развития Интернета мы смогли создать несколько замечательных продуктов с помощью React, включая многие компоненты Facebook.com. Кроме того, мы создали потрясающие фреймворки на JavaScript поверх React, такие как Relay, что позволяет нам значительно упростить выборку данных в масштабе. Конечно, веб — это только часть истории. Facebook также широко использует приложения для Android и iOS, которые построены на основе разрозненных проприетарных технологических стеков. Необходимость создавать наши приложения на нескольких платформах разделила нашу инженерную организацию, но это только одна из вещей, которая затрудняет разработку нативных мобильных приложений.

Почему нативная среда сложна

Есть много причин, по которым работать с нативной мобильной средой сложнее, чем с Интернетом. Во-первых, сложнее размещать элементы на экране, и нам часто приходится вручную вычислять размер и положение всех наших представлений. У нас также нет доступа к React или Relay, которые упростили масштабирование процесса разработки веб-сайтов и расширение нашей инженерной организации. Однако одна из самых болезненных вещей в нашем переходе на мобильные устройства — это то, насколько это замедлило скорость нашей разработки.

При разработке в Интернете мы можем просто сохранить наши файлы и перезагрузить браузер, чтобы увидеть результат наших изменений. Однако в нативном коде нам нужно перекомпилировать после каждого изменения, даже если мы просто хотим сместить текст на несколько пикселей на экране. В результате инженеры работают намного медленнее, особенно в большой кодовой базе, где компиляция особенно обременительна. Использование нативного кода также усложняет тестирование новых функций. В Facebook мы выпускаем новую версию веб-сайта два раза в день, поэтому мы можем практически сразу же получить результаты эксперимента. На мобильных устройствах нам часто приходится ждать недели или месяцы, чтобы получить результаты эксперимента или A/B-тестирования, потому что новые версии нашего приложения выпускаются гораздо реже. «Двигайся быстро» заложено в ДНК Facebook, но мы не можем двигаться так же быстро на мобильных устройствах, как в Интернете. Так зачем вообще отказываться от Интернета?

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

Почему нативные приложения необходимы

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

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

Лучшее из двух миров?

Что нам действительно нужно, так это пользовательский интерфейс нативных мобильных платформ в сочетании с опытом разработчиков, который мы получаем при создании с помощью React в Интернете. Есть несколько способов добиться этого:

1. 1. Использование веб-представлений

Одной из возможностей является использование WebView внутри простых собственных приложений-оболочек. Мы попробовали это несколько лет назад и на самом деле считаем, что это отличная идея. Хотя наша реализация не дала нам желаемой производительности и масштабируемости, этот подход удивительно гибок и обладает всеми преимуществами, связанными с опытом разработчиков в Интернете, такими как возможность в полной мере использовать React и быстрый цикл итераций в Интернете. . К сожалению, поскольку весь рендеринг выполняется с использованием веб-технологий, мы не можем создать действительно нативный пользовательский интерфейс.

1. 1. Перенос React на родной

Портирование React на нативный код — тоже отличная идея, и на самом деле мы сделали это для iOS! Этот проект называется ComponentKit, и вчера на F8 мы открыли его исходный код. С ComponentKit мы получаем все преимущества React, особенно декларативные, предсказуемые пользовательские интерфейсы, но мы также можем воспользоваться мощью собственной среды с компонентами для конкретных платформ и сложной обработкой жестов, а также асинхронным декодированием изображений, измерением текста. и рендеринга. Кроме того, поскольку ComponentKit использует flexbox для макета, вам не нужно вручную позиционировать и изменять размеры представлений в вашем приложении, поэтому ваш код становится более кратким и простым в обслуживании.

Однако у этого подхода есть пара небольших недостатков. Во-первых, это только для iOS, поэтому, если мы хотим использовать его на Android, нам придется создать отдельную реализацию и научить инженеров, как ее использовать. Кроме того, у нас нет доступа к каким-либо материалам, которые мы создали для Интернета поверх React, например к Relay, который помогает нам решать реальные проблемы, с которыми мы столкнулись при масштабировании выборки данных. Самое главное, однако, заключается в том, что мы принципиально не улучшили нашу задачу скорости разработки — нам все еще нужно перекомпилировать после каждого изменения.

1. 1. Собственный сценарий

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

Нативные сценарии — это сложно

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

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

К счастью, React предоставляет идеальную модель программирования, позволяющую сделать это правильно.

Знакомство с React Native

Поскольку компоненты React — это просто чистые функции без побочных эффектов, которые возвращают то, как выглядят наши представления в любой момент времени, нам никогда не нужно читать из нашей базовой реализации визуализированного представления, чтобы написать к этому. В среде браузера React не блокирует DOM, но красота React в том, что он абстрактен и не тесно связан с DOM. React может обернуть любую систему императивного представления, например UIKit на iOS.

Значит, немного поработав, мы сможем сделать так, чтобы тот же самый React, что и на GitHub, мог работать в действительно нативных мобильных приложениях. Единственная разница в мобильной среде заключается в том, что вместо запуска React в браузере и рендеринга в div и span мы запускаем его во встроенном экземпляре JavaScriptCore внутри наших приложений и рендерим в высокоуровневые специфичные для платформы компоненты.

Одна из лучших сторон этого подхода заключается в том, что мы можем внедрять его постепенно, создавая новые продукты поверх него или переделывая старые продукты, чтобы использовать их всегда и везде, где это имеет смысл. Точно так же, как нам не нужно было переписывать весь Facebook.com, чтобы начать использовать React в некоторых местах, нам не нужно полностью перестраивать наши мобильные приложения Facebook, чтобы начать осознавать преимущества React Native.

Это работает

Мы уже некоторое время используем React Native в производственной среде Facebook, и, несмотря на то, что предстоит еще много работы, у нас он работает очень хорошо. Стоит отметить, что мы не гонимся за «напиши один раз, беги куда угодно». Разные платформы имеют разный внешний вид, ощущения и возможности, поэтому мы по-прежнему должны разрабатывать отдельные приложения для каждой платформы, но один и тот же набор инженеров должен иметь возможность создавать приложения для любой выбранной ими платформы без необходимости изучения фундаментальных знаний. разный набор технологий для каждого. Мы называем этот подход «научись один раз, пиши где угодно».

Если у вас есть iPhone, вы можете протестировать несколько приложений, использующих React Native, которые доступны в App Store. Facebook Groups — это гибридное приложение, состоящее из представлений, созданных как с помощью собственного кода, так и с помощью React Native JavaScript, а Facebook Ads Manager полностью построен с использованием React Native.

Открытый исходный код

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

Сегодня мы рады открыть исходный код React Native для iOS и сделать его доступным на GitHub. Поддержка Android появится в ближайшее время, и мы также продолжим работу над React для Интернета, но мы хотели как можно раньше получить эту первоначальную поддержку iOS, чтобы мы могли получить отзывы от других, которые также в восторге от этого подхода. Имейте в виду, что, вероятно, многие вещи либо сломаны, либо еще не реализованы. Мы приветствуем ваши отзывы и вклад, и нам не терпится увидеть, что вы создадите!

MobileLab: предотвращение снижения производительности мобильных устройств

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

MobileLab, находящаяся сейчас в производстве, уже предотвратила выпуск тысяч регрессий благодаря своей способности обнаруживать очень небольшие изменения в производительности (всего 1 процент для многих наших показателей). По сравнению с нашим предыдущим стандартом, MobileLab улучшает доверительные интервалы в 7 раз и снижает количество ложных срабатываний на 75 процентов.

Создание среды проверки

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

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

Вот несколько примеров результатов нашей системы проверки:

• Наблюдаемый уровень ложноположительных результатов: Основываясь на построении нашего теста гипотезы, мы знаем, что при проведении множества экспериментов А/А ожидается 5-процентный уровень ложноположительных результатов. Мы используем t-тест в MobileLab, который предполагает, что наши испытания для каждого приложения независимы и одинаково распределены (IID). Если это предположение по какой-то причине нарушается, то мы можем увидеть резко отличающиеся показатели ложноположительных результатов.
• Дисперсия показателей контроля и лечения: Платформа будет сообщать о наблюдаемой дисперсии наших показателей, чтобы мы могли отслеживать наш прогресс в направлении 10-кратного сокращения.
• Среднее значение показателя по номеру испытания по экспериментам: Если данные действительно IID, то не должно быть корреляции между номером испытания и наблюдаемым значением.

С нашей структурой мы были готовы опробовать наши идеи — и были удивлены, обнаружив, что наш простой эксперимент нарушил некоторые из сделанных нами статистических предположений. На рисунке ниже показано ступенчатое изменение производительности, что означает, что наши испытания на самом деле не были IID, как мы предполагали. Очевидно, нам предстояло еще поработать.

Эксперимент A/A, иллюстрирующий скачкообразное изменение производительности во время выполнения, нарушающий допущения IID.

Устранение дисперсии

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

Стабильная производительность устройства
Мы начали с использования Profilo, нашего инструмента отслеживания, чтобы понять различия между пробными версиями в нашей системе. Каждый след, производимый нашей системой, был настолько отличным от других, что мы не могли добиться прогресса. Нам нужно было начать с простого и перейти к сложному приложению, такому как Facebook для Android. Мы разработали тест центрального процессора (ЦП), который позволил нам анализировать поведение нашей платформы и устройства отдельно от поведения рабочих нагрузок.

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

График, показывающий MFLOPS в зависимости от времени при выполнении эталонного теста ЦП с умножением матриц.

Android динамически изменяет частоту процессора, чтобы увеличить срок службы батареи и температуру телефона. Это означало, что скорость телефона менялась под нами по мере того, как устройство нагревалось. Используя настройки регулятора процессора наших телефонов, мы смогли заблокировать наши процессоры на фиксированной частоте, чтобы они могли работать неограниченное время без перегрева. Мы также построили аналогичный тест для графического процессора и зафиксировали его на фиксированной частоте. Эта работа привела к гораздо более стабильным результатам нашего теста.

 чмод 666 \
    /sys/модуль/msm_thermal/core_control/включено \
    /sys/модуль/cpu_boost/параметры/input_boost_freq \
    /sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0/devfreq/говернор \
    /sys/класс/kgsl/kgsl-3d0/devfreq/min_freq \
    /sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0/max_gpucklk \
    /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor \
    /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor \
    /sys/устройства/система/процессор/процессор2/cpufreq/scaling_governor \
    /sys/устройства/система/процессор/процессор3/cpufreq/масштабирование_говернор

# Отключить службы оптимизации процессора Android
остановить решение
эхо 0 > /sys/module/msm_thermal/core_control/enabled
эхо 0 > /sys/module/cpu_boost/параметры/input_boost_freq

# Установить фиксированную частоту для GPU
эхо-производительность > /sys/devices/fdb00000. qcom,kgsl-3d0/kgsl/kgsl-3d0/devfreq/governor
эхо 300000000 > /sys/класс/kgsl/kgsl-3d0/devfreq/min_freq
эхо 300000000 > /sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0/max_gpuclk

# Установите фиксированную частоту для CPU 0
эхо-производительность > /sys/devices/system/cpu/cpu0/cpufreq/scaling_Governor
эхо 1728000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
эхо 1728000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq

# ... повторить для ЦП 1-3 

Стабилизация MFLOPS при выполнении теста с фиксированной частотой процессора.

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

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

Стабильная производительность приложений
Наши последовательные тесты оказались полезными, но реальные приложения — это больше, чем просто тесты, привязанные к ЦП. Например, многие взаимодействия в наших приложениях получают информацию с серверов Facebook с помощью GraphQL. Это означает, что характеристики производительности серверов Facebook и зависимых от них сервисов влияют на наши тесты. Если нам случится получить доступ к Facebook.com в часы пик, страницы могут загружаться немного медленнее и изменить результаты наших тестов.

Чтобы изолировать нашу систему от этих эффектов, мы создали прокси-сервер HTTP. Прокси-сервер предоставляется устройству через USB через adb reverse . Мы записываем пары запросов и ответов, которые мы можем повторно использовать для предоставления согласованных данных и времени для эталонного теста. Этот подход аналогичен BrowserLab, нашей системе тестирования веб-браузеров.

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

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

Чтобы контролировать это, мы теперь делаем резервную копию состояния приложения на диске перед первой пробной версией. Между каждым испытанием мы останавливаем приложение и восстанавливаем это состояние. Это означает, что состояние приложения не может переноситься между испытаниями.

 # Резервное копирование состояния диска
rm -rf /data/data/com.facebook.testsnapshot
ср -а \
    /data/data/com. facebook.katana \
    /data/data/com.facebook.testsnapshot
rm -rf /data/app/com.facebook.testsnapshot
ср -а \
    /данные/приложение/com.facebook.katana-1 \
    /data/app/com.facebook.testsnapshot

# Восстановить состояние диска
rm -rf /data/data/com.facebook.katana
ср -а \
    /данные/данные/com.facebook.testsnapshot \
    /data/data/com.facebook.katana
rm -rf /data/app/com.facebook.katana-1
ср -а \
    /данные/приложение/com.facebook.testsnapshot \
    /data/app/com.facebook.katana-1 

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

1. Производительность записи на диск: Поскольку мы многократно запускаем один и тот же код, операции чтения с диска обычно попадают в кэш уровня ОС. Пишет, однако, нет. Производительность диска менее постоянна, чем производительность процессора, поэтому небольшие операции записи вызывали удивительное количество шума. Мы решили эту проблему, перемонтировав каталоги данных приложения на RAM-диск с помощью tmpfs. В этом сценарии наша производительность чтения и записи нереалистична, поэтому мы увеличиваем наши показатели задержки с помощью показателей ввода-вывода, таких как загруженные классы и записанные байты.
2. Часы устройства: Поведение некоторых приложений зависит от системного времени; одним из примеров является код, определяющий TTL для записей кэша. Если бы прошло слишком много времени, приложение использовало бы другие пути кода и демонстрировало бы другие характеристики производительности. Мы исправили это, сбросив часы устройства на одну и ту же отметку времени перед каждым испытанием.
3. Диалоговые окна сбоя: В некоторых редких случаях приложение может аварийно завершать работу во время выполнения, что приводит к отображению диалогового окна сбоя Android. Без дальнейших действий это диалоговое окно останется на экране до конца теста. Тест продолжал работать правильно, но внешний вид диалогового окна влиял на производительность приложения и приводил к несколько более медленным показателям. Мы исправили это, закрыв все диалоги перед каждым испытанием.
4. Устранение хвоста logcat: Первоначально мы передавали метрики через строки журнала, написанные приложением, и хвостовой logcat для получения этих показателей. Выполняющий тест узнает, что тест завершен, как только он прочитает все ожидаемые показатели из этих журналов. Активное прослушивание logcat через adb вызывает дополнительный шум в процессе тестирования. Вместо этого мы устанавливаем туннель adb reverse , и приложение напрямую отправляет метрики тестировщику через соединение через сокет.

Комбинация вышеупомянутых методов обеспечивает схему эксперимента, показанную ниже. Благодаря этим изменениям MobileLab успешно сократила дисперсию в важных тестах производительности на порядок и способна надежно обнаруживать регрессии менее 1% всего за 50 испытаний.

 set_fixed_cpu_gpu_frequency()
mount_tmpfs()
run_experiment (proxy_mode = Mode.RECORD, приложение = лечение, испытания = 1)
run_experiment (proxy_mode = Mode.RECORD, приложение = контроль, испытания = 1)
run_experiment (proxy_mode = Mode.REPLAY, приложение = лечение, испытания = N)
run_experiment(proxy_mode=Mode.REPLAY, приложение=управление, испытания=N)

def run_experiment (proxy_mode, приложение, испытания):
    # Настраивать
    proxy.set_mode(proxy_mode)
    приложение.установить()

    performance_test.setup()
    приложение.capture_snapshot()

    # Бенчмаркинг
    start_time = дата и время.сейчас()
    для испытания в диапазоне (испытания):
        приложение.restore_snapshot()
        set_device_time (начальное_время)
        performance_test.run()
        приложение.убить()
        уволить_crash_dialog() 

Тестирование с помощью MobileLab

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

Вместо этого в MobileLab мы предоставляем более ограниченный и самоуверенный тестовый API, который побуждает пользователей писать тесты, которые максимально быстро и просто продвигаются к измерению. В отличие от некоторых сквозных тестовых фреймворков, мы не опрашиваем элементы пользовательского интерфейса и не загружаем дополнительные библиотеки в приложение для тестирования. Это убирает все накладные расходы из фреймворка.

 по определению run_test():
    start_app()
    navigation_directly_to_interaction()
    wait_for_performance_marker() 

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

Наш подход к использованию показателей шумоподавления и потребления приводит к более синтетическому эталонному тесту, который менее репрезентативен для всех сценариев. Несмотря на явные отличия от производственной среды, мы обнаружили, что MobileLab по-прежнему может обнаруживать регрессии, возникающие в реальных сценариях. Мы сосредоточены на правильности направления, а не на производстве того же масштаба, что и производство. Мы запускаем каждый тест, в том числе непрерывный, как тест A/B, сообщая о разнице между A и B, а не об абсолютном значении одной стороны.

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

Автоматическое обнаружение регрессии

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

Заключение

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

Эти улучшения качества сигнала помогают нам выявлять регрессии, которые раньше невозможно было обнаружить, что делает MobileLab важной частью рабочего процесса для групп производительности в Facebook. Для некоторых команд MobileLab уловила каждую регрессию, которая должна была быть отправлена ​​в рабочую среду, что позволило их инженерам сосредоточиться на повышении скорости, а не на борьбе с регрессией.