※ 引述《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就已经有提供了！