這兩天例行查看UMeng中的統(tǒng)計數(shù)據(jù)時出現(xiàn)了一個頻現(xiàn)的BUG,簡直是觸目驚心,我的產(chǎn)品竟然能有BUG,簡直不能忍,直接貼圖吧
首先呢利用dSYM定位到了報錯的具體頁面,這個問題看字面意思是因為CollectionView的 layout 的布局原因而導(dǎo)致的崩潰
該頁面的的布局是一個TableView,Cell中會嵌套一個CollectionView而在實際使用的過程中,當(dāng)前頁面在上拉加載第一到兩頁時并不會產(chǎn)生崩潰,而在數(shù)據(jù)加載到第三頁之后,就會產(chǎn)生崩潰
[UICollectionView received layout attributes for a cell with an index path that does not exist: <NSIndexPath: 0xc000000000400016> {length = 2, path = 0 - 2}]
打了斷點之后會發(fā)現(xiàn),在運行過 numberOfItemsInSection 后, 不會進入到 cellForItemAt 中,而直接產(chǎn)生崩潰.
在上Google搜索了一番之后,在Stack overFlow 上有相應(yīng)的解決方案,在將 collectionView.collectionViewLayout.invalidateLayout() 添加到 numberOfItemsInSection 的 Return之前,使之前的布局失效,從新進行布局也會修復(fù)BUG, 但是我想 numberOfItemsInSection 是一個調(diào)動頻率較高的方法,將布局失效的代碼放置入內(nèi)會不會不合理呢.算了,還是自己動腦子想想其他方法吧.既然已經(jīng)大概找到問題的方向,解決 BUG 應(yīng)該是沒什么問題
我想之前的Layout都可以正常運轉(zhuǎn),在加載數(shù)據(jù)后在Layout方面產(chǎn)生了崩潰,那么問題應(yīng)該出現(xiàn)在 reloadData 這里.
最后檢查代碼發(fā)現(xiàn),在進行數(shù)據(jù)加載時判斷是否顯示collectionView時,我將reloadData放置在了判斷的內(nèi)部進行的,也就是說如果加載到的數(shù)據(jù)為不顯示collectionView,那么從緩存池中取出的item布局就會與數(shù)據(jù)源不符,并且沒有更新布局, 就會產(chǎn)生閃退報錯的情況.
好吧...說來說去這個疑難雜癥是解決了,原來是我的一個小失誤... 我的鍋,還想了這老半天的BUG,有什么辦法....怪我咯?
我也很絕望啊!!!
這一個小時夠我看一集人民的名義了啊!!!
