这个 NSPersistentStoreCoordinator 没有持久存储（设备锁定）。它无法执行保存操作。专门的静态方法

Question

在尝试保存或更新记录时，应用程序在生产中随机崩溃。

这是一个 VOIP 应用程序，获取后台 CallKit 推送，并且在某些情况下，将它们写入 CoreDate DB。我怀疑这就是导致应用程序崩溃的原因，但我在网上找不到任何关于它的参考资料。

尝试在本地重现此问题但没有成功，可能是因为在您第一次解锁手机之前无法使用 Xcode 进行调试。

这是我来自 AppDelegate 的 CoreDate 代码：

    lazy var persistentContainer: NSPersistentContainer = {

        let container = NSPersistentContainer(name: "Model")

        var persistentStoreDescriptions: NSPersistentStoreDescription

        let storeUrl =  FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.appname")!.appendingPathComponent("Model.sqlite")


        let description = NSPersistentStoreDescription()
        description.shouldInferMappingModelAutomatically = true
        description.shouldMigrateStoreAutomatically = true
        description.url = storeUrl

        container.persistentStoreDescriptions = [NSPersistentStoreDescription(url:  FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.com.appname")!.appendingPathComponent("Model.sqlite"))]

        container.loadPersistentStores(completionHandler: { (storeDescription, error) in
            if let error = error as NSError? {
                // Replace this implementation with code to handle the error appropriately.
                // fatalError() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.

                /*
                 Typical reasons for an error here include:
                 * The parent directory does not exist, cannot be created, or disallows writing.
                 * The persistent store is not accessible, due to permissions or data protection when the device is locked.
                 * The device is out of space.
                 * The store could not be migrated to the current model version.
                 Check the error message to determine what the actual problem was.
                 */
                Crashlytics.sharedInstance().recordError(error)
                #if DEBUG
                fatalError("Unresolved error \(error), \(error.userInfo)")
                #endif

            }
        })
        return container
    }()

    // MARK: - Core Data Saving support
    func saveContext () {
        let context = persistentContainer.viewContext
        managedContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
        if context.hasChanges {
            do {
                try context.save()
            } catch {
                // Replace this implementation with code to handle the error appropriately.
                // fatalError() causes the application to generate a crash log and terminate. You should not use this function in a shipping application, although it may be useful during development.
                Crashlytics.sharedInstance().recordError(error)
            }
        }
    }

发生崩溃的函数：

调用.swift：

let callEntity = NSEntityDescription.entity(forEntityName: "Call", in: managedContext)!

  static func upsertCall(call: Call?) {
        if(call == nil){
            return
        }

        //validation here..
        //..

        do {
            managedContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
            try managedContext.save()
        } catch {
            let nserror = error as NSError
            NSLog("Unresolved error \(nserror), \(nserror.userInfo)")
            Crashlytics.sharedInstance().recordError(error)
        }
    }

跑步 - 斯威夫特 5 - Xcode 10.2

Answer 1

这是一个 VOIP 应用程序，获取后台 CallKit 推送，并且在某些情况下，将它们写入 CoreDate DB。我怀疑这就是导致应用程序崩溃的原因，但我在网上找不到任何对它的引用。

尝试在本地重现此问题但没有成功，可能是因为在您第一次解锁手机之前无法使用 Xcode 进行调试。

前段时间我遇到过类似的问题，即当没有对 DB 文件的访问权限时运行应用程序。

我已使用以下设置来调试此问题：

1. 启用（实现）日志记录到文件（例如使用 CocoaLumberjack，但任何日志记录都可以）。 确保文件访问权限设置为NSFileProtectionNone，以便随时可以写入！
2. 尽可能记录有问题的代码以及与应用程序生命周期相关的所有应用程序委托回调。
3. 在设备上安装应用程序。 必须启用密码和锁定！

现在使用上面的设置，有多种情况会触发这个问题：

1. 重启手机，不要输入密码，让它躺下，旧的 iOS 过去常常在几个小时/几天后生成应用程序，只是为了执行后台提取（如果已设置）。
2. 重启手机，不要输入密码，触发远程推送通知或voip通话。

在分析日志后的两种情况下，很明显应用程序在后台被唤醒，但文件保护尚未解除（因为没有输入密码）。

现在，老实说，我不知道上述问题是否还会重现，但您的问题似乎非常相似。

那么 - 解决方案呢？

此问题会影响文件和钥匙串访问。我已经看到许多应用程序没有正确实现（结果：用户被随机注销，因为应用程序无法访问钥匙串来查询身份验证令牌）和经常共享的解决方案是通过指定 kSecAttrAccessibleAlways 来解除对文件/钥匙串的所有访问权限用于钥匙串条目或上面提到的NSFileProtectionNone 用于文件。

我相信虽然这样可行，但从安全角度来看，这通常是个坏主意。

可以做的是推迟应用服务的启动和所有设置，直到可以访问文件。如果应用程序应该在后台写入 DB，请将文件权限设置为至少 NSFileProtectionCompleteUntilFirstUserAuthentication 并仅在可以写入访问权限时打开 DB。检查isProtectedDataAvailable 不是一个很好的解决方案 - 根据我的经验，如果屏幕被锁定并设置了密码，则始终返回 false，并且不考虑个人文件访问权限。

Answer 2

我在崩溃中看到了类似的错误： CoreData：-[NSPersistentStoreCoordinator _coordinator_you_never_successfully_opened_the_database_device_loc ... + 52

我的理解是应用程序正在做某事，但不允许访问核心数据。就我而言，是在将数据从通知中保存到核心数据时。

我将此检查添加到保存到核心数据的方法中：

if !UIApplication.shared.isProtectedDataAvailable {
            return
        }