背景

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

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

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

卡片流

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

固定式瀑布流

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

交錯式瀑布流

現有方案的問題

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

轉轉公司內部針對交錯式瀑布流的實現主要有以下幾種方案

優點：采用 IntersectionObserve 實現瀑布流的懶加載，邏輯實現簡單

缺點：

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

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

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

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

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

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

用一張圖來簡單總結下

新瀑布流方案設計

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

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

布局方案

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

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

其中，Flex 布局兼容性、適配都沒什么問題，應該是移動端布局方案的最優解。所以新的瀑布流會采用這種布局方案

瀑布流邏輯實現

對于瀑布流的邏輯實現，也分為三種

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

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

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

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

新瀑布流具體實現

IntersectionObserver 兼容性

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

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

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

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

不支持的 IntersectionObserver 的環境才會去加載這個 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 的回調函數觸發后就開始進行下一張瀑布流圖片的加載極易出現長短不一列以及頁面抖動的情況，因為觸發回調時圖片可能只加載了一部分。上述方案 1 和方案 2 均存在這個問題

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

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

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

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

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

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

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

首屏渲染時的白屏問題

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

目前提供兩種解決方案

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

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

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

懶加載時的白屏問題

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

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

// 擴展intersectionRect交叉區域，可以提前加載部分數據，優化用戶瀏覽體驗
rootMargin: {
  type: String,
  default: '0px 0px 400px 0px'
}

如何配合無限加載組件

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

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

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

總結

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