CODEWITHSUNDEEP
iosperformancejquery-mobilecordova
Dillie-O
Dillie-O

Reputation: 29725

What are common sources of PhoneGap with jQuery Mobile performance issues?

I have an application written using PhoneGap 1.0 and jQuery Mobile 1.0b2 running on iPhone and iPad.

Ever since I started using the framework, I have been plagued by performance issues switching between "pages" in the application. After pressing the button, there is a good second pause, sometimes longer, before the transition occurs. I've tried all of the webkit tweaks out there, and I've even waited for upgrades in both frameworks (I started with Phongap 0.95 and jQuery Mobile Alpha 4) and this issue has not been resolved.

I'm using as much "built in" objects as possible (instead of custom button images) and I use my own PNG backgrounds on each screen. The application itself only consists of 3 pages, plus a page that serves as an options screen.

Instead of looking for a specific solution, I'd like to know what are some of the common issues surrounding performance exist when working with PhoneGap and jQuery Mobile for iOS? That way other people can look for a checklist of options when dealing with their own problems

Upvotes: 17

Views: 4611

Answers (8)

Aamir Shah
Aamir Shah

Reputation: 4493

Another way to improve the performance of the PhoneGap App is as follows :-

As @Kimm said :-

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

Here the response will be far better than .click but the system may propagate the event in some cases which results in an un-expected behaviour. To solve this problem use :- 

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

   return false;
});

Using this every thing will be proper and no side effects... :)

Upvotes: 1

Aamir Shah
Aamir Shah

Reputation: 4493

To improve the transition speed simply set the transition duration as :- 

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

In the above case the transition duration is 250 ms.

Upvotes: 0

Timm
Timm

Reputation: 12753

jQuery Mobile enforces a delay of roughly 300ms before the JavaScript function is called for buttons 'clicked' on touch devices. This resolves an issue on touch devices where by if the button clicked changes the content underneith it (e.g. a page change), then the click may also be interpreted on that content that replaces the button.

When the user takes their finger off the button after pressing it, a touchend event is called straight away followed closely by a vclick and then a tap event. Then you have the 300ms before the click, mousedown and mouseup events are called.

So if you do any of the following you will get that 300ms delay:

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

So instead you should bind a vclick or tap event to the button like this (I believe vclick is a bit faster than tap):

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

You could also bind to the touchend event, but this can give some undesired effects, but try it out.

The jQuery Mobile Documentation says this... (so my advice is to test vclick or tap on your test device thoroughly):

We recommend using click instead of vclick anytime the action being triggered has the possibility of changing the content underneath the point that was touched on screen. This includes page transitions and other behaviors such as collapse/expand that could result in the screen shifting or content being completely replaced.

A good discussion on this is here: http://forum.jquery.com/topic/how-to-remove-the-300ms-delay-when-clicking-on-a-link-in-jquery-mobile#14737000003088725

Upvotes: 5

Paul
Paul

Reputation: 1159

This snippet has really helped the performance of my PhoneGap/Jquery Mobile native app for iOS. I had the same issues also for a mobile site I was building last year and remember using 1/2 second fades with jQuery in order to tone it down, but this solution is a godsend:

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

Originally from Drew Dahlman's blog: http://www.drewdahlman.com/meusLabs/?p=135

This code makes total sense if you think about it. Puts all elements on the same plane.

Also, I've recently seen on this blog about a similar hack: http://jessefreeman.com/articles/room112-phonegap-exploration/

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

I haven't tested this yet, but thought I'd add it if it ends up helping someone.

Upvotes: 1

Doctuh D.
Doctuh D.

Reputation: 395

Try updating your software. PhoneGap 1.2 + jQueryMobile 1.0 (released today) are showing large performance gains for me so far.

Upvotes: 0

CM.
CM.

Reputation: 519

JQueryMobile is fairly slow on Phonegap, transitions are a major problem.

Improved performance for your app could be accomplished by -

  1. Turning off page transitions (if you want to keep JQM)
  2. Consider another framework like iWebKit (not as fancy as JQM, but fast in Phonegap)

I personally tried #1, but it did not give the desired user experience. That led to option #2 and a faster user experience.

Upvotes: 0

Jasper
Jasper

Reputation: 75993

I've had some success with removing text and box shadow, which is some fairly simple 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;
}

As Shane G said, the Nitro JavaScript engine is not used for UIWebViews in pre iOS 5.0 releases however on devices that have iOS 5.0 or greater the JavaScript engine will feel about twice as fast in native apps and homescreen-web-apps.

There is always the option of creating a HTML5 cache manifest so you're website can function offline but still be run in Safari: http://www.html5rocks.com/en/tutorials/appcache/beginner/

Upvotes: 2

sgliser
sgliser

Reputation: 2071

One of the biggest differences between running your jQuery Mobile app in Safari and running it in UIWebView in native iOS is the lack of the Nitro engine. It was introduced in iOS 4.3. It made JavaScript processing about twice as fast in Safari but they failed to build it into native apps or fullscreen cached webapps. As of iOS 5, the Nitro engine was brought to the rest of the platform.
http://arstechnica.com/apple/news/2011/06/ios-5-brings-nitro-speed-to-home-screen-web-apps.ars

Beyond the Nitro engine, there are other possible performance issues surrounding jQuery Mobile and page transitions. The slower the platform, the more noticeable the flukes are. Sometimes it can manifest as a white flicker between page renderings. Other times, it can manifest as: transition to new screen - flash to previous screen - flash to new screen. These flukes are not consistent and can be hell to try to figure out exactly why it's happening. Newer and faster devices have less of a problem with this so the good news is, over time, this problem will disappear. Build for the future, devices will soon catch up.

That being said, let's also consider performance in terms of how fast users are able to click what they want. Transition quirks are minimized by disabling page transitions. This gives the added benefit of increasing your effective page performance by 500 milliseconds. Page transitions are pretty, but the fact is, they're slow. Performance is a feature. Just turn off the transitions by including this in your custom scripts.

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

Also, (and this goes out to the community at large that might read this)... seriously consider if you need to actually have a native app. Unless you need PhoneGap to access the camera, gyroscopes, or some other piece of hardware support that Safari can't offer, you'll always get better performance by just using the web. I understand the desire to have a presence to have an an "app store" but only 1% of apps are ever discovered and their half life is only a few weeks. Then you have the maintenance nightmare of releasing updates whenever there's an update to the OS. There are a lot of advantages to just releasing only over the web. With a single update, you can have everyone on every platform updated. So, consider the performance of the platform, but also consider the performance of your releases.

Upvotes: 22

Related Questions