※ 引述《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 好像會自己結束，根本不用我操心
: 這是我難以理解的..
如果照你說的流程，我會選擇在有新的輸入的時候就把舊的Task給Cancel掉，然後重新起
新的Task!
建議你用Operation Queue是因為它本身應該就已經是Multithread了！我永遠都相信，如
果原生就有提供工具來實作，我就會讓它來處理這種東西！自己寫的不見得比較好！就像
我說的Cancel Operation功能在OperationQueue就已經有提供了！