作者：閑魚技術——羲凡
背景
不知道什麼時候開始，一種tab自動吸頂下的多容器嵌套滾動浏覽互動方式逐漸風靡在各大電商APP（美團、京東、拼多多等）。
這種相對複雜互動的滾動容器一般都在APP首頁容易看到，實作的技術棧是用戶端，h5下的實作案例比較少見，目前就隻看到閑魚跟拼多多有基于h5技術實作案例。個人猜測原因主要有兩點：1. 對于多容器嵌套滾動缺乏原生能力支援，實作成本較大；2. 自行實作多容器嵌套滾動能力流暢性不達标，畢竟h5是基于webview來進行渲染，在滾動浏覽階段稍有計算必然會導緻幀率下降。
效果與特征
但這樣的滑動浏覽互動在我們h5場景也同樣存在強烈訴求，基于這篇文章，我給大家介紹下我們前端團隊基于h5打造的多容器嵌套滾動浏覽的實作方案。在介紹之前我們先來看下我們的體驗效果：
從上面的效果我總結一下，一個既要滿足視覺互動又要滿足業務複雜訴求的多tab滾動容器需要具備以下特征：
- 外層滾動容器與tab容器滾動是一體化，滾動過渡要自然
- tabbar在滾動至頂時需自動吸頂
- 不同tab容器之間支援橫滑切換浏覽操作
- 不同tab容器的滾動浏覽是隔離的，需要保持各自的浏覽位置
- 不同tab容器可以承載着無限清單内容
常見方案
滾動偏移傳遞方式
從iOS用戶端同學那學習到一種方案是通過最頂層的一個不可見滾動容器(S0)來傳遞滾動偏移量，而真正内容承載的容器使用的是傳統的外滾動容器(S1)嵌套多個子滾動容器(S2-x)方式，大緻原理可以參考下圖：
大緻思路如下：
- S0同步S1與S2-x的滾動偏移總和，S0統一接收來自使用者的滾動行為
- 在tabbar觸頂之前，S0的滾動偏移傳遞給S1
- 在tabbar觸頂之後，S0的滾動偏移傳遞給S2-x
- 在tab子容器橫滑之後，根據S2-x的滾動偏移來重置最頂層S0的滾動偏移計數
注：S2-x代表目前的子滾動容器
上面方案有以下優勢：
- 多子滾動容器互相之間天然隔離，天然實作各tab容器的浏覽記錄隔離特性；
- 得益于最頂層的不可見滾動容器來接收統一的滾動互動，可以将滾動慣性傳遞下去，這點很重要，我們都知道單純的兩個嵌套滾動容器，滾動慣性是不能夠從父容器傳遞到子容器的。
但上面的方案是否适合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子容器時需做兩件事，
- 根據多tab子產品目前的距離頂部偏移量offset_1來設定其餘非可見區的子容器(C0/C2/C3)頂部偏移值，以保切換過程的獨立浏覽位置正确展示
- 記錄此時外層滾動容器的滾動偏移值n1，并記錄為scroll_1 = n1
以上操作會在橫滑視覺效果之前完成，保證橫滑過程中能正确看到下一子容器的正确浏覽位置。
橫滑結束
當橫滑動作結束後，我們做了三件事
- 恢複目前子容器C2的頂部偏移
- 使用目前子容器記錄的滾動偏移scroll_2來重新計算滾動容器S0的滾動偏移量
- 重置掉其他非可見區的子容器頂部偏移
橫滑至有浏覽記錄的tab容器
在目前tab容器為C2子容器時繼續進行上下滾動浏覽，當外層容器S0滾動值為n2時（此時C2容器距離頂部的偏移為offset_2）；再次進行右橫滑互動，此時需要操作基本與第二步一緻，但是由于C1已經存在滾動記錄，是以需對C1進行另外的計算方式：外層滾動偏移n2 減去 C1記錄的滾動偏移scroll_1 (n1)。
以上方案就能很好的完成開始總結的5個特征，并且在h5場景最大好處有兩方面：
- 各個tab容器中的内容在滾動浏覽過程中始終出自唯一的滾動容器，不會存在嵌套滾動中的滾動慣性無法傳遞或者傳遞過程的損耗；
- 主容器滾動過程完全依賴原生的滾動能力，沒有任何的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核心本身也會根據實際情況回收，并不會無邊界開銷；但對于我們來說在更長的清單中節點回收是不可逃避的話題，等待我們去解決的問題還很多，如何做到不定高回收重建？如何在不影響滾動性能的同時設計高性能回收與重建？低系統版本應該如何考慮？等等