How To Create An App For All Platforms On PhoneGap

Despite the growing processing powers of modern mobile devices, PhoneGap-based apps generally don’t do well at satisfying the growing demands to the visual richness of modern apps. This problem is solved through understanding:

1. the specificity of the platform, on which the app code is executed (mobile webView)
2. the processes which take place while preparing and displaying the content of the page.

The upcoming report will show the problematic moments in code execution, and the ways to solve them, with examples.

Execution Environment

The program code of PhoneGap is all executed in mobile webView — the browser which is built in your app. It plays the role of a wrap, or virtual environment for execution of your functional code.
The inner limitations and specificity of app execution are imposed by the architecture of the in-built browser.

How modern browsers work

What can we do to speed up our app? How can we make the responsiveness of our app not dependent on the processing power of the device it’s running on? One should consider the following:

 

Excessive (Slow) DOM:

As one can see from the scheme, DOM is basically a separate functional part in the browser. Owing to the fact that the document object model is stored in the memory as it is, processing/manipulation with the data, namely with DOM, requires time. The more data (the bigger DOM), the more time is required for manipulation.

The solution is unloading DOM as much as possible. There are four ways of achieving it:

1. Making the layouting as simple as possible — this will simplify and lighten the DOM structure.
2. Detach the unnecessary (temporarily invisible) parts of the application from the main DOM branch, which is rendered. This will not only increase the rendering speed, but will also allow to faster manipulate with the main DOM branch, which will have minimal number of nodes.
3. Use of the buundle of classic patterns for rendering big amounts of ‘heavy’ visual info: Flyweight+factory(adapter) and etc.
4. Rendering application pages from templates.

One should also consider advantages and drawbacks of these approaches and choose as appropriate.

 

Custom DOM events:

If you need fast performance — avoid custom DOM events when possible. During their distribution are involved both JavaScript and DOM mechanisms of the browser — which in turn requires additional time for synchronization between these mechanisms. This doesn’t run as fast as desired.

 

Cache Everything:

As was mentioned above, work with DOM takes time, that’s why cache everything whenever possible. This means, save links to frequently operated DOM nodes in JavaScript variables — thus don’t waste time on selection.

 

Keep It Simple, Keep It Flat (Rendering):

The simpler the visual style of an app, the better it is for performance and responsiveness. This can be seen in the latest design trends: flat or material by Google. These approaches stick to minimal use of complex design (such as shades or semitransparency), which in turn simplifies the algorithm of rasterization of visual representation and decreases the load on the CPU of the mobile device.

 

GPU Animation (Rendering):

The majority of modern smartphones and tablets has a GPU; it allows to speed up the animation by means of representing visual parts of the app as textures in GPU, and animating them.

 

Animation with CSS

But you should keep an eye on the following:

1. data mustn’t change during CSS animation, since it will require additional rendering;
2. the layers, which are not accelerated in GPU, mustn’t overlay the accelerated ones — this will cause lags by excessive rendering.

Separate & Manage CSS Layouts (Rendering):

In some cases, for example, when layers have position :absolute or fixed, but also in other cases other cases. These elements are drawn out of the main calculation flow; that’s why when the content of these layers is changed, there is no recalculation of the location of other elements on the page, which are situated in other layers.

That’s why, if you have app page elements, which you need to animate, or which contain frequently changing content — the most effective solution will be to remove this functionality into a separate CSS layer.

Try to use developer’s tools, for example, in Chrome, in order to see these layers and utilize them with maximum effectiveness.

 

Image Scaling (Rendering):

Try not to scale the size of your images in the app. Each resizing is a recalculation at the expense of the processing power and time. Along with the fact that most browsers execute all operations in one flow, it brings undesirable consumption of time for recalculation. It will be better to have images in several sizes beforehand.

 

Give It Rest (Browser Execution Flow):

Use segmentation of your app execution flow into smaller operations; launch them via setTimeout() or requestAnimationFrame(). This will allow the browser, in between executing the code of your app, to perform critical overhead operations, such as recalculation or reflow. This will also improve the general impression about the performance of your app.

Differences, advantages and drawbacks of each approach will be discussed during the presentation of our report.

 

Garbage Collector (Save Memory Patterns):

Now we should discuss the most annoying (from end user’s point of view) problems: small and short fades, which sometimes appear at random.
The main cause of these fades is Garbage Collector, which, while it’s functioning, stops the work of all flows in the browser. The thing is, it’s much more aggressive on mobile devices than on desktops.
That’s why to avoid these fades, you should use templates in development, which will rid you of creating temporary objects (which become useless once used). These templates are:

1. constant objects for storing temporary data
2. object pools

All this and much more will be discussed during the presentation of our report.

 

This guest post was written by Yurii Luchaninov (MobiDev).