Comments 6
По iPad добавлю в комментарии.
Есть некоторая вероятность, что iPad Air менее капризен в плане незначительных функциональных багов про многоходовочке. Но статистики у меня недостаточно, поэтому утверждать не берусь.
Самой крайне интересно почитать мнения.
Есть некоторая вероятность, что iPad Air менее капризен в плане незначительных функциональных багов про многоходовочке. Но статистики у меня недостаточно, поэтому утверждать не берусь.
Самой крайне интересно почитать мнения.
0
Вероятно, я не в теме, но для чего знать физические разрешения экранов, если мобильные устройства используют для отрисовки сайтов (и вероятно приложений) виртуальные значения ширинв и высоты.
В любом Веб браузере на основе Хрома в инспекторе кода это наглядно показано.
В яндекс метрике при выборе разрешения экрано гаджетов, тоже будут совсем не физические пиксели матриц.
В любом Веб браузере на основе Хрома в инспекторе кода это наглядно показано.
В яндекс метрике при выборе разрешения экрано гаджетов, тоже будут совсем не физические пиксели матриц.
0
Статья для тестировщиков и это не всеобъемлющий труд, а практическая инструкция. Отличие физического и логического разрешения они знают. В таблице по экрану три параметра, физическое разрешение, размер экрана, плотность. В моей таблице есть и логическое, но это не столько для выбора, сколько для работы.
>В яндекс метрике при выборе разрешения экрано гаджетов, тоже будут совсем не физические
В ЯндексМетрике есть оба варианта
Про DevTools сейчас поищу скриншоты, демонстрирующие, почему просмотр в браузере это отправная точка, если плохо там, то будет беда и на устройстве. Но реалии в том, что если хорошо там, еще не значит что будет хорошо и на устройстве. Поэтому крайне желательно проверять дальше браузера
>В яндекс метрике при выборе разрешения экрано гаджетов, тоже будут совсем не физические
В ЯндексМетрике есть оба варианта
Про DevTools сейчас поищу скриншоты, демонстрирующие, почему просмотр в браузере это отправная точка, если плохо там, то будет беда и на устройстве. Но реалии в том, что если хорошо там, еще не значит что будет хорошо и на устройстве. Поэтому крайне желательно проверять дальше браузера
0
В статье использован чисто технический подход, мне кажется так вы упускаете несколько важных моментов.
- Для начала вам нужно оценить количество потенциальных пользователей по странам.
Берем количество пользователей смартфонов, смотрим соотношение iOS vs Android можно среднее, но лучше по странам. - Выбираем страны на которые мы будем выпускать приложения, если хотите заходить в Китай где рынок в 3 раза больше Американского, то придется выбирать в какой App Store будуте грузить, а в какой нет (для примера Google Play Store занимет 22 место с 0.05% покрытия). Где-то будет нужно локализовать приложение перед выпуском (например Япония). Также проверяем где приложение можно выкладывать бесплатно, а где доступны платные опции: Android, iPhone
- Теперь учитываем сколько люди тратят в каждом App Store также по странам. Получаем примерный объем рынка.
- Далее смотрим top-10 смартфонов в каждой стране. После чего суммируем все полученые данные, на выходе должно получиться отсортированная таблица: смартфон — количество пользователей — количество денег (Android отдельно, iPhone отдельно). Можно еще попробовать оценить соотношение бесплатных/платных пользователей и учесть что количество трат на приложения тем больше, чем выше стоимость смартфона.
И только потом по полученному списку смотрим характеристики. Строим соотношение по разным параметрам: размер и особенности экрана, соотношение сторон, мощность cpu/gpu/ram, версия SDK и т.д. И начиная сверху списка выбираем смартфоны которые обеспечивают наибольшее покрытие по этим характеристикам. Как итог вы проверяете приложение на тех устройствах которые используют ваши наиболее ценные пользователи и покрываете максимум комбинаций. Насчет эталонного устройства поддержу, каждому разработчику должен быть доступен один и тот же vanilla Android/iPhone.
+1
Я писала на конкретную ЦА. Вы немного не понимаете роль тестировщика в команде ). В статье конкретно прописано предусловие максимально приближенное к реальному. Оно не упущено, оно дается как вводная. Тестировщик не решает как и где монетизировать приложение. Этим занимается менеджер/аналитик/владелец.
Ваша схема вполне годная для одиночки или небольшой студии, специализирующейся на написании серии небольших приложений. Но статья всеж немного о другом.
В любом случае спасибо что откликнулись на призыв, знать с чего начинается не помешает )
Ваша схема вполне годная для одиночки или небольшой студии, специализирующейся на написании серии небольших приложений. Но статья всеж немного о другом.
В любом случае спасибо что откликнулись на призыв, знать с чего начинается не помешает )
0
Sign up to leave a comment.
Выбор мобильных устройств: пошаговая инструкция для начинающих QA. Часть II