App Development: HTML5 application Acceleration solution in Hybrid architecture

In the Mobile APP development field, the mainstream development mode can be divided into Native, Hybrid, WebApp three kinds of ways. However, in 2013 years, the development of pure WEBAPP development has been a setback, and the independent App, represented by Facebook, has been transferred to the Native camp. But the developer's desire to update WebApp quickly and across platforms has not diminished, and the end result has been a surge in the number of Hybrid apps in 2013, and the rate of growth is very fast. Simply put, the Hybrid app is a hybrid of the Native app and Mobile Web, and HTML5 's pages are embedded in the webview of the Natvie app. So it combines the advantages of fast update speed, good interaction experience and cross-platform.

This article shares a solution for HTML5 pages, especially embedded H5 applications, to improve their loading speed and performance with the Hybrid architecture. This program requires you to make the following three-step transformation of the Hybrid App:

One: Modular your H5 page/ application, Introduction of module loader (optional)

Module Loader Needless to say, Seajs, Requirejs, Kissy loader and so familiar, let you choose. Using a modular approach to develop your application will not only facilitate later code maintenance, but will also benefit performance improvements in the Hrbrid architecture.

Perhaps you have questions: the finer the granularity of module development, the more static resources such as JS and CSS are requested when loading, the page performance will not be worse? My answer is: If you just use the module loader and load each module asynchronously, the load performance must be poor because the number of requests is too large. Of course, you would have thought of packaging and merging static resources before the release, so I can only give 50 points for such a solution, because as long as one of the files in the package merged file changes, then the entire file (JS or CSS) will be re-downloaded, the mobile bandwidth is still a burden.

How did it break? Please proceed to step two:

Two: Enable AppCache and introduce the incremental update mechanism

The students who have done WebApp should understand the Mainfest file, HTML5 provides the application cache function, the developer only need to cache the static resource file name listed in this list can guarantee two times access without reloading. It looks good! In this case, the problem of too many requests for modular development, at least two visits, will not happen again. Well, that would give you a 70-point plan. In fact, HTML5 provides the mainfest cache mechanism has a relatively large problem (compatibility will not mention): If a resource file in the Mainfest list needs to be updated, then the entire mainfest of the other files will need to be downloaded again. In other words, there are no problems with two visits, but the full-volume download will still occur when the HTML5 app is updated.

Don't forget, we are Hybrid app, also can take full advantage of Native layer's power, so abandon mainfest bar, let Native to help HTML5 application cache static resource file. The general idea is:

1, HTML5 application for the first time, call the Native provided by the load resource file dedicated Device API to request the required resource files, the Native layer issued a real resource request and cache the request results on the phone's SD card. Of course, this can be fully optimized for a ZIP package request because native can provide a powerful decompression capability.

2. When the H5 application starts again, all static resources are read locally via the Device API, eliminating the need to go to the network.

3. When static resource update occurs in H5 application, first load the files that need to be updated through the Device API and update the local cache when the application starts, and the other unchanged files continue to go cache.

The process looks smooth, with several key issues to be addressed:

1. How to load resource files through the Device API?

Here the advantages of using the module loader is reflected, only need to make small changes in the loader, do not go directly to the HTTP request, and directly call the Native provided by the file load Deviceapi can be. If you don't have a module loader, you'll need to write a unified function to load the resources.

In fact, Native also provides an interception mechanism to intercept all Http requests made by the H5 application and customize the processing, but such good functionality is not supported in versions Andorid 4.0. Therefore, the active call Device API is more reliable at this stage.

2, how to know the need to update the resources?

each static resource release generates a unique publish timestamp (or MD5 encoding of all resource contents), the H5 app starts, the current timestamp can be saved, and so on the next time the application starts, the latest publish timestamp is requested and compared with the local timestamp, if different, the first static Incremental update of the resource.

3. How to determine which resource files need to be replaced by incremental updates?

The answer to this question will be more complicated, the core idea is through the two resources files (JS, CSS, image, etc.) published content comparison completed:

In this way, the H5 application uses the ability of the Native application to complete the cache and incremental update of the resources, which guarantees the load speed of the H5 application at startup and update. Of course there are programs that use HTML5 's localstorage to replace the Native cache update policy, but receive a two-point limit:

1, if the Hybrid App is more complex, involving multiple subdomains or even the primary domain of static resource sharing, then the Localstorage scheme has a limit on storage space, is 5M.

2, Native can support the update package ZIP package download, one request, and decompression overwrite the local cache. Localstorage cannot be implemented.

If the application can ignore the above two points, the policy using the Localstorage cache is fully OK.

Three: Enable the Spdy protocol

Spdy protocol in Mobile development, it is an enhanced version of the HTTP protocol, the ability to request through a TCP link at the same time to multiple resource files, the request speed of ascension that is natural, very powerful! Chrome and other WebKit kernel browsers are already supported. Unfortunately, using the Spdy protocol with the browser itself requires that the static resource file (JS, CSS, image) must be the domain name service for HTTPS and that a background server that supports the SPDY protocol is deployed. It is believed that most static servers are HTTP services and cannot be directly supported by a browser.

Or that sentence, because we are hybrid application, can play native advantage! The native layer is fully capable of implementing a device API based on the SPDY protocol request, which can be invoked by the H5 application (JS). This makes it possible to use Spdy without an HTTPS domain name server.

If your Hybrid application already supports the Spdy protocol, then you can consider no longer need to package the incremental update of the resource files into a zip download, directly spdy protocol parallel download!

SPDY vs. HTTP protocol speed:

Summarize:

This paper provides a H5 application loading performance optimization scheme based on Hybrid architecture, and if you have any questions or suggestions, you are welcome to discuss it in the blog of Stone breaking.

App Development: HTML5 application Acceleration solution in Hybrid architecture