Каковы общие источники PhoneGap с проблемами производительности jQuery Mobile?

Ответ 1

Одно из самых больших различий между запуском вашего приложения jQuery Mobile в Safari и его запуском в UIWebView в родной iOS - это отсутствие движка Nitro. Он был представлен в iOS 4.3. Это сделало обработку JavaScript примерно в два раза быстрее в Safari, но они не смогли создать ее в родные приложения или полноэкранные кешированные веб-приложения. Начиная с iOS 5, двигатель Nitro был доставлен на остальную платформу.
http://arstechnica.com/apple/news/2011/06/ios-5-brings-nitro-speed-to-home-screen-web-apps.ars

Помимо двигателя Nitro существуют другие возможные проблемы с производительностью, связанные с jQuery Mobile и переходами на страницы. Чем медленнее платформа, тем более заметны флюки. Иногда он может проявляться в виде белого мерцания между визуализацией страниц. В других случаях он может проявляться как: переход на новый экран - переход на предыдущий экран - переход на новый экран. Эти флюки несовместимы и могут быть адом, чтобы попытаться выяснить, почему именно это происходит. Более новые и более быстрые устройства имеют меньше проблем с этим, так что хорошая новость, со временем эта проблема исчезнет. Построим для будущего, устройства скоро догонят.

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

$(document).bind("mobileinit", function(){
  $.mobile.defaultPageTransition="none";
});

Кроме того, (и это распространяется на сообщество в целом, которое может это прочитать)... серьезно подумайте, нужно ли вам иметь собственное приложение. Если вам не требуется PhoneGap для доступа к фотоаппарату, гироскопам или какой-либо другой аппаратной поддержке, которую Safari не может предложить, вы всегда получите лучшую производительность, просто используя Интернет. Я понимаю, что есть желание иметь "магазин приложений", но только 1% приложений когда-либо обнаруживаются, а их половина жизни - всего несколько недель. Тогда у вас есть кошмар для обслуживания выпуска обновлений, когда есть обновление ОС. Есть много преимуществ, которые можно просто выпускать только через Интернет. С одним обновлением вы можете обновлять всех пользователей на каждой платформе. Итак, рассмотрим производительность платформы, но также рассмотрим производительность ваших релизов.

Ответ 2

jQuery Mobile обеспечивает задержку примерно 300 мс до того, как функция JavaScript вызывается для нажатия кнопок на сенсорных устройствах. Это устраняет проблему на сенсорных устройствах, где, если нажатая кнопка изменяет содержимое под ним (например, изменение страницы), тогда щелчок также может быть интерпретирован на том содержимом, которое заменяет кнопку.

Когда пользователь отводит свой палец от кнопки после нажатия, событие touchend вызывается сразу, а за ним следует vclick, а затем событие tap. Затем у вас есть 300 мс до того, как вызываются события click, mousedown и mouseup.

Итак, если вы выполните любое из следующих действий, вы получите задержку в 300 мс:

$('#myButton').bind('click', ...
$('#myButton').click( ...
<div id='myButton' onClick='changePage()' ...

Поэтому вместо этого вы должны привязать событие vclick или tap к кнопке, подобной этой (я считаю, что vclick немного быстрее, чем tap):

$('#myButton').bind('vclick', function(ev) {
    ev.preventDefault();
    //Your code
});

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

jQuery Mobile Documentation говорит об этом... (поэтому мой совет - тщательно протестировать vclick или tap на вашем тестовом устройстве ):

Мы рекомендуем использовать клик вместо vclick в любое время, когда действие будет имеет возможность изменения содержимого под который был затронут на экране. Это включает переходы страниц и другие виды поведения, такие как сбой/расширение, что может привести к сдвиг экрана или полностью заменяемый контент.

Хорошее обсуждение здесь: http://forum.jquery.com/topic/how-to-remove-the-300ms-delay-when-clicking-on-a-link-in-jquery-mobile#14737000003088725

Ответ 3

У меня был некоторый успех с удалением текста и тени в ящике, что является довольно простым CSS:

.ui-shadow, .ui-btn-up-a, .ui-btn-hover-a, .ui-btn-down-a, .ui-body-b, .ui-btn-up-b, .ui-btn-hover-b, .ui-btn-down-b, .ui-bar-c, .ui-body-c, .ui-btn-up-c, .ui-btn-hover-c, .ui-btn-down-c, .ui-bar-c, .ui-body-d, .ui-btn-up-d, .ui-btn-hover-d, .ui-btn-down-d, .ui-bar-d, .ui-body-e, .ui-btn-up-e, .ui-btn-hover-e, .ui-btn-down-e, .ui-bar-e, .ui-overlay-shadow, .ui-shadow, .ui-btn-active, .ui-body-a, .ui-bar-a {
    text-shadow: none;
    box-shadow: none;
    -webkit-box-shadow: none;
}

Как Шейн G сказал, что механизм Nitro JavaScript не используется для UIWebViews в версиях до iOS 5.0, однако на устройствах с iOS 5.0 или выше движок JavaScript будет чувствовать примерно в два раза быстрее в родных приложениях и домашних веб-приложениях.

Всегда существует возможность создания манифеста кэша HTML5, поэтому вы можете работать в автономном режиме, но все равно выполняться в Safari: http://www.html5rocks.com/en/tutorials/appcache/beginner/

Ответ 4

Этот фрагмент действительно помог производительности моего мобильного приложения PhoneGap/JQuery Mobile для iOS. У меня были те же проблемы и для мобильного сайта, который я строил в прошлом году, и помню, как использовать 1/2 секунды затухания с помощью jQuery, чтобы смягчить его, но это решение - находка:

* {
    -webkit-transform: translateZ(0);
  }

Первоначально из блога Drew Dahlman: http://www.drewdahlman.com/meusLabs/?p=135

Этот код имеет смысл, если вы думаете об этом. Помещает все элементы в одну и ту же плоскость.

Кроме того, я недавно видел в этом блоге о подобном взломе: http://jessefreeman.com/articles/room112-phonegap-exploration/

 * {
    -webkit-transform: translate3d(0,0,0);
   }

Я еще не тестировал это, но думал, что добавлю его, если он поможет кому-то.

Ответ 5

Еще один способ улучшить производительность приложения PhoneGap: -

Как сказал @Kimm: -

$('#myButton').bind('vclick', function(ev) {
   ev.preventDefault();
   //Your code
});

Здесь ответ будет намного лучше, чем .click, но система может распространять событие в некоторых случаях, что приводит к непредсказуемому поведению. Для решения этой проблемы используйте: -

$('#myButton').bind('vclick', function(ev) {
    ev.preventDefault();
    //Your code

   return false;
});

Используя это, каждая вещь будет правильной и никаких побочных эффектов...:)

Ответ 6

JQueryMobile довольно медленный в Phonegap, переходы - серьезная проблема.

Повышенная производительность для вашего приложения может быть достигнута с помощью

• Отключение переходов страниц (если вы хотите сохранить JQM)
• Рассмотрим другую структуру, такую ​​как iWebKit (не так, как JQM, но быстро в Phonegap)

Я лично пробовал # 1, но это не давало желаемого опыта пользователя. Это привело к варианту №2 и более быстрому пользовательскому опыту.

Ответ 7

Попробуйте обновить программное обеспечение. PhoneGap 1.2 + jQueryMobile 1.0 (выпущенный сегодня) демонстрирует большие успехи в производительности для меня до сих пор.

Ответ 8

Для улучшения скорости перехода просто установите продолжительность перехода как: -

.in, .out {
-webkit-animation-duration: 250ms !important;
}

В приведенном выше случае продолжительность перехода составляет 250 мс.