背景

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

目前轉轉展示商品流時會采用三種布局方式：分別是卡片流、固定式瀑布流、交錯式瀑布流。

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

卡片流

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

固定式瀑布流

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

交錯式瀑布流

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

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

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

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

缺點：

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

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

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

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

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

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

用一張圖來簡單總結下

新瀑布流方案設計

目前并沒有一款簡單、易用的移動端瀑布流組件，所以打算整合已知方案，再重新實現(xiàn)一個新的瀑布流組件。新的瀑布流會包含以下一些優(yōu)點：

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

布局方案

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

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

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

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

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

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

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

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

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

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

IntersectionObserver 兼容性

首先面臨的一個問題就是 IntersectionObserver 的兼容性問題。 IntersectionObserver 在解決傳統(tǒng)的滾動監(jiān)聽帶來的性能問題的同時，兼容性一直并沒有得到一個主流的支持，可以看到 iOS 上的支持并不完美

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

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

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

不支持的 IntersectionObserver 的環(huán)境才會去加載這個 polyfill，其中檢測方法摘抄自 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
}

瀑布流圖片加載時序

圖片加載是個異步過程， 如何保證瀑布流圖片的加載時序呢？

直接在 IntersectionObserver 的回調函數(shù)觸發(fā)后就開始進行下一張瀑布流圖片的加載極易出現(xiàn)長短不一列以及頁面抖動的情況，因為觸發(fā)回調時圖片可能只加載了一部分。上述方案 1 和方案 2 均存在這個問題

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

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

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

// 瀑布流布局：取出隊列中位于隊頭的數(shù)據(jù)并添加到瀑布流高度最小的那一列進行渲染，等圖片完全加載后重復該循環(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ā)問題

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

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

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

首屏渲染時的白屏問題

由于是串行加載圖片，圖片一張一張依次渲染出來，這種情況在網(wǎng)絡不好的時候白屏現(xiàn)象會很嚴重，如下圖

目前提供兩種解決方案

• 方法一：首屏渲染時的圖片采取并行渲染，后續(xù)再采取串行渲染。假設接口返回的一頁瀑布流元素有 20 個，那么前 1-4 張圖片會用并行渲染，后 5-20 張圖片會用串行渲染。可以根據(jù)實際情況調整 firstPageCount，一般情況下首屏大概會渲染 4-6 張圖片。

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

• 方法二：加動畫，從視覺感官上消除白屏帶來的影響，組件內(nèi)置了兩個動畫，通過 animation 傳參即可

懶加載時的白屏問題

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

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

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

如何配合無限加載組件

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

可以在進行瀑布流渲染的過程中增加一個判斷，如果隊列中沒有數(shù)據(jù)了，就通知外部無限加載組件進行下一次請求

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

總結

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