CocosCreator之分層管理的ListView

前言

進入公衆號回覆listview便可得到demo的git地址。git

  1. 以前寫的一篇文章《Creator之ScrollView那些事》中提到了官方Demo中提供的ListViewCtl,只是實現了縱向滑動,沒有實現橫向滑動。而且建議官方能夠把功能作全而後放入組件庫中供開發者使用。
  2. 而後有個牛逼大神說這個ListView不ok。要我對本身的公衆號內容負責。我還覺得有什麼嚴重的bug,實際上是打斷了合批操做。對於官方提供的ListViewCtr的操做方式確定會打斷合批的 !不過對於一些簡單的需求,好比我上次文章中的這個截圖。
    image.png
    這樣的列表須要合批嗎?個人需求就是少建立幾個節點就能夠了。因此我以爲ok不ok仍是要看需求吧!爲何tableview呼聲那麼高,而Laya也在官方組件中支持了ListView,已是很好的說明了。

ListView的侷限

  1. 首先,這個ListView是有侷限的,它直接將Item放入了content中,確定會打斷合批操做;
    image.png
    若是你有一個多列多行,而且item很是複雜的需求,那麼用這個ListView確定是不合適的。就比如你用一把殺雞的刀去殺一頭牛,不悲劇纔怪!因此你們在看到別人分享東西的時候建議最好不要拿來主義,而是通過分析後決定用仍是不用,我相信做爲程序猿,這點判斷能力仍是有的!數組

  2. 其次 ,這個ListView不支持網格顯示。若是想要多行或者多列顯示,須要本身在一個Item中排列好。而後本身設置每一個道具的顯示與隱藏,因此對於有多列顯示需求的狀況仍是比較複雜的。性能優化

那麼我先說說ListView採用的原理,而後再說說如何改進吧。微信

ListView採用的原理

  1. 根據可顯示區域的寬或者高計算出須要建立的道具的數量。而後多加一行或者一列,避免滑動的時候顯示不天然。
    image.png
  2. 滑動時,將離開可見區域的道具放到與滑動方向相反的一端重複使用。
    image.png
  3. 原理其實就這麼兩點,目的就是少建立節點。

支持網格顯示的ListView——GridListView

  1. 首先我爲以前的ListView增長了網格顯示能力,代碼中經過給定的spaceX和spaceY 結合可顯示區域的寬或者高計算可顯示的列數或者行數
    image.png
  2. 若是隻是作了網格顯示能力而不作分層管理其實同樣有侷限1。雖然比你直接把道具放入content中好不少,可是dc依然很高。

支持分層管理的ListView——GridLayerListView

  1. GridLayerListView 是繼承了GridListView,重寫了設置座標和添加節點的方法。
    image.png
    image.png
  2. 這裏的item依然被添加到了content中,只是此時的它已經沒有子節點了,只是用來判斷是否離開顯示區域而存在的。
  3. 同時在添加item的時候給item自定義了一個LIST屬性,用於保存子節點的引用,由於已經不能經過item的children數組得到子節點了。
  4. 爲每一個子節點自定義一個屬性INIT_POS,保存本地座標,更新位置的時候會用到。
    image.png
  5. 爲了保證全部節點顯示位置的正確性,代碼中直接移除節點中存在的widget組件。
    image.png
  6. 當你將一個ScrollView拖到界面上時,只須要調整ScrollView和view的寬高,代碼中直接刪除了默認的item節點
    image.png
  7. GridLayerListView並無使用對象池,若是確實有須要能夠在getItem函數中本身經過對象池獲取道具。
    image.png
  8. 經過設置ScrollView的Horizontal 和 Vertical 改變滾動方向,同時只支持一個方向滾動。
    image.png

使用方式

  1. 將一個ScrollView拖到界面中,掛上GridLayerListView組件
    image.png
  2. 定義一個處理邏輯的組件掛到界面上,並在邏輯組件中聲明好使用的變量和函數,設置好GridLayerListView的參數。(其實跟ListViiew的使用方式是同樣的)
    image.png
  3. 設置ScrollView 和View 的寬高,注意尤爲是View的寬高,由於View大小就是可見區域,代碼中會根據View的寬高判斷應該顯示的列數或者行數。注意列數或者行數等於寬度或者高度/(item的寬度或者高度+橫向間距或者縱向間距)
    image.png

使用效果

爲了看優化的效果,用到的兩個紋理都去掉了Packable選項
image.png函數

  1. 不分層的GridListView dc=64
    image.png
    在不分層管理的狀況下,道具中的label是否設置爲Char模式dc都是同樣的。
  2. 分層+Label不爲Char模式 dc=23
    image.png
  3. 分層+Label爲Char模式 dc=9
    image.png
  4. 道具的預製體結構
    image.png
  5. 道具使用狀況
    image.png
    根據後臺輸出能夠看出,一共有35個須要顯示的道具,實際上只建立了3 x5 = 15個道具就搞定了。
  6. dc 從64 減小到9,依然用上了ListView少建立,重複利用的原理,只是加上分層管,達到了這樣的效果,還算過得去吧。

結語

  1. 以上是我在以前的ListView基礎上添加了網格顯示,分層管理等能力後寫出來的新組件,我給它起名叫GridLayerListView,是由於它是一個支持網格顯示,分層管理節點的ListView。一個既能夠殺雞也能夠殺牛的刀。就是對ListView情有獨鍾,沒辦法了。
  2. 我並無說這個是最優的方案,也不保證沒有bug(我還不是一個敢說本身寫的東西沒bug的牛人),思想僅供參考,大神能夠繞道。若是你想將dc降到更低,那麼你還須要作一些其餘的優化。建議閱讀文弱書生陳皮皮的《Cocos Creator 性能優化:DrawCall》

進入公衆號回覆listview便可得到demo的git地址。性能

歡迎掃碼關注公衆號《微笑遊戲》,瀏覽更多內容。若是您以爲文章還能夠,點贊、在看、分享、贊助都是對我最大的鼓勵,在下將感激涕零。

微信圖片_20190904220029.jpg

歡迎掃碼關注公衆號《微笑遊戲》,瀏覽更多內容。優化

相關文章
相關標籤/搜索