iOS 通知观察者的被调函数不一定运行在主线程

iOS 通知观察者的被调函数不一定运行在主线程

今天修复Bug时候发现的一个小细节，记录下。

问题描述

事情是这样的：我在A视图（UITableView）注册了一个通知，当接收到此通知时，就重新读取数据并调用[tableView reloadData]。但是视图有时刷新后的显示的内容不对，再重新切换下视图又正常了。

代码如下：

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

//A视图在初始化时注册通知 - ( void ) viewDidLoad {      //...      [ [ NSNotificationCenter defaultCenter ] addObserver :self selector : @selector ( reloadFavDBData : ) name : @"refreshMyFavortieData" object :nil ] ; }   //接收通知后的被调函数 - ( void ) reloadFavDBData : ( NSNotification * ) sender {      [ _dataArray release ] ;      _dataArray = [ MusicCollectedDataOperate getSongCollectedInfoWithKeyword :nil ] ;    //重新获取数据      [ tableView reloadData ] ; }   //调用者在一个线程中运行，调用通知告诉A视图刷新数据 [ [ NSNotificationCenter defaultCenter ] postNotificationName : @"refreshMyFavortieData" object :nil ] ;

分析 & 解决

经过一番调试，在被调函数reloadFavDBData打了断点后意外发现，它并不是在主线程运行的！而我们在这里做了与UI相关的[tableView reloadData]操作——在非主线程做UI刷新操作，导致了显示异常的问题。

解决办法也很简单，在被调函数中切换到主线程再做操作就行啦。

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

- ( void ) reloadFavDBData : ( NSNotification * ) sender {      @synchronized ( self ) //保证线程安全      {      //获取新数据，请注意这里和上述代码的区别，由于获取数据操作耗时相对较长， //原实现方式可能导致TableView获取数据时崩溃          NSArray *tmpArray = [ MusicCollectedDataOperate getSongCollectedInfoWithKeyword :nil ] ;          //切换到主线程          dispatch_async ( dispatch_get_main_queue ( ) , ^ {              [ _dataArray release ] ;              _dataArray = [ tmpArray retain ] ;              [ self . refreshTableView . myTableView reloadData ] ;          } ) ;      } }

WHY？

测试得来的结论还是不够完整。翻了翻官方文档，在NSNotificationCenter部分看到这样一段话：

In a multithreaded application, notifications are always delivered in the thread in which the notification was posted, which may not be the same thread in which an observer registered itself.

在多线程程序中，通知总是在发送通知者的线程中调用（delivered，可以这么理解么？），结合上述所遇到的情况，我的理解是，通知观察者的被调函数总是运行在发送通知者的线程中，如下图所示：

这个结论告诉我们，通知的被调函数不一定运行在主线程中，如果需要做UI相关操作，需要手动切换到主线程。

有空再尝试看看通知的实现原理，应该会有更透彻的理解。

原创文章，采用 知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议 进行许可。
转载请注明：转载自 Tony's blog，原文网址：http://itony.me/289.html