背景

瀑布流是大家日常開(kāi)發(fā)過(guò)程中經(jīng)常遇到的一個(gè)場(chǎng)景，我們公司內(nèi)部的組件庫(kù)中也提供了一些解決方案。但這些方案適用場(chǎng)景都很單一，且每個(gè)實(shí)現(xiàn)方案都或多或少存在一些問(wèn)題，基于此，我們?cè)O(shè)計(jì)與開(kāi)發(fā)了一個(gè)兼容多場(chǎng)景的瀑布流組件。

目前轉(zhuǎn)轉(zhuǎn)展示商品流時(shí)會(huì)采用三種布局方式：分別是卡片流、固定式瀑布流、交錯(cuò)式瀑布流。

其中卡片流以一個(gè)下拉列表的形式呈現(xiàn)。這種布局可以讓用戶專(zhuān)注于單個(gè)列表項(xiàng)，有利于閱讀。主要應(yīng)用于轉(zhuǎn)轉(zhuǎn)的二級(jí)列表頁(yè)入口，效果如下

卡片流

固定式瀑布流圖片區(qū)域大小高度保持不變。統(tǒng)一的高度會(huì)使整個(gè)界面看起來(lái)比較整齊，視覺(jué)上不亂。主要應(yīng)用于一些頻道頁(yè)場(chǎng)景，效果如下

固定式瀑布流

交錯(cuò)式瀑布流視覺(jué)表現(xiàn)為寬度相等、高度不定的元素組成參差不齊的多欄布局，轉(zhuǎn)轉(zhuǎn)的首頁(yè)以及商詳推薦頁(yè)面會(huì)選擇以這種方式來(lái)做承載

交錯(cuò)式瀑布流

現(xiàn)有方案的問(wèn)題

以上三種場(chǎng)景中，第一種和第二種場(chǎng)景圖片高度固定，實(shí)現(xiàn)相對(duì)簡(jiǎn)單，直接使用無(wú)限加載 List 組件即可。經(jīng)常出問(wèn)題的是第三種場(chǎng)景： 交錯(cuò)式瀑布流 。這種場(chǎng)景下需要等圖片加載完后，獲取到圖片高度，再添加到瀑布流的最低列，否則會(huì)影響最低列的計(jì)算，從而出現(xiàn)長(zhǎng)短不一的列。

轉(zhuǎn)轉(zhuǎn)公司內(nèi)部針對(duì)交錯(cuò)式瀑布流的實(shí)現(xiàn)主要有以下幾種方案

優(yōu)點(diǎn)：采用 IntersectionObserve 實(shí)現(xiàn)瀑布流的懶加載，邏輯實(shí)現(xiàn)簡(jiǎn)單

缺點(diǎn)：

• 方案 1：采用左右兩欄布局，先左右均分第一頁(yè)瀑布流數(shù)據(jù)并進(jìn)行渲染。等到第二頁(yè)數(shù)據(jù)渲染時(shí)，會(huì)先將第二頁(yè)第一個(gè)數(shù)據(jù)取出并渲染到最低列，并且進(jìn)行 IntersectionObserve 監(jiān)聽(tīng)，等到該元素出現(xiàn)在視窗內(nèi)，再?gòu)臄?shù)據(jù)源中取出第二個(gè)數(shù)據(jù)并添加到新的最低渲染列中，如此順環(huán)往復(fù)實(shí)現(xiàn)懶加載的瀑布流

1. 分欄布局只支持兩欄，不支持參數(shù)配置多列；
2. 第一頁(yè)數(shù)據(jù)不符合瀑布流的規(guī)范，有概率出現(xiàn)一列長(zhǎng)，一列短的情況；
3. IntersectionObserve 的兼容性問(wèn)題；
4. 沒(méi)有暴露數(shù)據(jù)加載完畢的事件，這樣在配合無(wú)限加載組件時(shí)，容易出現(xiàn)下拉請(qǐng)求兩次接口的問(wèn)題

• 方案 2：采用寬度百分比進(jìn)行樣式布局，首屏渲染就開(kāi)啟 IntersectionObserve 監(jiān)聽(tīng)，元素出現(xiàn)在視窗后，設(shè)置一個(gè) setTimeout 加載下一個(gè)瀑布流元素，同時(shí)在該 dom 上添加一個(gè)屬性標(biāo)識(shí)，防止二次觸發(fā)。
• 優(yōu)點(diǎn): 支持參數(shù)配置多欄布局，首屏符合瀑布流的規(guī)范，同時(shí)暴露了瀑布流加載完畢后的事件，配合無(wú)限加載時(shí)不會(huì)出現(xiàn)兩次請(qǐng)求接口的問(wèn)題
• 缺點(diǎn)： IntersectionObserve 的兼容性問(wèn)題依舊沒(méi)有解決；內(nèi)部 DOM 查詢(xún)、操作頻率較高；耦合無(wú)限加載 List 的邏輯，維護(hù)成本較高； setTimeout 無(wú)法保證圖片按照正確時(shí)序加載，會(huì)導(dǎo)致獲取最低列時(shí)不夠準(zhǔn)確
• 方案 3：使用絕對(duì)定位布局方案。實(shí)現(xiàn)原理是在每一個(gè)子組件 waterall-item 的內(nèi)部新建一個(gè) image 對(duì)象，監(jiān)聽(tīng) onload 事件然后觸發(fā)父組件 waterfall 進(jìn)行瀑布流的重排。
• 優(yōu)點(diǎn)：內(nèi)部邏輯簡(jiǎn)單，便于維護(hù)的同時(shí)也符合瀑布流規(guī)范，提供了瀑布流常用的幾個(gè)配置項(xiàng)，完全加載后也會(huì)觸發(fā)事件通知外部組件
• 缺點(diǎn)：不支持圖片懶加載；重繪次數(shù)過(guò)多（1+2+...+N），對(duì)性能不太友好；觸發(fā)重繪的時(shí)機(jī)并不是最精確的時(shí)間節(jié)點(diǎn)（通過(guò) new image 后的 onload 事件觸發(fā)，而不是在當(dāng)前 image 上綁定 onload 事件）

然后又去網(wǎng)上找了下開(kāi)源方案，這里列舉 Github 上的 Star 數(shù)排行前 4 的解決方案

• 缺點(diǎn)：需要在組件渲染前知道圖片的寬度和高度，而我們一般并不會(huì)在接口中返回這些數(shù)據(jù)

• vue-waterfall [1] ：Star 數(shù)最多的一個(gè)方案
• vue-waterfall-easy [2] ：無(wú)需提前獲取圖片的寬高信息，采用圖片預(yù)加載后再進(jìn)行排版。
• 缺點(diǎn)：耦合下拉、無(wú)限加載組件；包含 PC 端等邏輯，包體積較大，對(duì)于追求性能的頁(yè)面并不友好（作為開(kāi)源方案，兼容更多的場(chǎng)景其實(shí)無(wú)可厚非，只是這些功能我們都已經(jīng)有單獨(dú)的組件實(shí)現(xiàn)）；一次加載所有圖片，不支持懶加載
• vue-waterfall2 [3] ：支持高度自適應(yīng)，支持懶加載
• 缺點(diǎn)：內(nèi)部多次創(chuàng)建 image 對(duì)象，同時(shí)還伴隨著大量的計(jì)算和滾動(dòng)監(jiān)聽(tīng)。
• vue2-waterfall [4] ：通過(guò)對(duì) masonry-layout 和 imagesloaded 這兩個(gè)開(kāi)源方案的封裝來(lái)實(shí)現(xiàn)，邏輯簡(jiǎn)單明了。
• 缺點(diǎn)：不支持懶加載

用一張圖來(lái)簡(jiǎn)單總結(jié)下

新瀑布流方案設(shè)計(jì)

目前并沒(méi)有一款簡(jiǎn)單、易用的移動(dòng)端瀑布流組件，所以打算整合已知方案，再重新實(shí)現(xiàn)一個(gè)新的瀑布流組件。新的瀑布流會(huì)包含以下一些優(yōu)點(diǎn)：

• 簡(jiǎn)單的 CSS 布局
• 精簡(jiǎn)邏輯層面的實(shí)現(xiàn)
• 支持高度自適應(yīng)
• 支持懶加載

布局方案

了解到瀑布流 CSS 布局方案主要分為三種

• 絕對(duì)定位：上述的方案 3 以及開(kāi)源方案 vue-waterfall-easy 采用這種布局，比較適用于 PC 端瀑布流
• 寬度百分比：上述方案 2 以及開(kāi)源方案 vue-waterfall2 采用這種布局，但這種方案會(huì)存在一些精度問(wèn)題
• Flex 布局：一些大的電商網(wǎng)站像蘑菇街等采用這種布局

其中，F(xiàn)lex 布局兼容性、適配都沒(méi)什么問(wèn)題，應(yīng)該是移動(dòng)端布局方案的最優(yōu)解。所以新的瀑布流會(huì)采用這種布局方案

瀑布流邏輯實(shí)現(xiàn)

對(duì)于瀑布流的邏輯實(shí)現(xiàn)，也分為三種

• image onload DOM
• 直接在接口返回的圖片 url 中拼接圖片的寬高信息，提前布局，蘑菇街等采用這種方案
• IntersectionObserver 監(jiān)聽(tīng)圖片元素，出現(xiàn)在視圖當(dāng)中開(kāi)始從瀑布流數(shù)據(jù)隊(duì)列的列頭中取出一個(gè)數(shù)據(jù)并渲染到當(dāng)前瀑布流的最低列，如此循環(huán)往復(fù)實(shí)現(xiàn)瀑布流的懶加載

三種方案中，第一種比較常規(guī)，大部分開(kāi)源方案就是這么實(shí)現(xiàn)的。但是內(nèi)部需要進(jìn)行高度換算，同時(shí)也不支持圖片懶加載。

第二種方案應(yīng)該是比較好的一個(gè)方案，圖片加載前就可以開(kāi)始進(jìn)行排版，方便簡(jiǎn)單，也支持懶加載，用戶體驗(yàn)也好。蘑菇街、天貓、京東等都是采用這種方案。但這種場(chǎng)景需要進(jìn)行一些改造，比如在圖片入庫(kù)前將圖片信息拼接到 url 上，或者后端接口讀取圖片對(duì)象，然后將圖片信息返回給前端。要么改造成本較大，要么會(huì)增加服務(wù)器壓力，并不太適合我們業(yè)務(wù)。

而第三種方案可以在不需要其他改造的情況下支持懶加載，應(yīng)該是目前最合適的一個(gè)方案。所以新的瀑布流組件會(huì)采用 IntersectionObserver 來(lái)實(shí)現(xiàn)瀑布流的排版

新瀑布流具體實(shí)現(xiàn)

IntersectionObserver 兼容性

首先面臨的一個(gè)問(wèn)題就是 IntersectionObserver 的兼容性問(wèn)題。 IntersectionObserver 在解決傳統(tǒng)的滾動(dòng)監(jiān)聽(tīng)?zhēng)?lái)的性能問(wèn)題的同時(shí)，兼容性一直并沒(méi)有得到一個(gè)主流的支持，可以看到 iOS 上的支持并不完美

官方提供了一個(gè) polyfill [5] 來(lái)解決上述問(wèn)題，但是這個(gè) polyfill 體積較大，直接引入對(duì)一些追求極致性能的頁(yè)面不太友好，所以我們采用了動(dòng)態(tài)引入 polyfill 的方法

// 不支持IntersectionObserver的場(chǎng)景下，動(dòng)態(tài)引入polyfill
const ioPromise = checkIntersectionObserver()
  ? Promise.resolve()
  : import('intersection-observer')

ioPromise.then(() => {
  // do something
})

不支持的 IntersectionObserver 的環(huán)境才會(huì)去加載這個(gè) polyfill，其中檢測(cè)方法摘抄自 Vue lazyload

const inBrowser = typeof window !== 'undefined' && window !== null

function checkIntersectionObserver() {
  if (
    inBrowser &&
    'IntersectionObserver' in window &&
    'IntersectionObserverEntry' in window &&
    'intersectionRatio' in window.IntersectionObserverEntry.prototype
  ) {
    // Minimal polyfill for Edge 15's lack of `isIntersecting`
    // See: https://github.com/w3c/IntersectionObserver/issues/211
    if (!('isIntersecting' in window.IntersectionObserverEntry.prototype)) {
      Object.defineProperty(window.IntersectionObserverEntry.prototype, 'isIntersecting', {
        get: function() {
          return this.intersectionRatio > 0
        }
      })
    }
    return true
  }
  return false
}

瀑布流圖片加載時(shí)序

圖片加載是個(gè)異步過(guò)程， 如何保證瀑布流圖片的加載時(shí)序呢？

直接在 IntersectionObserver 的回調(diào)函數(shù)觸發(fā)后就開(kāi)始進(jìn)行下一張瀑布流圖片的加載極易出現(xiàn)長(zhǎng)短不一列以及頁(yè)面抖動(dòng)的情況，因?yàn)橛|發(fā)回調(diào)時(shí)圖片可能只加載了一部分。上述方案 1 和方案 2 均存在這個(gè)問(wèn)題

查看文檔，可以看到 IntersectionObserver 的回調(diào)函數(shù)中提供的 IntersectionObserverEntry 對(duì)象會(huì)提供以下屬性

• time：可見(jiàn)性發(fā)生變化的時(shí)間，是一個(gè)高精度時(shí)間戳，單位為毫秒
• target：被觀察的目標(biāo)元素，是一個(gè) DOM 節(jié)點(diǎn)對(duì)象
• rootBounds：根元素的矩形區(qū)域的信息， getBoundingClientRect() 方法的返回值，如果沒(méi)有根元素（即直接相對(duì)于視口滾動(dòng)），則返回 null
• boundingClientRect：目標(biāo)元素的矩形區(qū)域的信息
• intersectionRect：目標(biāo)元素與視口（或根元素）的交叉區(qū)域的信息
• intersectionRatio：目標(biāo)元素的可見(jiàn)比例，即 intersectionRect 占 boundingClientRect 的比例，完全可見(jiàn)時(shí)為 1，完全不可見(jiàn)時(shí)小于等于 0

我們可以在 target 上綁定 onload 事件，onload 之后再執(zhí)行下一次瀑布流數(shù)據(jù)渲染，這樣能保證下一次渲染時(shí)獲取最低列時(shí)的準(zhǔn)確性

// 瀑布流布局：取出隊(duì)列中位于隊(duì)頭的數(shù)據(jù)并添加到瀑布流高度最小的那一列進(jìn)行渲染，等圖片完全加載后重復(fù)該循環(huán)
observerObj = new IntersectionObserver(
  (entries) => {
    for (const entry of entries) {
      const { target, isIntersecting } = entry
      if (isIntersecting) {
        if (target.complete) {
          done()
        } else {
          target.onload = target.onerror = done
        }
      }
    }
  }
)

IntersectionObserver 二次觸發(fā)問(wèn)題

我們知道，采用 IntersectionObserver 監(jiān)聽(tīng)目標(biāo)元素，當(dāng)目標(biāo)元素的可見(jiàn)性發(fā)生變化時(shí)，回調(diào)函數(shù)一般會(huì)觸發(fā)兩次。一次是目標(biāo)元素剛剛進(jìn)入視口（開(kāi)始可見(jiàn)），另一次是完全離開(kāi)視口（開(kāi)始不可見(jiàn)）。為了避免第二次再次觸發(fā)監(jiān)聽(tīng)邏輯，可以在第一次觸發(fā)的時(shí)候停止觀察

if (isIntersecting) {
  const done = () => {
    // 停止觀察，防止回拉時(shí)二次觸發(fā)監(jiān)聽(tīng)邏輯
    observerObj.unobserve(target)
  }

  if (target.complete) {
    done()
  } else {
    target.onload = target.onerror = done
  }
}

首屏渲染時(shí)的白屏問(wèn)題

由于是串行加載圖片，圖片一張一張依次渲染出來(lái)，這種情況在網(wǎng)絡(luò)不好的時(shí)候白屏現(xiàn)象會(huì)很?chē)?yán)重，如下圖

目前提供兩種解決方案

• 方法一：首屏渲染時(shí)的圖片采取并行渲染，后續(xù)再采取串行渲染。假設(shè)接口返回的一頁(yè)瀑布流元素有 20 個(gè)，那么前 1-4 張圖片會(huì)用并行渲染，后 5-20 張圖片會(huì)用串行渲染?？梢愿鶕?jù)實(shí)際情況調(diào)整 firstPageCount，一般情況下首屏大概會(huì)渲染 4-6 張圖片。

waterfall() {
  // 更新瀑布流高度最小列
  this.updateMinCol()
  // 取出數(shù)據(jù)源中最靠前的一個(gè)并添加到瀑布流高度最小的那一列
  this.appendColData()
  // 首屏采用并行渲染，非首屏采用串行渲染
  if (++count < this.firstPageCount) {
    this.$nextTick(() => this.waterfall())
  } else {
    this.$nextTick(() => this.startObserver())
  }
}

• 方法二：加動(dòng)畫(huà)，從視覺(jué)感官上消除白屏帶來(lái)的影響，組件內(nèi)置了兩個(gè)動(dòng)畫(huà)，通過(guò) animation 傳參即可

懶加載時(shí)的白屏問(wèn)題

我們采取懶加載的方案：當(dāng)圖片出現(xiàn)在視圖后才去加載下一個(gè)瀑布流圖片，這樣對(duì)性能比較友好。但是這種情況下用戶在滾動(dòng)瀏覽時(shí)，如果下一張圖片加載過(guò)慢，可能會(huì)有短暫的白屏?xí)r間，如何解決這個(gè)體驗(yàn)問(wèn)題呢

IntersectionObserver 有一個(gè) rootMargin 屬性，我們可以利用它來(lái)擴(kuò)大交叉區(qū)域，從而提前加載后面的數(shù)據(jù)。這樣既可以防止用戶滾動(dòng)到底部的時(shí)候的白屏，也可以防止渲染過(guò)多影響性能。默認(rèn)設(shè)置的是 400px，大約是提前渲染半屏的數(shù)據(jù)。

// 擴(kuò)展intersectionRect交叉區(qū)域，可以提前加載部分?jǐn)?shù)據(jù)，優(yōu)化用戶瀏覽體驗(yàn)
rootMargin: {
  type: String,
  default: '0px 0px 400px 0px'
}

如何配合無(wú)限加載組件

一般我們?yōu)榱司S護(hù)方便，會(huì)將無(wú)限加載和瀑布流這兩部分邏輯分開(kāi)，所以當(dāng)瀑布流數(shù)據(jù)渲染完后需要通知外部組件，否則很容易造成瀑布流還未渲染完又觸發(fā)了無(wú)限加載的邏輯，發(fā)送兩次接口請(qǐng)求的問(wèn)題。

可以在進(jìn)行瀑布流渲染的過(guò)程中增加一個(gè)判斷，如果隊(duì)列中沒(méi)有數(shù)據(jù)了，就通知外部無(wú)限加載組件進(jìn)行下一次請(qǐng)求

const done = () => {
  if (this.innerData.length) {
    this.waterfall()
  } else {
    this.$emit('rendered')
  }
}

總結(jié)

以上就是在做新瀑布流組件時(shí)遇到的一些問(wèn)題以及對(duì)應(yīng)的解決方案。當(dāng)然，這套方案還有待優(yōu)化的空間，目前作為公司內(nèi)部一個(gè)組件區(qū)塊在使用中。