Re: [問題] UICollectionView 的更新加快(已解決)

看板MacDev作者 (吹笛牧童)時間9年前 (2014/11/03 01:25), 9年前編輯推噓0(0010)
留言10則, 2人參與, 最新討論串1/2 (看更多)
: → mraaa: 何不用OperationQueue的方式把每一小塊的運算放進Queue裡? 11/02 13:36 : → mraaa: 再配合Thread,每個Operation做完用Delegate回頭去處理顯示 11/02 13:37 : → mraaa: 基本上CollectionView適合每個小塊會重複的動作.... 11/02 13:38 : → mraaa: 如果每個小區塊都不同...實在沒有用CollectionView的意義 11/02 13:39 剛大略看了 NSOperationQuere 不知道我這是不是多做了 這兩天我寫了個架構,可以重覆使用,解決了運算及 ui 間不流暢的問題: 1.我設定的任務是 ui 可以有輸入,然後內部要經過運算,再去更新 ui 2.假設計算很花費時間,比如兩秒,因此我另外用一個專門的 thread 在做 3.當運算中如果 ui 又有輸入,則會重新運算,不急著更新 ui 因此輸出結果的 ui 是會有點慢,但整體就流暢了 (輸入部份不會卡卡) 這就是我經常被要求的,程式架構如下 - (void)updateThread { [mDirtyEvent lock]; while ( !mQuitThread ) { if ( !mDirty ) [mDirtyEvent wait]; mDirty = false; //calc, 假設兩秒, 因為這是專門運算的 thread, 所以不會拖到 ui if ( mDirty ) continue; dispatch_async(dispatch_get_main_queue(), ^{ //update ui, 因為 ui 必需在 mainthread 中操作,所以必需 //dispatch 出去 }); } [mDirtyEvent unlock]; } - (void)setDirty { mDirty = true; [mDirtyEvent signal]; } - (void)init { newObj->mDirtyEvent = [NSCondition new]; dispatch_queue_t queue = dispatch_queue_create("updateui", NULL); dispatch_async(queue, ^{ [newObj updateThread]; //啟動一個專門運算的 thread }); } - (void)dealloc { mQuitThread = true; } 如上,這架構這兩天用得蠻開心的 但還是有些不懂 mQuitThread 這個變數,似乎不太需要 因為 updateThread 好像會自己結束,根本不用我操心 這是我難以理解的.. -- 活動/美食計劃 蘭嶼 魚白 勝興車站 星月天空 武陵 草嶺古道 嘉義阿里山小火車 保齡球  司馬庫斯 手包水餃 日月潭纜車 合歡攻頂 馬祖 鹽山 南庄 澎湖 溪頭/松林町 南投天梯 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 27.244.151.168 ※ 文章網址: http://www.ptt.cc/bbs/MacDev/M.1414949158.A.41B.html

11/03 01:36, , 1F
updateThread 是個內部有 while loop 的 thread
11/03 01:36, 1F

11/03 01:37, , 2F
因此如果不結束它,應該是會浪費系統資源;我用一個變數
11/03 01:37, 2F

11/03 01:37, , 3F
來管理它的生命週期;然後在 unlock 那行設中斷點,想檢
11/03 01:37, 3F

11/03 01:38, , 4F
查 while loop 有沒有如我預期的結束;結果都等不到..
11/03 01:38, 4F

11/03 02:14, , 5F
mQuitThread 在dealloc中才改變,等不到是正常的.
11/03 02:14, 5F

11/03 04:57, , 6F
為什麼?因為我 create 的 queue 會自己先結束?
11/03 04:57, 6F

11/03 04:57, , 7F
有這一段的說明文件嗎?
11/03 04:57, 7F

11/03 09:35, , 8F
去檢查一下mQuitThread在那裡會改變吧.
11/03 09:35, 8F

11/03 09:35, , 9F
從你公開的內容中, mQuitThread只在dealloc 會變動.
11/03 09:35, 9F

11/03 09:36, , 10F
如果dealloc一直沒被呼叫到, 把中斷點設在迴圈外有用嗎?
11/03 09:36, 10F
我寫了一小段程式來測這個現象 程式非常小,以避免檢查不完的 reference TestView* view; view = [TestView new]; view = nil; // dealloc soon view = [[NSBundle mainBundle] loadNibNamed:@"TestView" owner:nil options:nil][0]; view = nil; // dealloc later view = [[NSBundle mainBundle] loadNibNamed:@"TestView" owner:nil options:nil][0]; view = nil; // dealloc later TestView.xib 很簡單,new 出來後就指定唯一的 view 是 TestView 這個 class 然後用 nslog 監視 TestView 的 dealloc 上面程式的測試結果,dealloc soon 的就是馬上釋放 later 的就不是了,當下沒釋放,但程式最後完全退出前是有釋放的 光以這部份程式來說,既然'最後有釋放'那也就算了 雖然我不知道它用什麼機制 但在我其他專案中,這可有困擾了 因為我在 view 中產生了一個 thread,用 while loop 維持 於是我真的維持了 n 個多餘的 thread... Orz 幸好我有寫 wait,把 thread 停掉了 但如果我沒寫 wait,經測試,那些 thread 的確都活跳跳的 所以我可能不該依賴系統幫我找的時機... ※ 編輯: HuangJC (60.251.197.63), 11/03/2014 13:17:52 查到原因了 當元件內部再產生的 thread 沒結束時,元件就不會結束 所以根本就是這個 thread 和元件在互等 解決方法是把 while loop 拆掉,還原成一次性的 update 而每次 setDitry 時,都重新開始一個 thread ※ 編輯: HuangJC (60.251.197.63), 11/03/2014 21:17:39
文章代碼(AID): #1KLcacGR (MacDev)
文章代碼(AID): #1KLcacGR (MacDev)