iOS 27 静默上线的 Media Intelligence:人脸分组不用再自己写了

上手试过在 app 里做人脸相册的 iOS 开发者，应该都对那套胶水代码有印象：Vision 做完检测，自己把 observations 塞进数据库，再写聚类逻辑，还要纠结增量更新的边角问题。iOS 27 偷偷加了一个框架，把这些脏活一次性收走了。SwiftLee 的投递里推荐了一篇 Substack 文章，作者 Anton Gubarenko 在真机上跑通了完整的 Demo，我跟着踩了一遍，把关键决策点整理出来。

Media Intelligence 的定位：集合关系编排器

框架核心就俩分析器：FaceGroupAnalyzer 负责照片里的人脸，VideoAnalyzer 负责视频里的关键帧和高光片段。它们的输入是资产集合，而非单张图片。这一点直接决定了使用分野。

FaceGroupAnalyzer 一个类型干四件事：导入图像资产、检测人脸、持久化检测结果、把检测聚类成"人"。人脸检测本身不难，难的是把结果稳定存下来、跨照片归组——这两步以前全靠自己写。VideoAnalyzer 则专注于从视频里找有代表性的时刻，标记出值得回看的时间区间。

所有这些计算都在设备端完成，网络从始至终没有参与。工作目录一给，分析器在 Application Support 下建好自己的存储，app 重启数据还在。这跟 Vision 只给单次 observation 完全不同——Media Intelligence 是在 observations 之间建立持续的关系。

如果你之前用过 Vision 的 VNDetectFaceRectanglesRequest，会发现它返回的是一堆 VNFaceObservation，没有身份信息，没有持久化，你拿到的就是一堆矩形和特征向量。把这些向量变成“这是张三的脸”这件事，Vision 不管。Media Intelligence 管了，代价是你得把整个流程交给它，中间不能插手。

FaceGroupAnalyzer 实战：一个 Demo 踩出完整链路

我准备的素材是 AI 生成的含人脸测试图——原文作者特意强调这点：用 AI 生成测试人脸，版权和水印问题一次解决。五张图里故意混入同一个人在不同场景下的照片，这样才能触发聚类行为。

启动后的初始界面很干净（原文截图拍于 iPad），demo 的素材直接从 app Bundle 里取：五张 PNG 拷到本地目录后，用稳定的 URL 喂给分析器，省掉 Photos picker 的权限环节。

工作目录：避不开的第一道坎

文档里明确要求给一个可写的持久化目录。原文作者选 Application Support 的理由很直接：这是框架托管的持久数据，不是临时缓存。我第一反应是放 Caches 或临时目录，仔细想才明白为什么不行——临时目录的清理时机不受 app 控制，索引随时会被系统删掉，等于白建。

let workingDirectory = URL.applicationSupportDirectory
    .appending(path: "FaceGroupData", directoryHint: .isDirectory)
try FileManager.default.createDirectory(
    at: workingDirectory,
    withIntermediateDirectories: true
)
let analyzer = try FaceGroupAnalyzer(workingDirectory: workingDirectory)

这个目录一给，分析器就在里面建立自己的数据库结构。同一组资产用同一个目录，下次启动时内部已经有分组状态，不需要重新跑检测。如果你每次传不同目录，或者每次都给同一批资产但不停重建 analyzer，那就等于反复重置存储，永远得不到增量更新。

稳定 ID 的关键性

资产定义里有一个 id 字段，这个 id 不是可选的装饰，它直接决定分析器是把它当成已识别资产去更新，还是当成全新资产重新导入。我用的是照片文件的哈希值作为 id，保证同一张照片在不同启动周期里保持相同 id。

let assets = preparedPhotos.map { photo in
    MediaIntelligenceImageAsset(id: photo.id, kind: .url(photo.url))
}

如果这里随手给个 UUID() 生成的随机 id，每一次调用 insertOrUpdateAssets 对分析器来说都是一批完全陌生的照片，内部 entity 关联全断，之前建好的分组一键归零。这一点在文档里写得隐晦，实测后才发现是整个链路里最关键的一环。

检测与分组是两步

把资产喂进去之后，insertOrUpdateAssets 返回一个 AsyncSequence，逐个吐出每个资产上检测到的人脸。这时候分析器的状态会变成 .stale，意思是人脸数据已经入库，但跨资产的分组关系还没有重新计算。

我必须显式调用 update() 来完成分组这第二步，否则后续查询仍然读到的是上一次分组结果。

let stream = try await analyzer.insertOrUpdateAssets(assets)
for try await (assetID, faces) in stream {
    facesByAssetID[assetID] = faces.map { face in
        DetectedFace(
            id: String(describing: face.id),
            assetID: face.assetID,
            entityID: face.entityID.map(String.init(describing:)),
            bounds: face.bounds
        )
    }
}

if await analyzer.state == .stale {
    try await analyzer.update()
}

检测阶段速度很快，原文作者说五张 demo 图跑完"相当快"（it's working pretty fast）。分组计算也不慢，完成后分析器状态切回 .ready，这时候 FaceGroupAnalyzer 的查询方法才能返回正确的分组列表。

face ID vs entity ID 的区分

每一张人脸会同时带有自己的 face ID，和一个可选的 entity ID。face ID 标记这张脸在特定照片里的检测实例，entity ID 则是跨照片的聚类结果——同一个 entity ID 表示分析器认为这些脸属于同一个人。

如果某张脸在聚类算法里没有被分配到任何实体，entity ID 就是 nil。这意味着它要么是新面孔，要么算法暂时没找到足够相似的邻居。我在 UI 里把这种情况单独标记为“未分组”，避免用户以为分析器漏掉了。

查询结果可以按 entity 汇总，一个 entity 下会有多张照片里的同一个人的多张脸。分组结果列表就是最终输出。

三个真机才会暴露的坑，文档一句没提

模拟器完全不可用

在模拟器上创建 FaceGroupAnalyzer 会直接抛出一个描述性很强的 "Can't create context" 错误。Media Intelligence 的管线依赖硬件，模拟器能渲染周围的 SwiftUI 界面，但跑不了背后的分析流程。原文作者的处理方式是用 #if targetEnvironment(simulator) 包一层 ContentUnavailableView，编译到模拟器时直接显示"需要真机"提示。

目前没有公开的 isNeuralEngineAvailable 之类的布尔值可以提前判断。真机上初始化或处理也可能失败，app 需要把这类错误当成真正的"不可用"状态处理，给用户一个明确的错误界面，而不是转一个永远不结束的 loading。

@concurrent 不保证后台运行

我按照 Apple 官方文档给分析方法的包装打上了 @concurrent 修饰符，Model 用 @MainActor @Observable 保护，想把耗时计算自动调度到后台。

@MainActor
@Observable
final class PeopleDemoModel {
    @concurrent
    private func analyzeAssets(
        _ assets: [MediaIntelligenceImageAsset],
        workingDirectory: URL
    ) async throws -> AnalysisResult { }
}

这里有个命名陷阱：@concurrent 跟 iOS 后台任务没关系。它改的是 executor 行为，跟 app 生命周期是两回事。普通 Task 在 app 被挂起后同样不保证继续执行。如果你的分析要跑几分钟，用户切后台再回来发现进度丢了，问题出在这里。

原文的 demo 把分析结果一次性返回，五张图够用；换成五千张照片，就需要 AsyncStream、actor 或持久化任务记录来分批推进。这个坑在 demo 阶段看不到，量级一上来就暴露。

没有 confidence score，不要假装能判断准确度

当前 beta 的公开 API 没有暴露分组的数值置信度。你能拿到的只有 face.entityID，框架认为这两张脸属于同一个人，但没有告诉你它有多确定。

这意味着 UI 层面要收敛承诺：界面文案写"People"（相似面孔合集）没问题，写成"已验证身份"就过了。产品上把分组当成整理助手来设计，合并、拆分、重命名这些纠错工具要配套跟上——它们属于功能本体，得跟分组一起交付。

VideoAnalyzer：关键帧和高光的打包方案

VideoAnalyzer 的使用模式更轻，它不管理持久化，不参与分组，只是对一个视频资产输出两样东西：关键帧列表和高光片段。

let asset = MediaIntelligenceVideoAsset(url: videoURL)
let keyFrameRequest = KeyFrameAnalysisRequest()
let highlightRequest = HighlightAnalysisRequest()
let (keyFrameResult, highlightResult) = try await VideoAnalyzer.shared.analyze(
    asset, for: keyFrameRequest, highlightRequest
)

注意这里没有 working directory，也没有 insert/update 这类状态操作，一次分析就是一次独立调用。KeyFrameAnalysisRequest 选出一个有代表性的时刻，HighlightAnalysisRequest 返回时间线上值得看的片段区间。app 仍然自己负责播放、缩略图和展示——Media Intelligence 给你的是决策结果，不包办 UI 管线。

它不做视频中的人脸分组。如果你想在视频里找到同一个人出现的所有片段，这条路仍然要回到 Vision + 自己的跨帧关联逻辑。VideoAnalyzer 的价值是替掉那些自己写关键帧采样和时间聚合的私人实现。

决策树：什么时候继续用 Vision，什么时候切到 Media Intelligence

判断标准就一条线：你的功能是在处理单张图的 observation，还是在处理一组资产之间的 relationship。

如果需求是 OCR 文字识别、地标检测、人体姿势分析、图像分割，这些 Vision 已经做得很干净，而且每次调用独立，Media Intelligence 完全帮不上忙。它不提供比 Vision 更细粒度的检测能力，反而把这些细节封装掉了。

如果需要的是：在用户整个图库里找出同一个人出现的所有照片；自动生成某个人的精选集；让 app 记住这些分组，下次启动不需要重新计算，那就轮到 Media Intelligence 上场。它的核心价值是跨请求的记忆和分组决策，单一 detection 交给 Vision 更合适。

另一个判断维度是是否愿意把持久化交给系统。如果你已经有自己打磨了很久的数据库结构、矢量存储、边缘匹配逻辑，并且很依赖自定义的聚类参数，切到 Media Intelligence 反而丢掉了控制力。只有当那些胶水代码真的成了维护负担，才值得用框架替换。

我自己在评估时定了三个条件：需求涉及跨照片的时间线决策、app 没有现成的分类数据库、用户量级不需要极致的微调参数。同时满足这三条，才考虑接入。

产品层面：别因为新框架就硬加功能

拿到框架后的第一反应往往是“我们要在下一个版本加人脸分组功能”。停顿一下。分组功能本身不是用户价值，帮助用户快速找到某个人、生成分享合集、清理重复照片这些才是。如果做完分组，用户看到一群人脸堆在旁边，不知道该点哪里，那就是用新技术给自己找麻烦。

另一个容易忽略的细节：分组不等于身份验证。entityID 是聚类算法的输出，同一个人可能被拆进多个组，相似的两张脸也可能被错误合并到一组。在产品上把它当成照片整理助手就好，千万别拿来做登录或授权依据。

用户必须有删除数据的入口。Media Intelligence 在工作目录里存下了所有人脸特征，这些数据不会跟着 Photo Library 的删除自动消失。如果用户想从 app 里抹掉这些信息，你要能清晰地指出“删除人脸数据”这一操作，并在代码层面区分 deleteAllAssets 和 purge。前者移除资产引用，后者清空所有缓存和特征。产品上应该两者都提供，让用户有完全清除的选择。

并且，分组完成后用户还有属于自己的操作需求：把两个人组合并成一个、把一个组拆成两个、给组命名。这些功能不在框架能力范围内，得自己实现。如果只给用户吐出一堆匿名 entity 列表，却没有任何编辑权力，体验会非常差。投入的成本不是接完 API 就结束了，后续的 UI 工作才是真大头。

一句话收场

Media Intelligence 把 iOS 开发者纠结了好几年的人脸分组问题一次性收走，代价是必须接受它封闭的持久化和有限的检测细节。Vision 还在原地，负责单张图的 observations；真正被替代的，是你自己搭的那套从 detection 到 grouping 的胶水代码。

官方文档入口：Media Intelligence^[1]，人脸分组看 Detecting and grouping faces in images^[2]，视频部分看 Finding the best moments in a video^[3]。

适合接入的场景清单（原文给的七个）：家庭相册、活动照片墙、旅行整理、私人图库、按人筛选照片、新导入照片自动匹配已有分组、视频自动预览。如果你在做一个需要记住“这张脸是谁”的应用，这个框架是 iOS 27 最值得投入时间的新增能力。

最后提醒一句：这个框架还在 beta，API 名字和行为到正式版都可能变。现在接入练手可以，生产代码建议等正式版落地再上。