分析:
reloadData 是一个异步方法,并不会等待 UITableView 或者 UICollectionView (后面统称 listView )真正刷新完毕后才执行后续代码,而是立即执行后续代码。我们执行 reloadData 的本意是刷新 listView ,随后会进入一系列的DataSource和Delegate回调,有些是和reloadData同步发生的,有些是异步发生的。
问题:
由于cell复用的原因,直接在 reloadData 后执行代码是有可能出问题的。比如在 reloadData 前保留了一个cell,在 reloadData 后,对这个cell(已经不是原来的cell了)进行某些操作,会出现一些异常问题。
解决办法:
在 reloadData 前不是保留cell,二是保留当前cell对应的 NSIndexPath ,然后在 reloadData 完毕( listView 真正刷新完毕)后通过方法 cellForItemAtIndexPath: 重新获取cell,然后进行相应的操作。
获取listView真正刷新完毕的时机的几种方法
方法1、通过layoutIfNeeded方法,强制重绘并等待完成。
[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,在即将进入休眠时执行异步任务,重绘一次界面。
[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
// 发生死锁,永远不会执行任务2和3 NSLog(@"1"); dispatch_sync(dispatch_get_main_queue(), ^{ NSLog(@"2"); }); NSLog(@"3");
方法3、自定义UICollectionView、UITableView,layoutSubviews之后当作reloadData完成(复杂,但可以更好的理解方法一)
#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。
__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,因为没有办法进入主线程。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持小牛知识库。
本文向大家介绍Android AsyncTask 后监听异步加载完毕的动作详解,包括了Android AsyncTask 后监听异步加载完毕的动作详解的使用技巧和注意事项,需要的朋友参考一下 Android 使用AsyncTask 后监听异步加载完毕的动作 AsyncTask 的使用方法网上有很多例子,使用起来也非常的方便。这里就不详细说具体的使用方法了,同学可以Google 一下,很多。 场
本文向大家介绍详解angular中如何监控dom渲染完毕,包括了详解angular中如何监控dom渲染完毕的使用技巧和注意事项,需要的朋友参考一下 刚刚看到群上一个人说,他们公司凡是用angular和jquery插件一起用的人,都被解雇了,没看到这句话之前我很惭愧的说我有这样用过,其实angular的生态系统那么完善,完全可以不用去操作任何的dom元素都可以满足你的提倡开发需求。 那么如果真的需要
本文向大家介绍Oracle监听口令及监听器安全详解,包括了Oracle监听口令及监听器安全详解的使用技巧和注意事项,需要的朋友参考一下 很多Oracle用户都知道,Oracle的监听器一直存在着一个安全隐患,假如对此不设置安全措施,那么能够访问的用户就可以远程关闭监听器。 相关示例如下: 命令执行成功 大家可以发现,此时缺省的监听器的日志还无法记录操作地址: 有鉴于此,为了更好的保证监听器的安全,
本文向大家介绍Javascript添加监听与删除监听用法详解,包括了Javascript添加监听与删除监听用法详解的使用技巧和注意事项,需要的朋友参考一下 本文实例讲述了Javascript添加监听与删除监听的用法。分享给大家供大家参考。具体分析如下: js中事件监听就是利用addEventListener来绑定一个事件,这个用法在jquery中非常常用并且简单,但在原生js中比较复杂,这里整理了
本文向大家介绍Android 滑动监听的实例详解,包括了Android 滑动监听的实例详解的使用技巧和注意事项,需要的朋友参考一下 Android 滑动监听的实例详解 摘要: ScollBy,ScollTo是对内容的移动,view.ScollyBy是对view的内容的移动 view,ScollTo是对内容的移动(移动到指定位置),view.ScollyBy是对view的内容的移动(移动距离) 在
uniapp项目如何监听页面刷新