16、Core Data迁移与性能调优全解析

Core Data迁移与性能调优全解析

在应用开发过程中，数据模型的变更不可避免，而如何将旧数据迁移到新的数据模型版本，以及如何确保Core Data的性能，是开发者需要面对的重要问题。本文将详细介绍Core Data迁移的相关知识，包括不同类型的迁移方式、迁移与UI的交互，以及如何对Core Data进行性能调优。

1. Core Data迁移概述

当数据模型发生变化时，需要进行迁移操作，将旧数据转换为与当前数据模型版本兼容的格式。Core Data提供了多种迁移方式，开发者可以根据具体需求选择合适的方法。

2. 迁移类型

2.1 自动迁移与手动迁移

自动迁移相对简单，适合数据模型变更不频繁的情况。Core Data会自动检测现有模型版本，并创建到新模型的推断映射模型。而手动迁移则需要开发者自己控制迁移过程，需要编写更多的代码来维护。

2.2 推断映射模型（轻量级迁移）

如果两个模型版本之间的变化仅限于一些简单的转换，Core Data可以推断出它们之间的映射模型，这种迁移方式也称为轻量级迁移。轻量级迁移可以处理以下几种转换：
- 添加、删除和重命名属性
- 添加、删除和重命名关系
- 添加、删除和重命名实体
- 更改属性的可选状态
- 添加或删除属性上的索引
- 添加、删除或更改实体上的复合索引
- 添加、删除或更改实体上的唯一约束

不过，轻量级迁移也有一些注意事项：
- 如果将属性从可选更改为非可选，必须指定默认值。
- 更改索引（属性索引和复合索引）不会被视为模型更改，需要在更改的属性或实体上指定哈希修饰符，以强制Core Data在迁移时正确处理。
- 重命名属性或实体时，需要使用重命名ID（在数据模型检查器中）为Core Data提供前一个名称的提示。

在自动迁移过程中，开发者无需做额外的操作。但如果使用手动迁移，可以通过 NSMappingModel 的 inferredMappingModel(forSourceModel:destinationModel:) 方法来创建推断映射模型。示例代码如下：

extension Version: ModelVersion {
    func mappingModelsToSuccessor() -> [NSMappingModel]? {
        switch self {
        case .version1:
            let mapping = try! NSMappingModel.inferredMappingModel(
                forSourceModel: managedObjectModel(),
                destinationModel: successor!.managedObjectModel())
            return [mapping]
        // ...
        }
    }
}

2.3 自定义映射模型

当数据模型的变化超出了轻量级迁移的范围时，就需要创建自定义映射模型，详细指定旧数据模型如何映射到新模型。可以使用Xcode的映射模型编辑器来创建自定义映射模型，该编辑器会提示输入源模型和目标模型，并预先填充未更改部分的映射。

以示例项目中的“Moody 4 - Moody 5.xcmappingmodel”映射模型为例，在这次迁移中，移除了 Continent 实体，并在 Country 实体上添加了 isoContinent 属性。可以通过 NSExpression 来指定新属性的值，例如：

$source.continent.numericISO3166Code

对于更复杂的情况，如创建新的关系，可以使用更复杂的表达式。例如，在“Moody 2 - Moody 3.xcmappingmodel”映射模型中，创建了 Continent 和 Mood 实体之间的一对多关系：

FUNCTION($manager,
    "destinationInstancesForEntityMappingNamed:sourceInstances:",
    "ContinentToContinent", $source.country.continent)

2.4 自定义实体映射策略

如果在映射模型编辑器中指定表达式无法满足需求，可以为每个实体映射指定自定义的 NSEntityMigrationPolicy 子类，以完全控制迁移过程。

在示例项目中，创建了 Country5ToCountry6Policy 子类，将带有 numeric isoContinent 属性的 Country 实体拆分为 Country 实体和 Continent 实体，并建立它们之间的新关系。示例代码如下：

final class Country5ToCountry6Policy: NSEntityMigrationPolicy {
    override func createDestinationInstances(
        forSource sInstance: NSManagedObject, in mapping: NSEntityMapping,
        manager: NSMigrationManager) throws
    {
        try super.createDestinationInstances(forSource: sInstance,
            in: mapping, manager: manager)
        guard let continentCode = sInstance.isoContinent else { return }
        guard let country =
            manager.destinationInstances(
                forEntityMappingName: mapping.name,
                sourceInstances: [sInstance]).first
        else { fatalError("must return country") }
        guard let context = country.managedObjectContext
        else { fatalError("must have context") }
        let continent = context.findOrCreateContinent(withISOCode: continentCode)
        country.setContinent(continent)
    }
}

3. 迁移与UI交互

迁移操作可能会消耗大量资源，因此需要在后台队列中执行，并向用户展示合理的UI，最好带有进度报告。通常，迁移任务的优先级应高于其他后台任务，用户发起的服务质量类通常是合适的选择。

如果在应用程序委托中设置Core Data栈并启用自动迁移，迁移将在主队列上运行，可能会导致应用程序长时间卡顿，甚至被操作系统终止。因此，需要异步设置UI，在迁移过程中显示中间迁移UI，直到迁移完成。

可以利用迁移管理器对 NSProgress 的支持，在自定义迁移函数中报告迁移进度。示例代码如下：

public func migrateStore<Version: ModelVersion>(
    from sourceURL: URL, to targetURL: URL, targetVersion: Version,
    deleteSource: Bool = false, progress: Progress? = nil)
{
    // ...
    var migrationProgress: Progress?
    if let p = progress {
        migrationProgress = Progress(
            totalUnitCount: Int64(migrationSteps.count),
            parent: p, pendingUnitCount: p.totalUnitCount)
    }
    for step in migrationSteps {
        migrationProgress?.becomeCurrent(withPendingUnitCount: 1)
        let manager = NSMigrationManager(sourceModel: step.source,
            destinationModel: step.destination)
        migrationProgress?.resignCurrent()
        // ...
    }
    // ...
}

4. 迁移测试

迁移是应用程序中至关重要的代码路径，如果迁移代码存在bug，可能会导致应用程序在更新后无法正常使用。因此，建议为所有可能的迁移路径添加自动化测试。

测试的基本原理是，对于应用程序中可能发生的每个迁移路径，需要一个包含已知源格式数据的SQLite存储，以及一个包含迁移后预期数据的测试夹具，用于与迁移结果进行比较。

可以创建一个遵循 TestEntityData 协议的结构体来保存测试数据，并创建 TestVersionData 结构体来封装某个模型版本的测试夹具数据。示例代码如下：

protocol TestEntityData {
    var entityName: String { get }
    func matches(_ object: NSManagedObject) -> Bool
}

struct TestVersionData {
    let data: [[TestEntityData]]
    func match(with context: NSManagedObjectContext) -> Bool {
        for entityData in data {
            let request = NSFetchRequest<NSManagedObject>(
                entityName: entityData.first!.entityName)
            let objects = try! context.fetch(request)
            guard objects.count == entityData.count else { return false }
            guard objects.all({ o in
                entityData.some { $0.matches(o) }
            }) else { return false }
        }
        return true
    }
}

5. 迁移调试输出

可以通过设置启动参数 -com.apple.CoreData.MigrationDebug 1 来启用Core Data的迁移调试模式，该模式会在迁移过程中输出额外的诊断信息，有助于调试迁移问题。

6. 性能调优

除了迁移，Core Data的性能也是开发者关注的重点。可以通过SQL调试输出了解Core Data在执行获取请求、访问属性或保存数据时的幕后操作。

6.1 SQL调试输出

启用Core Data的SQL调试输出的方法是设置启动参数 -com.apple.CoreData.SQLDebug 1 ，可以在Xcode的方案编辑器中设置该参数。

通过SQL调试输出，可以看到Core Data执行的SQL语句，以及每个请求的执行时间和返回的行数。例如，在显示区域表视图控制器时，获取请求的日志输出如下：

sql: SELECT t0.Z_ENT, t0.Z_PK
FROM ZGEOGRAPHICREGION t0
WHERE t0.ZMARKEDFORDELETIONDATE = ?
ORDER BY t0.ZUPDATEDAT DESC
annotation: sql connection fetch time: 0.0004s
annotation: total fetch execution time: 0.0007s for 5 rows.

可以使用SQLite的命令行工具打开数据库文件，并使用 EXPLAIN QUERY PLAN 命令分析SQLite如何处理SQL语句，从而了解索引的使用情况，优化查询性能。例如：

$ sqlite3 <moody-document-dir>/Moody.moody
sqlite> EXPLAIN QUERY PLAN
SELECT t0.Z_ENT, t0.Z_PK FROM ZGEOGRAPHICREGION t0
WHERE t0.ZMARKEDFORDELETIONDATE = ?
ORDER BY t0.ZUPDATEDAT DESC;

6.2 故障填充

当Core Data从数据库中填充故障时，SQL调试输出也会有所体现。如果在短时间内看到大量“fault fulfilled from database”语句，说明Core Data需要多次往返数据库来获取应用程序所需的数据，这通常是由于获取请求配置不当导致的。

6.3 保存数据

保存数据时，SQL调试输出会显示Core Data执行的SQL语句，例如保存新心情时的输出：

sql: BEGIN EXCLUSIVE
sql: SELECT Z_MAX FROM Z_PRIMARYKEY WHERE Z_ENT = ?
sql: UPDATE Z_PRIMARYKEY SET Z_MAX = ? WHERE Z_ENT = ? AND Z_MAX = ?
sql: COMMIT
sql: BEGIN EXCLUSIVE
sql: INSERT INTO
ZMOOD(Z_PK, Z_ENT, Z_OPT, ZCOUNTRY, ZCOLORS, ZDATE, ZLATITUDE,
ZLONGITUDE, ZMARKEDFORDELETIONDATE,
ZMARKEDFORREMOTEDELETION, ZREMOTEIDENTIFIER)
VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
sql: UPDATE ZGEOGRAPHICREGION SET ZUPDATEDAT = ?, Z_OPT = ?
WHERE Z_PK = ? AND Z_OPT = ?
sql: COMMIT

总结

Core Data提供了丰富的迁移和性能调优功能，开发者可以根据具体需求选择合适的迁移方式，并通过SQL调试输出和性能分析工具来优化Core Data的性能。在进行迁移时，要确保对所有可能的迁移路径进行测试，以保证应用程序的稳定性。同时，要注意迁移与UI的交互，为用户提供良好的体验。

迁移类型总结表格

迁移类型	适用场景	优点	缺点
自动迁移	数据模型变更不频繁	简单易用	无法处理复杂变更
手动迁移	需要精细控制迁移过程	灵活性高	代码维护成本高
轻量级迁移	模型变化为简单转换	无需手动创建映射模型	有一定限制条件
自定义映射模型	复杂的数据模型变更	可实现复杂映射	开发成本高
自定义实体映射策略	对迁移过程有完全控制需求	高度定制	代码复杂

迁移流程mermaid流程图

graph LR
    A[开始] --> B{是否需要迁移?}
    B -- 是 --> C{选择迁移方式}
    C -- 自动迁移 --> D[Core Data自动处理]
    C -- 手动迁移 --> E{轻量级迁移?}
    E -- 是 --> F[创建推断映射模型]
    E -- 否 --> G[创建自定义映射模型]
    G --> H{需要自定义策略?}
    H -- 是 --> I[创建自定义实体映射策略]
    H -- 否 --> J[执行迁移]
    F --> J
    D --> J
    J --> K[迁移完成]
    B -- 否 --> L[无需迁移]
    L --> K

性能调优流程mermaid流程图

graph LR
    A[开始] --> B[启用SQL调试输出]
    B --> C[执行操作]
    C --> D[分析SQL输出]
    D --> E{是否存在性能问题?}
    E -- 是 --> F[使用EXPLAIN QUERY PLAN分析]
    F --> G[优化索引]
    G --> C
    E -- 否 --> H[性能良好]

7. 利用SQL调试输出深入分析Core Data性能

7.1 深入理解SQL调试输出信息

Core Data的SQL调试输出能让开发者清晰了解其在执行各种操作时的幕后行为。当启用 -com.apple.CoreData.SQLDebug 1 启动参数后，输出的信息包含了SQL语句、执行时间和返回行数等关键内容。

例如，在执行获取请求时，输出的SQL语句展示了具体的查询逻辑。如在显示区域表视图控制器时，获取请求的日志输出为：

sql: SELECT t0.Z_ENT, t0.Z_PK
FROM ZGEOGRAPHICREGION t0
WHERE t0.ZMARKEDFORDELETIONDATE = ?
ORDER BY t0.ZUPDATEDAT DESC
annotation: sql connection fetch time: 0.0004s
annotation: total fetch execution time: 0.0007s for 5 rows.

从这个输出中，我们可以看到查询的表是 ZGEOGRAPHICREGION ，查询条件是 ZMARKEDFORDELETIONDATE ，排序依据是 ZUPDATEDAT 。同时，还能得知SQL连接的获取时间和整个请求的执行时间，以及返回的行数。

7.2 结合SQLite命令行工具分析查询

为了更深入地了解SQLite如何处理这些查询，我们可以使用SQLite的命令行工具。通过 EXPLAIN QUERY PLAN 命令，能分析SQLite对SQL语句的处理方式，从而了解索引的使用情况。

例如，对上述获取请求进行分析：

$ sqlite3 <moody-document-dir>/Moody.moody
sqlite> EXPLAIN QUERY PLAN
SELECT t0.Z_ENT, t0.Z_PK FROM ZGEOGRAPHICREGION t0
WHERE t0.ZMARKEDFORDELETIONDATE = ?
ORDER BY t0.ZUPDATEDAT DESC;

执行该命令后，输出如下：

0|0|0|SEARCH TABLE ZGEOGRAPHICREGION AS t0
USING INDEX ZGEOGRAPHICREGION_ZMARKEDFORDELETIONDATE_INDEX
(ZMARKEDFORDELETIONDATE=?)
0|0|0|USE TEMP B-TREE FOR ORDER BY

这表明SQLite使用了 ZMARKEDFORDELETIONDATE 的索引来筛选行，然后为 ORDER BY 子句临时构建了一个B - 树索引。

7.3 索引优化实践

在实际开发中，我们可以通过优化索引来提高查询性能。例如，当我们为 ZUPDATEDAT 添加索引后，发现SQLite仍然没有使用该索引进行排序，这是因为SQLite每个表最多使用一个索引，且已经使用了 ZMARKEDFORDELETIONDATE 的索引来筛选行。

此时，我们可以创建一个复合索引，包含 ZMARKEDFORDELETIONDATE 和 ZUPDATEDAT 。创建复合索引后，再次执行 EXPLAIN QUERY PLAN 命令：

0|0|0|SEARCH TABLE ZGEOGRAPHICREGION AS t0
USING INDEX
ZGEOGRAPHICREGION_ZMARKEDFORDELETIONDATE_ZUPDATEDAT
(ZMARKEDFORDELETIONDATE=?)

可以看到，复合索引被成功使用，且可以移除 ZMARKEDFORDELETIONDATE 的单一索引，因为SQLite可以部分使用复合索引。

同样，在 Mood 实体的查询中，使用复合索引 ZMOOD_ZMARKEDFORREMOTEDELETION_ZMARKEDFORDELETIONDATE_ZDATE 可以同时满足谓词和排序的需求。

sql: SELECT 0, t0.Z_PK FROM ZMOOD t0
WHERE (( t0.ZMARKEDFORDELETIONDATE = ?
AND t0.ZMARKEDFORREMOTEDELETION = ?
) AND t0.ZCOUNTRY = ?)
ORDER BY t0.ZDATE DESC
annotation: sql connection fetch time: 0.0006s
annotation: total fetch execution time: 0.0009s for 44 rows.

执行 EXPLAIN QUERY PLAN 后：

0|0|0|SEARCH TABLE ZMOOD AS t0
USING INDEX
ZMOOD_ZMARKEDFORREMOTEDELETION_ZMARKEDFORDELETIONDATE_ZDATE
(ZMARKEDFORREMOTEDELETION=? AND ZMARKEDFORDELETIONDATE=?)

SQLite会优化谓词的顺序以使用复合索引，这种索引顺序还可以被同步引擎用于查询 markedForRemoteDeletion 属性为 true 的心情。

8. 故障填充与性能影响

8.1 故障填充的表现与原因

Core Data的SQL调试输出还能反映故障填充的情况。当设置 includesPropertyValues 为 false 时，会出现类似如下的输出：

sql: SELECT t0.Z_ENT, t0.Z_PK, t0.Z_OPT, t0.ZMARKEDFORDELETIONDATE,
t0.ZNUMBEROFMOODS, t0.ZNUMERICISO3166CODE,
t0.ZUNIQUENESSDUMMY, t0.ZUPDATEDAT, t0.ZNUMBEROFCOUNTRIES,
t0.ZCONTINENT
FROM ZGEOGRAPHICREGION t0
WHERE t0.Z_PK = ?
annotation: sql connection fetch time: 0.0005s
annotation: total fetch execution time: 0.0008s for 1 rows.
annotation: fault fulfilled from database for : 0xd000000000100002
<x-coredata://DE6497F9-8B94-420D-81B7-E25B992E28C2/Country/p4>

从输出可以看出，Core Data通过查询特定主键的行来填充故障。如果在短时间内看到大量这样的“fault fulfilled from database”语句，说明Core Data需要多次往返数据库来获取数据，这通常是由于获取请求配置不当导致的。

8.2 解决故障填充性能问题的方法

为了解决故障填充带来的性能问题，开发者需要检查获取请求的配置。例如，合理设置 fetchBatchSize 可以减少不必要的数据库查询。同时，确保获取请求包含了应用程序真正需要的属性，避免频繁的故障填充。

9. 保存数据的性能分析

9.1 保存数据时的SQL输出分析

保存数据时，SQL调试输出展示了Core Data执行的一系列SQL语句。以保存新心情为例：

sql: BEGIN EXCLUSIVE
sql: SELECT Z_MAX FROM Z_PRIMARYKEY WHERE Z_ENT = ?
sql: UPDATE Z_PRIMARYKEY SET Z_MAX = ? WHERE Z_ENT = ? AND Z_MAX = ?
sql: COMMIT
sql: BEGIN EXCLUSIVE
sql: INSERT INTO
ZMOOD(Z_PK, Z_ENT, Z_OPT, ZCOUNTRY, ZCOLORS, ZDATE, ZLATITUDE,
ZLONGITUDE, ZMARKEDFORDELETIONDATE,
ZMARKEDFORREMOTEDELETION, ZREMOTEIDENTIFIER)
VALUES(?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?)
sql: UPDATE ZGEOGRAPHICREGION SET ZUPDATEDAT = ?, Z_OPT = ?
WHERE Z_PK = ? AND Z_OPT = ?
sql: COMMIT

从输出可以看出，保存操作涉及到事务的开始和提交，以及插入和更新操作。开发者可以通过分析这些语句，了解保存数据的具体流程和可能存在的性能瓶颈。

9.2 优化保存数据性能的建议

为了优化保存数据的性能，可以考虑批量保存数据，减少事务的频繁开启和提交。同时，合理设计数据模型，避免不必要的关联更新，减少更新操作的数量。

10. 综合优化建议

10.1 迁移与性能优化的综合考量

在进行数据模型迁移和性能优化时，需要综合考虑两者的关系。迁移过程可能会对性能产生影响，因此在选择迁移方式时，要考虑到迁移的复杂性和性能开销。

例如，轻量级迁移虽然简单，但可能无法满足复杂的数据模型变更需求；而自定义映射模型和实体映射策略虽然可以实现复杂的迁移，但开发成本和性能开销相对较高。

10.2 持续监控与优化

Core Data的性能会随着数据量的增加和应用程序的发展而发生变化。因此，开发者需要持续监控Core Data的性能，定期进行性能分析和优化。

可以建立性能监控机制，记录关键操作的执行时间和资源消耗情况。根据监控结果，及时调整数据模型、索引和查询配置，确保Core Data始终保持良好的性能。

总结

Core Data的迁移和性能调优是应用开发中不可忽视的重要环节。通过合理选择迁移方式、利用SQL调试输出深入分析性能瓶颈、优化索引和查询配置等方法，开发者可以确保应用程序在数据模型变更时能够顺利迁移数据，同时保持良好的性能。

在实际开发过程中，要始终关注用户体验，将迁移操作放在后台队列执行，并提供进度报告。同时，为所有可能的迁移路径编写自动化测试，保证迁移代码的稳定性。通过持续的监控和优化，不断提升Core Data的性能，为用户提供更加流畅的应用体验。

性能优化关键点总结表格

优化方面	具体方法	效果
索引优化	创建复合索引、合理排序索引属性	提高查询性能，减少临时索引创建
故障填充优化	合理配置获取请求，设置 fetchBatchSize	减少数据库往返次数
保存数据优化	批量保存数据，减少事务操作	提高保存数据的效率

综合优化流程mermaid流程图

graph LR
    A[开始] --> B[进行迁移规划]
    B --> C{选择迁移方式}
    C -- 自动迁移 --> D[Core Data自动处理迁移]
    C -- 手动迁移 --> E{轻量级迁移?}
    E -- 是 --> F[创建推断映射模型并迁移]
    E -- 否 --> G[创建自定义映射模型和策略并迁移]
    D --> H[启用SQL调试输出]
    F --> H
    G --> H
    H --> I[执行操作并分析性能]
    I --> J{是否存在性能问题?}
    J -- 是 --> K[优化索引和查询配置]
    K --> I
    J -- 否 --> L[性能良好，持续监控]
    L --> M[定期评估和优化]
    M --> I