Каковы общие источники PhoneGap с проблемами производительности jQuery Mobile? - PullRequest
17 голосов
/ 24 октября 2011

У меня есть приложение, написанное с использованием PhoneGap 1.0 и jQuery Mobile 1.0b2, работающее на iPhone и iPad.

С тех пор, как я начал использовать фреймворк, меня мучают проблемы с производительностью при переключении между "страницами" в приложении. После нажатия кнопки перед переходом наступает хорошая вторая пауза, иногда дольше. Я попробовал все настройки веб-набора и даже ждал обновлений в обеих платформах (я начал с Phongap 0.95 и jQuery Mobile Alpha 4), и эта проблема не была решена.

Я использую как можно больше «встроенных» объектов (вместо пользовательских кнопок) и использую свои собственные фоновые изображения PNG на каждом экране. Само приложение состоит только из 3 страниц плюс страница, которая служит экраном параметров.

Вместо того, чтобы искать конкретное решение, я хотел бы знать, какие существуют общие проблемы с производительностью при работе с PhoneGap и jQuery Mobile для iOS? Таким образом, другие люди могут искать контрольный список вариантов при решении своих собственных проблем

Ответы [ 8 ]

22 голосов
/ 28 октября 2011

Одним из самых больших различий между запуском вашего приложения jQuery Mobile в Safari и его запуском в UIWebView на родной iOS является отсутствие движка Nitro.Он был представлен в iOS 4.3.Благодаря этому в Safari JavaScript обрабатывался примерно вдвое быстрее, но им не удалось встроить его в нативные приложения или полноэкранные кэшированные веб-приложения.Начиная с 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% приложений когда-либо обнаруживаются, и их период полураспада составляет всего несколько недель.Тогда у вас будет кошмар обслуживания выпуска обновлений при каждом обновлении ОС.Есть много преимуществ, чтобы просто выпустить только через Интернет.С помощью одного обновления вы можете обновить всех на каждой платформе.Итак, оцените производительность платформы, а также производительность ваших выпусков.

5 голосов
/ 15 августа 2012

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 говорит об этом ... (поэтому я советую тщательно проверить vclick или tap на вашем тестовом устройстве):

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

Хорошая дискуссия по этому вопросу здесь: http://forum.jquery.com/topic/how-to-remove-the-300ms-delay-when-clicking-on-a-link-in-jquery-mobile#14737000003088725

2 голосов
/ 01 ноября 2011

У меня был некоторый успех в удалении текста и тени от блока, что является довольно простым 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/

1 голос
/ 15 декабря 2012

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

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

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

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

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

   return false;
});

С этим все будет правильно и без побочных эффектов ... :)

1 голос
/ 31 марта 2012

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

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

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

Этот код имеет смысл, если вы об этом думаете. Размещает все элементы в одной плоскости.

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

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

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

0 голосов
/ 15 декабря 2012

Чтобы улучшить скорость перехода, просто установите продолжительность перехода как: -

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

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

0 голосов
/ 18 ноября 2011

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

0 голосов
/ 01 ноября 2011

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

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

  1. Отключение переходов страниц (если вы хотите сохранить JQM)
  2. Рассмотрим другой фреймворк, например iWebKit (нестоль же причудливый, как JQM, но быстрый в Phonegap)

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...