作者HuangJC (吹笛牧童)
看板MacDev
标题Re: [问题] UICollectionView 的更新可不可以加快
时间Mon Nov 3 01:25:55 2014
: → 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://webptt.com/cn.aspx?n=bbs/MacDev/M.1414949158.A.41B.html
1F：→ HuangJC: updateThread 是个内部有 while loop 的 thread 11/03 01:36
2F：→ HuangJC: 因此如果不结束它，应该是会浪费系统资源；我用一个变数 11/03 01:37
3F：→ HuangJC: 来管理它的生命周期；然後在 unlock 那行设中断点，想检 11/03 01:37
4F：→ HuangJC: 查 while loop 有没有如我预期的结束；结果都等不到.. 11/03 01:38
5F：→ atst2: mQuitThread 在dealloc中才改变,等不到是正常的. 11/03 02:14
6F：→ HuangJC: 为什麽？因为我 create 的 queue 会自己先结束？ 11/03 04:57
7F：→ HuangJC: 有这一段的说明文件吗？ 11/03 04:57
8F：→ atst2: 去检查一下mQuitThread在那里会改变吧. 11/03 09:35
9F：→ atst2: 从你公开的内容中, mQuitThread只在dealloc 会变动. 11/03 09:35
10F：→ atst2: 如果dealloc一直没被呼叫到, 把中断点设在回圈外有用吗? 11/03 09:36
我写了一小段程式来测这个现象
程式非常小，以避免检查不完的 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