In the field of mobile App development, mainstream development models can be divided into three methods: Native, Hybrid, and WebApp. However, in 2013, the development of the pure WebApp development model suffered a certain setback, and independent apps represented by Facebook switched to the Native camp. However, developers’ desire for WebApp updates is fast, and their desire for cross-platform advantages has not diminished. The end result is a rapid increase in the number of Hybrid App in 2013, and the growth rate is very fast. To put it simply, Hybrid App is a product of the mixed development of Native App and Mobile Web. HTML5 pages are embedded in the webview of Natvie App. Therefore, it combines the advantages of fast update speed, good interactive experience, and cross-platform.
This article is sharing a solution for HTML5 pages (especially embedded H5 applications) to improve their loading speed and performance with the help of Hybrid architecture. This solution requires you to modify the Hybrid App in the following three steps:
One: Modularize your H5 page/application and introduce a module loader (optional)
Module loader Needless to say, SeaJS, requireJS, kissy loader, etc. are familiar to you, so you can choose. Using a modular approach to develop your application will not only benefit the later code maintenance, but in the Hrbrid architecture, it will also benefit performance.
Maybe you have questions: The more granular the module development, the more static resources such as JS and CSS are requested during loading, and the performance of the page will not be worse? My answer is: if you just use the module loader and load each module asynchronously, then the loading performance must be poor, because the number of requests is too large. Of course, you will definitely think of packaging and merging static resources before release. Then I can only give 50 points for such a solution, because as long as one sub-file in the packaged and merged file changes, then the entire file (JS or CSS) It has to be re-downloaded, which is still a burden on mobile bandwidth.
How to break? Please proceed to step two:
2: Enable AppCache and introduce incremental update mechanism
Students who have done WebApp should understand the mainfest file, the application cache function provided by Html5, and develop The user only needs to list the static resource file names to be cached in this list to ensure that there is no need to reload during the second visit. Looks good! In this way, the problem of excessive number of requests caused by modular development mentioned above will not happen again at least during the second visit. Well, such a plan can be awarded 70 points. In fact, the mainfest caching mechanism provided by Html5 has a big problem (compatibility will not be mentioned first): if a resource file in the mainfest list needs to be updated, other files in the whole mainfest also need to be downloaded again. That is to say, there is no problem with the second visit, but the problem of full download will still occur when the Html5 application is updated.
Don’t forget, we are Hybrid App and can also take full advantage of the powerful capabilities of the Native layer, so abandon mainfest and let Native help Html5 applications cache static resource files. The general idea is:
1. When the Html5 application is launched for the first time, call the Device API dedicated to loading resource files provided by Native to request the required resource files, and the Native layer sends out the real resource request and sends the request The results are cached on the SD card of the phone. Of course, this can be optimized as a zip package request, because native can provide powerful decompression capabilities.
2. When the H5 application is started again, all static resources are read from the local cache through the Device API, so there is no need to go to the network.
3. When a static resource update occurs in an H5 application, the file that needs to be updated is first loaded through the Device API when the application starts, and the local cache is updated, and other unchanged files continue to be cached.
The process looks smooth, and there are several key issues that need to be resolved:
1. How to load resource files through Device API?
The advantages of using the module loader here are reflected. You only need to make a small modification in the loader, instead of directly making Http requests, you can directly call the file provided by Native to load the DeviceAPI. If you don’t have a module loader, you need to write a unified function to load resources.
In fact, Native also provides an interception mechanism, which can intercept all Http requests sent by H5 applications and perform custom processing. Unfortunately, such good features are not supported in Andorid 4.0 and below. Therefore, it is more reliable to call Device API actively at this stage.
2. How do I know that the resource needs to be updated?
Each time a static resource is released, a unique release timestamp (or MD5 encoding of all resource content) will be generated. After the H5 application is started, the current timestamp can be saved, and the application will be launched next time , Request the latest release timestamp and compare it with the local timestamp. If it is different, the incremental update of the static resource is performed first.
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 to compare the contents published by the two resource files (js, css, image, etc.) before and after:
In this way, the H5 application uses the capabilities of the Native application to complete the caching and increment of resources The update can ensure the loading speed of the H5 application during startup and update. Of course, there are also plans to use HTML5 localstorage to replace Native’s cache update strategy, but they will receive two restrictions:
1. If Hybrid App is more complicated, it involves the sharing of static resources in multiple subdomains or even the main domain. Then the localstorage scheme has an upper limit on the storage space, which is 5M.
2. Native can support the zip package download of the update package, one request, and decompression to cover the local cache. Localstorage cannot be implemented.
If the application can ignore the above two points, the strategy of using localstorage caching is completely ok.
Three: Enable the spdy protocol
The spdy protocol is promising in mobile development. It is an enhanced version of the HTTP protocol. It can request multiple resource files at the same time through a TCP link. The request speed It is natural to improve on the upper level, and it is very powerful! Chrome and other webkit kernel browsers are already supported. Unfortunately, if the browser itself uses the spdy protocol, the static resource files (js, css, image) must be https domain name services, and a backend server that supports the spdy protocol is deployed. I believe that most static servers are still http services and cannot be directly supported by browsers.
The same sentence, because we are a hybrid application, we can take advantage of the native! The native layer can fully implement the device API requested by the spdy protocol for H5 applications (JS) to call. In this way, spdy can be used without the https domain name server.
If your Hybrid application already supports the spdy protocol, then you can consider that you no longer need to package the incrementally updated resource files into a zip download, just download the spdy protocol in parallel!
SPDY and HTTP protocol speed comparison:
Summary:
This article provides a H5 application loading performance optimization solution based on the Hybrid architecture. If you have any questions or suggestions, please feel free to discuss it in Shiba’s blog.
Reposted from: http://www.woshipm.com/pd/70862.html
In the field of mobile App development, mainstream development models can be divided There are three ways: Native, Hybrid, and WebApp. However, in 2013, the development of the pure WebApp development model suffered a certain setback, and independent apps represented by Facebook switched to the Native camp. However, developers’ desire for WebApp updates is fast, and their desire for cross-platform advantages has not diminished. The end result is a rapid increase in the number of Hybrid App in 2013, and the growth rate is very fast. To put it simply, Hybrid App is a product of the mixed development of Native App and Mobile Web. HTML5 pages are embedded in the webview of Natvie App. Therefore, it combines the advantages of fast update speed, good interactive experience, and cross-platform.
This article is sharing a solution for HTML5 pages (especially embedded H5 applications) to improve their loading speed and performance with the help of Hybrid architecture. This solution requires you to modify the Hybrid App in the following three steps:
One: Modularize your H5 page/application and introduce a module loader (optional)
Module loader Needless to say, SeaJS, requireJS, kissy loader, etc. are familiar to you, so you can choose. Using a modular approach to develop your application will not only benefit the later code maintenance, but in the Hrbrid architecture, it will also benefit performance.
Maybe you have questions: The more granular the module development, the more static resources such as JS and CSS are requested during loading, and the performance of the page will not be worse? My answer is: if you just use the module loader and load each module asynchronously, then the loading performance must be poor, because the number of requests is too large. Of course, you will definitely think of packaging and merging static resources before release. Then I can only give 50 points for such a solution, because as long as one sub-file in the packaged and merged file changes, then the entire file (JS or CSS) It has to be re-downloaded, which is still a burden on mobile bandwidth.
How to break? Please proceed to step two:
2: Enable AppCache and introduce incremental update mechanism
Students who have done WebApp should understand the mainfest file, the application cache function provided by Html5, and develop The user only needs to list the static resource file names to be cached in this list to ensure that there is no need to reload during the second visit. Looks good! In this way, the problem of excessive number of requests caused by modular development mentioned above will not happen again at least during the second visit. Well, such a plan can be awarded 70 points. In fact, the mainfest caching mechanism provided by Html5 has a big problem (compatibility will not be mentioned first): if a resource file in the mainfest list needs to be updated, other files in the whole mainfest also need to be downloaded again. That is to say, there is no problem with the second visit, but the problem of full download will still occur when the Html5 application is updated.
Don’t forget, we are Hybrid App and can also take full advantage of the powerful capabilities of the Native layer, so abandon mainfest and let Native help Html5 applications cache static resource files. The general idea is:
1. When the Html5 application is launched for the first time, call the Device API dedicated to loading resource files provided by Native to request the required resource files, and the Native layer sends out the real resource request and sends the request The results are cached on the SD card of the phone. Of course, this can be optimized as a zip package request, because native can provide powerful decompression capabilities.
2. When the H5 application is started again, all static resources are read from the local cache through the Device API, so there is no need to go to the network.
3. When a static resource update occurs in an H5 application, the file that needs to be updated is first loaded through the Device API when the application starts, and the local cache is updated, and other unchanged files continue to be cached.
The process looks smooth, and there are several key issues that need to be resolved:
1. How to load resource files through Device API?
The advantages of using the module loader here are reflected. You only need to make a small modification in the loader, instead of directly making Http requests, you can directly call the file provided by Native to load the DeviceAPI. If you don’t have a module loader, you need to write a unified function to load resources.
In fact, Native also provides an interception mechanism, which can intercept all Http requests sent by H5 applications and perform custom processing. Unfortunately, such good features are not supported in Andorid 4.0 and below. Therefore, it is more reliable to call Device API actively at this stage.
2. How do I know that the resource needs to be updated?
Each time a static resource is released, a unique release timestamp (or MD5 encoding of all resource content) will be generated. After the H5 application is started, the current timestamp can be saved, and the application will be launched next time , Request the latest release timestamp and compare it with the local timestamp. If it is different, the incremental update of the static resource is performed first.
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 to compare the contents published by the two resource files (js, css, image, etc.) before and after:
In this way, the H5 application uses the capabilities of the Native application to complete the caching and increment of resources The update can ensure the loading speed of the H5 application during startup and update. Of course, there are also plans to use HTML5 localstorage to replace Native’s cache update strategy, but they will receive two restrictions:
1. If Hybrid App is more complicated, it involves the sharing of static resources in multiple subdomains or even the main domain. Then the localstorage scheme has an upper limit on the storage space, which is 5M.
2. Native can support the zip package download of the update package, one request, and decompression to cover the local cache. Localstorage cannot be implemented.
If the application can ignore the above two points, the strategy of using localstorage caching is completely ok.
Three: Enable the spdy protocol
The spdy protocol is promising in mobile development. It is an enhanced version of the HTTP protocol. It can request multiple resource files at the same time through a TCP link. The request speed It is natural to improve on the upper level, and it is very powerful! Chrome and other webkit kernel browsers are already supported. Unfortunately, if the browser itself uses the spdy protocol, the static resource files (js, css, image) must be https domain name services, and a backend server that supports the spdy protocol is deployed. I believe that most static servers are still http services and cannot be directly supported by browsers.
The same sentence, because we are a hybrid application, we can take advantage of the native! The native layer can fully implement the device API requested by the spdy protocol for H5 applications (JS) to call. In this way, spdy can be used without the https domain name server.
If your Hybrid application already supports the spdy protocol, then you can consider that you no longer need to package the incrementally updated resource files into a zip download, just download the spdy protocol in parallel!
SPDY and HTTP protocol speed comparison:
Summary:
This article provides a H5 application loading performance optimization solution based on the Hybrid architecture. If you have any questions or suggestions, please feel free to discuss it in Shiba’s blog.
Reprinted from: http://www.woshipm.com/pd/70862.html