基於duilib的虛擬列表實現

本文由做者鄒啓文受權網易雲社區發佈。

在郵箱大師選擇duilib做爲UI開發庫後，咱們面臨這樣一個問題。隨着時間的積累，用戶數據會愈來愈多，如何保證咱們的軟件在展現這些數據時依然保持很是好的體驗？

原生態duilib列表的實現是，數據與控件（列表的每一項）一一對應，即有多少數據，便有多少控件。經過粗略測試，咱們發現，當數據量達到10000封郵件時，僅僅是構造這10000個控件就須要花費16s，也就是說在這16s內，用戶沒法操做軟件，這是咱們沒法接受的。因此，咱們決定改進duilib列表，經過虛擬化的方式解決這個問題。

  虛擬化，就是，對於10000封郵件，咱們並不須要構造10000個控件，由於真正可讓用戶看見的不超過20（根據屏幕高度和控件高度計算）個控件，那麼，咱們能夠經過反覆利用這20個控件來達到展現10000封郵件的目的。

  那麼，具體如何實現呢？很簡單，在鼠標上下滾動的時候，咱們對這20個控件從新佈局（更改其位置）和更新其內容。

  可是，產品和視覺提出了一個需求，給列表滾動加上動畫效果，即用戶滾動列表鬆開鼠標後，列表內容仍要向上或向下以必定的速度前進，以後才停下來。那麼，上面的方案便行不通，由於20個控件在滾動時不斷從新佈局和更新內容比較耗時，會致使列表出現卡頓式的前進，用戶體驗太差。如何解決這個問題呢？

  咱們的解決辦法是採用100個控件。這樣，在滾動時判斷是否須要從新佈局，若是不須要，則直接刷新繪製新的郵件內容，若是到了臨界條件，那麼再從新佈局而後繪製新的郵件內容。具體作法以下：

臨界條件的判斷：

　　假設滾動條的位置爲yScrollPos，列表的區域爲rcList，第一個列表項的位置爲rcFirst，最後一個列表項的位置爲rcLast。

　　當yScrollPos > (rcLast.bottom-rcList.top)-rcList.Height時，爲向下滾動的臨界條件；

　　當yScrollPos < rcFirst.top-rcList.top時，爲向上滾動的臨界條件。

1，向下滾動到臨界條件

特別注意：存在靠近最底部時從新佈局的狀況，100個列表項的後面不可見的一部分項能夠置爲無效。

2，向上滾動到臨界條件

特別注意：存在靠近頂部時從新佈局的狀況，此時，與上面圖不一樣的是，大部分項會佈局在下面，少部分在上面，可是沒有關係，由於此後向上滾動，不會再觸發從新佈局。

目前郵箱大師中，虛擬列表應用在郵件列表、通信錄列表、寫信聯繫人列表等，極大提升了軟件運行性能和體驗，並且運行穩定。

免費領取驗證碼、內容安全、短信發送、直播點播體驗包及雲服務器等套餐

更多網易技術、產品、運營經驗分享請訪問網易雲社區。

文章來源： 網易雲社區