Производительность мобильных JS приложений

Очень часто сталкиваюсь с высказываниями людей — «у веб-приложений не оправданно плохая репутация низкой производительности, они могут работать столь быстро/хорошо, как их нативные аналоги!»

Например, в блоге Mozzila (https://hacks.mozilla.org/2012/11/html5-mythbusting/), есть публикации под заголовками «аппаратное ускорение CSS / WebGL решает все проблемы». Или публикация от Sencha (http://www.sencha.com/blog/the-making-of-fastbook-an-html5-love-story), которая была направленна на «критику» Facebook, за переход от веб-приложения к нативному.

Я не буду в даваться в демагогии откуда берутся такие посты и для чего?! Ниже сравнения SunSpider JS Perfomance (чем «меньше» тем производительнее)

AMR-js

Как Вам картинка ?

А теперь давайте вспомним, что по мимо V8 от Google, у Apple есть свой движок JS Nitro — попробуем его отключить ? Кстати, Apple так и не разрешил Google включить Nitro в браузер Chrome на мобильных устройствах.

AMR-not-nitro

 

Хотя, если Вы подразумеваете что веб-приложение это сайт с двумя кнопками, то можно не делать benchmarkов и продолжать жить далее в этом «минимальном мире». Но, если вы подразумеваете, что веб-приложение это — работа с изображениями, использование local storage, анимация, анимация между экранами и т.д., надеюсь, Вы задумаетесь, делать ли такое веб-приложение на базе ARM.

Я не буду спорить, что можно, можно сделать оптимизированное/производительную версию веб-приложения для мобильных устройств, если —, если есть хорошие специалисты. Но, стоит ли тратить силы/время/деньги таких специалистов?

Современный мир технологий постоянно движется вперед. Чипсеты ARM так же становяться производительнее и быть может уже через несколько лет мы сможем полноценно портировать на мобильные устройства современные десктоп приложения.

Javascript & HTML5 — optimization tips

Workers & Timers

• Никакая операция в JavaScript-сценарии не должна выполняться дольше 100 мс. Более длительные операции будут вызывать заметные задержки реакции пользовательского интерфейса и создавать негативные впечатления у пользователя.
• Броузеры по-разному реагируют на действия пользователя, производимые во время выполнения JavaScript-еценариев. Но независимо от поведения броузера у пользователя складываются отрицательные впечатления, когда выполнение сценария продолжается слишком долго.
• Применение таймеров позволяет отложить выполнение программного кода на более поздний срок, что дает возможность делить продолжительные операции на последовательности более мелких заданий.
• В новых версиях броузеров появился новый инструмент — фоновые потоки выполнения, с помощью которых можно выполнять программный код на JavaScript за пределами главного потока выполнения и тем самым предотвратить блокирование пользовательского интерфейса.

Language Tips

• Избегайте повторной интерпретации за счет отказа от использования функции evalQ и конструктора FunctionQ. Кроме того, функциям setTimeoutQ и setlntervalQ желательно передавать не строки, а ссылки на функции. Continue reading “Javascript & HTML5 — optimization tips” »