Скорее всего так
Digital (IEC)
Converts a number of bytes using binary prefixes. It scales to use the unit that’s the best fit.

Такая логика - мы указываем тип, чтобы графина знала, как данные скалировать, если мы хотим видеть четко исходные данные, то указываем none

Да, помню как удивился, что мне нужны не мегабайты а какие мебибайты :)

(Чтобы в 1 мегабайте было 1024 килобайт нужны как раз они, по стандарту IEC)

Добрый день!
Вопросы чуть дальше.

Разрабатывается приложение под Android и iOS.
Требование сделать, что бы первая экранная форма отрабатывала 3с, вторая 2с, третья 2.5с и тд. таких экранных форм грубо 500 штук.
Время допустимое так же разделено на когда приложение первый раз запускается и второй раз.
Есть требования на минимальную версию Android, процессор телефона, на версию iPhone, на максимальную загрузку процессора фоновыми задачами
Есть требование на качество сети в виде 3g, ping не более 300ms

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

Как померить бэкенд приблизительно понятно, например jmeter и в чате помню об это писали

Вопрос как померить такие метрики фронт + бэк на android?
Вопрос как померить такие метрики фронт + бэк на iOS?
Кто ни будь имеет опыт решения такой задачи. Как это происходило?

Мысли:
1. Посадить человека с секундомером, ужасно, не повторимо и тд
2. Добавить замеры в код + человек переходящий по вкладкам с Android Device Monitor. Тут обращаться к разработчикам для добавления меток времени которые будут видны в Android Device Monitor (сами замеры дадут погрешность, но не супер страшно наверное, хотя не уверен + эмулятор даст погрешность)
Сложить фронт + бэкэнд даст погрешность приличную (наверняка какая то часть фронта ждет бэк и еще что-нибудь не учел)
3. Пункт 2 + в это время давать нагрузку на бэк (вариант кажется лучший, но это еще трудозатраты)
4.Пункт 3, но заменить человека на АТ UI-тесты, если такие вообще планируются
Итог, это сложно, дорого, трудозатратно, зачем оно вообще надо пусть кто то другой о фронте думает)


Разработка еще толком не началась, ТЗ, экранные формы уже есть системы.

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

Соответственно, т.к. вы хотите условно фронт померить, а это и есть activity, то легче в код залезть и там счетчик поставить и выводить все в лог

В метод onCreate

И в андроид приложении нет грубо говоря фронта и Бека. Там мещанина. Если речь про андроид студио и разработку на джава/котлин

И если мы действительно говорим про нативное приложение которое не на реакте написано. В случае андроида

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

В функциональном тестировании приложений через UI используется разработка от касперсого - kaspresso. Покопайье туда

Написал как будто один в чате сижу, сам с собой

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

Перечитал все доки, возможно и на react native в документах не указано (чувство, что в тех плане отстал года на 3😢 если не больше)

Хотя концепцию по идеи не меняет, в том смысле, что если кому то нужно замерять отработку всего приложения бэк (ответы сервера) + фронт (грубо отрисовка)
То для этого надо в конкретном телефоне сделать эту прогрузку приложения

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

Посмотрел негативные отзывы на старое приложение, жуть жалоб))
1. 80% Сложный/не продуманный интерфейс и подлагивает
2. Несколько месяцев назад был частый отвал авторизации и тд на неопределенное время

Пальцем в небо - sitespeed.io не зайдет?

Что это за дивный песочный зверь у нас завелся?

У него же мобильное приложение а не сайт..

всем привет. Вот интересует такой вопрос, всегда ли нужно оборачивать HTTP request в Transaction controller? ТО есть , нужно ли это если запрос 1 и уже лежит в Throughput controller

?