匠心打造多tab自動吸頂下的多滾動容器（詳細）-有解無憂

背景

不知道什么時候開始，一種tab自動吸頂下的多容器嵌套滾動瀏覽互動方式逐漸風靡在各大電商APP（美團、京東、拼多多等），

這種相對復雜互動的滾動容器一般都在APP首頁容易看到，實作的技術堆疊是客戶端，h5下的實作案例比較少見，目前就只看到閑魚跟拼多多有基于h5技術實作案例，個人猜測原因主要有兩點：

1. 對于多容器嵌套滾動缺乏原生能力支持，實作成本較大；

2. 自行實作多容器嵌套滾動能力流暢性不達標，畢竟h5是基于webview來進行渲染，在滾動瀏覽階段稍有計算必然會導致幀率下降，

效果與特征

但這樣的滑動瀏覽互動在我們h5場景也同樣存在強烈訴求，基于這篇文章，我給大家介紹下我們前端團隊基于h5打造的多容器嵌套滾動瀏覽的實作方案，在介紹之前我們先來看下我們的體驗效果：

從上面的效果我總結一下，一個既要滿足視覺互動又要滿足業務復雜訴求的多tab滾動容器需要具備以下特征：

1.外層滾動容器與tab容器滾動是一體化，滾動過渡要自然

2.tabbar在滾動至頂時需自動吸頂

3.不同tab容器之間支持橫滑切換瀏覽操作

4.不同tab容器的滾動瀏覽是隔離的，需要保持各自的瀏覽位置

5.不同tab容器可以承載著無限串列內容

常見方案

滾動偏移傳遞方式

從iOS客戶端同學那學習到一種方案是通過最頂層的一個不可見滾動容器(S0)來傳遞滾動偏移量，而真正內容承載的容器使用的是傳統的外滾動容器(S1)嵌套多個子滾動容器(S2-x)方式，大致原理可以參考下圖：

大致思路如下：

1.S0同步S1與S2-x的滾動偏移總和，S0統一接收來自用戶的滾動行為

2.在tabbar觸頂之前，S0的滾動偏移傳遞給S1

3.在tabbar觸頂之后，S0的滾動偏移傳遞給S2-x

4.在tab子容器橫滑之后，根據S2-x的滾動偏移來重置最頂層S0的滾動偏移計數

注：S2-x代表當前的子滾動容器

上面方案有以下優勢：

1.多子滾動容器相互之間天然隔離，天然實作各tab容器的瀏覽記錄隔離特性；

2.得益于最頂層的不可見滾動容器來接收統一的滾動互動，可以將滾動慣性傳遞下去，這點很重要，我們都知道單純的兩個嵌套滾動容器，滾動慣性是不能夠從父容器傳遞到子容器的，

但上面的方案是否適合h5技術堆疊呢？頂層滾動行為需要監聽，滾動時需要實時傳遞滾動偏移，真正承載內容的滾動容器不再是復用原生滾動能力，而且是由js計算驅動滾動，然而h5技術堆疊運行在webview中，屬于APP系統下的一個子系統，性能相對敏感，從以往經驗，容器滾動時的任何js執行都有可能導致掉幀，我們要打造滾動極致流暢只能是完全貼合h5原生的滾動，做到滾動階段無監聽、無計算，

注：Android端的NestedScrollingParent雖然是原生控制元件，但思路是與上面方案是大體一致的，都是父滾動事件分發的思路，

閑魚h5方案

為了很好解決特征1，我們的方案是基于獨一的滾動容器，并且直接復用滾動容器的默認滾動行為，不做滾動偏移傳遞或者滾動時的計算，從下圖結構看出，我們唯一的滾動容器是S0，它承載所有需要展示的內容，包括多tab模塊與其他模塊，多tab模塊中由各自子容器（C0~3）承載對應的內容，子容器不再是滾動容器，初始化階段記錄各子容器對應的外層滾動偏移值（scroll_0~3 = 0），并根據當前tab子容器C1

初始狀態

上下滾動狀態

S0上下滾動時，為了實作特征2，我們的tabbar吸頂功能采用position:sticky來實作，使用sticky最大的收益就是吸頂銜接效果好，滾動程序無額外滾動監聽計算，從sticky支持的程度來看（iOS9，Android 5.0）剛好能我們移動側的最低兼容機型，

橫滑開始

在解決特質4時，我們在橫滑開始切換時tab子容器時需做兩件事，

1.根據多tab模塊當前的距離頂部偏移量offset_1來設定其余非可見區的子容器(C0/C2/C3)頂部偏移值，以保切換程序的獨立瀏覽位置正確展示

2.記錄此時外層滾動容器的滾動偏移值n1，并記錄為scroll_1 = n1 以上操作會在橫滑視覺效果之前完成，保證橫滑程序中能正確看到下一子容器的正確瀏覽位置，

橫滑結束

當橫滑動作結束后，我們做了三件事

1.恢復當前子容器C2的頂部偏移

2.使用當前子容器記錄的滾動偏移scroll_2來重新計算滾動容器S0的滾動偏移量

3.重置掉其他非可見區的子容器頂部偏移

橫滑至有瀏覽記錄的tab容器

在當前tab容器為C2子容器時繼續進行上下滾動瀏覽，當外層容器S0滾動值為n2時（此時C2容器距離頂部的偏移為offset_2）；再次進行右橫滑互動，此時需要操作基本與第二步一致，但是由于C1已經存在滾動記錄，所以需對C1進行另外的計算方式：外層滾動偏移n2 減去 C1記錄的滾動偏移scroll_1 (n1)，

以上方案就能很好的完成開始總結的5個特征，并且在h5場景最大好處有兩方面：

1.各個tab容器中的內容在滾動瀏覽程序中始終出自唯一的滾動容器，不會存在嵌套滾動中的滾動慣性無法傳遞或者傳遞程序的損耗；

2.主容器滾動程序完全依賴原生的滾動能力，沒有任何的js計算，給16.6ms留足了時間，

至此，所有大致的思路已經完成，但還有些邊界情況仍需要我們打磨，

匠心打磨

iOS下的translate3d閃屏問題

在水平方向橫滑瀏覽時，為了能達到最好的流暢度，我們采用的是translate3d，實作結構如下；

當translate3d作用于在一塊較大圖層時是會偶現閃屏問題，猜測與合成圖層（Compositing Layer）的實作有關系，在合成渲染加速架構中使用了translate3d的渲染圖層會被提升為合成圖層，每個合成圖層會擁有自己獨立的紋理快取與相應的管理機制；但即便是擁有獨立的紋理快取管理，也同樣受限于底層OpenGL最大紋理尺寸大小(2000 * 2000像素點)，而網上常規的解法為每個滑塊添加-webkit-translate3d: (0px, 0, 0)其實就是為了將一張大的合成圖層拆成各個小的合成圖層，

中間父節點的overflow:hidden導致position:sticky吸附失效問題

隨著業務的使用，互動場景越來越多樣化，每個tab容器中開始出現子tabbar的互動，子tabbar也希望能sticky到主tabbar底部，這時候我們業務同學發現直接將子tabbar的吸附到主tabbar底部時發現不生效，定位后發現是由于tab容器設定了overflow:hidden屬性，這個問題很久前就有過關于標準的爭論，大概的意思是sticky節點是以最近一個擁有滾動機制的父節點來固定，怎么定義擁有滾動機制呢？overflow不等于visible時，但至于為什么overflow:hidden也算擁有滾動機制呢，猜測應該是只要是涉及到內容溢位就算吧，畢竟可以通過js來實作scroll，

This value always creates a new stacking context. Note that a sticky element "sticks" to its nearest ancestor that has a "scrolling mechanism" (created when overflow is hidden, scroll, auto, or overlay), even if that ancestor isn't the nearest actually scrolling ancestor. This effectively inhibits any "sticky" behavior (see the GitHub issue on W3C CSSWG).

我們之所以要給某些容器設定overflow:hidden主要原因是在不同tab容器內容高度是不一致的，為保證當前tab正確的滾動高度，我們需要借助overflow:hidden來裁剪掉相比當前tab容器長度要長的其余容器，大致如下圖：

子tab吸頂問題與overflow:hidden之間沒有什么好的解法，我們最終選擇的是繞開它兩同時的時機，

橫滑開始時：所有tab容器取消overflow:hidden，這樣可以保證橫滑程序中看到的是正常吸頂的

橫滑結束時：當前可見tab容器不需要設定，其他tab容器設定overflow:hidden

其他

除此之外，我們還解決了好多更細的問題，比如

?Android部分機型（基于Chrome 69及之前的內核）出現側滑問題，父容器overflow:hidden無法防止孫子節點超寬內容左右拖拽

?Android中低端機型Intersection Observer捕獲頻率不足的問題

?多tab之間跳躍切換時如何確保其他中間tab不被觸發加載問題

未來規劃

在方案分析程序中，我們也意識到了合成圖層帶來的GPU紋理快取壓力，前期考慮到webkit內核本身也會根據實際情況回收，并不會無邊界開銷；但對于我們來說在更長的串列中節點回收是不可逃避的話題，等待我們去解決的問題還很多，如何做到不定高回收重建？如何在不影響滾動性能的同時設計高性能回收與重建？低系統版本應該如何考慮？等等

匠心打造多tab自動吸頂下的多滾動容器（詳細）

背景