Hybrid app development history sharing _php Tutorials

Hybrid App development history sharing

On this topic, this article is not intended to elaborate on some common technologies related to mobile development, such as viewport, REM, Flexbox, media queries, etc. Here we focus on our hybrid product strategy, development process and specifications, performance optimization, and the pits we've stepped on. And often these, online related information is relatively scarce, and lack of similar experience articles, so hope that through this article, with you to share some Meizu team on hybrid product development experience.

Product background

1. We hope this kind of products have relatively strong operational capability;
2. Interface data from the CP data integration, there may be some differences, and even need a certain degree of fault-tolerant ability;
3. Requirements enable fast updates and iterations.

Android and H5 Integration solutions

Under the above background, we finally chose the Hybrid app for this scenario. So, the question is, how do clients access the Web front-end resources? Can you use a previous browser to access the server Web page way? The answer is not absolute, and of course it can be used in the above way. Depending on the business needs, there will always be different ways. The following two scenarios are most commonly used:

Static resource localization

The program will first embed a static resource in the app, and then send a request to the background and ask for resources when the user launches the app or accesses an HTML page and meets certain criteria. If updates are found, the latest resources are downloaded locally, and then the user accesses the local static resources. If the update fails, then he accesses a static resource that is embedded or has already been downloaded.

HTML 5 Application Cache

The solution, in fact, is to use the HTML5 application cache (HTML5 cache Manifest). This is not detailed here, there is a lot of information on the Internet. The notable point is that the manifest configuration file needs to be configured with the correct mime-type, which is "text/cache-manifest".

This is usually a second scenario when you are developing activities or feature pages that are short on-line and have a very varied UI.

And most of the app pages are relatively stable, or iterative development, regularly updated, with regularity, in this case, we are using the first scenario. In this scenario, we need to strictly control the size of the resource file, in addition to the necessary compression, you can also extract long-term fixed resources, built into the app in advance. Then, each time the user updates the resources, only need to go to the server to obtain the changes, greatly reducing the use of traffic.

The above two scenarios have obvious advantages over each access to the server's static resources:

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

Page load

First, the client loads a page, and after the load is completed (pagefinish), the client invokes the initialization method (InitParams) provided by the front end. The method is used to implement the parameter delivery and the initialization of the page.

Resource Building

We currently use FIS3 for resource compression, merging, adding MD5 stamping and other building functions, for the use of ES6 projects, but also need to use Babel. Based on this, we have also developed some internal Fis3-based plugins that are used internally. The ultimate goal is to achieve a command line to complete the construction work.

Development environment Construction

Build a local Web service, using Nodejs+express.

Development process

From what we can see, visual design, front-end development, client development, background development are to a large extent to achieve the parallel development.

Next, a brief description of how the front-end development is implemented and the backend, and the client decoupling, and then implement parallel development.

First, the interface document (the background interface document and the Client interface documentation) is not blocking the premise. With the background interface documentation, we can then build the appropriate pseudo-data and simulate the corresponding interface request. With the Android interface documentation, we can also simulate invoking the client interface, at least ensuring that the basic logic is smooth. Therefore, as long as the interface document, before the actual connection, the front end, the background, the client 3 are independent development, non-blocking.

Then the word of the joint is divided into three stages:

Analog false data linking

At this stage, you just need to write some fake data locally and then use Ajax to request it. The call to the Android interface is also a mock call. At this stage, the main purpose is to ensure that the front-end logic basically runs.

Background real-world interface calls

In this phase, we need to access the local static resources and invoke the interface of the remote server. In this case, the main problem is to solve the cross-domain request of Ajax. Implementation is also quite a lot, the simplest is to set the browser support cross-domain. Of course, you can also use Nginx or Apache's reverse proxy to implement AJAX cross-domain requests.

Three-party joint adjustment

This step has reached the final step before the test. At this point, the client is already integrated with the static resource, and then the interface that is called, whether it is the Android interface or the backend server interface, is no longer simulated.

3 kinds of switching state, whether in the development, bug positioning, page debugging, and so on, are often needed to use. For example, when you modify a JS logic bug, first of all, you are generally from the second kind of joint steps to start, after all, in the PC browser debugging bugs or to facilitate a lot. Then, until the bug is changed to the same time, the static resources will be push to the top of the phone, for real-machine debugging.

Then there is a problem, how to realize the flexible switching of the 3 kinds of modulation states? Let's look at a piece of code:

2345678910111213141516171819202122

In order to achieve 3 kinds of switching state, we developed a plug-in based on FIS3, the plug-in function is very simple, is to deal with 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 Analog code module (with and wrapped), the second is the Real code module ( wrapped up). The analog code module includes a JS file that simulates the Android interface, a path to the dummy data, and an initialization interface that simulates the android call. Real code modules can write some of the paths that are actually needed to go online. None of these two modules is required.

What the plugin needs to do is to remove the analog code module and release the real code module.

Again, the benefit of doing so, in the simulation of false data in the phase, do not need to use the plug-in, then according to the above code, the operation is the analog code module. And once we're going to do a real interface tune-up, we need to call the plug-in at Fis3 's parser stage to get rid of the analog code and use the real code. And the use of plug-ins, is configured in the FIS3 configuration file, through the FIS3 Media API, we can implement dynamic control plug-in is used.

Performance optimization and Pit

This is a big topic, like those who have been familiar with the Yahoo 14 and other page optimization guidelines and information, that is very much. Here, I will try to enumerate some of the problems we have done to optimize and solve from the perspective of our project.

Image

If you can not use it, try not to use it. If you have to use it, you can optimize it from multiple angles. Like what:

1. Put in a CDN to keep resources close to the user, while also reducing the transmission of non-essential data such as cookies.
2. Use Csssprites to reduce the amount of requests.
3. Use WebP to reduce picture volume.
4. The small icon can use the Base64:url image.
5. In some cases, you are not able to optimize from a technical point of view, you may need to adjust the UI or product scenarios without compromising the user experience as much as possible. For example, UI classmates set a background image of an irregular blur gradient. In this case, you have to preserve the blur gradient, but make it regular, so you can do this by capturing a small portion of the image and then tiling it. Sometimes you have to make such a tradeoff and choose a compromise solution.

Viewport

There are two common ways to set the viewport width:

1. Write Dead Fixed width
2. Set to device width

The first way, simple and convenient, no media queries, no need for REM, a version, suitable for all models. And on the page fineness of the problem, when the viewport width setting is relatively large, lines, fonts and so can achieve more granular control.

On the second way, most of the big companies are now moving in this way. This way performance is higher than the previous one, after all, there is less a scaling process, and then the compatibility is also relatively good.

So after this comparison, we recommend the second way. But we also found that in the process of communicating with people in other companies, they used the first way for various reasons. At the same time, we also have a number of projects, but also implemented in the first way.

In the first way, we found that sometimes when the page loads, the drawing effect is not very good, there will be a left-to-right tiling process (in fact, a scaling process). In fact, it is possible to optimize the effect by opacity control.

Animation

Animation this piece, must be hybrid app of a pain point. Want to in Android built-in webview inside, achieve and Android almost effect animation, its difficulty is too difficult, and will encounter quite many pits.

For example, when making a cinema reservation page, the seat selection area is to be able to be scaled. With this feature requirement, we're about to start developing.

The first thing we think about scaling is the scale value of the transform attribute in CSS3. Next, we use the scale scheme for development.

Animation development process is always bumpy, sure enough, the problem arises. Seats in the seat selection area become quite blurred after being manually enlarged.

You might think that it would be reasonable to use a picture, and then enlarge the image to become blurred. OK, so next, we're going to try to draw the seats directly using CSS to set the background color. However, the result of this is that when zoomed in, it is still blurred.

In this case, we need to calm down to think about it. What is it for?

Before describing the cause, introduce another old CSS attribute, zoom, and tell the difference between the two:

1. Zoom started out as a private property of IE, and most of the browsers were later compatible with the use of the property, but were not able to write the specification. And scale is written to the standard.
2. The rendering order is different. Scale first to post-dye scaling, zoom after zooming to render.
3. There are many control parameters related to scale, such as scaling origin, zooming direction and so on. The zoom default is the upper-left corner, and there is no direct parameter to make changes to the origin of the zoom point.

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

1. Zoom with zoom, the visual effect becomes sharper. When scaled with scale, the visual effect becomes blurred.
2. Zooming with zoom may cause the page to reflow. Scaling with scale does not cause the page to reflow.
3. Zoom using zoom, limited by the HTML rendering rules, such as the minimum font is 12px, how do you shrink, font or 12px. And the scale does not.

Now let's talk about how to solve the problem when the seat is enlarged and blurred. Based on these conclusions, two solutions are obtained:

1. Zoom with zoom so you can solve the problem of magnifying the blur.
2. Scale is used, but for the first time the value is set larger, such as 3 (3 times times the size). Then secretly (SetTimeout and the like) set the scale to 1 time times.

About the optimization of the animation, the first to speak of this column, but in fact, in our hybrid app development process, there are many optimization process, of course, also stepped on a lot of pits. Interested to understand, you can try the Meizu Life service, Activity Center, telephone yellow pages and other apps, these are more or less using the hybrid program for development.

Conclusion

At present, the front-end technology is changing rapidly, we are constantly trying some new technology (react, ES6, etc.), constantly fastening some details, continuous optimization and optimization. All this, not just a blog post can be finished, follow-up we will have new content to join in to discuss learning.

http://www.bkjia.com/PHPjc/1075175.html www.bkjia.com true http://www.bkjia.com/PHPjc/1075175.html techarticle Hybrid App development history sharing on this topic, this article is not intended to detail some of the common technologies associated with mobile development, such as viewport, REM, Flexbox, media queries, etc. The main story here is ...

