分析:
reloaddata 是一个异步方法,并不会等待 uitableview 或者 uicollectionview (后面统称 listview )真正刷新完毕后才执行后续代码,而是立即执行后续代码。我们执行 reloaddata 的本意是刷新 listview ,随后会进入一系列的datasource和delegate回调,有些是和reloaddata同步发生的,有些是异步发生的。
- 同步: numberofsectionsincollectionview 和 numberofitemsinsection
- 异步: cellforitematindexpath
- 同步+异步: sizeforitematindexpath
问题:
由于cell复用的原因,直接在 reloaddata 后执行代码是有可能出问题的。比如在 reloaddata 前保留了一个cell,在 reloaddata 后,对这个cell(已经不是原来的cell了)进行某些操作,会出现一些异常问题。
解决办法:
在 reloaddata 前不是保留cell,二是保留当前cell对应的 nsindexpath ,然后在 reloaddata 完毕( listview 真正刷新完毕)后通过方法 cellforitematindexpath: 重新获取cell,然后进行相应的操作。
获取listview真正刷新完毕的时机的几种方法
方法1、通过layoutifneeded方法,强制重绘并等待完成。
1
2
3
4
5
6
7
8
9
|
[self.collectionview reloaddata]; [self.collectionview layoutifneeded]; // 刷新完成,执行后续需要执行的代码 if ( self.didplayidx ) { mycell* cell = (mycell*)[self.collectionview cellforitematindexpath:self.didplayidx]; if (cell) { [cell playwithplayer:self.player]; } } |
方法2、 reloaddata 方法会在主线程执行,通过gcd,使后续操作排队在 reloaddata 后面执行。一次runloop有两个机会执行gcd dispatch main queue中的任务,分别在休眠前和被唤醒后。设置 listview 的 layoutifneeded 为yes,在即将进入休眠时执行异步任务,重绘一次界面。
1
2
3
4
5
6
7
8
9
10
|
[self.collectionview reloaddata]; dispatch_async(dispatch_get_main_queue(), ^{ // 刷新完成,执行后续代码 if ( self.didplayidx ) { mycell* cell = (mycell*)[self.collectionview cellforitematindexpath:self.didplayidx]; if (cell) { [cell playwithplayer:self.player]; } } }); |
知识点关联:gcd死锁、runloop
1
2
3
4
5
6
|
// 发生死锁,永远不会执行任务2和3 nslog(@ "1" ); dispatch_sync(dispatch_get_main_queue(), ^{ nslog(@ "2" ); }); nslog(@ "3" ); |
方法3、自定义uicollectionview、uitableview,layoutsubviews之后当作reloaddata完成(复杂,但可以更好的理解方法一)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
#import "mytableview.h" @interface mytableview() @property (nonatomic, copy) void (^reloaddatacompletionblock)(); @end @implementation mytableview - ( void )reloaddatawithcompletion:( void (^)())completionblock { self.reloaddatacompletionblock = completionblock; [super reloaddata]; } - ( void )layoutsubviews { [super layoutsubviews]; if (self.reloaddatacompletionblock) { self.reloaddatacompletionblock(); self.reloaddatacompletionblock = nil; } } @end // 调用的时候 [self.tableview reloaddatawithcompletion:^{ nslog(@ "完成刷新" ); }]; |
引申:更新ui放在主线程的原因
原因一:安全+效率
因为uikit框架不是线程安全的,当多个线程同时操作ui的时候,抢夺资源,导致崩溃,ui异常等问题。假如在两个线程中设置了同一张背景图片,很有可能就会由于背景图片被释放两次,使得程序崩溃。或者某一个线程中遍历找寻某个subview,然而在另一个线程中删除了该subview,那么就会造成错乱。apple有对大部分的绘图方法和诸如uicolor等类改写成线程安全可用,可还是建议将ui操作保证在主线程中。例如说,我们需要在子线程中读取一个image对象,使用接口 [uiimage imagenamed:] ,但 imagenamed: 实际上在 ios9 以后才是线程安全的, ios9 之前都需要在主线程获取。所以,我们需要从子线程切换到主线程获取image,然后再切回子线程拿到这个image,这里我们必须使用sync。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
__block uiimage *image; dispatch_sync_on_main_queue(^{ image = [uiimage imagenamed:@ "resource/img" ]; }); attachment.image = image; // yykit中提供了一个同步扔任务到主线程的安全方法: /** submits a block for execution on a main queue and waits until the block completes. */ static inline void dispatch_sync_on_main_queue( void (^block)()) { if (pthread_main_np()) { block(); } else { dispatch_sync(dispatch_get_main_queue(), block); } } |
原因二:用户体验
ios中只有主线程才能立即刷新ui。在子线程中是不能够更新ui,我们看到的子线程能够更新ui的原因是,等到子线程执行完毕,自动进入了主线程去执行子线程中更新ui的代码。由于子线程执行时间非常短暂,让我们误以为子线程可以更新ui。如果子线程一直在运行,则无法更新ui,因为没有办法进入主线程。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持服务器之家。
原文链接:https://juejin.im/post/5bf572a3e51d45218f3d0591