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

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

Можно ли технически "классифицировать" устройства в этом направлении, используя базу данных "WURF"? И какие возможности устройства я должен использовать для "группировки" устройств как "быстрые" с точки зрения графической мощности?

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

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

Обновление-1. Я получил ответ от ScientiaMobile: "Мы играли с идеей какого-то индекса производительности Javascript (возможно, на основе одного из существующих тестов), который мог бы дайте некоторые указания на это, но мы все еще не находимся. Проблема сложная".

Обновление-2. Самые большие узкие места, которые мы обнаружили в мобильных веб-приложениях.

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

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

Спасибо.

Ответ 1

К сожалению, я не считаю, что сегодня это возможно для общего случая.

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

В контексте толстого приложения (например, вы "оберните" свой веб-сайт чем-то вроде Apache Cordova), это можно предоставить доступ к JavaScript для некоторых внутренних компонентов устройства (например, объем общей памяти, объем свободной памяти, скорость процессора), но в остальном эта информация недоступна в браузере. Как вы намекали, доступ к этому типу информации устройства может быть недостаточным (например, по-видимому, "высокие спецификации", которые работают плохо).

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

Аналогично, наборы данных Browserscope и связанный с ним проект ringmark (что-то вроде JavaScript-аналога WURFL), ответьте на эти вопросы поддержки браузеров на основе каждой версии браузера с помощью краудсорсинговых тестов бенчмаркинга (например, поддерживает ли iPhone CSS3-переходы?), а в общем случае это это то, что было бы необходимо. Вам нужно будет запустить тестовый тест для различных функций, о которых идет речь, и оценить производительность в реальном времени. Однако даже это имеет свои ограничения:

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

Конечным моментом является то, что я даже не обратился к тому, что производительность довольно субъективна. Скажите, что было возможно оценить/предсказать скорость анимации. Если анимация будет работать со скоростью 15 кадров в секунду, должен ли пользователь видеть эту анимацию? Как насчет 5 кадров в секунду? Кто станет конечным арбитром, который решает порог того, работает ли данная функция достаточно хорошо?

Лучшим советом, который я могу предложить сегодня, является сокращение (или устранение) вашей зависимости от проблемных функций на данный момент. Может показаться ужасным предложить вернуться к "старому" способу использования изображений с предустановленными тенями или создания фоновых градиентов без CSS3, но в конце концов пользовательский опыт должен иметь преимущество перед использованием новой технологии. Многие мобильные устройства просто еще нет, и методы обнаружения не являются. Если вы должны использовать эти функции, возможно, рассмотрите простой, но ненавязчивый способ для пользователей отказаться или отказаться от функций просмотра "стандартного" или "основного HTML" Gmail или автоматически рассмотреть возможность выбора для известных хороших браузеров.

Ответ 2

Я не могу добавить намного больше, чем 'user113215' уже сказал. Также это не ответ на реальный вопрос, а скорее на реальную проблему:

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

Спасибо. г

Ответ 3

Короче говоря, нет. Как мы определяем гладкость анимаций и графики, зависит только от FPS (кадр за секунду). И в этом вопросе мы говорим о "веб-приложениях", которые используют HTML и JS на стороне клиента. Поскольку ни одна из клиентских сторон не предоставляет интерфейс для программ для получения FPS с помощью HTML или JS, невозможно определить, является ли клиент гладким или нет.

Однако, если вам действительно нужен тест производительности веб-приложения. Вы можете использовать stats.js для контроля изменения стата и иметь ориентир для того, чтобы вы предлагали вашему клиенту активировать или отключать какие-либо эффекты во время выполнения. Этот метод даже работает с большинством FXs Javascript-библиотек, таких как jquery. Но вам потребуется некоторое время, чтобы получить достаточное количество данных, прежде чем применять изменения, и статистика может отличаться от состояния устройства, например, использования памяти, одновременных приложений и т.д.