「無限加載更多」帶來的移動端性能瓶頸

引子

相信不少前端都遇到過這樣的需求，在一個頁面中預加載一個列表數據，當瀏覽器滾動到底部以後加載更多數據，而後循環往復這個操做。不知道你們有沒有想過這個問題，設備的內存是有限的，而操做系統分配給每個程序的內存資源也是有限制的，假如咱們一直把這個列表加載下去，會出現什麼樣的問題？

OK，我遇到問題了

其實我發現這個加載更多帶來的性能瓶頸，並非從加載更多這個功能自己得知的。而是從其餘方面發現的。

在咱們產品的首頁 txbb.com/m ，在iPhone6上我發現slider組件滾動的那麼頓呢，這個組件是本身寫的zepto插件，在 西祠首頁 也是用的它，西祠就很流暢，爲何它這麼頓呢？後來我想起來，曾經我改過一次代碼，是把類的形式轉成了$.fn的形式，是否是這個緣由呢？因而我從新寫了一個頁面，加載了這個slider組件，發現，很流暢！還有一個重點，我拿同事的安卓機發現還比iPhone6上要快一點。

後來我猜到了是否是跟內存容量有關係，頁面太大了。我用了一個笨的方法定位問題，我不停的刪原來頁面裏的元素，當我刪掉部分列表數據以後，問題瞬間暴露出來了，這個slider變快了！

呵呵，懂了，列表數據太多，用的內存太大，致使slider卡頓了。由於西祠的首頁很簡單，而咱們如今的產品的首頁數據不少，因此這是問題的關鍵所在。

找到問題以後，就是優化了，但是怎麼優化呢？

淘寶M版帶來的靈感

我直接想到在大淘寶的M版首頁上也有這個相似的加載更多，因而我去了大淘寶首頁看看，大淘寶的首頁也有加載更多的列表，可是基本不怎麼卡，這是爲神馬呢？

OK，開始調試他們的頁面。我又驚奇了，發現淘寶首頁的列表數據中的圖片都是以background形式加載的而不是img的src，並且滾出視野的圖片會被隱藏，搜噶！原來問題出在這裏。

開始優化

說幹就幹，我模仿淘寶首頁進行了代碼重構，將個人加載更多列表也作了同樣的優化：

• 圖片改成background

• 滾出視野範圍隱藏圖片

速度頓時快了很多，但仍是有點卡頓，我擦，這咋辦，還卡，我鬱悶了......

觸類旁通

我思考了一下，既然是把圖片隱藏，它快了一些，那我乾脆把滾出視野的dom元素都隱藏不就好了，不能用opacity，沒意義，不能用display:none，影響高度，計算又帶來代碼複雜度的提高，怎麼辦呢？visibility:hidden！

OK，進行了對滾出視野範圍的元素 visibility:hidden 以後，slider組件立馬快了，我很欣慰。優化成功！

遺留問題的猜想

爲何高大上的iOS卡，安卓卻好一些？

我猜是由於iOS對app的內存分配的更加嚴格，而安卓卻很慷慨，因此不會卡。

總結

在web前端製做加載更多數據的場景中，尤爲是在移動端，內存資源很是珍貴，一些簡單的優化均可能帶來性能提高，必定要注意。

此次的優化工做獲得瞭如下靈感：

• img src 比 background 方式展現圖片，使用到的內存資源可能會更多

• 移動端的內存是有限的，在進行代碼設計是要充分考慮有可能帶來的性能瓶頸。

• 圖片很浪費內存！要當心！

• visibility:hidden, display:none 均可以節約內存

---

這是個人原創文章，原文地址：http://lpgray.me/article/51/