CoreData批量导入时UITableView卡顿问题及优化咨询

看起来你现在遇到的核心问题是批量导入10万+数据时，主线程被占满导致UI完全无响应。我先帮你拆解下现有代码里的几个关键问题，再给出针对性的修复方案：

问题根源分析 #

1. 上下文层级不合理：你当前的导入私有上下文(taskContext)把主上下文(context)作为父，这意味着每次taskContext保存后，变更都会直接推送到主线程的主上下文，频繁的变更推送和同步会直接阻塞主线程。
2. 主上下文强制同步：在importOneBatch里，你每次保存taskContext后都调用context.performAndWait来保存主上下文，这相当于把后台的导入操作强行同步到主线程，直接拉满了主线程负载。
3. FRC全量刷新：你的controllerDidChangeContent直接调用tableView.reloadData()，10万条数据的全量刷新会带来巨大的主线程开销，哪怕是小批量的导入变更都会触发全量刷新，让UI彻底卡死。

修复方案 #

1. 调整上下文层级，让导入上下文直接关联根上下文 #

把导入用的taskContext的父设置为根上下文(parentContext)，而不是主上下文。这样导入的变更会先提交到私有队列的根上下文，不会直接影响主线程的主上下文。修改importQuakes里的taskContext创建逻辑：

private func importQuakes(from geoJSON: GeoJSON) throws {
    guard !geoJSON.quakePropertiesArray.isEmpty else { return }
    let taskContext = NSManagedObjectContext(concurrencyType: .privateQueueConcurrencyType)
    // 改为关联根上下文，而非主上下文
    taskContext.parent = parentContext 
    taskContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
    taskContext.undoManager = nil
    // ... 后续批量处理逻辑保持不变
}

2. 取消主上下文手动同步，改用自动合并 #

让主上下文自动监听根上下文的变更，而不是每次批量保存后手动同步。在主上下文的初始化代码中添加自动合并设置：

lazy var context: NSManagedObjectContext = {
    let moc = NSManagedObjectContext(concurrencyType: .mainQueueConcurrencyType)
    moc.parent = parentContext
    // 开启自动合并来自父上下文的变更
    moc.automaticallyMergesChangesFromParent = true
    // 设置和导入上下文一致的合并策略
    moc.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
    return moc
}()

然后删除importOneBatch里这段强制同步主上下文的代码：

context.performAndWait {
    try? context.save()
}

这样主上下文会在合适的时机自动合并根上下文的变更，既不会阻塞后台导入线程，也不会频繁触发主线程的无效操作。

3. 优化FRC的更新逻辑，避免全量刷新 #

把controllerDidChangeContent的全量刷新改成增量更新，利用FRC的代理方法只更新变化的行：

extension QuakesViewController: NSFetchedResultsControllerDelegate {
    func controllerWillChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>) {
        tableView.beginUpdates()
    }
    
    func controller(_ controller: NSFetchedResultsController<NSFetchRequestResult>, didChange anObject: Any, at indexPath: IndexPath?, for type: NSFetchedResultsChangeType, newIndexPath: IndexPath?) {
        switch type {
        case .insert:
            if let newIndexPath = newIndexPath {
                tableView.insertRows(at: [newIndexPath], with: .automatic)
            }
        case .delete:
            if let indexPath = indexPath {
                tableView.deleteRows(at: [indexPath], with: .automatic)
            }
        case .update:
            if let indexPath = indexPath {
                tableView.reloadRows(at: [indexPath], with: .automatic)
            }
        case .move:
            if let indexPath = indexPath, let newIndexPath = newIndexPath {
                tableView.deleteRows(at: [indexPath], with: .automatic)
                tableView.insertRows(at: [newIndexPath], with: .automatic)
            }
        @unknown default:
            break
        }
    }
    
    func controllerDidChangeContent(_ controller: NSFetchedResultsController<NSFetchRequestResult>) {
        tableView.endUpdates()
    }
}

这样每次只有新增的行会被插入，而不是全量刷新整个tableView，能大幅降低主线程的负载。

4. 导入期间临时禁用FRC代理（可选） #

如果导入的是10万+级别的数据，哪怕是增量更新也会有大量的插入通知，可以在导入开始前禁用FRC的代理，导入完成后再重新加载数据：

// 开始导入前，先禁用FRC代理
dataProvider.fetchedResultsController.delegate = nil

// 导入完成后，重新设置代理并刷新数据
dataProvider.fetchQuakes { [weak self] error in
    DispatchQueue.main.async {
        guard let self = self else { return }
        self.dataProvider.fetchedResultsController.delegate = self
        do {
            try self.dataProvider.fetchedResultsController.performFetch()
            self.tableView.reloadData()
        } catch {
            print("重新加载数据失败: \(error)")
        }
    }
}

这种方式适合一次性导入大量数据的场景，避免导入过程中频繁的UI更新干扰用户操作。

5. 其他小优化 #

• 可以适当调大批量大小（比如从256改成1000），减少保存的次数，降低上下文切换的开销。
• 确保quake.update(with: quakeData)里没有任何主线程操作，所有数据处理都在后台上下文的队列里完成。

总结 #

通过调整上下文层级、取消手动同步主上下文、优化FRC的更新逻辑，就能让导入操作完全在后台执行，不会阻塞主线程。这样用户在导入期间可以正常滚动tableView，UI也能保持流畅响应。

内容的提问来源于stack exchange，提问作者Igor Kasuan