Core Data：被低估的iOS数据持久化老兵

上周五晚上，我正窝在成都太古里的咖啡馆里，一边刷着京东618大促的监控大盘，一边给家里那台老旧的MacBook Pro擦灰。突然收到前同事发来的消息：“哥，你不是搞后端的吗？怎么最近在捣鼓iOS开发？”——其实这事儿还得从上个月说起。

当时产品狗（划掉）产品经理提了个“小需求”：要给内部运维工具加个离线缓存功能，方便工程师在机房没信号时也能查设备信息。我心想，这不就是个简单的本地存储嘛，随手用UserDefaults糊一下就行。结果第二天测试妹子直接甩给我一张截图：“数据超过2MB，App启动卡成PPT”。那一刻，我仿佛又回到了去年双11凌晨三点，面对数据库连接池爆满的绝望。

作为在京东熬过五个大促的老兵，我深知“简单”二字在工程世界里往往藏着深坑。于是咬咬牙，决定认真研究下Apple官方力推的Core Data。毕竟，人家连SwiftUI都给你集成好了，不用白不用。

为什么不是SQLite or Realm？

先别急着喷“都2025年了还用Core Data？”，咱得讲点道理。在评估方案时，我和团队列了个对比表：

方案	学习成本	性能	内存占用	与SwiftUI集成	迁移复杂度
UserDefaults	⭐	⭐⭐	⭐⭐	⭐	⭐
SQLite (原生)	⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐	⭐	⭐⭐⭐
Realm	⭐⭐	⭐⭐⭐⭐	⭐⭐	⭐⭐	⭐⭐⭐⭐
Core Data	⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐

看到最后两项了吗？特别是和SwiftUI的无缝集成，简直香到不行。Apple这几年明显在推声明式UI+响应式数据流这套组合拳，而Core Data的@FetchRequest配合NSManagedObject，写起来比手写SQL舒服多了。

当然，我也试过用Rust写个FFI桥接SQLite，但被领导一句“你是不是想在双11前离职”给劝退了。毕竟在成都这种生活节奏舒服的地方，没必要给自己找罪受。

从爬虫数据说起：我的真实场景

说回那个运维工具，其实它的数据来源是个内部API，但考虑到机房网络环境堪忧，我们做了个折中方案：定期爬取设备数据 → 本地持久化 → 离线可用。

这里有个小插曲：最初我用Python写了个多线程爬虫，结果被安全团队警告“内网扫描行为异常”。后来改成单线程+随机延时，才勉强过关。果然，在大厂做事，合规比技术更重要。

爬下来的数据是JSON格式，结构大概长这样：

{
  "device_id": "JD-SVR-001",
  "status": "online",
  "last_maintenance": "2025-04-01",
  "specs": {
    "cpu": "Intel Xeon Gold 6348",
    "memory": "256GB"
  }
}

问题来了：怎么把这种嵌套结构塞进Core Data？答案是——别硬塞。

Core Data建模：别被Xcode骗了

很多人第一次用Core Data，都会被Xcode的图形化建模界面迷惑，以为拖拖拽拽就能搞定。结果一运行就报错：

CoreData: error: Mutating a managed object after it has been removed from its context

我当时真的想砸电脑。后来翻遍Apple文档才发现，Core Data不是ORM，而是对象图管理器。这意味着：

1. 嵌套对象要拆成独立Entity
2. 关系要用Relationships表示
3. 所有操作必须在Context中进行

于是我把数据模型重构为：

• Device Entity：包含device_id, status等基础字段
• Spec Entity：包含cpu, memory等硬件信息
• 两者建立一对一关系

在.xcdatamodeld文件里配置好后，Xcode自动生成的Swift代码长这样：

// Device+CoreDataClass.swift
@objc(Device)
public class Device: NSManagedObject {
    @NSManaged public var deviceId: String?
    @NSManaged public var status: String?
    @NSManaged public var spec: Spec? // Relationship
}

// Spec+CoreDataClass.swift
@objc(Spec)
public class Spec: NSManagedObject {
    @NSManaged public var cpu: String?
    @NSManaged public var memory: String?
    @NSManaged public var device: Device? // Inverse relationship
}

数据保存：Context的正确打开方式

最开始我犯了个低级错误——直接在主线程操作Context。结果App在导入大量数据时直接卡死，被测试妹子无情嘲笑：“你这体验，比我们双11抢购页面还卡”。

正确的做法是使用后台Context：

func saveDevices(_ devices: [JSON]) {
    // 获取后台Context
    let backgroundContext = persistentContainer.newBackgroundContext()
    
    backgroundContext.perform {
        for json in devices {
            let device = Device(context: backgroundContext)
            device.deviceId = json["device_id"] as? String
            device.status = json["status"] as? String
            
            let spec = Spec(context: backgroundContext)
            spec.cpu = json["specs"]?["cpu"] as? String
            spec.memory = json["specs"]?["memory"] as? String
            
            // 建立关系
            device.spec = spec
            spec.device = device
        }
        
        do {
            try backgroundContext.save()
            DispatchQueue.main.async {
                // 通知UI更新
                NotificationCenter.default.post(name: .dataUpdated, object: nil)
            }
        } catch {
            print("保存失败: \(error)")
        }
    }
}

这里有个坑：不要跨Context传递NSManagedObject！正确的做法是传递NSManagedObjectID，然后在目标Context中用object(with:)获取。

SwiftUI集成：响应式数据流真香

重头戏来了！有了Core Data，配合SwiftUI简直如鱼得水。以前用UITableView时，光是处理数据刷新就要写一堆代理方法，现在一行代码搞定：

struct DeviceListView: View {
    @Environment(\.managedObjectContext) private var viewContext
    @FetchRequest(
        entity: Device.entity(),
        sortDescriptors: [NSSortDescriptor(keyPath: \Device.deviceId, ascending: true)]
    ) private var devices: FetchedResults<Device>
    
    var body: some View {
        List {
            ForEach(devices, id: \.self) { device in
                DeviceRowView(device: device)
            }
        }
        .onReceive(NotificationCenter.default.publisher(for: .dataUpdated)) { _ in
            // 自动刷新列表
        }
    }
}

注意到没？完全不需要手动reloadData！@FetchRequest会自动监听数据变化并刷新UI。这体验，比我们后端写WebSocket推送还爽。

性能优化：从OOM到丝滑

当然，好事多磨。当设备数量突破10万条时，App又开始内存爆炸。查了下Instruments，发现是FetchedResultsController默认加载了所有数据到内存。

解决方案是启用分页加载：

@FetchRequest(
    entity: Device.entity(),
    sortDescriptors: [...],
    predicate: nil,
    animation: .default
) var devices: FetchedResults<Device>

等等，这代码好像没体现分页？其实关键在NSFetchedResultsController的fetchBatchSize属性。但在SwiftUI中，我们需要通过FetchRequest的初始化参数来设置：

init() {
    _devices = FetchRequest(
        entity: Device.entity(),
        sortDescriptors: [...],
        predicate: nil,
        animation: .default,
        fetchRequest: {
            let request: NSFetchRequest<Device> = Device.fetchRequest()
            request.fetchBatchSize = 20 // 关键！
            return request
        }()
    )
}

实测效果：内存占用从300MB+降到50MB以内，滚动列表再也不卡顿。这优化效果，比我当年在京东优化Redis缓存命中率还立竿见影。

App Store审核那些事儿

说到上线，不得不提Apple的审核指南。去年有个同事因为用Core Data存储用户敏感信息被拒，理由是“未使用加密存储”。后来我们学乖了，对敏感字段做了AES加密：

extension Device {
    var encryptedStatus: String? {
        get { 
            guard let encrypted = status else { return nil }
            return try? AES256.decrypt(encrypted) 
        }
        set { 
            status = try? AES256.encrypt(newValue ?? "") 
        }
    }
}

虽然有点麻烦，但总比被拒审强。毕竟在成都，谁不想早点下班去吃火锅呢？

开发心得：老兵的新认知

折腾完这个项目，我对Core Data有了全新认识：

1. 它不是数据库，而是对象图管理系统——理解这点能避免90%的坑
2. Context就是你的事务边界——永远不要跨线程乱用
3. SwiftUI是它的最佳拍档——声明式UI + 响应式数据 = 开发效率翻倍
4. 性能问题往往出在建模阶段——提前规划好Entity关系比后期优化更有效

说到底，技术选型没有银弹。就像我们在京东做架构设计，从来不是“新技术一定好”，而是“合适场景用合适方案”。Core Data可能不够酷，不够新，但在Apple生态里，它依然是那个稳如老狗的选择。

最后分享个小秘密：其实我最近研究Rust，就是想看看能不能用它重写Core Data的底层存储引擎。不过嘛，在成都这种地方，还是先把眼前的需求搞定，周末约朋友喝茶打麻将更实在。

---

附：避坑清单

• ❌ 不要在NSManagedObject子类里加自定义初始化方法
• ✅ 用 awakeFromInsert()代替init()
• ❌ 不要直接修改NSManagedObject属性（除非在Context中）
• ✅ 所有修改操作包裹在context.perform {}里
• ❌ 不要忽略迁移方案（即使只是加个字段）
• ✅ 从第一天就规划好轻量级/重型迁移策略

搞定收工！希望这篇带点烟火气的技术文，能帮你少走些弯路。毕竟，程序员的时间，应该花在更有意思的事情上——比如研究怎么用Rust写iOS应用，或者... 准备今晚的火锅蘸料？