Re: [問題] UICollectionView 的更新可不可以加快

[HuangJC (吹笛牧童)]

: → 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
→ HuangJC: updateThread 是個內部有 while loop 的 thread
→ HuangJC: 因此如果不結束它，應該是會浪費系統資源；我用一個變數
→ HuangJC: 來管理它的生命週期；然後在 unlock 那行設中斷點，想檢
→ HuangJC: 查 while loop 有沒有如我預期的結束；結果都等不到..
→ atst2: mQuitThread 在dealloc中才改變,等不到是正常的.
→ HuangJC: 為什麼？因為我 create 的 queue 會自己先結束？
→ HuangJC: 有這一段的說明文件嗎？
→ atst2: 去檢查一下mQuitThread在那裡會改變吧.
→ atst2: 從你公開的內容中, mQuitThread只在dealloc 會變動.
→ atst2: 如果dealloc一直沒被呼叫到, 把中斷點設在迴圈外有用嗎?
我寫了一小段程式來測這個現象
程式非常小，以避免檢查不完的 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