相信很多前端都遇到過這樣的需求，在乙個頁面中預載入乙個列表資料，當瀏覽器滾動到底部之後載入更多資料，然後迴圈往復這個操作。不知道大家有沒有想過這個問題，裝置的記憶體是有限的，而作業系統分配給每乙個程式的記憶體資源也是有限制的，假如我們一直把這個列表載入下去，會出現什麼樣的問題？
其實我發現這個載入更多帶來的效能瓶頸，並不是從載入更多這個功能本身得知的。而是從其他方面發現的。
在我們產品的首頁 txbb.com/m ，在iphone6上我發現slider元件滾動的那麼頓呢，這個元件是自己寫的zepto外掛程式，在 西祠首頁 也是用的它，西祠就很流暢，為什麼它這麼頓呢？後來我想起來，曾經我改過一次**，是把類的形式轉成了$.fn的形式，是不是這個原因呢？於是我重新寫了乙個頁面，載入了這個slider元件，發現，很流暢！還有乙個重點，我拿同事的安卓機發現還比iphone6上要快一點。
後來我猜到了是不是跟記憶體容量有關係，頁面太大了。我用了乙個笨的方法定位問題，我不停的刪原來頁面裡的元素，當我刪掉部分列表資料之後，問題瞬間暴露出來了，這個slider變快了！
呵呵，懂了，列表資料太多，用的記憶體太大，導致slider卡頓了。因為西祠的首頁很簡單，而我們現在的產品的首頁資料很多，所以這是問題的關鍵所在。
找到問題之後，就是優化了，可是怎麼優化呢？
我直接想到在大**的m版首頁上也有這個類似的載入更多，於是我去了大**首頁看看，大**的首頁也有載入更多的列表，但是基本不怎麼卡，這是為神馬呢？
ok，開始除錯他們的頁面。我又驚奇了，發現**首頁的列表資料中的都是以background形式載入的而不是img的src，而且滾出視野的會被隱藏，搜噶！原來問題出在這裡。
速度頓時快了不少，但還是有點卡頓，我擦，這咋辦，還卡，我鬱悶了......
我思考了一下，既然是把隱藏，它快了一些，那我乾脆把滾出視野的dom元素都隱藏不就行了，不能用opacity，沒意義，不能用display:none，影響高度，計算又帶來**複雜度的提公升，怎麼辦呢？visibility:hidden！
ok，進行了對滾出視野範圍的元素visibility:hidden之後，slider元件立馬快了，我很欣慰。優化成功！
為什麼高大上的ios卡，安卓卻好一些？
在web前端製作載入更多資料的場景中，尤其是在移動端，記憶體資源非常珍貴，一些簡單的優化都可能帶來效能提公升，一定要注意。
這次的優化工作得到了以下靈感：
移動端的記憶體是有限的，在進行**設計是要充分考慮有可能帶來的效能瓶頸。
很浪費記憶體！要小心！
visibility:hidden,display:none都可以節約記憶體
移動端touch事件 上拉載入更多
我不認為是外掛程式的問題，當時的想法是覺得引用的外掛程式存在衝突 於是，我就直接通過封裝touch事件完成上拉載入實現分頁的功能。備註 文章最後會加上為實現這個功能我找的一些外掛程式 在應用touch事件實現上拉載入更多實現分頁的效果上，其實我們用到的只有touchstart，touchmove，t...
關於H5移動端頁面的上拉載入更多的原生實現
我們知道在移動端的分頁處理 都是上拉載入更多 這樣的互動更加的友好 下面來簡單的講講 實現的原理 這個原理很簡單 就是頁面到達最底部了，那麼就去執行請求資料載入，把新得到的資料載入到分頁裡去 我們怎麼來判斷是否到底部了呢？觀察右邊的滾動條 滾動條的高度 等於瀏覽器視窗的高度 他的上下留白 頁面的總高...
移動端h5列表頁上拉分頁載入更多
解釋一下這個載入的原理，首先第乙個紅色箭頭是 成功後獲取的資料，預設是 第一頁的資料 讓後端給介面的時候要分頁 然後把第一頁的資料放到data.recordlist裡面。重點在第二個箭頭，我利用的是當螢幕高度 網頁被卷去的高 網頁正文全文高 的時候，再次呼叫getlist 就如第乙個箭頭所見，第一次...