Case: 360 development practices of waterfall stream layout for Image Search

　　

 

The layout of waterfall streams is usually flat and trivial. The first attraction should be the image, and the picture is uneven. If there are too many texts in the waterfall stream, it will give people a very messy feeling, so the waterfall stream is more suitable for simply browsing images.

Not long ago, the company launched the project-the Beauty Show Channel of 360 image search, and used the waterfall stream layout method. This kind of pure beautiful pictures page is quite suitable for waterfall stream.

I have never developed a waterfall stream layout website before. The first implementation method is multi-column floating. On the surface, this method is simple.

　　Traditional positioning and layout Methods

However, the current mainstream waterfall stream layout uses the positioning method to calculate the positioning value for each cell, such:

　　

 

The positioning method is actually easy to implement. During window resize, you can also conveniently re-calculate and sort cells. However, the computing frequency is relatively high. If you want to load data infinitely and adjust the auto-arrangement during resize, performance is a problem that must be paid attention.

Without any optimization means, it would consume resources for hundreds of cells, and re-calculate all the cells during resize. we can imagine that the browser would be very hard at this time, the browser will inevitably be suspended.

　　Multi-column floating Layout

Let's take a look at the implementation of multi-column floating layout. Multiple cells form a column, without the need to locate a single cell and then float the entire column, for example:

　　

Vcq9yrXP1rXExtmyvMH3sry + 1g = "height =" 550 "src =" http://www.bkjia.com/uploads/allimg/131122/011409B48-2.png "width =" 580 "/>

 

Of course, this layout method is facing the same problem in the face of the self-adaptation of infinite loading and resize.

　　Adaptive Window

First, the layout adaptation during resize. Although the calculation of floating layout is not as convenient as positioning, it is still possible to achieve adaptive layout. For example, if there are four columns, the page width becomes smaller when resize, and only three columns can be placed. The total number of cells remains unchanged, and the data sequence is fixed, then, only the cells in the original four columns are cleared, and the cells are re-calculated and sorted in the order of data, and added to the three columns in sequence. Note that the DOM elements of cells are extracted from the DOM tree and stored in a file fragment, this avoids the creation of DOM elements for cells every time and saves the performance overhead during creation. In other words, offline operations are commonly used.

　Unlimited loading challenges

WEB programs running in browsers cannot be used as much CPU and memory as those running in desktop software. When the number of DOM elements in a webpage increases exponentially, the memory occupied by the DOM elements will inevitably increase proportionally, and each DOM element will have performance overhead, generally, the number of DOM does not reach the threshold value that requires attention on performance.

You must pay attention to the performance problems caused by the large number of DOM. You cannot think that the user may not roll out for a long time. The waterfall stream layout project has no inner pages at all. It is a float layer that shows the big picture directly. Although it facilitates the user to a certain extent, it also puts a lot of performance pressure on the browser end. If you do not need to jump to the List page of the waterfall stream, as long as you do not close this page, the memory will never be released.

Although the page can be infinitely long, the visible area of the user's monitor is limited. Just like a rich person, the area occupied by the user's sleeping at night is still so large, the bed area is also limited. Because the visible area is limited, we usually use this to perform delayed loading on the unloaded DOM elements. In turn, can we post on the loaded DOM elements that are not in the visible area? The answer is yes. How bold are people and how productive are there.

When the page scroll down, the waterfall flow creates a new cell, and the old cell will scroll down with the page and be in a non-visible range. Since it is invisible, to save performance, you can delete these old cells. Of course, you also need to delete it skillfully. If the page is rolled up, you cannot show the whiteboard to the user when you roll back. Therefore, the original deleted items must be added back to the original location. If it is not easy, it is enough for the browser to take the two actions of deleting and adding. As a WEB developer, It is very fragile to always have a browser.

　Group operations

The skillful deletion mentioned above is to extract DOM elements in a non-visible area from the DOM tree and store them in a container of document fragments. The separation of DOM elements from the DOM tree greatly reduces the performance overhead, thus achieving the goal of saving performance. Of course, if you only want to do this step, it is not very interesting to say that it is a skill. Because of this, I wrapped the HTML structure to another layer and added

Div is called a group. Its actual structure is shown in.

　　

 

Here, a group is a larger unit than a column, and a group can be the size of the visible area (currently the group is not accurate to different resolutions ), A group contains several columns of floating adaptive screen resolution, and each column contains cells. For example, several columns can form a group. With a group, you can easily balance the performance overhead of DOM elements frequently in and out of the DOM tree to each group. You can scroll down to the specified position on the page, delete only one group, continue to roll down, and then continue to delete. Delete the group at the top of each operation, because it is in a non-visible area and the user does not know your deletion operation.

The height of a page is supported by cells. After a cell is deleted, the height of the page changes. As a result, the height of the page also changes. The height of the group element is calculated before deletion, and its visibility is set to hidden, so that the original position and height of the group element are retained after deletion, so that there will be no change in the height.

By using the optimization method to delete DOM elements in a non-visible area, the page can always maintain 1-2 groups of cells, as long as you can grasp the number of cells in the group. In this way, the performance overhead of the page is greatly mitigated due to the large number of DOM.

When the window resize reaches the re-sorting width condition, you still need to re-calculate and sort all cells on the page. Because cells in the non-visible area are no longer in the DOM tree, there is no pressure on calculation. The cells stored in the File Fragment container still need to be computed, because if the offline cells need to be re-displayed when the page is scrolled up, this computation is not in the DOM tree.