监听reloadData刷新列表完毕的时机

@(IOS零落的记忆)[runloop, GCD死锁, 多线程]

分析:

reloadData是一个异步方法,并不会等待UITableView或者UICollectionView(后面统称listView)真正刷新完毕后才执行后续代码,而是立即执行后续代码。我们执行reloadData的本意是刷新listView,随后会进入一系列的DataSource和Delegate回调,有些是和reloadData同步发生的,有些是异步发生的。

  • 同步:numberOfSectionsInCollectionViewnumberOfItemsInSection
  • 异步:cellForItemAtIndexPath
  • 同步+异步:sizeForItemAtIndexPath

问题:

由于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中的任务,分别在休眠前和被唤醒后。设置listViewlayoutIfNeeded为YES,在即将进入休眠时执行异步任务,重绘一次界面。
dispatch_async(dispatch_get_main_queue(), ^{[self.tableView reloadData];dispatch_async(dispatch_get_main_queue(), ^{ // do sth});
}); 

外层的dispatch_async(dispatch_get_main_queue(), ^{})是为了保证调用reloadData函数的时候其他的工作已经做完了

知识点关联: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,因为没有办法进入主线程。

参考博客:

iOS 事件处理机制与图像渲染过程

为什么都要在主线程中更新UI(iOS开发)

IOS为什么在主线程刷新UI?(子线程刷新UI测试)

更新UI放在主线程的原因

如何安全使用dispatch_sync# 学习计划安排

我一共划分了六个阶段,但并不是说你得学完全部才能上手工作,对于一些初级岗位,学到第三四个阶段就足矣~

这里我整合并且整理成了一份【282G】的网络安全从零基础入门到进阶资料包,需要的小伙伴可以扫描下方CSDN官方合作二维码免费领取哦,无偿分享!!!

如果你对网络安全入门感兴趣,那么你需要的话可以

点击这里👉网络安全重磅福利:入门&进阶全套282G学习资源包免费分享!

①网络安全学习路线
②上百份渗透测试电子书
③安全攻防357页笔记
④50份安全攻防面试指南
⑤安全红队渗透工具包
⑥HW护网行动经验总结
⑦100个漏洞实战案例
⑧安全大厂内部视频资源
⑨历年CTF夺旗赛题解析

  • 23
    点赞
  • 23
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值