Некоторые устройства Android чрезвычайно медленны при рендеринге элементов холста

Я разрабатываю приложение для устройств Android и обнаружил, что samsung galaxy S4 специально имеет чрезвычайно низкую производительность, когда приложение/веб-страница использует холст. Странно, что это не всегда так.

Я тестировал 2 примера приложений.

http://ie.microsoft.com/testdrive/Performance/FishIETank/Default.html

http://ie.microsoft.com/testdrive/Graphics/TouchEffects/Default.html

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

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

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

Есть ли способ решить проблему с холстом на Samsung S4... и, возможно, другие устройства Android, работающие на 4.2.x. Если у пользователей StackOverflow есть S4, можете ли вы протестировать обе демоверсии и подтвердить мои наблюдения?

Ответ 1

Я сильно подозреваю, что это не проблема с Canvas, а проблема requestAnimationFrame. Первая анимация не пытается использовать requestAnimationFrame, но вторая делает в этот файл на line 206.

Android-браузер на прошивках <= 4.2 не поддерживает requestAnimationFrame и вместо этого использует setTimeout, разделяя одну секунду на заданную частоту кадров в Гц, которая выполняет рендеринг в обычном цикле событий.

setTimeout не выполняется в точечное время в миллисекундах, но завершает событие в цикле в указанное время. Если цикл события висит на другом javascript на странице, или одноядерное устройство решает, что что-то еще более важно, среда выполнения очень уязвима для де-приоритезации без API requestAnimationFrame, а обратные вызовы в очереди с использованием setTimeout будут заикаться и сгущаться. Подробнее о setTimeout разрешении и времени.

К сожалению, вы находитесь на милость очереди событий, если вы (1) собираетесь использовать этот подход на основе Canvas и (2) на платформе, которая не поддерживает requestAnimationFrame. Вот справочная таблица, для которой браузер поддерживает эту функцию.

Ура!