Pull to refresh

Comments 6

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

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

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

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

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


  1. Для начала вам нужно оценить количество потенциальных пользователей по странам.
    Берем количество пользователей смартфонов, смотрим соотношение iOS vs Android можно среднее, но лучше по странам.
  2. Выбираем страны на которые мы будем выпускать приложения, если хотите заходить в Китай где рынок в 3 раза больше Американского, то придется выбирать в какой App Store будуте грузить, а в какой нет (для примера Google Play Store занимет 22 место с 0.05% покрытия). Где-то будет нужно локализовать приложение перед выпуском (например Япония). Также проверяем где приложение можно выкладывать бесплатно, а где доступны платные опции: Android, iPhone
  3. Теперь учитываем сколько люди тратят в каждом App Store также по странам. Получаем примерный объем рынка.
  4. Далее смотрим top-10 смартфонов в каждой стране. После чего суммируем все полученые данные, на выходе должно получиться отсортированная таблица: смартфон — количество пользователей — количество денег (Android отдельно, iPhone отдельно). Можно еще попробовать оценить соотношение бесплатных/платных пользователей и учесть что количество трат на приложения тем больше, чем выше стоимость смартфона.

И только потом по полученному списку смотрим характеристики. Строим соотношение по разным параметрам: размер и особенности экрана, соотношение сторон, мощность cpu/gpu/ram, версия SDK и т.д. И начиная сверху списка выбираем смартфоны которые обеспечивают наибольшее покрытие по этим характеристикам. Как итог вы проверяете приложение на тех устройствах которые используют ваши наиболее ценные пользователи и покрываете максимум комбинаций. Насчет эталонного устройства поддержу, каждому разработчику должен быть доступен один и тот же vanilla Android/iPhone.

Я писала на конкретную ЦА. Вы немного не понимаете роль тестировщика в команде ). В статье конкретно прописано предусловие максимально приближенное к реальному. Оно не упущено, оно дается как вводная. Тестировщик не решает как и где монетизировать приложение. Этим занимается менеджер/аналитик/владелец.
Ваша схема вполне годная для одиночки или небольшой студии, специализирующейся на написании серии небольших приложений. Но статья всеж немного о другом.
В любом случае спасибо что откликнулись на призыв, знать с чего начинается не помешает )
Sign up to leave a comment.

Articles