Create a silky smooth H5 page flip library

background

With the popularity of mobile marketing pages in recent years, a Chinese term "H5" has emerged. The most common form of H5 is a slideshow-like page turning effect.

When we need to make H5, the fastest way is to use some sliding plug-in libraries, such as Swiper produced by iDangero.us and iSlider produced by Baidu BE-FE. Through the powerful configuration functions provided by these page turning libraries, we can achieve very cool page turning effects. Of course, these libraries also support configurations such as automatic play, click switching and current page indication, so they can also be used on web pages to achieve some web carousel effects.

[[208184]]

Baidu H5 also used Swiper and iSlider as the page turning framework of H5 runtime. As the number of users increased, some problems were encountered:

1. The H5 platform does not fit well with these libraries. Some configuration items cannot be used, and some necessary functions need to be implemented in a "Hack" way.
2. Some H5s have many elements and animations. When turning pages on low-end models, there will be a "stuttering" and "sticky feeling", which provides a poor user experience.

We hope that the H5 page turning library can be perfectly matched with the platform's own functions, while keeping the size small and making the page turning smooth. So we started our research journey.

start

When developing an H5 sliding screen framework, the first question is: Does the page follow the finger sliding? This is also the first question of the Tencent ISUX team's "Nine Questions on Sliding Screen H5 Development Practice" (the original source of this article is now 404, you can see it on other reprinted websites). Here I use the picture of this article to illustrate this issue.

The one on the left does not follow the finger sliding. It only needs to pay attention to the two time points when the finger touches and leaves, and does not need to consider the intermediate process. Therefore, it is relatively simple to implement. However, there is no real-time feedback on the user's operation, and the experience is not good enough. Therefore, although it is more complicated to implement, we still decided to implement the former "follow the finger sliding" effect.

Getting Started

The following figure is the most intuitive version of H5 that follows the finger sliding. All the "pages" are connected from top to bottom. It should be noted that the "pages" here are in quotation marks because they are actually divs. The pages mentioned later refer to these divs. At the same time, we take the most common vertical sliding as an example, and the horizontal direction is the same.

Basic Schematic Diagram

The width and height of these divs are 100% of the container height, and the visible area is the middle part. We listen for touchstart, touchmove, and touchend events, similar to the principle of mouse dragging:

1. When touchstart is called, the starting point is recorded;
2. touchmove calculates the sliding distance in real time and translates all pages along the Y axis by this distance.
3. When touchend is called, the final sliding distance can be obtained and compared with the set threshold. Then the page will enter the automatic control stage: if it is greater than the threshold, the page will slide to the next page; if it is less than the threshold, it will return to the starting position.

Digging Deeper

The simple version is easy to implement in the previous section. If there are not many other requirements and there are few elements and animations on the page, it is basically enough. However, this article will explore how to achieve "silky smoothness", which is actually two words: performance.

What is the performance bottleneck?

Our goal is to minimize lag when swiping and turning pages under the circumstances of "Three Mores and One Low" (more pages, more elements, more animations, and low configuration).

We divide this problem into two parts: before the finger leaves the screen and after the finger leaves the screen.

Before your finger leaves the screen

The operation that consumes more performance at this time is: when touchmove is triggered, the distance to be moved is calculated, and all pages need to move the same distance along the Y axis. At this time, DOM operations are inevitable, and DOM operations are very "expensive". In addition, if the performance handling is not good enough, frequent triggering of touchmove events will easily cause lag.

In order to optimize performance, we naturally think of a strategy: reduce DOM operations.

This includes two parts: reducing the elements of DOM operations and reducing the attributes of DOM operations. For example, the former means that the invisible pages will not participate in the animation. For example, the latter means only changing one or several CSS attributes of the element.

Reduce the number of DOM manipulation elements

In the first simple version of the example, when touchmove is triggered, all pages move along the Y axis. In fact, this is not necessary because a considerable part of the pages are invisible. So in general, how many pages do we need to operate at least? The answer is two. You can recall that when we slide, we can see at most two pages at the same time. This method improves performance exponentially compared to moving all pages together.

Reduce DOM manipulation attributes

The main meaning of this method is that the effect can be achieved by operating the DOM only once, never twice. In fact, for the slide animation, we only need to change the transform value of the page, and other DOM operations (adding classes, modifying the innerHTML of elements) can be avoided.

We have come up with a preliminary solution: at initialization, all pages are placed in the container at once, except for the two pages we use, and the display property is set to none. When touchmove, only the transform property of these two pages changes.

The touchmove process can be expressed as a mathematical expression:

• x represents the distance the finger slides, s represents the distance the page slides, sideLength

is the length of the current sliding edge. If sliding along the y axis, it is the page height. At this point, it is very similar to the popular concept of "data-driven". We only need to implement a render function, the input is the user's interaction data, and the output is the page performance.

After you lift your finger off the screen

When the finger leaves the screen, we already know the result of the slide (up or down? Turn the page or rebound?), and we only need to achieve the animation effect. We have two options:

• Solution 1: reuse the render logic of touchmove, and use requestAnimationFrame to control the animation according to the speed of finger sliding;
• Solution 2: Use css3 transition animation;
• The advantages of solution 1 are: the same render function can be used in the finger sliding and animation process, the code can be reused to the maximum extent, and the logic is unified; at the same time, each frame of the animation can be accurately controlled, and the animation curve will be smoother. The disadvantage is that there may be performance issues. Solution 2 is just the opposite of solution 1. In fact, it is still a question of js animation vs css animation.

Animation performance experiments

In order to compare the performance of the two solutions on H5 page turning animation, we take a slightly more complicated example:

• H5: Baidu driverless car recruitment H5
• Animation: Flip from page 1 to page 2
• CPU: 6 * slowdown
• Browser: Chrome 61.0.3163.100 (64-bit)
• js animation solution: click here
• CSS animation solution: click here

• js page turning animation solution, Profile results

• CSS page turning animation solution, Profile result

Through experiments, we can see that during the js animation process, the frame rate is mostly maintained at around 30 fps. While for the css animation, it is basically around 60 fps. And during the animation process, the js animation is obviously stuck. This situation is particularly obvious on some Android models with relatively low CPU and graphics card configurations. For those who are interested in this issue, you can take a look at the raf branch of the swiper library, which is the js used in this comparison test.

Therefore, although the js animation solution looks more "elegant" and can use the "data-driven" concept to uniformly solve the problems of the sliding process and the animation process, in fact, there is a performance bottleneck. We can only use the CSS animation solution to ensure performance after the finger leaves the screen. It is just as the saying goes, "If you can do it with CSS, never solve it with JS."

Implementation

The following figure shows the basic idea of ​​our implementation, which is only two pages:

• currentPage : current page
• activePage : The next page to be turned to

The rest of the pages are loaded into the DOM structure at initialization, but display is none and z-index is 0. The "stacked" state is shown here for a more vivid display.

Swiper schematic

In order to facilitate page retrieval, we use a doubly linked list to save the page structure. Each page has prev and next pointing to the previous and next page respectively.

What we need to focus on is how to determine the activePage? That is, the next page to go to. The answer is simple. In fact, when the user starts to touch the screen and slide, it can be determined:

1. Slide distance x < 0, indicating that the page slides upward, and activepage = currentPage.next
2. Slide distance x > 0, indicating that the page slides down, and activepage = currentPage.prev

Extensions

Page turning effect

The page turning effect in our example is the most common sliding effect. How to expand support for cube, flip and other effects? You can look back at the "before the finger leaves the screen" section, where we proposed

s=f(x), x is the user's sliding distance, s is the page's sliding distance. We use s

By expanding it to "page flip angle" or "page zoom ratio", other effects can be supported.

In fact, when we slide, we use the transform attribute of CSS3. By properly combining translate, rotate, and scale, we can create a variety of page-turning effects.

More pleasing animations

Here we are referring to animation-timing-function. Let's take the simplest sliding effect as an example. If it is a linear function, the user's sliding speed is always equal to the page's sliding speed. And the "feel" smoother and more sensitive should be: at the beginning, the page sliding speed is greater than the user's sliding speed. As the page turns, the two tend to be the same. After a certain point, the page sliding speed begins to gradually decrease in unit time. If the speed is expressed as distance, we can get

x and s

The relationship between them is shown in the figure below:

The relationship between x and s (x on the horizontal axis and s on the vertical axis)

)

Here, we have to mention two more animation solutions: js animation and css animation.

One advantage of the js animation solution is that it can precisely control the progress of the animation, which CSS cannot do. For example, when the user leaves the screen at x = 0.8, because the same renderer is used, js can know that x is at 0.8 at the moment the finger leaves the screen, and the subsequent animation is completed by requestAnimationFrame, and the whole process is smooth and complete.

CSS animation is different. CSS animation can only set the animation-timing-function before the animation starts. When the user leaves the screen at x = 0.8, the original JS control of the sliding process is interrupted, and the remaining animation is completed by CSS. CSS cannot dynamically calculate the animation-timing-function based on the moment the finger leaves the screen, so at the connection point, the speeds of the two do not match, which will affect the overall animation effect.

Unfortunately, the js animation solution has performance issues, so we can only use the CSS animation solution for the part after the user's finger leaves the screen. This "more pleasing animation" can only be used during the finger sliding period.

Summary and Outlook

This article describes some problems encountered during the development of a "silky smooth" H5 page turning library and the corresponding solutions. After the basic sliding page turning model was established, the focus was on performance issues, which were divided into two stages: before the finger leaves the screen and after the finger leaves the screen. The former stage mainly focused on reducing DOM operations. The latter stage focused on the performance of animations, and compared the performance data of js animations and css animations, and finally concluded that css animations should be used after the finger leaves the screen. In addition, based on the idea of ​​"data-driven", we have expanded the page turning effects and animation functions, enhanced the functions of the page turning library, and enriched the presentation effects of H5.