452

Единые показатели производительности кроссплатформенности

альфа выгодное предложение альфа выгодное предложение

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

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

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

Как разработчик приложения, рассматривающий эту обратную связь, я спрашиваю себя:

Что они подразумевают под медленным?

Где они замечают проблему в приложении?

Имеют ли другие пользователи или другие устройства одинаковые результаты?

Является ли это лучше или хуже для них с течением времени?

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

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

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

Мы обсудим, ПОЧЕМУ нам нужны кросс-платформенные показатели, с глубоким погружением в КАК мы внедрили метрики времени запуска и ЧТО мы узнали в пути.

Почему важны единые кросс-платформенные показатели?

Из-за стремительного характера итераций Slack мы отслеживали производительность отдельно для каждой клиентской платформы.

На настольных компьютерах, Android и iOS были разные словари и определения показателей.

Например, мы измерили время запуска приложения как на iOS, так и на Android, но мы назвали его cold_start_time_authenticatedна iOS и cold_startAndroid.

Время запуска отслеживалось с различными начальными и конечными точками.

Каждая платформа отправляет различные типы свойств в метаданные.

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

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

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

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

Нам нужны общие метрики словарей и определений на разных платформах по многим причинам:

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

Они дают нам согласованные контрольные показатели и цели для достижения измеримых целей.

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

Внешне наши клиенты являются кросс-платформенными.

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

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

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

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

Мы определили общий интерфейс для серии кросс-платформенных показателей производительности, включая время запуска, время переключения канала и статистику частоты кадров.

Мы используем Thrift для спецификации метрики производительности, которая предоставляет нам унифицированный и нечувствительный к языку интерфейс с сильно типизированными метаданными.

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

Спецификация служит соглашением о структуре и типах данных метрик и их параметрах.

Это упрощает агрегацию, форматирование и мониторинг данных для аналитиков данных.

Один конвейер данных не только предотвращает повторение работы для каждой платформы, но также позволяет сравнивать данные о производительности на настольном компьютере, iOS и Android бок о бок.

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

Короче говоря, есть три ключевых преимущества для унифицированных кросс-платформенных показателей:

1.Соответствие ожидаемой производительности в соответствии с целями совместной работы.

2.Улучшение коммуникации внутри и снаружи с помощью определения и реализации общих показателей.

3.Имейте единый конвейер данных для агрегации и анализа данных.

Теперь давайте рассмотрим тематическое исследование времени запуска приложения и того, как мы использовали единые показатели производительности в клиентских приложениях для настольных компьютеров, iOS и Android.

Отслеживание времени запуска приложения

Первые впечатления имеют значение, когда дело касается как людей, так и приложений.

Очень важно приносить самую актуальную и обновленную информацию пользователю во время каждого запуска приложения.

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

Как мы используем кросс-платформенные показатели, чтобы помочь нам справиться с отслеживанием времени запуска?

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

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

Мы идентифицировали две метрики в процессе запуска, которые применяются ко всем платформам: время до видимого (TTV) и время к использованию(TTU).

Время видимости

Время видимости (TTV) определяется как время от запуска приложения до момента отображения локально кэшированного содержимого.

С точки зрения пользователя Slack, настало время показать первый значащий контент  -  обычно сообщения  -  чтобы они могли начать с того места, где они остановились в прошлый раз.

Подобно понятию First Meaningful Paint для веб-браузеров, мы хотели понять, как быстро они могут начать чтение актуального контента в Slack, что отражает их восприятие скорости запуска приложения.

Для TTV клиент приложения полностью контролирует эту часть времени запуска приложения.

Поскольку кэшированные данные доступны локально, время достижения TTV не зависит от производительности бэкэнд или сети.

Даже если пользователь отключен во время запуска приложения, приложение все еще может отображать загруженное ранее.

Для наших пользователей они будут видеть разговор с того места, где они остановились.

Тем не менее, они, возможно, не смотрят на самый последний контент.

Время использования

Время использования (TTU) определяется как время от запуска приложения до момента отображения последнего содержимого на экране.

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

Время достижения TTU может зависеть от состояния сети, задержки API, размера ответа и т.д.

Тем не менее, TTU отражает пользовательский интерфейс, когда они сообщаются самыми последними сообщениями и могут принимать действия на основе того, что они видят, следовательно, термин «Полезный».

Мы явно не проверяем, является ли интерфейс интерактивным, так как пользователь может не выбрать прокрутку или ввод сообщений сразу.

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

Пример выше записан на устройстве iPhone 5S с медленным сетевым подключением для демонстрации TTV и TTU.

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

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

Пользователь нажимает на значок приложения Slack

Приложение запускается на экран загрузки

Отображаются локально кэшированные сообщения. TTV завершен

Приложение получает новые сообщения из веб-запроса и обновляет пользовательский интерфейс. TTU завершен

Специальные случаи везде!

Кажется просто отслеживать процесс запуска из вышеперечисленных шагов.

Однако это довольно сложно с несколькими факторами, и мы часто сталкиваемся с особыми случаями.

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

Сценарии идентифицируются клиентскими приложениями и явно помечены в метаданных.

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

Вот несколько примеров особых случаев, которые мы зарегистрировали для TTV / TTU:

Нет существующего кеша (TTV)

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

В этом случае TTV - это то же самое, что и TTU, поскольку нам всегда нужно пинговать сервер для загрузки данных.

На мобильных устройствах менее 1% сеансов не имеют кэшированного содержимого, но на рабочем столе это 100% из-за отсутствия локального кеша.

Нет нового контента (TTU)

Возможно, после того, как ping-сервер сообщит, что текущий канал уже синхронизирован, это означает, что больше не нужно загружать контент.

Для конечного пользователя не будет обновления пользовательского интерфейса после TTV.

В этом случае мы по-прежнему включаем время запроса в TTU, но отмечаем его флагом.

На мобильных устройствах 90% сеансов не синхронизируются с новым контентом, в то время как для всех настольных сеансов требуется выгрузка контента с сервера.

Пользовательское вмешательство

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

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

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

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

Способы запуска приложения

Мы отслеживаем TTV / TTU для холодного и теплого запуска.

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

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

Многие действия могут инициировать запуск приложения.

Мы отмечаем каждый запуск соответственно:

На Android и iOS мы отмечаем запуск приложений из значка приложения, уведомлений, глубоких ссылок и т.д.

На рабочем столе мы отмечаем запуск с иконки приложения и когда клиент загружается в браузере.

Обновление приложений или баз данных

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

Мы отмечаем этот случай, поэтому его не путают с фактической регрессией во время запуска.

Все указанные выше особые случаи регистрируются как общие свойства для всех клиентов.

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

Например, мы заметили, что около 8% запусков iOS вызваны уведомлением, в то время как эта сумма составляет около 21% на Android.

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

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

Вызовы и извлеченные уроки

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

Во время процесса мы столкнулись с множеством проблем:

Ограничения платформы

Различные реализации на каждой платформе (например, как кэшируются и визуализируются сообщения)

Стандартизация определения и развертывания показателей

Управление обновлениями данных и управлением версиями

Сотрудничество между несколькими командами платформы

Вот некоторые уроки, которые мы изучили до сих пор, от решения этих проблем.

Бизнес-ориентированный бизнес-процесс

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

Ожидайте того, что нормально, а что нет.

Например: в каком диапазоне должны учитываться показатели показателей?

Какие возможные значения должны иметь метаданные?

Каким должно быть распределение значений метаданных?

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

Определить причины для отслеживания и принятия решений

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

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

Инвестировать в процессы и инструменты

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

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

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

Раннее обмен знаниями и обучение

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

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

Будущее

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

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

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

0 комментариев

Написать сообщение

Пожалуйста, оцените по 5 бальной шкале