❌

阅读视图

发现新文章，点击刷新页面。

赛博深渊(上)：用 Apple Foundation Models 提炼“禁忌知识”的求生指南

✇掘金 iOS
大熊猫侯佩

在这里插入图片描述

🍎 引子

新九龙城的雨从未停过。霓虹灯的废气在湿漉漉的街道上晕染开来，像极了那个死于代码过载的倒霉蛋老王流出的脑浆。

在贫民窟第 404 区的一间昏暗安全屋里，一名代号为“老 K”的黑客正对着一块发着幽蓝光芒的屏幕，手指在键盘上敲击出残影。墙角的服务器风扇发出濒死的哀鸣，仿佛随时都会起飞爆炸。

在这里插入图片描述

在这个被巨型企业“果核公司（Fruit Corp）”统治的赛博世界里，数据就是生命，而算力就是货币。

老 K 刚刚从公司的主机里偷出了一份代号为“创世纪”的加密文本，文件大得惊人，如果不赶紧在本地进行 “摘要提炼”，追踪程序（那些被称为“猎犬”的 AI）顺着网线摸过来，把他那可怜的脑机接口烧成灰烬只是时间问题。

在本次冒险中，您将学到如下内容：

  • 🍎 引子
  • 🧠 缩水的“大脑”与本地化的艺术
  • 🛠️ 装备检查：不要试图在烤面包机上运行核程序
  • 🕵️‍♂️ 侦测可用性：敌我识别系统
  • 💉 注入代码：瞒天过海
  • 🎭 模拟测试：在母体中演练
  • 🎆 尾声：黎明前的微光

但他不能上传到云端处理。云端是“它们”的地盘。他必须在本地，用那个刚刚解禁的传说级武器——Apple Foundation Models。

🧠 缩水的“大脑”与本地化的艺术

“听着，菜鸟，”老 K 转过头，仿佛打破了第四面墙，对着作为学徒的你说道，“想要活命，就得学会如何在端侧（On-device）跑大模型。”

Apple Foundation Models 提供了一种能在用户终端设备（不管是你的义体植入终端，还是手里的 iPhone/Mac）上本地运行的大语言模型（LLM）。

在这里插入图片描述

你要知道，传统的 LLM 就像是住在数据中心里的巨型怪兽，吃的是高功率 GPU，喝的是海量的显存和电力。想要把这种怪兽塞进你的口袋里，不仅需要勇气，还需要黑科技。

这里有两个关键的 “瘦身” 魔法：

  1. 参数削减 (Reducing Parameters)：把脑子里那些没用的神经元切掉，只保留核心逻辑。
  2. 模型量化 (Quantizing Model Values)：如果说原来每个神经元需要 32 位浮点数的高精度，现在我们把它压缩到 4 位或 8 位。虽然精度略有下降，但体积小到可以忽略不计。

在这里插入图片描述

⚠️ 风险提示：这些被“阉割”过的模型依然保留了 LLM 的通病——幻觉 (Hallucinations)。它可能会一本正经地胡说八道，就像喝了假酒的算命先生。但在提炼摘要、理解文本、甚至简单的数据生成任务上，它依然是把好手。

好了，废话少说，让我们开始改装你的代码，让它能驾驭这股力量。

🛠️ 装备检查：不要试图在烤面包机上运行核程序

想要驾驭 Apple Intelligence，你的硬件得跟得上。

“别拿你那台老古董来丢人现眼。”老 K 吐了一口烟圈。

硬性指标：

  • 操作系统：必须是 macOS 26.0 或更高版本（对于 iOS 设备，则是 iOS 26/iPadOS 26）。
  • 硬件支持：设备必须原生支持 Apple Intelligence（那种山寨的义体插件不仅没用，还会炸）。
  • 开关状态：用户必须在设置里手动开启了 Apple Intelligence。

在这里插入图片描述

☠️ 避坑指南：如果你在 macOS 26 的虚拟机里折腾，大概率会翻车。Apple Foundation Models 对虚拟化环境过敏。找台真机，或者支持该特性的物理设备。

在这里插入图片描述

🕵️‍♂️ 侦测可用性：敌我识别系统

我们的目标是那个 Share Extension（分享扩展）。我们要让它变成一个能吞噬长文本并吐出精华摘要的黑洞。

在这里插入图片描述

现在的 App 像个傻子，只会把你选中的文字原样复读一遍。我们要改造它。

首先，在 SummarizeExtension 文件夹下创建一个新的 SwiftUI 视图，命名为 ModelCheckView.swift。这就像是我们的看门狗，用来检测当前环境是否安全。

在这里插入图片描述

在该文件顶部引入这一行禁忌的咒语：

import FoundationModels // 引入 Apple 的本地模型库

然后在结构体里加入这些属性：

// 这里的 sharedText 是我们要处理的“赃物”（文本）
let sharedText: String
// 任务完成后的回调，毕竟我们得知道什么时候跑路
let onDone: () -> Void
// 核心：获取系统默认的语言模型实例
let model = SystemLanguageModel.default

接下来，把原本的 body 替换成这一段充满求生欲的代码：

// 1. 检查模型的可用性状态
switch model.availability {

// 2. 状态：可用。谢天谢地，我们可以干活了
case .available:
  // 这里调用真正干活的摘要视图（后面我们会讲）
  SummaryView(sharedText: sharedText, onDone: onDone)

// 3. 各种不可用的“死法”
case .unavailable(.deviceNotEligible):
  Text("⚠️ 你的设备太老了，跑不动 Apple Intelligence。")
  
case .unavailable(.appleIntelligenceNotEnabled):
  Text("🛑 Apple Intelligence 虽已就绪，但你还没打开开关。快去设置！")
  
case .unavailable(.modelNotReady):
  Text("⏳ 模型还没热身完毕，稍后再试。") 
  // 注意：在模拟器里看到这个，通常意味着你的宿主机不支持，或者你在虚拟机里套娃。

// 4. 未知错误，最可怕的一种
case .unavailable:
  Text("👾 未知错误阻止了 Apple Intelligence 的运行。可能是赛博幽灵作祟。")
}

在这里插入图片描述

老 K 的技术旁白：

  • model.availability：这是你的盖革计数器。一定要先 switch 它，不然直接调用模型会导致程序崩溃，就像在没有氧气的地方点火一样。
  • unavailable 的各种姿势：一定要给用户（或者你自己）清晰的反馈。与其让 App 闪退，不如告诉他“你的装备不行”。

在这里插入图片描述

💉 注入代码：瞒天过海

现在，我们要把这个检测机制植入到 ShareViewController.swift 里。这个文件是连接古老的 UIKit 世界和新锐 SwiftUI 世界的桥梁。

找到 showSwiftUIView(with:) 方法，我们要玩一招“偷梁换柱”。

// 用我们新的 ModelCheckView 替换掉原来的直接调用
let wvc = UIHostingController(
  rootView: ModelCheckView(
    sharedText: text,
    onDone: closeExtension // 事情办完就销毁现场
  )
)

这样，当你在 Safari 里选中一段长得令人发指的文本，点击“分享 -> LocalSummarizer”时，系统会先经过我们的 ModelCheckView 查岗。

在这里插入图片描述

🎭 模拟测试：在母体中演练

“别急着上线，现在的网络全是眼线。”老 K 按住你的手，“先在 Xcode 的模拟环境中跑一遍。”

即使你的设备牛逼哄哄，你也得测试一下如果用户没开功能会怎样。

在这里插入图片描述

  1. 在 Xcode 顶部选择 SummarizeExtension 方案。
  2. 点击 Edit Scheme...。
  3. 在 Run -> Options 标签页下，找到 Simulated Foundation Models Availability。

在这里插入图片描述

这就是你的上帝模式开关。你可以把它设为：

  • Apple Intelligence Not Enabled：看看你的 App 会不会乖乖提示用户去开启。
  • Off：这是默认值，反映你真实设备的状态。

在这里插入图片描述

⚠️ 警告：测完记得把它改回 Off。别到时候明明设备支持，却因为这里没改回来而对着屏幕怀疑人生，那种感觉就像是找了半天眼镜结果眼镜架在鼻子上一样蠢。

在这里插入图片描述

为了让主 App (LocalSummarizer) 也能自检，我们顺手改一下 ContentView.swift：

import FoundationModels

// ... 在 body 里 ...
switch SystemLanguageModel.default.availability {
case .available:
  Text("✅ 此设备已准备好接入 Apple Foundation Models。")
// ... 其他 case 照抄上面的 ...
}

在这里插入图片描述

🎆 尾声：黎明前的微光

老 K 敲下最后一个回车键。屏幕闪烁了一下，那段数百万字的冗长文本，瞬间被 Apple Foundation Models 压缩成了寥寥几百字的精华摘要。

没有联网，没有上传，一切都在悄无声息中完成。

在这里插入图片描述

“搞定了。”老 K 拔掉数据线，嘴角露出一丝不易察觉的微笑，“猎犬们还在云端嗅探我们的踪迹，殊不知我们已经带着情报，大摇大摆地从它们眼皮子底下溜走了。”

在这里插入图片描述

窗外的雨似乎小了一些。在这个被数据淹没的时代，掌握本地大模型技术，不仅仅是为了开发几个花哨的功能，更是为了在这个监视无处不在的赛博丛林里，保留最后一份隐私和自由。

在这里插入图片描述

你看着手里显示着 "Summary Generated" 的屏幕，深知这只是开始。下一章，我们将利用这股力量，去触碰更深层的禁忌……

（未完待续...）

2-6.【Concurrency】TaskGroup 的设计目的是什么？它如何保证并发安全？

✇掘金 iOS
项阿丑

一句话先给结论

TaskGroup 的设计目的，是在保持结构化并发的前提下，
安全地表达“一组并发执行、统一收敛结果的子任务”。

或者更狠一点的说法：

TaskGroup = “不会失控的 fork–join 并发”。

1️⃣ 为什么需要 TaskGroup？（设计动机）

先看一个“天真实现”的问题：

var results: [Int] = []

Task {
    Task { results.append(await f1()) }
    Task { results.append(await f2()) }
    Task { results.append(await f3()) }
}

❌ 问题一堆：

  • results 有数据竞争
  • 子任务生命周期不受控
  • 取消无法统一传播
  • 无法确定什么时候全部完成

TaskGroup 想解决的正是这些问题

let sum = await withTaskGroup(of: Int.self) { group in
    group.addTask { await f1() }
    group.addTask { await f2() }
    group.addTask { await f3() }

    var total = 0
    for await value in group {
        total += value
    }
    return total
}

2️⃣ TaskGroup 的核心设计目标

🎯 目标 1：结构化并发（Structured Concurrency）

  • 所有子任务：

    • 必须在 group 作用域内完成
    • 不能逃逸

  • 离开 withTaskGroup：

    • 要么所有完成
    • 要么全部取消

👉 不会“偷偷活着的任务”

🎯 目标 2：安全地共享结果，而不是共享状态

TaskGroup 的哲学是：

并发任务之间不共享可变状态，只通过结果汇合

  • 子任务：

    • 不写共享变量
    • 只 return 值

  • 父任务：

    • 串行地消费结果

🎯 目标 3：明确的并发边界

  • 并发只发生在：

    • group.addTask

  • 收敛点是：

    • for await value in group

这让代码在语义上可推理。

3️⃣ TaskGroup 的工作模型（非常重要）

逻辑结构

Parent Task
 └─ TaskGroup
     ├─ Child Task 1
     ├─ Child Task 2
     └─ Child Task 3

特点：

  • 子任务都是：

    • 当前 task 的子 task
    • 自动继承取消 / 优先级 / actor

生命周期规则（强约束）

行为 结果
父 task 被取消 group 中所有子任务被取消
任一子任务抛错（throwing group） 其余子任务全部取消
离开作用域 等待所有子任务完成

4️⃣ TaskGroup 如何保证并发安全？

这是你问题的核心 👇

✅ 1. 类型系统层面的隔离 

withTaskGroup(of: Int.self) { group in
    group.addTask {
        // 只能返回 Int
    }
}
  • 子任务无法直接访问 group 的内部状态
  • 只能通过 返回值通信

✅ 2. 串行消费结果 

for await value in group {
    // 这里是顺序执行的
}
  • 即使子任务并发完成
  • 结果的处理是单线程、顺序的
  • 所以你可以安全地：
var sum = 0
sum += value

✅ 3. 作用域限制（无法逃逸）

你做不到：

var g: TaskGroup<Int>?
withTaskGroup(of: Int.self) { group in
    g = group // ❌ 不允许
}
  • group 不能被存储
  • 不能被跨作用域使用

👉 这从根源上消灭了悬垂并发。

✅ 4. 自动取消传播

  • 父取消 → 子取消
  • 错误 → 全部取消

这避免了：

  • 子任务写了一半共享状态
  • 父任务已经不关心结果

✅ 5. 与 actor 隔离完美配合 

actor Store {
    func loadAll() async {
        await withTaskGroup(of: Item.self) { group in
            for id in ids {
                group.addTask {
                    await fetchItem(id)
                }
            }
            for await item in group {
                self.items.append(item) // actor 内，安全
            }
        }
    }
}
  • 子任务不直接修改 actor 状态
  • 所有 mutation 都在 actor 上顺序执行

5️⃣ TaskGroup vs async let（顺便对比）

特性 TaskGroup async let
子任务数量 动态 静态
结果处理 流式 一次性
错误处理 可逐个 一起
适合场景 批量 / 不定量 少量固定

6️⃣ 常见误区（非常常见）

❌ 误区 1：TaskGroup 里共享变量是安全的

var sum = 0
withTaskGroup(of: Int.self) { group in
    group.addTask { sum += 1 } // ❌ 数据竞争
}

子任务仍然是并发的。

❌ 误区 2：TaskGroup 会限制并发数量

不会。
如果你要限流，需要：

withTaskGroup { group in
    // 自己控制 addTask 的节奏
}

或使用 semaphore / AsyncSemaphore。

7️⃣ 终极总结（可以直接背）

TaskGroup 的设计目的，是在结构化并发模型下，
安全地表达“多个并发子任务 + 统一收敛”的计算模式。
它通过作用域约束、结果传递而非状态共享、串行消费、自动取消传播，
从语言和类型系统层面避免了数据竞争和失控并发。

❌