Question

更新：在我看来，问题仍然存在，所以我在标记我的代码中存在潜在的设计缺陷。我在VC1的viewWillAppear:中调用异步数据填充方法， NEVER 是填充数据和重新加载表视图的好地方，除非在主线程中对所有内容进行序列化。当您必须重新加载表格视图时，代码中始终存在潜在的执行点，并且viewWillAppear 不其中一个。从VC2返回时，我总是在VC1 viewWillAppear中重新加载表视图数据源。但是理想的设计可以使用来自VC2的展开segue并在VC2准备时（prepareForSegue）重新填充数据源，只有在实际需要时才重新填充。不幸的是，到目前为止似乎没有人提到它:(

我认为之前有过类似的问题。不幸的是，他们都没有解决我面临的问题。

我的问题结构非常简单。我有两个视图控制器，比如VC1和VC2。在VC1中，我显示了一个UITableView中的一些项目列表，从数据库加载，在VC2中我显示了所选项目的详细信息，并进行编辑和保存。当用户从VC2返回VC1时，我必须重新填充数据源并重新加载表。 VC1和VC2都嵌入在UINavigationController中。

听起来非常微不足道，确实是这样，直到我在UI线程中做了所有事情。问题是在VC1中加载列表有点费时。因此，我必须将繁重的数据加载任务委托给一些后台工作线程，并在数据加载完成时重新加载主线程上的表，以提供流畅的UI体验。所以我的初始构造类似于以下内容：

-(void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    dispatch_async(self.application.commonWorkerQueue, ^{
        [self populateData]; //populate datasource
        dispatch_async(dispatch_get_main_queue(), ^{
            [self.tableView reloadData]; //reload table view
        });
    });
}

这一功能非常实用，直到iOS10从UITableView停止立即呈现到reloadData并开始将reloadData视为注册请求以重新加载某些UITableView运行循环的后续迭代。所以我发现如果[self.tableView reloadData]在后续调用[self populateData]之前没有完成，我的应用程序偶尔会崩溃，而且非常明显，因为[self populateData]不再是线程安全的，如果数据源在reloadData完成之前发生更改，很可能会导致应用程序崩溃。所以我尝试添加一个信号量来使[self populateData]线程安全，我发现它工作得很好。我后来的构造类似于以下内容：

-(void)viewWillAppear:(BOOL)animated {
    [super viewWillAppear:animated];
    dispatch_async(self.application.commonWorkerQueue, ^{
        [self populateData]; //populate datasource
        dispatch_async(dispatch_get_main_queue(), ^{
            [self.tableView reloadData]; //reload table view
            dispatch_async(dispatch_get_main_queue(), ^{
                dispatch_semaphore_signal(self.datasourceSyncSemaphore); //let the app know that it is free to repopulate datasource again
            });
        });
        dispatch_semaphore_wait(self.datasourceSyncSemaphore, DISPATCH_TIME_FOREVER); //wait on a semaphore so that datasource repopulation is blocked until tableView reloading completes
    });
}

不幸的是，当我在VC1中向下滚动UITableView 时，这个结构也从iOS11 开始破坏，选择一个调出VC2然后返回VC1的项目。它再次调用VC1的viewWillAppear:，然后尝试通过[self populateData]重新填充数据源。但崩溃的堆栈跟踪显示UITableView已经开始从头开始重新创建它的单元格，并且出于某种原因调用tableView:cellForRowAtIndexPath:方法，甚至在viewWillAppear:之前，我的数据源在后台重新填充，它是处于某种不一致的状态。最终应用程序崩溃了。 最令人惊讶的是，只有当我选择了一个不在屏幕上的底行时，才会发生这种情况，最初。以下是崩溃期间的堆栈跟踪：

我知道如果我从主线程中调用两个方法，一切都会正常运行，如：

-(void)viewWillAppear:(BOOL)animated { [super viewWillAppear:animated]; [self populateData]; //populate datasource [self.tableView reloadData]; //reload table view }

但这不是预期的良好用户体验。我觉得问题发生了，因为UITableView在向下滚动时尝试在重新显示时获取屏幕外顶行。但不幸的是，在理解了这么多该死的东西后，我几乎无法解决这个问题。

我真的希望这个网站的专家帮助我摆脱困境或向我展示一些方法。提前感谢负荷！

PS：self.application.commonWorkerQueue是在此上下文中在后台运行的串行调度队列。

Answer 1

您应该拆分populateData功能。让我们举例说明fetchDatabaseRows和populateDataWithRows。 fetchDatabaseRows应该在自己的线程和新的数据结构中将行检索到内存中。完成IO部分后，您应该在UI线程中调用populateDataWithRows（然后是reloadData）。 populateDataWithRows应该修改TableView使用的集合。

Answer 2

UIKit在主线程上运行。所有UI更新必须仅在主线程上。如果数据源的更新仅在主线程上发生，则没有竞争条件。

重要的是要了解您需要保护数据。因此，如果你使用信号量或互斥量或类似这样的结构总是：

为我索取资源。（例如：mutex.lock（））
进行处理
解锁资源（例如：mutex.unlock（））

事实是，因为UI线程用于UI而后台线程用于处理，所以你无法锁定共享数据源，因为你也会锁定UI线程。主线程将等待从后台线程解锁。所以这个结构很大NO-NO。这意味着当UI在主线程上使用自己的副本时，populateData（）函数必须在后台创建数据副本。数据准备就绪后，只需将更新移动到主线程中（不需要信号量或互斥量）

dispatch_async(dispatch_get_main_queue(), ^{
            //update datasource for table view here
            //call reload data
        });

另一件事： viewWillAppear不是进行此更新的地方。因为你有推送你的细节的导航，你可以做滑动以解雇，并在midle只是改变你的想法，并保持细节。但是，将调用vc1 viewWillAppear。 Apple应该将该方法重命名为＆＃34; viewWillAppearMaybe＆＃34; :)。所以正确的做法是创建一个协议，定义将被调用的方法，并使用委托只调用一次更新函数。这不会导致崩溃错误，但为什么不止一次调用更新？另外，为什么你要提取所有项目，如果只有一个已经改变？我只会更新一个项目。

还有一个：您可能正在创建参考周期。在块中使用self时要小心。

如果它看起来像这样，你的第一个例子几乎是好的：

-(void)viewWillAppear:(BOOL)animated {
  [super viewWillAppear:animated];
  dispatch_async(self.application.commonWorkerQueue, ^{
    NSArray* newData = [self populateData]; //this creates new array, don't touch tableView data source here!
    dispatch_async(dispatch_get_main_queue(), ^{
        self.tableItems = newData; //replace old array with new array
        [self.tableView reloadData]; //reload
    });
  });
}

（self.tableItems是NSArray，tableView的简单数据源，作为数据源的一个例子）

Answer 3

更新：在仔细查看您的问题之后，您的问题的根本原因似乎是为您的tableview使用可变的支持数据结构。系统期望在数据更改的同一运行循环迭代中，如果没有显式调用reloadData，数据将永远不会更改。行总是懒洋洋地加载。

正如其他人所说，解决方案是使用具有不可变值的readwrite属性。数据处理完成后，更新属性并在主队列上调用reloadData。

Answer 4

我的假设是因为你在getMain中访问self.tableView时有裁判周期。 Ans在后台的某个地方出现了这个表视图的泄露版本，这些版本开始在iOS 11中崩溃应用程序

您可以使用Xcode中的内存图验证这一点。

要修复此访问权限，您需要像这样访问自我的弱副本

   -(void)viewWillAppear:(BOOL)animated {
        [super viewWillAppear:animated];
        __weak typeof(self) weakSelf = self;
        dispatch_async(self.application.commonWorkerQueue, ^{
            if (!weakSelf) { return; }
            [weakSelf populateData]; //populate datasource
            dispatch_async(dispatch_get_main_queue(), ^{
                [weakSelf.tableView reloadData]; //reload table view
            });
        });
    }

Answer 5

在iOS11中，执行“繁重的数据加载任务”的正确方法是实现UITableViewDataSourcePrefetching协议，如下所述：https://developer.apple.com/documentation/uikit/uitableviewdatasourceprefetching

如果正确实现'tableView：prefetchRowsAtIndexPaths：'，则不必担心后台线程，工作队列，临时数据源或线程同步。 UIKit为您完成所有这些工作。

UITableView reloadData在iOS 11

5 个答案: