Question recap: We have a list display page, which is an infinite waterfall stream, and the display elements are encapsulated into a single component, let’s call it the Item component. This waterfall stream contains several Item components, and this Item component is also relatively complex, including various display styles (according to different types, about 9, anyway, there are many rendering nodes), in the process of sliding, about 30-40 Item loading, will cause the small program memory shortage and exit, blue thin mushroom…… [Dry goods at the end, small program code snippets served]

Solution:

Unrender components in the list that are beyond a certain portion of the screen (i.e., unload components with wX :if) and start rendering when the critical rendering point is reached; Keep a small amount of data present at a time.

In our project, we keep 15 items. We request 5 items per page, divided by the first 5 items, the middle 5 items, and the last 5 items. If not, we replace them with a skeleton of equal height and unload the components

Initial implementation (more optimized later)

When an Item is exposed, the height of the Item is recorded and put into the array as the filling height of the skeleton. If the height has been recorded, it will not be recorded again. The exposure is handled by passing a central value of the current render range (such as the page number of the current Item, or the current Item index).

Here is a little note, if you have a list of item component is more complex, the height of the need to record when ready set to item minimum height, or component to reload will have certain render time, in the critical point can cause screen [here have been solved through the skeleton components, can be ignored, just as a record on pit 】

Optimization point at this point

  • In order to avoid frequent setData and rendering, an anti-shake function is made, and the time is 600ms

At this point defect

  • When sliding very fast, there will be a white screen, because the exposure monitor is inside the component, while when scrolling super fast, the component is not loaded in, and exposure monitor cannot be carried out, so it cannot be triggered. Here, we consider using skeleton component for secondary listening exposure

Optimization iteration

  • Wrap the skeleton component around the Item as a shellslot), and the skeleton monitoring exposure, can solve the above shortcomings
  • Give skeleton components a regular skeleton screen style instead of pure white for a more elegant look

Continue to find problems

After a series of practices, the above scheme has some problems, among which the most troublesome is that it needs to pass a current index externally, and then control the data display before and after; Here, for each page that uses the Skeleton component, a method is repeatedly written to take the index and render the corresponding data for the page.

To optimize the

It is still the listening skeleton exposure, here the listening scheme is changed to the content blocks appearing on n screens up and down the screen for display, the content blocks outside this range will be unloaded.

As is shown in

The core code

RelativeToViewport ({top: XXX, bottom: XXX}) relativeToViewport({top: XXX, bottom: XXX})letInfo = systeminfo.getInfo () // Obtain system informationlet { windowHeight = 667 } = info.source.system
      letShowNum = 2 // The number of screens exceeded. Currently, this setting is 2 up and 2 downlet listItemContainer = this.createIntersectionObserver()
      listItemContainer.relativeToViewport({ top: showNum * windowHeight, bottom: showNum * windowHeight })
        .observe(`#list-item-${this.data.skeletonId}`, (res) => {// To control the slot display, see code snippet})Copy the code

Dry goods

Without further ado, the dry stuff comes later. Click to get the code snippet

Click on to making

Finally, minimize the number of nodes and optimize your code