EXC_BAD_ACCESS iOS6 GM UITableTextAccessibilityElement
来源:互联网 发布:java静态变量重新赋值 编辑:程序博客网 时间:2024/03/29 20:23
今天遇到一个一个EXC_BAD_ACCESS错误,使用之前的定位方式定位到这么一句话
EXC_BAD_ACCESS iOS6 GM UITableTextAccessibilityElement
网上搜索了下,找到这么个问题
http://stackoverflow.com/questions/12444233/exc-bad-access-ios6-gm-uitabletextaccessibilityelement
很明显 下面的答案是在装逼或者不负责任的回答 但是回复比较有意思 可能和main thread有关系 提供了一个思路 就是找自己代码中和thread有关的代码 还有就是reload写的位置
因为自己代码中有这么一句话
[selfperformSelectorOnMainThread:@selector(finishReloadingData)withObject:nilwaitUntilDone:YES];
于是根据这个思路 找到了这篇文章http://blog.csdn.net/ouyangtianhan/article/details/7835041
虽然写的太随意了,而且有点装13的嫌疑 但是还是认真看了看,原文摘录如下
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------相信很多人会遇到这种情况,当tableView正在滚动的时候,如果reloadData,偶尔发生App crash的情况。 这种情况有时候有,有时候没有,已经难倒了很多人。直至今天,我在stackoverflow上面,仍没有发现真正有说到其本质的帖子。我的处女贴,选择这个问题来阐述一下我的观点。
小弟我英语很好,一般都是用英语记笔记,当然,我知道,论坛愤青很多,如果只贴英文出来,肯定找骂。 故简单翻译一下,以显示我的诚意。 原英文笔记附在后面。 请大家不要挑英语语法错误了,笔记就是笔记,不是出书。
第一句话,阐述问题的本质:在tableView的dataSource被改变 和 tableView的reloadData被调用之间有个时间差,而正是在这个期间,tableView的delegate方法被调用,如果新的dataSource的count小于原来的dataSource count,crash就很有可能发生了。
下面的笔记提供了两种解决方案,和记录了一个典型的错误,即 在background thread中修改了datasource,虽然调用 [self.tableView performSelectorOnMainThread:@selector(reloadData) withObject:nilwaitUntilDone:NO];
记住正确的原则: Always change the dataSource and(注意这个and) reloadData in the mainThread. What's more, reloadData should be called immediately after the dataSource change.
If dataSource is changed but tableView's reloadData method is not called immediately, the tableView may crash if it's in scrolling.
Crash Reason: There is still a time gap between the dataSource change and reloadData. If the table is scrolling during the time gap, the app may Crash!!!!
WRONG WAY:
Following codes is WRONG: even the reloadData is called in main thread, there is still a time gap between the dataSource change and reloadData. If the table is scrolling during the time gap, the app may Crash!!!!
wrong codes samples:
-(void) changeDatasource_backgroundThread
{
@autoreleasepool{
[self.dataSourceArray removeAllObjects];
[self.tableViewperformSelectorOnMainThread:@selector(reloadData) withObject:nil waitUntilDone:NO];
}
}
RIGHT WAY:
Principle: Always change dataSource in MAIN thread and call the reloadData immediately after it.
Option 1: If the operation to change the dataSource should be executed in background, the operation can create a temp dataSource array and pass it to main thread with notification, the main thread observes the notification, assign the tmpDataSource to dataSource and reload the tableView by reloadData.
Option 2: In the background, call the GDC dispatch_async to send the two methods to main thread together.
dispatch_async(dispatch_get_main_queue(), ^{
self.dataSourceArray= a new Array.
[self.tableView reloadData];
});
根据上文尝试改动代码 发现自己居然是先调用的[reloaddata]方法 然后创建线程更新的数据
把roloadData方法写到了finishReloadingData里面,
在IOS 6.1模拟器上测试 正常了,之前在iPhone5真机测试正常,模拟器上不正常 由于没有4S等其他机型,担心会出现崩溃 影响用户体验 还是硬着头皮花了一上午时间来搞这个问题
以上纯属自己的思路总结,由于基础不怎么好,对IOS的理解也比较肤浅,如果有写的不对的地方 还望网友们积极指出
- EXC_BAD_ACCESS iOS6 GM UITableTextAccessibilityElement
- EXC_BAD_ACCESS
- EXC_BAD_ACCESS
- EXC_BAD_ACCESS
- EXC_BAD_ACCESS
- EXC_BAD_ACCESS
- EXC_BAD_ACCESS
- EXC_BAD_ACCESS
- 绝魂GM
- EXC_BAD_ACCESS 解决办法
- EXC_BAD_ACCESS,XCode4
- EXC_BAD_ACCESS,XCode4
- EXC_BAD_ACCESS原因
- IOS EXC_BAD_ACCESS
- NSMutableArray EXC_BAD_ACCESS
- EXC_BAD_ACCESS iphone
- EXC_BAD_ACCESS 解决办法
- 解决EXC_BAD_ACCESS
- myeclipse 8.5.0 序列号 注册码 可用到2016 插件
- openstack获取用户token(及endpoints)
- TYPO3 的命名空间
- Visual Studio 2010安装后出现“未能初始化‘新建项目’”错误
- Windows Phone 7 优秀开源项目概览
- EXC_BAD_ACCESS iOS6 GM UITableTextAccessibilityElement
- C#将数据集DataSet中的数据导出到EXCEL文件的几种方法
- android ndk空指针导致CRASH的问题
- C# 将Word文档转换为HTML
- iOS UIWebView下拉刷新实现
- JavaScript 拖放效果
- flex验证码生成
- objective-C 中使用@Class和 #import区别
- SSL handshake failed: SSL 错误:在证书中检测到违规的密钥用法