Hybrid app development process sharing_PHP tutorial

Hybrid app development history sharing

Regarding this topic, this article is not going to detail some common technologies related to mobile development, such as: viewport, rem, flexbox, media query, etc. Here we mainly talk about our hybrid product strategy, development process and specifications, performance optimization, and the pitfalls we have overcome. These are often the ones where relevant information on the Internet is relatively scarce, and similar experience articles are lacking, so I hope to share with you some of the Meizu team’s experience in hybrid product development through this article.

Product background

1. We hope that this type of product has relatively strong operational capabilities;
2. The interface data comes from cp data integration, and there may be certain differences. stability, and even requires a certain degree of fault tolerance;
3. requires the ability to achieve rapid updates and iterations.

Android and H5 integration solution

Under the above background, we finally chose the Hybrid App solution. So, the next question is, how should the client access the front-end resources of the web page? Can I just use the previous method of using browsers to access server web pages? The answer is not absolute, of course the above methods can also be used. According to different business needs, the methods will always be different. We use the following two solutions the most:

Static resource localization

This solution will first embed a static resource in the app, and then when the user starts the app or accesses the html page And if certain conditions are met, a request will be sent to the background to inquire about the resource status. If an update is found, the latest resources will be downloaded locally, and then all the users will access are local static resources. If the update fails, then he accesses embedded or downloaded static resources.

HTML 5 application cache

This solution actually uses HTML5 application cache (HTML5 Cache Manifest). I won’t go into details here, there is a lot of information about this online. What is worth noting is that the manifest configuration file needs to be configured with the correct MIME-type, that is, "text/cache-manifest".

Usually the second option is used when developing some activities or special pages (the online time is short and the UI changes a lot).

Most app pages are relatively stable, or developed iteratively, updated regularly, and have regularity. In this case, we adopt the first solution. When adopting this solution, 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. Then, every time the user updates a resource, he only needs to go to the server to obtain the changed part, which greatly reduces traffic usage.

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

1. Offline access
2. Fast loading of resources
3. Low server load

Page loading

First, the client loads a page. After the loading is completed (pagefinish), the client will call the initialization provided by the front end method(initParams). Through this method, the parameters are passed and the page is initialized.

Resource construction

We currently use fis3 for resource compression, merging, adding md5 stamps and other construction functions. For projects using es6, we also need to use Babel. On this basis, we also developed some fis3-based plug-ins for internal use. The ultimate goal is to implement a command line to complete all construction work.

Development environment setup

Build a local web service using nodejs express.

Development Process

From the picture above we can see that visual design, front-end development, client development, and back-end development are all implemented to a large extent parallel development.

Next, let’s briefly describe how front-end development is implemented with the backend, decoupled from the client, and then implemented in parallel.

First of all, interface documents (backend interface documents and client interface documents) are a prerequisite for non-blocking. With the background interface document, we can construct the corresponding fake data and simulate the corresponding interface request. With the Android interface document, we can also simulate calling the client interface, at least ensuring that the basic logic is smooth. Therefore, as long as there is an interface document, before actual joint debugging, the front-end, back-end, and client are developed independently and do not block each other.

Then joint debugging is divided into three stages:

Simulating fake data joint debugging

In this stage, you only need to write some fake data locally, and then use ajax to request it. . The call to the android interface can also be simulated. At this stage, the main purpose is to ensure that the front-end logic is basically running smoothly.

Background real interface call

At this stage, what we need is to access local static resources, but what we call is the interface of the remote server. In this case, the main thing is to solve the ajax cross-domain request problem. There are many ways to implement it. The simplest is to set the browser to support cross-domain. Of course, you can also use nginx or apache's reverse proxy to implement ajax cross-domain requests.

Three-party joint debugging

This step has reached the last step before the preliminary test. At this time, the client has been integrated with the static resources, and the interface called, whether it is the Android interface or the background server interface, is no longer simulated.

Switching between the three joint debugging states is often needed whether in development, bug locating, page debugging, etc. For example, when you modify a certain js logic bug, first of all, you usually start with the second joint debugging step. After all, it is much more convenient to debug bugs on a PC browser. Then, when the bugs are almost corrected, the static resources will be pushed to the mobile phone for real-device debugging.

The next question arises, how to achieve flexible switching of these three joint debugging states? Let’s look at a piece of code:

2345678910111213141516171819202122

In order to achieve switching between the three joint debugging states, we developed a plug-in based on fis3. The function of this plug-in is also very simple, which is to process the above code.

How to deal with it? First, take a look at the above code. It can be divided into two modules. The first is the simulation code module (wrapped with and), and the second is the real code module (wrapped with ). The simulation code module includes a js file introduction that simulates the android interface, the path of the fake data, and the simulated android call initialization interface. The real code module can write some paths that need to be used in real production. Neither module is required.

What the plug-in needs to do is to remove the simulation code module and release the real code module.

Let’s talk about the benefits of doing this. During the stage of simulating fake data joint debugging, this plug-in is not needed. Then according to the above code, the simulation code module is run. Once we want to perform real interface joint debugging, we need to call the plug-in in the parser stage of fis3 to remove the simulation code and use real code. The use of plug-ins is configured in the fis3 configuration file. Through the media api of fis3, we can dynamically control whether the plug-in is used.

Performance Optimization and Pitfalls

This is a relatively big topic. There are a lot of page optimization guidelines and information such as Yahoo’s Fourteen Points that everyone is already familiar with. Here, I will try my best to list some of the optimizations we have made and some of the problems we have solved from the perspective of our project.

Pictures

If you can’t use it, try not to use it. If it must be used, it can be optimized from multiple angles. For example:

1. is placed on CDN to bring resources closer to users, while also reducing the transmission of unnecessary data such as cookies.
2. Use CSSSprites to reduce the number of requests.
3. Use WebP to reduce image size.
4. Small icons can use base64:URL images.
5. In some cases, you cannot optimize 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, a UI student set up a background image with irregular blurred gradients. In this case, you have to retain the blur gradient, but make it regular. This can be achieved by intercepting a small part of the picture and then tiling it. Sometimes you have to make such a trade-off and choose a compromise solution.

viewport

Regarding the setting of the viewport width, there are currently two common methods:

1. Fixed width
2. Set to device width

The first method is simple and convenient, no media query, no rem, etc., one version, suitable for all models. And regarding the issue of page finesse, when the viewport width is set relatively large, lines, fonts, etc. can achieve more refined control.

Regarding the second method, most large companies currently use this method for their mobile terminals. The performance of this method is higher than the previous one. After all, there is one less scaling process, and the compatibility is also better.

So after the above comparison, we recommend the second method. But we also found that in the process of communicating with people from other companies, they still adopted the first method due to various reasons. At the same time, we also have some projects that are also implemented using the first method.

When using the first method, we found that sometimes when the page is loaded, the drawing effect is not very good, and there will be a tiling process from left to right (actually a scaling process). Regarding this point, the effect can actually be optimized through opacity control.

Animation

Animation must be a pain point of Hybrid apps. If you want to implement animation with similar effects to Android in the built-in webview of Android, it is really difficult, and you will encounter many pitfalls.

For example, when making a theater reservation page, the seat selection area must be able to be zoomed. After having this functional requirement, we will start development.

Regarding scaling, the first thing we think of is the scale value of the transform attribute in CSS3. Next, we adopted the scale solution for development.

The process of animation development is always bumpy, and sure enough, problems arise. The seats in the seat selection area became quite blurry after manual zooming.

Maybe you are wondering if it is because of the use of pictures, and then the pictures become blurry when enlarged, and that is reasonable. Okay, so next, we try to draw the seats directly using css to set the background color. However, the result of this is that when zooming in, it is still blurry.

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

Before describing the reasons, we must first introduce another ancient CSS attribute zoom, and talk about the differences between the two:

1. Zoom was only a private attribute of the IE browser at first. Later, most browsers became compatible with the use of this attribute, but after all, it was still not written into the specification. Scale is written into the w3c standard.
2. The rendering order is different. Scale is first dyed and then scaled, zoom is scaled and then rendered.
3. There are many control parameters related to scale, such as scaling origin, scaling direction, etc. The default zoom origin of zoom is the upper left corner, and there are no direct parameters to modify the zoom origin.

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

1. Use zoom to zoom, and the visual effect will become sharper. When using scale to zoom, the visual effect will become blurry.
2. Using zoom to zoom may cause page reflow. Using scale for scaling will not cause page rearrangement.
3. Using zoom to zoom is limited by HTML rendering rules. For example, if the minimum font is 12px, no matter how you reduce it, the font will still be 12px. But scale does not.

Next, let’s talk about how to solve the problem of seats becoming blurry after being enlarged. Based on the above conclusions, two solutions are drawn:

1. Use zoom to zoom, which can solve the problem of magnification blur.
2. Use scale to zoom, but set the scale value a little larger the first time, such as 3 (3 times the size). Then secretly set the scale to 1x (such as setTimeout).

Regarding the optimization of animation, I will talk about this example first, but in fact, in the development process of our hybrid app, there are still many optimization processes, and of course we have stepped on a lot of steps. pit. If you are interested to know more, you can try Meizu’s life services, activity center, phone yellow pages and other apps, all of which are developed more or less using the hybrid solution.

Conclusion

Currently, front-end technology is changing with each passing day. We are constantly trying some new technologies (react, es6, etc.), constantly focusing on some details, and constantly optimizing and re-optimizing. All of this cannot be covered in just one blog post. We will add new content in the future to discuss and learn together.

http://www.bkjia.com/PHPjc/1075175.htmlwww.bkjia.comtruehttp: //www.bkjia.com/PHPjc/1075175.htmlTechArticleHybrid app development history sharing Regarding this topic, this article is not going to detail some common technologies related to mobile development, such as :viewport, rem, flexbox, media queries, etc. Here we mainly talk about...