Development History of Hybrid app

Development History of Hybrid app

This article does not detail some general technologies related to mobile development, such as viewport, rem, flexbox, and media query. This section describes our hybrid product policies, development processes and specifications, performance optimization, and the pitfalls we have taken. This is often the case where the relevant online materials are relatively scarce and similar experience articles are lacking. I hope to share some experiences of the meizu team on developing hybrid products with you through this article.

Background

1. We hope this type of products can provide powerful operation capabilities;
2. Interface data comes from cp data integration, which may be different and even requires fault tolerance;
3. Fast update and iteration are required.

Android and H5 integration solutions

In the above background, we finally chose the Hybrid App solution. Then, the question that arises one after another is, how does the client access the webpage's front-end resources? Can I access the server Webpage through a browser? The answer is not absolute. Of course, the above method can also be used. There are always different approaches based on different business needs. We use the following two solutions at most:

Static resource localization

This solution first embeds a static resource in the app, and then sends a request to the background when the user starts the app or accesses the html page and meets certain conditions, query resource information. If an update is found, download the latest resource to the local device, and then access the local static resource. If the update fails, it accesses embedded or downloaded static resources.

HTML 5 Application Cache

This solution uses HTML5 application Cache (HTML5 Cache Manifest ). I will not go into details here. There is a lot of information about this on the Internet. It is worth noting that the configuration file of manifest needs to be configured with the correct MIME-type, that is, "text/cache-manifest ".

Generally, the second solution is used when developing some activities or special topics Pages (with a short launch time and a varied ui.

Most of the app pages are relatively stable, or iterative development, regularly updated, and regular. In this case, we adopt the first solution. When using this scheme, we need to strictly control the size of resource files. In addition to necessary compression, we can also extract long-term fixed resources and build them into the app in advance. Therefore, each time you update a resource, you only need to go to the server to obtain the changed part, which greatly reduces the traffic usage.

The above two solutions have obvious advantages over accessing static server resources every time:

1. Offline access
2. Fast resource Loading
3. Low server load

Page loading

First, the client loads a page. After the page is loaded (pagefinish), the client calls the initialization method provided by the front-end (initParams ). This method is used to transmit parameters and initialize pages.

Resource Construction

Currently, we use fis3 to compress, merge resources, and add md5 stamps. Babel is also required for es6 projects. On this basis, we have also developed some internal plug-ins Based on fis3. The ultimate goal is to implement a command line and complete all the build work.

Development Environment Construction

Build a local web service using nodejs + express.

Development Process

We can see that visual design, front-end development, client development, and background development have all achieved parallel development to a large extent.

Next, let's briefly describe how to implement front-end development and backend development, and decouple it from the client, and then implement parallel development.

First, the interface documentation (background interface documentation and client interface documentation) is not a prerequisite for blocking. With the background interface document, we can build the corresponding false data and simulate the corresponding interface request accordingly. With the android interface documentation, we can simulate the call to the client interface, at least to ensure that the basic logic is smooth. Therefore, as long as the interface documentation is available, the front-end, backend, and client are independently developed before the real joint debugging.

Then the joint debugging is divided into three phases:

Joint debugging of simulated false data

At this stage, you only need to write some fake data locally and then use ajax requests. The android interface can also be called through a simulated call. At this stage, the main purpose is to ensure that the front-end logic runs normally.

Real background interface call

At this stage, we need to access local static resources and call the remote server interface. In this case, the problem of cross-origin requests of ajax is mainly solved. There are many implementation methods. The simplest thing is to set up the browser to support cross-origin. Of course, you can also use nginx or apache reverse proxy to implement cross-origin ajax requests.

Joint third-party commissioning

This step is the last step before the test. At this time, the client has been integrated with static resources and then called interfaces, both android and backend server interfaces, are no longer simulated.

Switching between the three joint debugging statuses is often required in development, bug Locating, page debugging, and other situations. For example, when you modify a js logic bug, you generally start with the second joint debugging step. After all, debugging bugs on pc browsers is much more convenient. Then, when the bug is almost changed, the static resources will be pushed to the mobile phone for debugging on the real machine.

Next, a problem arises. How can we achieve flexible switching between the three joint debugging states? Let's look at a piece of code:

2345678910111213141516171819202122

To implement switching between the three joint debugging statuses, we developed a plug-in based on fis3. The function of this plug-in is also very simple, that is, to process the above Code.

What should we do? First, let's take a look at the above Code. It can be divided into two modules. The first is to simulate the code module (Use and package), and the second is the real code module (Use Package ). The simulated code module contains a js file that simulates the android interface, the path of false data, and the initialization interface that simulates android calls. The real code module can write some paths that are required for real online use. Both modules are not required.

What plug-ins need to do is to remove the simulated code module and release the real code module.

Let's talk about the benefits of doing so. In the simulation of the joint debugging of false data, you do not need to use this plug-in. In this case, according to the above Code, the simulation code module is run. Once we need to conduct real interface joint debugging, we need to call this plug-in the parser phase of fis3 to remove the simulated code and use the real code. The use of plug-ins is configured in the configuration file of fis3. Through the media api of fis3, We can dynamically control whether the plug-in is used.

Performance Optimization and pitfalls

This is a big topic. There are so many page optimization guidelines and materials, such as the Fourteen pages of Yahoo that everyone is familiar. Here, I will try my best to list some of our optimization and problems from the perspective of our project.

Image

If not, try not to use it. If necessary, optimization can be performed from multiple perspectives. For example:

1. It is placed on cdn to keep resources closer to users and reduce the transmission of non-essential data such as cookies.
2. Use CSSSprites to reduce the number of requests.
3. UseWebPReduce the image size.
4. Small icons can use base64: URL images.
5. In some cases, you cannot optimize it from a technical perspective. You may need to adjust the ui or product solution without affecting the user experience as much as possible. For example, the ui user sets a background image with irregular Fuzzy Gradient. In this case, you have to retain the Fuzzy Gradient, but make it regular. This can be achieved by capturing a small part of the image and then tiled. Sometimes you have to make such a trade-off and select a compromise.

Viewport

Currently, the following two methods are commonly used to set the width of a view:

1. Fixed write width
2. Set to device width

The first method is simple and convenient, and does not require media queries or rem. One version is applicable to all models. In addition, when the width of the page is relatively large, lines and fonts can be controlled in a more refined manner.

For the second method, most large companies currently use this method on mobile terminals. The performance of this method is higher than the previous one. After all, there is a scaling process missing, and the compatibility is also better.

Therefore, after comparison, we recommend the second method. However, we also found that, in the process of communicating with people from other companies, they still adopt the first approach for various reasons. At the same time, we also have some projects that are implemented in the first way.

In the first method, we found that sometimes the page loading is not very effective, there will be a process of tiled from left to right (in fact, it is a process of scaling ). In fact, the opacity control can be used to optimize the effect.

Animation

Animation must be a pain point of the Hybrid app. It is too difficult to implement animations with similar effects to android in the embedded webview of android, and there will be many pitfalls.

For example, when you create a cinema reservation page, you must be able to scale the selected seat area. With this function requirement, we are about to start development.

For scaling, we first think of the scale value of the transform attribute in css3. Next, we will adopt the scale solution for development.

The history of animation development is always bumpy. Indeed, the problem arises. The seats in the seat selection area are quite blurred after being manually enlarged.

Maybe you want to see if the image is blurred due to the image. Okay. Next, let's try to use css to set the background color for seat painting. However, the result is that the image is blurred when it is enlarged.

In this case, we need to calm down and think about it. Why.

Before describing the cause, introduce another ancient css attribute zoom and talk about the differences between the two:

1. Zoom was a private attribute of IE browser at the beginning. Later, most browsers were compatible with this attribute, but they still failed to write standards. Scale is written to w3c standards.
2. The Rendering sequence is different. Scale: scale the image first, then zoom the image, and then perform rendering.
3. There are many scale-related control parameters, such as the zoom origin and zoom direction. The default zoom origin is the upper left corner, and no direct parameter can be used to modify the zoom origin.

Based on the Differences listed above, we can draw the following conclusions:

1. Zoom is used to zoom, and the visual effect becomes sharp. Scaling will blur the visual effect.
2. Zoom may cause page shuffling. Scaling does not cause page rearrangement.
3. Zooming with zoom is restricted by html Rendering rules. For example, if the minimum font size is 12px, how can you scale down the font size? The font size is still 12px. But scale does not.

Next, let's talk about how to solve the problem of blurred seats after enlarged seats. Based on the above conclusions, two solutions are proposed:

1. Zoom to solve the problem of fuzzy amplification.
2. Scale is used for scaling, but the scale value is set to a greater value for the first time, for example, 3 (3 times the size ). Then, you can set the scale to 1 times by secretly (such as setTimeout.

We will first talk about the optimization of animation, but in fact, there are still many optimizations in the Development of Our hybrid app, of course, there are also a lot of pitfalls. If you are interested, you can try meizu's life service, Activity Center, phone yellow pages and other apps. These apps are more or less developed using the hybrid solution.

Conclusion

At present, front-end technologies are changing with each passing day. We are constantly trying some new technologies (such as react and es6) to keep up with some details, constantly optimize and optimize them. All of this is not the end of a blog post. We will discuss and learn new content later.