360 Picture Search waterfall Flow layout development practice case

The way the waterfall flows are laid out is usually flat, trivial stuff. The first attraction should be the picture, and the picture is that kind of uneven, if the waterfall flow in the text too much, will give people very messy feeling, so waterfall flow is more suitable for simple picture browsing.

Shortly before the company's online project –360 picture search beauty Show channel, used to the waterfall flow layout way, this pure look at the picture of the beautiful page with waterfall flow is quite appropriate.

Previously did not develop the waterfall flow layout of the site, the first thought of the implementation is a multiple-column floating, from the surface to see this way to simple.

　　Traditional positioning and layout methods

However, the current mainstream waterfall flow layout is the positioning of the way, for each cell to calculate the positioning value, the following figure:

The positioning of the way to achieve is actually simple, when the window resize, you can easily recalculate the cell sorting. But the calculation of the frequency is relatively high, if you want to do unlimited load data, and resize when the adaptive arrangement, then performance is a must pay attention to the problem.

If there is no optimization means, hundreds of cells themselves are very resource-consuming, resize when all again, you can imagine the browser at this time must be very difficult, there will be a browser in the case of suspended animation.

　　Layout of multiple columns floating

Take a look at how a multiple-column floating layout is implemented, where multiple cells form a column without the need to position the individual cells, and then float the entire column, as shown in the following figure:

Of course, this layout in the infinite load and resize in front of the adaptive, face the same problem.

　　Adaptive window

First of all, resize when the layout of adaptive, although the calculation of floating layout is not so convenient, but to achieve an adaptive layout is still possible. For example, there are 4 columns, resize when the page width becomes smaller, can only put 3 columns, the total number of cells is unchanged, the order of the data is fixed, then only the original 4 columns inside the cells all empty, according to the order of the data recalculated, and then added to 3 columns. Note that when you empty the DOM elements of a cell are not deleted, instead, it is extracted from the DOM tree and stored in a document fragment, which avoids the need to create a cell's DOM element every time, saving the performance overhead at the time of creation, which is a popular point of off-line operation.

　　The challenge of unlimited loading

WEB programs that run in the browser do not have as much CPU and memory to use as desktop software. When the number of DOM elements in a Web page increases exponentially, its memory footprint is bound to grow, and every DOM element has performance overhead, but typically the number of DOM does not reach the threshold that requires attention-type performance.

An infinite load of waterfalls must be aware of this performance problem caused by the large number of DOM. Can not hold a lucky mentality to think that the user may not be able to scroll much longer will jump out. This waterfall flow layout of the project does not have the inside page, are floating directly show the big picture, although to a certain extent convenient to the user, but also to the browser end of a large performance pressure. If the user does not need to jump the list page that has been stuck in the waterfall stream, as long as the page is not closed, the memory will not have the opportunity to release.

Although the page can be infinitely long, but the user's visible area of the display is limited, like a rich person, he slept at night when the area is still so large, the size of the bed is also limited. Since the viewable area is limited, which is usually used to delay loading of the DOM elements that are not loaded, can the reverse be done to the loaded DOM element that is not in the viewable region? The answer is yes, how bold people are, how big the place is.

When the page scrolls down, the waterfall creates a new cell, and the old cell scrolls down to the invisible range as the page rolls down, so you can remove the old cells in order to save performance. Of course, also need to have the skill to delete. If the page rolls up, go back to the time you can not give the user to see the whiteboard, not so deceptive. So the original deleted also have to keep the original position added back. If you don't slow down, the two actions that you delete will be enough for your browser. As a WEB developer, it is very fragile to have browsers at all times, such as the mentality of the mans back.

　　Grouping operations

The technical deletion mentioned above is to extract the DOM elements that are not visible from the DOM tree and store them in a container of document fragments. Dom elements that break away from the DOM tree can also greatly reduce the cost of performance, thus achieving the goal of saving performance. Of course, if only to do this step is not too shy to say is a skill. It is precisely because of this, I will be the HTML structure to wrap a layer, outside the UL added a

Div, called a group, has its true structure as shown in the following figure.

Here, the group is a larger unit than the column, a group can be the size of the viewable area (the current group is not accurate to the different resolution), a group of floating adaptive screen resolution in a few columns, each column is a cell. As shown above, these columns can form a group. Having a group makes it easier to allocate performance-cost balances for DOM elements that are frequently in the DOM tree to each group. You can scroll down to the specified position in the page, delete only a group, continue rolling down, and then continue deleting. Each time you delete a group that is at the top of the list, because it is in a non-visual area, the user will not know your deletion.

The height of the page is propped up by a cell, and when the cell is deleted, the height changes, and the height of the page changes accordingly. Calculate the height of the group element before deleting it, and then set its visibility to hidden so that it retains the original position and height of the group element after it has been deleted, so that there is no height change.

By using the optimization method of removing DOM elements from a non-visual region, you can keep the page in 1-2 groups of cells, as long as the number of cells within your group is well grasped. This, in part, greatly alleviates the problem of performance overhead due to the excessive number of DOM in the page.

When the window resize to the reordered width condition, you will still want to recalculate all the cells in the page. Because cells in a non-visual region are no longer in the DOM tree, their calculations are no longer stressful. The cells that are stored in the document fragment container also need to be counted, because those offline cells will have to meet the user again if the page scrolls up, but the calculation is not in the DOM tree.