摘要：論壇上有過這么一篇熱門文章，它從角度分析了無限滾動(dòng)加載的設(shè)計(jì)實(shí)踐。無限滾動(dòng)加載背后的技術(shù)挑戰(zhàn)其實(shí)比想象中要多不少。整體思路和方案設(shè)計(jì)我們要實(shí)現(xiàn)的頁面樣例如圖，它能夠做到無限下拉加載內(nèi)容。

UX Planet論壇上有過這么一篇熱門文章: Infinite Scrolling Best Practices，它從UX角度分析了無限滾動(dòng)加載的設(shè)計(jì)實(shí)踐。

無限滾動(dòng)加載在互聯(lián)網(wǎng)上到處都有應(yīng)用：
豆瓣首頁是一個(gè)，F(xiàn)acebook的Timeline是一個(gè)，Tweeter的話題列表也是一個(gè)。當(dāng)你向下滾動(dòng)，新的內(nèi)容就神奇的“無中生有”了。這是一個(gè)得到廣泛贊揚(yáng)的用戶體驗(yàn)。

無限滾動(dòng)加載背后的技術(shù)挑戰(zhàn)其實(shí)比想象中要多不少。尤其是要考慮頁面性能，需要做到極致。
本文通過代碼實(shí)例，來實(shí)現(xiàn)一個(gè)無限滾動(dòng)加載效果。更重要的是，在實(shí)現(xiàn)過程中，對于頁面性能的分析和處理力圖做到最大化，希望對讀者有所啟發(fā)，同時(shí)也歡迎與我討論。

在開啟我們的代碼之前，有必要先了解一下常用的性能測量手段：

1）使用window.performance

HTML5帶來的performance API功能強(qiáng)大。我們可以使用其performance.now()精確計(jì)算程序執(zhí)行時(shí)間。performance.now()與Date.now()不同的是，返回了以微秒（百萬分之一秒）為單位的時(shí)間，更加精準(zhǔn)。并且與 Date.now() 會(huì)受系統(tǒng)程序執(zhí)行阻塞的影響不同，performance.now() 的時(shí)間是以恒定速率遞增的，不受系統(tǒng)時(shí)間的影響（系統(tǒng)時(shí)間可被人為或軟件調(diào)整）。
同時(shí)，也可以使用performance.mark()標(biāo)記各種時(shí)間戳（就像在地圖上打點(diǎn)），保存為各種測量值（測量地圖上的點(diǎn)之間的距離），便可以批量地分析這些數(shù)據(jù)了。

2）使用console.time方法與console.timeEnd方法

其中console.time方法用于標(biāo)記開始時(shí)間，console.timeEnd方法用于標(biāo)記結(jié)束時(shí)間，并且將結(jié)束時(shí)間與開始時(shí)間之間經(jīng)過的毫秒數(shù)在控制臺中輸出。

3）使用專業(yè)的測量工具／平臺：jsPerf

這次實(shí)現(xiàn)中，我們使用第二種方法，因?yàn)樗呀?jīng)完全可以滿足我們的需求，且兼容性更加全面。

我們要實(shí)現(xiàn)的頁面樣例如圖，

它能夠做到無限下拉加載內(nèi)容。我把紅線標(biāo)出的部分叫做一個(gè)block-item，后續(xù)也都用這種命名。

1）關(guān)于設(shè)計(jì)方案，肯定第一個(gè)最基本、最樸素的思想是下拉到底部之后發(fā)送ajax異步請求，成功之后的回調(diào)里進(jìn)行頁面拼接。

2）但是觀察頁面布局，很明顯圖片較多，每一個(gè)block-item區(qū)塊都有一張配圖。當(dāng)加載后的內(nèi)容插入到頁面中時(shí)，瀏覽器就開始獲取圖片。這意味著所有的圖像同時(shí)下載，瀏覽器中的下載通道將被占滿。同時(shí)，由于內(nèi)容優(yōu)先于用戶瀏覽而加載，所以可能被迫下載底部那些永遠(yuǎn)也不會(huì)被用戶瀏覽到的圖像。
所以，我們需要設(shè)計(jì)一個(gè)懶加載效果，使得頁面速度更快，并且節(jié)省用戶的流量費(fèi)用和延長電池壽命。

3）上一條提到的懶加載實(shí)現(xiàn)上，為了避免到真正的頁面底部時(shí)才進(jìn)行加載和渲染，而造成用戶較長時(shí)間等待。我們可以設(shè)置一個(gè)合理閾值，在用戶滾動(dòng)到頁面底部之前，先進(jìn)行提前加載。

4）另外，頁面滾動(dòng)的事件肯定是需要監(jiān)聽的。同時(shí)，頁面滾動(dòng)問題也比較棘手，后面將專為滾動(dòng)進(jìn)行分析。

5）DOM操作我們知道是及其緩慢而低效的，有興趣的同學(xué)可以研究一下jsPerf上一些經(jīng)典的benchmark，比如這篇。關(guān)于造成這種緩慢的原因，社區(qū)上同樣有很多文章有過分析，這里就不再深入。但我想總結(jié)并補(bǔ)充的是：DOM操作，光是為了找一個(gè)節(jié)點(diǎn)，就從本質(zhì)上比簡單的檢索內(nèi)存中的值要慢。一些DOM操作還需要重新計(jì)算樣式來讀取或檢索一個(gè)值。更突出的問題在于：DOM操作是阻塞的，所以當(dāng)有一個(gè)DOM操作在進(jìn)行時(shí)，其他的什么都不能做，包括用戶與頁面的交互（除了滾動(dòng)）。這是一個(gè)極度傷害用戶體驗(yàn)的事實(shí)。

所以，在下面的效果實(shí)現(xiàn)中，我采用了大量“不可思議”的DOM緩存，甚至極端的緩存everything。當(dāng)然，這樣做的收益也在最后部分有所展現(xiàn)。

滾動(dòng)問題不難想象在于高頻率的觸發(fā)滾動(dòng)事件處理上。具我親測，在極端case下，滾動(dòng)及其卡頓。即使?jié)L動(dòng)不卡頓，你可以打開Chrome控制臺發(fā)現(xiàn)，幀速率也非常慢。關(guān)于幀速率的問題，我們有著名的16.7毫秒理論。關(guān)于這個(gè)時(shí)間分析，社區(qū)上也有不少文章闡述，這里不再展開。

針對于此，有很多讀者會(huì)立刻想到“截流和防抖動(dòng)函數(shù)”（Throttle和Debounce）。
簡單總結(jié)一下：

1）Throttle允許我們限制激活響應(yīng)的數(shù)量。我們可以限制每秒回調(diào)的數(shù)量。反過來，也就是說在激活下一個(gè)回調(diào)之前要等待多少時(shí)間;

2）Debounce意味著當(dāng)事件發(fā)生時(shí)，我們不會(huì)立即激活回調(diào)。相反，我們等待一定的時(shí)間并檢查相同的事件是否再次觸發(fā)。如果是，我們重置定時(shí)器，并再次等待。如果在等待期間沒有發(fā)生相同的事件，我們就立即激活回調(diào)。

具體這里就不代碼實(shí)現(xiàn)了。原理明白之后，應(yīng)該不難寫出。

但是我這里想從移動(dòng)端主要瀏覽器處理滾動(dòng)的方式入手，來思考這個(gè)問題：

1）在Android機(jī)器上，用戶滾動(dòng)屏幕時(shí)，滾動(dòng)事件高頻率發(fā)生——在Galaxy－SIII手機(jī)上，大約頻率是一秒一百次。這意味著，滾動(dòng)處理函數(shù)也被調(diào)用了數(shù)百次，而這些又都是成本較大的函數(shù)。

2）在Safari瀏覽器上，我們遇到的問題恰恰是相反的：用戶每次滾動(dòng)屏幕時(shí)，滾動(dòng)事件只在滾動(dòng)動(dòng)畫停止時(shí)才觸發(fā)。當(dāng)用戶在iPhone上滾動(dòng)屏幕時(shí)，不會(huì)運(yùn)行更新界面的代碼（滾動(dòng)停止時(shí)才會(huì)運(yùn)行一次）。

另外，我想也許會(huì)有讀者想到rAf（requestAnimationFrame），但是據(jù)我觀察，很多前端其實(shí)并不明白requestAnimationFrame技術(shù)的原理和解決的問題。只是機(jī)械地把動(dòng)畫性能、掉幀問題甩到這么一個(gè)名詞上。在真實(shí)項(xiàng)目中，也沒有親自實(shí)現(xiàn)過，更不要說考慮requestAnimationFrame的兼容性情況了。這里場景我并不會(huì)使用rAf，因?yàn)?。setTimeout的定時(shí)器值推薦最小使用16.7ms（原因請去社區(qū)上找答案，不再細(xì)講），我們這里并不會(huì)超過這個(gè)限制，并且考慮兼容性。關(guān)于這項(xiàng)技術(shù)的使用，如果有問題，歡迎留言討論。

基于以上，我的解決方案是既不同于Throttle，也不同于Debounce，但是和這兩個(gè)思想，尤其是Throttle又比較類似：把滾動(dòng)事件替換為一個(gè)帶有計(jì)時(shí)器的滾動(dòng)處理程序，每100毫秒進(jìn)行簡單檢查，看這段時(shí)間內(nèi)用戶是否滾動(dòng)過。如果沒有，則什么都不做；如果有，就進(jìn)行處理。

在圖像加載完成時(shí)，使用淡入（fade in）效果出現(xiàn)。這在實(shí)際情況上會(huì)稍微慢一下，應(yīng)該慢一個(gè)過渡執(zhí)行時(shí)間。但用戶體驗(yàn)上感覺會(huì)更快。這是已經(jīng)被證實(shí)且普遍應(yīng)用的小“trick”。但是據(jù)我感覺，它確實(shí)有效。我們的代碼實(shí)現(xiàn)也采用了這個(gè)小竅門。不過類似這種“社會(huì)心理學(xué)”范疇的東西，顯然不是本文研究的重點(diǎn)。

代碼上將會(huì)采用：超前閾值的懶加載＋DOM Cache和圖片Cache＋滾動(dòng)throttle模擬＋CSS fadeIn動(dòng)畫。
具體功能封裝上和一些實(shí)現(xiàn)層面的東西，請您繼續(xù)閱讀。

整體結(jié)構(gòu)如下：

主體內(nèi)容放在id為“expListBox”的container里面，id為“expList”的ul是頁面加載內(nèi)容的容器。
因?yàn)槊看渭虞d并append進(jìn)入HTML的內(nèi)容相對較多。我使用了模版來取代傳統(tǒng)的字符串拼接。前端模版這次選用了我的同事顏海鏡大神的開源作品，模版結(jié)構(gòu)為：

     <#dataList.forEach(function (v) {#>
        

            

                
                    
                    
                    <#=v.title#>
                    <#=v.writer#>
                    <#=v.succNum#>
                
            
        
    <#})#>

以上模版內(nèi)容由每次ajax請求到的數(shù)據(jù)填充，并添加進(jìn)入頁面，構(gòu)成每個(gè)block-item。
這里需要注意觀察，有助于對后面邏輯的理解。頁面中一個(gè)block-item下div屬性存有該block-item的eid值，對應(yīng)class叫做"slide"，子孫節(jié)點(diǎn)包含有一個(gè)image標(biāo)簽，src初始賦值為1px的空白圖進(jìn)行占位。真實(shí)圖片資源位置存儲(chǔ)在"data-src"中。
另外，請求返回的數(shù)據(jù)dataList可以理解為由9個(gè)對象構(gòu)成的數(shù)組，也就是說，每次請求加載9個(gè)block-item。

樣式方面不是這篇文章的重點(diǎn)，挑選最核心的一行來說明一下：

    .slide .img{
        display: inline-block;
        width: 90px;
        height: 90px;
        margin: 0 auto;
        opacity: 0;
        -webkit-transition: opacity 0.25s ease-in-out;
        -moz-transition: opacity 0.25s ease-in-out;
        -o-transition: opacity 0.25s ease-in-out;
        transition: opacity 0.25s ease-in-out;
    }

唯一需要注意的是image的opacity設(shè)置為0，圖片將會(huì)在成功請求并渲染后調(diào)整為1，輔助transition屬性實(shí)現(xiàn)一個(gè)fade in效果。
對應(yīng)我們上面所提到的那個(gè)“trick”

我是完全按照業(yè)務(wù)需求來設(shè)計(jì)，并沒有做抽象。其實(shí)這樣的一個(gè)下拉加載功能完全可以抽象出來。有興趣的讀者可以下去自己進(jìn)行封裝和抽象。
我們先把精力集中在邏輯處理上。
下面進(jìn)入我們最核心的邏輯部分，為了防止全局污染，我把它放入了一個(gè)立即執(zhí)行函數(shù)中：

    (function() {
        var fetching = false; 
        var page = 1;
        var slideCache = [];
        var itemMap = {};
        var lastScrollY = window.pageYOffset;
        var scrollY = window.pageYOffset;
        var innerHeight;
        var topViewPort;
        var bottomViewPort;
        
        function isVisible (id) {
            // ...判斷元素是否在可見區(qū)域
        }
        
        function updateItemCache (node) {
            // ....更新DOM緩存
        }
        
        function fetchContent () {
            // ...ajax請求數(shù)據(jù)
        }
        

        function handleDefer () {
            // ...懶加載實(shí)現(xiàn)
        }

        function handleScroll (e, force) {
            // ...滾動(dòng)處理程序
        } 
        
        window.setTimeout(handleScroll, 100);
        fetchContent();
    }());

我認(rèn)為好的編程習(xí)慣是在程序開頭部分便聲明所有的變量，防止“變量提升”帶來的潛在困擾，并且也有利于程序的整體把控。
我們來看一下變量設(shè)置：

    // 加載中狀態(tài)鎖
    1）var fetching = false;
    // 用于加載時(shí)發(fā)送請求參數(shù)，表示第幾屏內(nèi)容，初始為1，以后每請求一次，遞增1
    2）var page = 1; 
    // 只緩存最新一次下拉數(shù)據(jù)生成的DOM節(jié)點(diǎn)，即需要插入的dom緩存數(shù)組
    3）var slideCache = []; 
    // 用于已經(jīng)生成的DOM節(jié)點(diǎn)儲(chǔ)存，存有item的offsetTop，offsetHeight
    4) var slideMap = {}; 
    // pageYOffset設(shè)置或返回當(dāng)前頁面相對于窗口顯示區(qū)左上角的Y位置。
    5）var lastScrollY = window.pageYOffset; var scrollY = window.pageYOffset;
    // 瀏覽器窗口的視口（viewport）高度
    6）var innerHeight;
    // isVisible的上下閾值邊界
    7) var topViewPort; 
    8) var bottomViewPort; 

關(guān)于DOM cache的變量詳細(xì)說明，在后文有提供。

同樣，我們有5個(gè)函數(shù)。在上面的代碼中，注釋已經(jīng)寫明白了每個(gè)方法的具體作用。接下來，我們逐個(gè)分析。

它接受兩個(gè)變量，第二個(gè)是一個(gè)布爾值force，表示是否強(qiáng)制觸發(fā)滾動(dòng)程序執(zhí)行。

核心思路是：如果時(shí)間間隔100毫秒內(nèi)，沒有發(fā)生滾動(dòng)，且并未強(qiáng)制觸發(fā)，則do nothing，間隔100毫秒之后再次查詢，然后直接return。
其中，是否發(fā)生滾動(dòng)由lastScrollY === window.scrollY來判斷。
在100毫秒之內(nèi)發(fā)生滾動(dòng)或者強(qiáng)制觸發(fā)時(shí)，需要判斷是否滾動(dòng)已接近頁面底部。如果是，則拉取數(shù)據(jù)，調(diào)用fetchContent方法，并調(diào)用懶加載方法handleDefer。
并且在這個(gè)處理程序中，我們計(jì)算出來了isVisible區(qū)域的上下閾值。我們使用600作為浮動(dòng)區(qū)間，這么做的目的是在一定范圍內(nèi)提前加載圖片，節(jié)省用戶等待時(shí)間。當(dāng)然，如果我們進(jìn)行抽象時(shí)，可以把這個(gè)值進(jìn)行參數(shù)化。

    function handleScroll (e, force) {
        // 如果時(shí)間間隔內(nèi)，沒有發(fā)生滾動(dòng)，且并未強(qiáng)制觸發(fā)加載，則do nothing，再次間隔100毫秒之后查詢
        if (!force && lastScrollY === window.scrollY) {
            window.setTimeout(handleScroll, 100);
            return;
        }
        else {
            // 更新文檔滾動(dòng)位置
            lastScrollY = window.scrollY;
        }
        scrollY = window.scrollY;
        // 瀏覽器窗口的視口（viewport）高度賦值
        innerHeight = window.innerHeight;
        // 計(jì)算isVisible上下閾值
        topViewPort = scrollY - 1000;
        bottomViewPort = scrollY + innerHeight + 600;

        // 判斷是否需要加載
        // document.body.offsetHeight;返回當(dāng)前網(wǎng)頁高度 
        if (window.scrollY + innerHeight + 200 > document.body.offsetHeight) {
            fetchContent();
        }
        // 實(shí)現(xiàn)懶加載
        handleDefer();
        window.setTimeout(handleScroll, 100);
    } 

這里我用到了自己封裝的ajax接口方法，它基于zepto的ajax方法，只不過又手動(dòng)采用了promise包裝一層。實(shí)現(xiàn)比較簡單，當(dāng)然有興趣可以找我要一下代碼，這里不再詳細(xì)說了。
我們使用前端模版進(jìn)行HTML渲染，同時(shí)調(diào)用updateItemCache，將此次數(shù)據(jù)拉取生成的DOM節(jié)點(diǎn)緩存。之后手動(dòng)觸發(fā)handleScroll，更新文檔滾動(dòng)位置和懶加載處理。

    function fetchContent () {
        // 設(shè)置加載狀態(tài)鎖
        if (fetching) {
            return;
        }
        else {
            fetching = true;
        }
        ajax({
            url: (!location.pathname.indexOf("/m/") ? "/m" : "")
                + "/list/asyn?page=" + page + (+new Date),
            timeout: 300000,
            dataType: "json"
        }).then(function (data) {
            if (data.errno) {
                return;
            }
            console.time("render");

            var dataList = data.data.list;
            var len = dataList.length;
            var ulContainer = document.getElementById("expList");
            var str = "";
            var frag = document.createElement("div");

            var tpl = __inline("content.tmpl");
            for (var i = 0; i < len; i++) {
                str = tpl({dataList: dataList});
            }
            frag.innerHTML = str;
            ulContainer.appendChild(frag);
            // 更新緩存
            updateItemCache(frag);
            // 已經(jīng)拉去完畢，設(shè)置標(biāo)識為true
            fetching = false;
            // 強(qiáng)制觸發(fā)
            handleScroll(null, true);
            page++;
            console.timeEnd("render");
        }, function (xhr, type) {
            console.log("Refresh:Ajax Error!");
        });
    }

之前參數(shù)里提到過，一共有兩個(gè)用于緩存的對象／數(shù)組：

1）slideCache：緩存最近一次加載過的數(shù)據(jù)生成的DOM內(nèi)容，緩存方式為數(shù)組儲(chǔ)存：

    slideCache = [
        {
            id: "s-97r45",
            img: img DOM節(jié)點(diǎn),
            node: 父容器DOM node,類似
,
            src: 圖片資源地址
        },
        ...
    ]

slideCache由updateItemCache函數(shù)更新，主要用于懶加載時(shí)的賦值src。這樣我們做到“只寫入DOM”原則，不需要再從DOM讀取。

2）slideMap：緩存DOM節(jié)點(diǎn)的高度和offsetTop，以DOM節(jié)點(diǎn)的id為索引。存儲(chǔ)方式：

    slideMap = {
        s-97r45: {
            node: DOM node,類似
,
            offTop: 300,
            offsetHeight: 90
        }
    }

slideMap根據(jù)isVisible方法的參數(shù)進(jìn)行更新和讀取。使得我們在判斷是否isVisible時(shí)，大量減少讀取DOM的操作。

在上面的滾動(dòng)處理程序中，我們調(diào)用了handleDefer函數(shù)。我們看一下這個(gè)函數(shù)的實(shí)現(xiàn)：

    function handleDefer () {
        // 時(shí)間記錄
        console.time("defer");

        // 獲取dom緩存
        var list = slideCache;
        // 對于遍歷list里的每一項(xiàng)，都使用一個(gè)變量，而不是在循環(huán)內(nèi)部聲明。節(jié)省內(nèi)存，把性能高效，做到極致。
        var thisImg;

        for (var i = 0, len = list.length; i < len; i++) {
            thisImg = list[i].img; // 這里我們都是從內(nèi)存中讀取，而不用讀取DOM節(jié)點(diǎn)
            var deferSrc = list[i].src; // 這里我們都是從內(nèi)存中讀取，而不用讀取DOM節(jié)點(diǎn)
            // 判斷元素是否可見
            if (isVisible(list[i].id)) {
                // 這個(gè)函數(shù)是圖片onload邏輯
                var handler = function () {
                    var node = thisImg;
                    var src = deferSrc;
                    // 創(chuàng)建一個(gè)閉包
                    return function () {
                        node.src = src;
                        node.style.opacity = 1;
                    }
                }
                var img = new Image();
                img.onload = handler();
                img.src = list[i].src;
            }
        }
        console.timeEnd("defer");
    }

主要思路就是對DOM緩存中的每一項(xiàng)進(jìn)行循環(huán)遍歷。在循環(huán)中，判斷每一項(xiàng)是否已經(jīng)進(jìn)入isVisible區(qū)域。如果進(jìn)入isVisible區(qū)域，則對當(dāng)前項(xiàng)進(jìn)行真實(shí)src賦值，并設(shè)置opacity為1。

針對每一個(gè)slide類，我們緩存對應(yīng)DOM節(jié)、id、子元素img DOM節(jié)點(diǎn)：

    function updateItemCache (node) {
        var list = node.querySelectorAll(".slide");
        var len = list.length;
        slideCache = [];
        var obj;

        for (var i=0; i < len; i++) {
            obj = {
                node: list[i],
                id: list[i].getAttribute("id"),
                img: list[i].querySelector(".img")
            }
            obj.src = obj.img.getAttribute("data-src");
            slideCache.push(obj);
        };
    }

該函數(shù)接受相應(yīng)DOM id，并進(jìn)行判斷。
如果判斷條件晦澀難懂的話，你一定要手動(dòng)畫畫圖理解一下。如果你就是懶得畫圖，那么也沒關(guān)系，我?guī)湍惝嫼昧?，只是丑一些。。?/p>

    function isVisible (id) {
        var offTop;
        var offsetHeight;
        var data;
        var node;

        // 判斷此元素是否已經(jīng)懶加載正確渲染，分為在屏幕之上（已經(jīng)懶加載完畢）和屏幕外，已經(jīng)添加到dom中，但是還未請求圖片（懶加載之前）
        if (itemMap[id]) {
            // 直接獲取offTop，offsetHeight值
            offTop = itemMap[id].offTop;
            offsetHeight = itemMap[id].offsetHeight;
        }
        else {
            // 設(shè)置該節(jié)點(diǎn)，并且設(shè)置節(jié)點(diǎn)屬性：node，offTop，offsetHeight
            node = document.getElementById(id);
            // offsetHeight是自身元素的高度
            offsetHeight = parseInt(node.offsetHeight);
            // 元素的上外緣距離最近采用定位父元素內(nèi)壁的距離
            offTop = parseInt(node.offsetTop);
        }

        if (offTop + offsetHeight > topViewPort && offTop < bottomViewPort) {
            return true;
        }
        else {
            return false;
        }
    }

如上代碼，我們主要進(jìn)行了兩方面的性能考量：

1）延遲加載時(shí)間

2）渲染DOM時(shí)間

整體收益如下：

優(yōu)化前延遲平均值：49.2ms 中間值：43ms；

優(yōu)化后延遲平均值：17.1ms 中間值：11ms；

優(yōu)化前渲染平均值：2129.6ms 中間值：2153.5ms；

優(yōu)化后渲染平均值：120.5ms 中間值：86ms；

做完這些，其實(shí)也遠(yuǎn)遠(yuǎn)沒有達(dá)到所謂的“極致化”性能體驗(yàn)。我們無非就做了各種DOM緩存、映射、懶加載。如果繼續(xù)分析edge case，我們還能做的更多，比如：DOM回收、墓碑和滾動(dòng)錨定。這些其實(shí)很多都是借鑒客戶端開發(fā)理念，但是超前的谷歌開發(fā)者團(tuán)隊(duì)也都有了自己的實(shí)現(xiàn)。比如在去年7月份的
一篇文章：Complexities of an Infinite Scroller就都有所提及。這里從原理（非代碼）層面，也給大家做個(gè)介紹。

它的原理是，對于需要產(chǎn)生的大量DOM節(jié)點(diǎn)（比如我們下拉加載的信息內(nèi)容）不是主動(dòng)用createElement的方式創(chuàng)建，而是回收利用那些已經(jīng)移出視窗，暫時(shí)不會(huì)被需要的DOM節(jié)點(diǎn)。如圖：

雖然DOM節(jié)點(diǎn)本身并非耗能大戶，但是也不是一點(diǎn)都不消耗性能，每一個(gè)節(jié)點(diǎn)都會(huì)增加一些額外的內(nèi)存、布局、樣式和繪制。同樣需要注意的一點(diǎn)是，在一個(gè)較大的DOM中每一次重新布局或重新應(yīng)用樣式（在節(jié)點(diǎn)上增加或刪除樣式所觸發(fā)的過程）的系統(tǒng)開銷都會(huì)比較昂貴。所以進(jìn)行DOM回收意味著我們會(huì)保持DOM節(jié)點(diǎn)在一個(gè)比較低的數(shù)量上，進(jìn)而加快上面提到的這些處理過程。

據(jù)我觀察，在真正產(chǎn)品線上使用這項(xiàng)技術(shù)的還比較少?？赡苁且?yàn)閷?shí)現(xiàn)復(fù)雜度和收益比并不很高。但是，淘寶移動(dòng)端檢索頁面實(shí)現(xiàn)了類似的思想。如下圖，

每加載一次數(shù)據(jù)，就生成“.page-container .J-PageContainer_頁數(shù)”的div，在滾動(dòng)多屏之后，早已移除視窗的div的子節(jié)點(diǎn)進(jìn)行了remove()，并且為了保證滾動(dòng)條的正確比例和防止高度塌陷，顯示聲明了2956px的高度。

如之前所說，如果網(wǎng)絡(luò)延遲較大，用戶又飛快地滾動(dòng)，很容易就把我們渲染的DOM節(jié)點(diǎn)都甩在千里之外。這樣就會(huì)出現(xiàn)極差的用戶體驗(yàn)。針對這種情況，我們就需要一個(gè)墓碑條目占位在對應(yīng)位置。等到數(shù)據(jù)取到之后，再代替墓碑。墓碑也可以有一個(gè)獨(dú)立的DOM元素池。并且也可以設(shè)計(jì)出一些漂亮的過渡。這種技術(shù)在國外的一些“引領(lǐng)技術(shù)潮流”的網(wǎng)站上，早已經(jīng)有了應(yīng)有。比如下圖取自Facebook：

我在“簡書”APP客戶端上，也見過類似的方案。當(dāng)然，人家是native...

滾動(dòng)錨定的觸發(fā)時(shí)機(jī)有兩個(gè)：一個(gè)是墓碑被替換時(shí)，另一個(gè)是窗口大小發(fā)生改變時(shí)（在設(shè)備發(fā)生翻轉(zhuǎn)時(shí)也會(huì)發(fā)生）。這兩種情況，都需要調(diào)整對應(yīng)的滾動(dòng)位置。

當(dāng)你想提供一個(gè)高性能的有良好用戶體驗(yàn)的功能時(shí)，可能技術(shù)上一個(gè)簡單的問題，就會(huì)演變成復(fù)雜問題的。這篇文章便是一個(gè)例證。
隨著 “Progressive Web Apps” 逐漸成為移動(dòng)設(shè)備的一等公民（會(huì)嗎？），高性能的良好體驗(yàn)會(huì)變得越來越重要。
開發(fā)者也必須持續(xù)的研究使用一些模式來應(yīng)對性能約束。這些設(shè)計(jì)的基礎(chǔ)當(dāng)然都是成熟的技術(shù)為根本。

這篇文章參考了Flicker工程師，前YAHOO工程師Stephen Woods的《Building Touch Interfaces with HTML5》一書。以及王芃前輩對于《Complexities of an Infinite Scroller》一文的部分翻譯。