🍎 概述

大家都知道，我对 Swift 语言中算法这套玩意儿乐此不疲，几乎把 Apple 所有内置框架搞了个翻天覆地——为了图表、统计、集合、并发啥的，时不时还要补上一堆自定义计算。

今天，我们要聊聊隐藏在苹果设备底层的“神器”——Accelerate 框架，堪称锦上添花！

在本篇文章中，您将学到如下内容：

⚡ 1. 什么是 Accelerate？ ➕ 2. 求和：sum 📏 3. 平均值：mean 📉 4. 标准差：standard deviation 🧠 5. 更多魔法：矩阵、FFT、ML ✅ 6. 总结

那还等什么呢？让我们马上开始速度与激情之旅吧！ Let's go！！！;)

---

⚡ 1. 什么是 Accelerate？

早在多年前，Apple 就端出了 Accelerate 框架，现在几乎各个平台都能享用它的妙处。

此乃是专门给 大数据量和高性能准备的神兵利器：利用底层的向量处理能力，帮你 又快又省电，堪称 一箭双雕！

Accelerate 中有一个高效 API 集合叫做 vDSP，专治各种数字信号处理的各种不服，还内置了许多超优化函数。

现在，就让我们从最常用的几个亮点函数说起吧👇

➕ 2. 求和：sum

我们先从最基础的操作“求和”说起。普通 Swift 代码可能这样写：

let values = [6,6,8,7,8,10,10.0]
let sum = values.reduce(0.0, +)

小数据貌似没啥问题，但倘若上来就是“千军万马”时，就会捉襟见肘。我们可以用 vDSP 来轻松搞定它：

import Accelerate
let sum = vDSP.sum(values)

一行搞定，省时省力又省心！

📏 3. 平均值：mean

接下来是“平均值”。

传统写法是：

let mean = values.reduce(0.0, +) / Double(values.count)

而用 vDSP 我们可以这么写：

let mean = vDSP.mean(values)

简洁到令人发指，性能上也是真刀真枪地快！vDSP，你怎么可以这样无理取闹呢？

📉 4. 标准差：standard deviation

接下来轮到标准差登场——也就是判断我们生活是否“离谱”的神器。如果周一到周五宝子们睡 6-7 小时，周末一觉睡到 10 小时，平均 8 看着不错，但其实差距将会天壤之别，根本就是作息放飞自我，有种“月亮不睡我不睡，我是秃头小宝贝”的感觉。

然而，vDSP 标准差的算法会是下面这个样子的：

let sd = vDSP.standardDeviation(values)
if sd > 0.5 {
    print("improve your bedtime routine!")
} else {
    print("you have a good sleep schedule!")
}

不过注意，这个方法在较老系统上不可用。如果你要兼容旧系统，那就“拆东墙补西墙”，亲手搞个简化版来“尝尝鲜”：

extension vDSP {
    static func sd(_ vector: some AccelerateMutableBuffer<Double>) -> Double {
        guard vector.count > 1 else { return 0.0 }
        let mean = vDSP.mean(vector)
        let meanVector = Array(repeating: mean, count: vector.count)
        let differences = vDSP.subtract(vector, meanVector)
        return vDSP.rootMeanSquare(differences)
    }
}

靠着 mean、subtract 和 rootMeanSquare 三大法宝，咱们就能举重若轻地算出标准差，性能也如风驰电掣般流畅！很赞哦！

🧠 5. 更多魔法：矩阵、FFT、ML

当然啦，Accelerate 的江湖地位不止于此，它还内含了很多深藏功与名的模块，比如矩阵乘法、傅里叶变换、甚至机器学习支持等……如果小伙伴们经常处理大量数据，又希望节能高效，那它绝对是如虎添翼的存在。

建议大家逆水行舟，不进则退，有空多看看文档，说不定哪天你就写出了下一个爆款 App。

• Apple Accelerate 框架官方文档

---

我决定用 Accelerate 写一个超越迅雷的下载 App，就叫掩耳下载吧，因为“迅雷不及掩耳”。;)

---

✅ 6. 总结

• ✅ vDSP.sum、vDSP.mean、vDSP.standardDeviation 一行代码搞定复杂计算，堪称效率爆表；
• ✅ 旧平台也能手动组装方法，水到渠成；
• ✅ Accelerate 是 Apple 官方提供的“压箱底”级高性能库，用得好，一鸣惊人指日可待！

希望这篇“Accelerate”能让宝子们醍醐灌顶、茅塞顿开，同时还能笑出声 😆。

如有疑问，记得去找我私信，咱们下回再聊，不见不散！

再会啦！8-)

🌊 Liquid Glass 简介：苹果设计美学的新纪元

苹果在 WWDC25 上大刀阔斧推出了全新设计语言 Liquid Glass（液态玻璃），全面影响旗下所有平台。其核心特点是界面元素的玻璃质感与光影通透效果，实现真正意义上的“虚实结合，界面如水”。

在上一篇博文中，我们聚焦于 Tabs 的玻璃化，这里我们将深入探讨另一关键控件的变革——工具栏（Toolbars） 的玻璃化蜕变。

在本篇博文中，您将学到如下内容：

• 🌊 Liquid Glass 简介：苹果设计美学的新纪元
• 🍸 工具栏新体验：不改代码，也能自动变身
• 📦 基础示例：新旧兼容的优雅演绎
• 🎭 保持兼容旧系统：labelStyle 定制样式
• 🧱 自定义 LabelStyle：向下兼容神器
• ✨ Placement 的魔法：位置决定样式
• 示例：
• 完整示例代码：
• 🧰 Toolbar 分组与 Spacer 控制
• 示例：
• 📌 总结：Liquid Glass 下的 Toolbar 重构指南
• 📮 写在最后

那小伙伴们还等什么呢？让我们马上开始 iOS 26 液态玻璃工具栏大冒险吧！ Let's go！！！;)

---

🍸 工具栏新体验：不改代码，也能自动变身

Liquid Glass 对工具栏的设计带来了如下革新：

• 背景呈现出半透明玻璃质感；
• 支持 多组分布，将按钮逻辑分组显示；
• 自动应用新风格，无需修改旧代码。

不过，为了更上一层楼，我们依然可以使用新 API 进行更为细致的定制。

---

📦 基础示例：新旧兼容的优雅演绎

struct ContentView: View {
    var body: some View {
        NavigationStack {
            List {
                Text("Item 1")
                Text("Item 2")
                Text("Item 3")
            }
            .navigationTitle("Items")
            .toolbar {
                ToolbarItem(placement: .cancellationAction) {
                    Button("Cancel", systemImage: "xmark") {}
                }
                ToolbarItem(placement: .confirmationAction) {
                    Button("Done", systemImage: "checkmark") {}
                }
            }
        }
    }
}

运行结果如下图所示：

🧠 技术解析：
该示例依旧采用经典 .toolbar 修饰器，并结合 ToolbarItem 类型。Liquid Glass 推崇图标优先，因此按钮建议使用图文并茂样式，而不是纯文字。

---

🎭 保持兼容旧系统：labelStyle 定制样式

若宝子们仍需兼容旧版本的系统（例如 iOS 18 及之前），则我们可以保留文字工具栏的样式：

.labelStyle(.toolbar)

完整示例如下所示：

struct ContentView: View {
    var body: some View {
        NavigationStack {
            List {
                Text("Item 1")
                Text("Item 2")
                Text("Item 3")
            }
            .navigationTitle("Items")
            .toolbar {
                ToolbarItem(placement: .cancellationAction) {
                    Button("Cancel", systemImage: "xmark") {}
                        .labelStyle(.toolbar)
                }
                ToolbarItem(placement: .confirmationAction) {
                    Button("Done", systemImage: "checkmark") {}
                        .labelStyle(.toolbar)
                }
            }
        }
    }
}

---

🧱 自定义 LabelStyle：向下兼容神器

上面的 Label 自定义样式 .toolbar 是如何做到的呢？下面我们就为宝子们揭晓答案：

struct ToolbarLabelStyle: LabelStyle {
    func makeBody(configuration: Configuration) -> some View {
        if #available(iOS 26, *) {
            Label(configuration)
        } else {
            Label(configuration)
                .labelStyle(.titleOnly)
        }
    }
}

@available(iOS, introduced: 18, obsoleted: 26, message: "Remove this property in iOS 26")
extension LabelStyle where Self == ToolbarLabelStyle {
    static var toolbar: Self { .init() }
}

📚 技术说明：

• 为不同系统设置条件样式；
• iOS 26 起设置为自动废弃，减少技术欠债；
• labelStyle(.toolbar) 作为语义扩展点，增强代码整洁性。

---

✨ Placement 的魔法：位置决定样式

在 Liquid Glass 影响之下，工具栏中的 ToolbarItemPlacement 实参不仅决定按钮位置，也影响其风格！

.labelStyle(.toolbar)
.tint(.red) // 改变按钮颜色
.badge(3)   // 显示角标

示例：

ToolbarItem(placement: .confirmationAction) {
    Button("Done", systemImage: "checkmark") {}
        .labelStyle(.toolbar)
        .badge(3)
}

完整示例代码：

struct ContentView: View {
    var body: some View {
        NavigationStack {
            List {
                Text("Item 1")
                Text("Item 2")
                Text("Item 3")
            }
            .navigationTitle("Items")
            .toolbar {
                ToolbarItem(placement: .cancellationAction) {
                    Button("Cancel", systemImage: "xmark") {
                        
                    }
                    .labelStyle(.toolbar)
                    .tint(.red)
                }
                
                ToolbarItem(placement: .confirmationAction) {
                    Button("Done", systemImage: "checkmark") {
                        
                    }
                    .labelStyle(.toolbar)
                    .badge(3)
                }
            }
        }
    }
}

在 Xcode 26 中，预览运行结果如下所示：

💡 温馨提示：
虽然 tint 和 badge 炫酷抢眼，但苹果建议少量使用，依旧推荐通过 placement 实现布局分离。因为让液态玻璃自行决定大显身手的场景才是“你好，她也好！”。

---

🧰 Toolbar 分组与 Spacer 控制

在 Liquid Glass 中，库克为我们引入了两个新能力：

• ToolbarItemGroup：将按钮按逻辑进行组内布局；
• ToolbarSpacer：在 toolbar 中灵活插入空隙，支持 .fixed 或 .flexible 宽度。

示例：

struct ToolsToolbar: ToolbarContent {
    var body: some ToolbarContent {
        ToolbarItem(placement: .cancellationAction) {
            Button("Cancel", systemImage: "xmark") {}
        }

        ToolbarItemGroup(placement: .primaryAction) {
            Button("Draw", systemImage: "pencil") {}
            Button("Erase", systemImage: "eraser") {}
        }

        ToolbarSpacer(.flexible)

        ToolbarItem(placement: .confirmationAction) {
            Button("Save", systemImage: "checkmark") {}
        }
    }
}

🛠 工程亮点：

• 更符合实际业务分工：主操作、次操作、取消操作分组；
• Spacer 提供更强自适应布局能力，排兵布阵，自由挥洒。

---

📌 总结：Liquid Glass 下的 Toolbar 重构指南

亮点	解说
自动玻璃化	工具栏无需更改代码，即刻享受 Liquid Glass 风格
图标优先	建议使用 systemImage + 文本
可扩展性	自定义 LabelStyle 支持老版本兼容
可分组	ToolbarItemGroup 组织逻辑结构
自适应布局	ToolbarSpacer 实现弹性间距
样式控制	支持 .badge、.tint 等视觉修饰

---

📮 写在最后

工具栏的“玻璃化”不仅是视觉提升，更是对 UI/UX 一次脱胎换骨的优化。它让工具栏不再是生硬的控制面板，而是一个融入设计，功能与美感并存的现代化模块。

感谢观赏，再会啦！8-)

楔子

江湖风云变幻，Swift 武林近日再掀波澜。

传闻 Apple 于密室推演三月，终得《Swift 6.2 并发新篇》，扬言要破解困扰开发者多年的 "经脉错乱" 之症 —— 那便是异步函数与同步函数运行规则不一、主 Actor 调用常生冲突之陈年旧疾。

想当年，多少英雄好汉折戟于 GCD 到 Swift 并发的转型之路：明明是同门函数，同步者循调用者经脉而行，异步者却偏要另辟蹊径，轻则编译器怒目相向，重则数据走火入魔。

如今 6.2 版本携 "nonisolated (nonsending)" 与 "defaultIsolation" 两大神功而来，声称要让代码运行如行云流水，再无经脉冲突之虞。

在本篇博文，您将学到如下内容：

6. @concurrent：破界而行的旁门秘籍
7. 何时启用 NonisolatedNonsendingByDefault？非必要不增乱
8. defaultIsolation：主 Actor 门派的包级新规矩
9. defaultIsolation 实战：隐式标注，逆势需明
10. 逆势而行：如何脱离主 Actor？
11. 该不该启用 defaultIsolation？利弊权衡，因地制宜

今日列位武林好汉且随老夫执剑开卷，一探这两门新功究竟有何玄妙，又将如何改写 Swift 并发的江湖格局吧。

Let‘s go！！！;)

---

6. @concurrent：破界而行的旁门秘籍

与 “nonisolated (nonsending)” 一同出现的，还有 “@concurrent” 这枚破界令牌。

有了这枚令牌，函数的行为就能和 Swift 6.1 旧制一样 —— 脱离调用者的经脉，建立新的隔离语境（专属经脉）。

请看示例：

@MainActor
class NetworkingClient {
    @concurrent
    nonisolated func loadUserPhotos() async throws -> [Photo] {
        return [Photo()]
    }
}

给函数标注@concurrent，就如同立下誓言：必定脱离调用者的 Actor，创建专属的隔离语境。

这枚令牌有一条铁律：只能用于 “nonisolated” 函数。如果将其用于 Actor 门派的招式，除非该招式明确标注 “nonisolated”，否则就是违规练功：

actor SomeGenerator {
    // 此为禁忌，不可如此
    @concurrent
    func randomID() async throws -> UUID {
        return UUID()
    }

    // 此为正道，可如此行
    @concurrent
    nonisolated func randomID() async throws -> UUID {
        return UUID()
    }
}

需要注意的是，在撰写本文时，这两种写法暂时都能运行，而且未标注 “nonisolated” 的@concurrent函数在运行时似乎没有隔离 —— 但根据《SE-0461 秘籍》的规定，这是 Swift 6.2 工具链的一个临时疏漏，日后定会修正，大家千万不要效仿前者，以免走火入魔。

7. 何时启用 NonisolatedNonsendingByDefault？非必要不增乱

在老夫看来，启用 “NonisolatedNonsendingByDefault” 令牌实乃明智之举。

它带来了一种新的工作方式：nonisolated 异步函数会跟随调用者的 Actor 运行，而非在独立的隔离语境中运行。实际上，这能减少很多编译器错误，而且根据本人的尝试，还能省去不少主 Actor 标注。

老夫一直主张减少应用中的并发量，只在确实需要时才引入 —— 这一令牌恰好能帮助宝子们实现这一点。在决定给应用中的所有内容都标注@concurrent以确保安全之前，请先问问自己是否真的有此必要。

其实，很可能根本没必要，而且从整体来看，并非所有代码都并发运行，这会让代码及其执行过程更容易理解。

当同时采用 Swift 6.2 的第二项主要特性 “defaultIsolation” 时，情况更是如此。

8. defaultIsolation：主 Actor 门派的包级新规矩

Swift 6.2 的另一大绝招 “defaultIsolation”，堪称主 Actor 门派的包级（package）新规。

在 Swift 6.1 中，代码只有在被@MainActor标注（或遵循标有@MainActor的协议）时，才会归入主 Actor—— 就像只有加入主 Actor 门派，才能学习主经脉的功法一样。

给代码标注@MainActor是解决编译器错误的常用方法，而且大多数情况下都是正确的做法。并非所有代码都需要在后台线程异步执行。那样做成本相对较高，往往对性能没有提升，还会让代码难以理解。

在采用 Swift 并发之前，各位秃头少侠们不会到处使用，那样做成本相对较高，往往对性能没有提升，反而还会让代码难以理解。

在采用 Swift 并发之前，小伙伴们不会到处使用DispatchQueue.global()，那现在又何必做类似的事情呢？

言归正传，在 Swift 6.2 中，我们可以在包级别（package）设置默认在主 Actor 上运行代码。这是《SE-0466 秘籍》引入的特性。

这意味着，UI 包、应用目标和模型包等，都能自动在主 Actor 上运行代码，除非通过@concurrent或自定义 Actor 明确选择不在主 Actor 上运行。

要启用这一特性，可在swiftSettings中设置defaultIsolation，或作为编译器参数传入：

swiftSettings: [
    .defaultIsolation(MainActor.self),
    .enableExperimentalFeature("NonisolatedNonsendingByDefault")
]

不必将defaultIsolation与NonisolatedNonsendingByDefault一起使用，但在老夫的实验中，同时使用这两个选项效果很好。

9. defaultIsolation 实战：隐式标注，逆势需明

目前，可以将MainActor.self作为默认隔离传入，使所有代码默认在主 Actor 上运行；也可以传入nil以保持现有行为（或者根本不传入该设置，同样保持现有行为）。

启用这一特性后，Swift 会推断所有对象都带有@MainActor标注，除非明确指定其他情况：

@Observable
class Person {
    var myValue: Int = 0
    let obj = TestClass()

    // 如果 defaultIsolation 设置为主 Actor，此函数始终在主 Actor 上运行
    func runMeSomewhere() async {
        MainActor.assertIsolated()
        // 执行一些操作、调用异步函数等
    }
}

这段代码包含一个 nonisolated 异步函数。这意味着，默认情况下，它会继承调用runMeSomewhere的 Actor。如果从主 Actor 调用，它就在主 Actor 上运行；如果从另一个 Actor 或非 Actor 处调用，它就不在主 Actor 上运行。

这很可能完全不是预期的结果。

或许我们编写异步函数只是为了能调用其他需要等待的函数。如果runMeSomewhere不执行任何繁重的处理，我们可能希望Person在主 Actor 上。它是一个可观察类，很可能用于驱动 UI，这意味着几乎所有对该对象的访问都应该在主 Actor 上进行。

当defaultIsolation设置为MainActor.self时，Person会被隐式标注@MainActor，因此Person的所有工作都在主 Actor 上运行。

10. 逆势而行：如何脱离主 Actor？

假设我们想给Person添加一个不在主 Actor 上运行的函数。可以像往常一样使用 nonisolated：

// 此函数将在调用者的 Actor 上运行
nonisolated func runMeSomewhere() async {
    MainActor.assertIsolated()
    // 执行一些操作、调用异步函数等
}

如果想确保函数绝对不在主 Actor 上运行则可以这样做：

// 此函数将在调用者的 Actor 上运行
@concurrent
nonisolated func runMeSomewhere() async {
    MainActor.assertIsolated()
    // 执行一些操作、调用异步函数等
}

对于每个想要设置为 nonisolated 的函数或属性，都需要明确选择不使用主 Actor 推断；不能为整个类型进行这样的设置。

当然，自定义的 Actor 不会突然开始在主 Actor 上运行，而且标注了其它全局 Actor 的类型也不会受到这一变化的影响。

11. 该不该启用 defaultIsolation？利弊权衡，因地制宜

这个问题很难回答。老夫的初步想法是 “应该启用”。

对于应用目标、UI 包和主要存放视图模型的包，默认在主 Actor 上运行无疑是正确的选择。

不过，列位仍然可以在需要的地方引入并发，而且会比以往更具目的性。

那么本篇的内容就要告一段落了！大家学“废”了吗？

最后，感谢大家的观看，再会啦！8-)

楔子

江湖风云变幻，Swift 武林近日再掀波澜。

传闻 Apple 于密室推演三月，终得《Swift 6.2 并发新篇》，扬言要破解困扰开发者多年的 "经脉错乱" 之症 —— 那便是异步函数与同步函数运行规则不一、主 Actor 调用常生冲突之陈年旧疾。

想当年，多少英雄好汉折戟于 GCD 到 Swift 并发的转型之路：明明是同门函数，同步者循调用者经脉而行，异步者却偏要另辟蹊径，轻则编译器怒目相向，重则数据走火入魔。

如今 6.2 版本携 "nonisolated (nonsending)" 与 "defaultIsolation" 两大神功而来，声称要让代码运行如行云流水，再无经脉冲突之虞。

在本篇博文，您将学到如下内容：

1. 开篇明义：Swift 并发的 “武功瓶颈” 与 6.2 新突破
2. nonisolated (nonsending) 新功揭秘：SE-0461 秘籍的前世今生
3. 旧制之弊：Swift 6.1 前的 “nonisolated” 暗伤
4. 冲突根源：双脉并行的 “数据争夺” 危机
5. nonisolated (nonsending) 新功详解：经脉随行，边界不破

今日列位武林好汉且随老夫执剑开卷，一探这两门新功究竟有何玄妙，又将如何改写 Swift 并发的江湖格局吧。

Let‘s go！！！;)

---

1. 开篇明义：Swift 并发的 “武功瓶颈” 与 6.2 新突破

江湖之中，Swift 并发之道向来以高深难悟著称，其心法与昔日 GCD 的招式路数截然不同。

许多开发者初涉此域，常因概念繁杂而倍感困惑。Apple 早已洞察这一弊端，在《武林愿景》中宣告：Swift 6.2 将对并发体系进行革新 —— 并非撼动根基，而是调整招式默认的发力点（即代码默认的运行位置）。

今日，且随老夫一同探寻两大核心变革：一是 “nonisolated (nonsending) 默认令牌” 这门新功，二是借助 “defaultIsolation” 设置让代码默认归入 “主 Actor 门派” 的新规矩。

通读此文后，各位定能明晰 Swift 6.2 对代码的深远影响，以及在未来 Xcode 正式收录该版本前应如何做好准备。

2. nonisolated (nonsending) 新功揭秘：SE-0461 秘籍的前世今生

“nonisolated (nonsending)” 这门新功，源自《SE-0461 秘籍》，堪称 Swift 并发体系的一次脱胎换骨的变革。在撰写本文时，它仍被封印在 “NonisolatedNonsendingByDefault” 这枚功法令牌之后 —— 若要启用此令牌，使用 SPM 包的开发者可参考《SPM 新功启用要诀》，使用 Xcode 的开发者则需查阅《Xcode 新功解锁指南》。

老夫在此次演练中使用的是 SPM 包，因此在 Package.swift 中设置了这样的门规：

.executableTarget(
    name: "SwiftChanges",
    swiftSettings: [
        .enableExperimentalFeature("NonisolatedNonsendingByDefault")
    ]
)

话不多说，先来解析这门新功的来龙去脉：它究竟是什么路数？能解决什么武学瓶颈？又会如何彻底改变代码的运行方式呢？

3. 旧制之弊：Swift 6.1 前的 “nonisolated” 暗伤

在 Swift 6.1 及更早版本中，“nonisolated” 异步函数存在一处暗伤。请看这样的招式：

class NetworkingClient {
    func loadUserPhotos() async throws -> [Photo] {
        // ...
    }
}

当调用loadUserPhotos时，这一招式绝不会进入任何 “Actor 经脉”（即远离主线程）。因为它既是 “nonisolated”（非隔离）的，又是异步函数，就像一门脱离主经脉的旁支功法，天生与主经脉格格不入。

这种特性往往会引发内力冲突。请看下面的代码：

struct SomeView: View {
    let network = NetworkingClient()

    var body: some View {
        Text("Hello, world")
            .task { await getData() }
    }

    func getData() async {
        do {
            // 传递'self.network'恐生数据冲突
            let photos = try await network.loadUserPhotos()
        } catch {
            // ...
        }
    }
}

编译器见此情景定会厉声呵斥：“将主 Actor 隔离的‘self.network’传入 nonisolated 方法，可能导致‘非隔离’与‘主 Actor 隔离’操作之间产生‘数据 race’（内力冲撞）！” 。

这种错误就如同主经脉的内力流入旁支，极易造成气血紊乱。

4. 冲突根源：双脉并行的 “数据争夺” 危机

上面这段代码的问题在于：loadUserPhotos运行在自身的隔离语境（独立经脉）中，与主 Actor 的运功节奏并行。

由于NetworkingClient实例由主 Actor 创建并掌控，主 Actor 可以在loadUserPhotos运行时对其进行读写操作；而该函数又能访问self，这就意味着两条经脉可能同时操作同一个NetworkingClient实例 —— 如果该实例不具备 “Sendable”（可安全传递）特性，这种双脉并行的情况必然会导致数据 race（内力互冲）。

更让人困扰的是：同样是 “nonisolated”，同步函数和异步函数的运功路数却大相径庭。

同步函数总会跟随调用者的 Actor 运行；而如果从主 Actor 调用 nonisolated 异步函数，该函数不会在主 Actor 上运行；即便从非 Actor 处调用 nonisolated 异步函数，它也不会在主 Actor 上运行。

看以下注解示例便可知晓：

// 此招必随调用者经脉运行
nonisolated func nonIsolatedSync() {}

// 此招属某 Actor（此处为主 Actor）专属，必在其经脉运行
@MainActor func isolatedSync() {}

// 此招绝不入任何 Actor，只在后台经脉运行
nonisolated func nonIsolatedAsync() async {}

// 此招属某 Actor（此处为主 Actor）专属，必在其经脉运行
@MainActor func isolatedAsync() async {}

可见，异步函数和同步函数的行为差异显著，尤其是 nonisolated 异步函数与 nonisolated 同步函数之间，更是界限分明。

Swift 6.2 将以 “nonisolated (nonsending)” 作为新的默认规则，消除这种武学乱象，使异步函数和同步函数的行为保持一致。

5. nonisolated (nonsending) 新功详解：经脉随行，边界不破

Swift 6.1 及更早版本中函数行为的不一致，常常让开发者感到困惑。

因此在 Swift 6.2 中，异步函数将采用 “nonisolated (nonsending)” 作为 nonisolated 函数的新默认规则。开发者无需手动标注，所有 nonisolated 异步函数都会遵循这一规则，除非另有说明。

这门新功的精妙之处在于：标有 “nonisolated (nonsending)” 的函数不会跨越 Actor 边界（不突破经脉壁垒）；通俗地说，就是会跟随调用者的经脉运行。

因此，启用 “NonisolatedNonsendingByDefault” 令牌后，前文出现错误的代码便能正常运行：loadUserPhotos默认属于 “nonisolated (nonsending)”，其运行会在主 Actor 经脉上，而非协同线程池（旁支经脉）。

且看以下几个示例：

class NetworkingClient {
    func loadUserPhotos() async throws -> [Photo] {
        // ...
    }
}

这里的loadUserPhotos既是 nonisolated 又是异步函数，所以默认遵循 “nonisolated (nonsending)” 规则，它会跟随调用者的 Actor（如果有的话）运行。

也就是说：从主 Actor 调用，它就在主 Actor 上运行；从非 Actor 处调用，它就进入旁支经脉运行。

若给NetworkingClient加上@MainActor标注，就如同将其归入主 Actor 门派一般：

@MainActor
class NetworkingClient {
    func loadUserPhotos() async throws -> [Photo] {
        return [Photo()]
    }
}

这样一来，loadUserPhotos就成为主 Actor 的专属招式，无论从何处调用，都会在主 Actor 经脉上运行。

再看主 Actor 门派中，某一招式明确标注 “nonisolated” 的情况：

@MainActor
class NetworkingClient {
    nonisolated func loadUserPhotos() async throws -> [Photo] {
        return [Photo()]
    }
}

此时，即便没有手动标注 “nonisolated (nonsending)”，新的默认规则依然生效：NetworkingClient属于主 Actor 门派，但loadUserPhotos跳出了门派限制，会跟随调用者的经脉运行 —— 从主 Actor 调用，就在主 Actor 上运行；从其他地方调用，就在相应的地方运行。

然而，要是想让某一招式绝对不在主 Actor 经脉上运行，该怎么做呢？前面提到的方法，要么让loadUserPhotos隶属于主 Actor，要么让它跟随调用者的 Actor，它们都无法实现这一需求，在下一篇中，列为秃头少侠们且听我继续讲解。

我们不见不散！别走远，马上回来！8-)

1. 引子：千呼万唤始出来

2025 年 6 月，WWDC25（全球开发者武林大会） 如期而至，武林中风云再起。

此次大会，Apple 为我们带来了 SwiftUI 7 的重磅更新，简直让人期待已久。诸位江湖侠客，今天就随我一起揭开这重磅更新的神秘面纱，看看这些新变化如何改变我们以往的撸码江湖，打破枷锁，轻松御前行走。

在本篇博文中，您将学到如下内容：

1. 引子：千呼万唤始出来
2. 增强 Xcode 模拟器：神兵利器
3. “液态玻璃”设计语言：重塑江湖
4. 标签页的新变革：推陈出新
5. 工具栏：以新面貌登场
6. Button：新“玻璃”按钮样式
7. 玻璃效果：如影随形
8. 新增的 Attributed String 和 WebView 支持：久旱逢甘霖
9. macOS 上的巨大进步：如虎添翼
10. 展望未来：万象更新

闲言少叙，让我们马上开始一探 SwiftUI 7 江湖吧！ Let's go！！！8-)

---

2. 增强 Xcode 模拟器：神兵利器

这一次，Apple 为 Xcode 模拟器增强了一些强力的新功能。想要比较设计、显示尺规、添加网格？没问题！

Xcode 26 还支持最近构建的快速操作，甚至能创建带触摸和音频的录屏，剪辑后直接导出成 MP4 或 GIF，随时通过拖放分享给其他侠客。

甚至截图和视频中都可以添加边框，进一步提升视觉效果。

这等神兵利器，非江湖中人不可得也！

3. “液态玻璃”设计语言：重塑江湖

Apple 引入了一种新的设计语言，名为 液态玻璃（Liquid Glass）。此设计语言如同武侠小说中的独门轻功，轻盈而流畅，可谓：“佛手摘花，杀人于无形”。

由于 SwiftUI 的声明式特性，我们无需对代码做大幅度修改，即可将现有的应用重新设计成符合这种设计理念的全新风貌。

只需要使用 Xcode 26 来构建 App，宝子们的应用就会立刻变得清新透明，闪亮如水晶。害的我此时只想仰天长啸：“一闪一闪亮晶晶，你是我的小星星”

现在，导航栈、标签页、工具栏、检查器等界面元素，无一不如液态玻璃般更加圆润、透明，充满诱惑。

这些变化让人仿佛置身于江湖中的清流，体验犹如滔滔江水连绵不绝。

4. 标签页的新变革：推陈出新

虽然导航栈的 API 并没有改变，但标签页（Tab）导航得到了显著的改进，新增了一些 API 来帮助我们更好地适应这一新设计理念。

如果小伙伴们还在使用老旧的 TabView API，现在正是时候进行一次“换血”，重构大家标签页导航的机会了。

---

关于 SwiftUI 7 新标签页的详细介绍，请宝子们前往如下链接观赏精彩的内容：

• SwiftUI 7（iOS 26 / iPadOS 26）中玻璃化标签页的全新玩法

---

在下文的例子中，我们使用了新的 Tab API，利用 role 将搜索功能移至屏幕底部，脱离其它标签页，形成独立的存在：

private var tabNavigation: some View {
    TabView {
        Tab("feed", systemImage: "ruler") {
            feedTab
        }

        Tab("insights", systemImage: "chart.xyaxis.line") {
            NavigationStack {
                InsightsFeatureView()
                    .navigationTitle("insights")
            }
        }

        Tab("awareness", systemImage: "text.book.closed") {
            NavigationStack {
                AwarenessView()
                    .navigationTitle("awareness")
            }
        }

        Tab("settings", systemImage: "ruler") {
            NavigationStack {
                SettingsView(settings: settings)
                    .navigationTitle("settings")
            }
        }

        Tab("search", systemImage: "magnifyingglass", role: .search) {
            NavigationStack {
                SearchFeatureView(store: searchStore)
            }
        }
    }
}

显示效果如下图所示：

5. 工具栏：以新面貌登场

在 SwiftUI 7 中，工具栏如今也变得如同“玻璃”般轻盈。无论是分组工具栏，还是通过新的 ToolbarSpacer 来实现工具栏的分隔，SwiftUI 都赋予了我们更大的自由度。

以下便是一个展示如何使用这些新 API 来创建分隔式工具栏的例子：

@ToolbarContentBuilder private var toolbar: some ToolbarContent {
    ToolbarItem(placement: .topBarLeading) {
        Button {
            if isPro {
                sheetShown = .gpt
            } else {
                unlockPro()
            }
        } label: {
            Label("gpt", systemImage: "sparkles")
        }
        .popoverTip(FeedTip.gpt)
    }

    ToolbarItemGroup(placement: .topBarTrailing) {
        Button("editor", systemImage: "pencil") {
            sheetShown = .editor
        }
        .keyboardShortcut("n")
    }

    ToolbarSpacer(.fixed, placement: .topBarTrailing)

    ToolbarItemGroup(placement: .topBarTrailing) {
        Button(LocalizedStringKey(HKQuantityType.bloodGlucose.identifier), systemImage: "carrot") {
            sheetShown = .bloodGlucose
        }
        .buttonStyle(.glass)

        Button(LocalizedStringKey(HKQuantityType.bodyMass.identifier), systemImage: "scalemass") {
            sheetShown = .bodyMass
        }
    }
}

想要了解更多 SwiftUI 7 中新工具栏表现的奥义吗？请各位英雄好汉们前往如下龙潭虎穴恣意探索：

• SwiftUI 7（iOS 26）中玻璃化工具栏的艺术

---

6. Button：新“玻璃”按钮样式

不出意外，按钮的样式也发生了新变化。

如今，按钮也能轻松应用新的 GlassButtonStyle，使得界面更加统一、清新，香味扑鼻：

Button {
    // action
} label: {
    Label("add", systemImage: "plus")
}
.buttonStyle(.glass)

7. 玻璃效果：如影随形

若宝子们希望自定义的视图也能拥有这种“玻璃”效果，那么 SwiftUI 7 提供了一个专门的视图修饰符 glassEffect，轻松为任何视图加上透明、圆润的绝伦美妙：

HStack {
   // views
}
.glassEffect()

8. 新增的 Attributed String 和 WebView 支持：久旱逢甘霖

经过漫长的等待，Attributed String 终于在 TextEditor 视图中得到了支持。

另外， WebView 也如愿而至！有了 WebView，我们不仅可以加载网页，还能对其进行观察和自定义用户代理等操作。

import WebKit

struct BrowserView: View {
    @State var page = WebPage()

    var body: some View {
        WebView(page)
            .onAppear {
                page.load(URLRequest(url: URL(staticString: "https://google.com")))
            }
    }
}

9. macOS 上的巨大进步：如虎添翼

SwiftUI 在 macOS Tahoe（她好） 上也有了巨大的进步，正所谓“她好，我也好！”

特别是针对 List 和其它可滚动视图，Apple 提供了巨大的性能提升。

此外，新的 Instruments 模板也让我们在调试和分析 SwiftUI 应用时更加得心应手。

10. 展望未来：万象更新

正如江湖上流传的那句老话：“千里之行，始于足下”，在这片充满挑战的 SwiftUI 武林中，每一位身处其间的侠士都在用手中的剑——或者说是键盘——不断开辟新的疆域。这一年的更新，犹如一位隐世高人走出深山，不露声色间便将江湖局势大为改观。

你我皆是这场江湖风云中的一份子，无论是小试身手，还是披荆斩棘地攻克新技术，都将是一段精彩绝伦的江湖传说。

所以，兄弟姐妹们，拿起你们的代码长剑，迎接更为激烈的挑战吧！未来的 SwiftUI 之路，定会像无数江湖英雄的征途一般，精彩纷呈、不可预测。我们下次江湖再见！

那么，感谢大家的观看，我们再会咯！8-)

🍸 Liquid Glass 登场：界面设计焕然一新

WWDC25 可谓惊喜连连，其中最引人瞩目的变革之一，莫过于苹果推出的全新跨平台设计语言 —— Liquid Glass（液态玻璃）。这一设计风格涵盖了从按钮到导航栏，再到本篇的主角——标签页（Tabs）。

在 Liquid Glass 中，标签页不仅视觉上焕然一新，交互也有了脱胎换骨的变化。本文将带你一探 SwiftUI 中关于新标签页的 API 和用法，助你 快人一步、技高一筹。

在本篇博文中，您将学到如下内容：

• 🍸 Liquid Glass 登场：界面设计焕然一新
• 🧭 Tab 的新写法：表里如一，图文并茂
• 📌 编程式控制 tab：与状态同步，持久不灭
• 🔍 使用 Tab 角色：让搜索独树一帜
• 🧱 跨平台适配：Sidebar 自动切换
• 🧩 Tab 附加视图（Accessory）：不止于导航
• 🌀 滚动时最小化标签栏：内容为王，导航让位
• 📌 总结：Tab 的新纪元

闲言少叙，让我们马上开始液态玻璃 TabView 大冒险吧！ Let's go！！！;)

---

🧭 Tab 的新写法：表里如一，图文并茂

为了能够充分利用全新 TabView 惊鸿艳影般的外观，我们需要使用 Tab 视图来代替之前的 tabItem 修改器方法：

struct ContentView: View {
    var body: some View {
        TabView {
            Tab("feed", systemImage: "list.star") {
                // 内容区域
            }

            Tab("settings", systemImage: "gear") {
                // 内容区域
            }
        }
    }
}

🔍 解析：

• 我们依然使用 TabView，但每个 tab 不再直接放在 TabView 内部；
• 每个子视图包裹在新的 Tab 类型中，图标采用 SF Symbols，图文并茂，美观实用；
• 如此写法符合 Liquid Glass 风格，可享受其视觉特性与交互增强。

---

📌 编程式控制 tab：与状态同步，持久不灭

利用 @SceneStorage 动态属性，我们可以将 selectedTabIndex 放在 App 关联的持久存储中，让每次应用重启都能“刻骨铭心”：

@SceneStorage("selectedTab") private var selectedTabIndex = 0

TabView(selection: $selectedTabIndex) {
    Tab("feed", systemImage: "list.star", value: 0) {
        // Feed 内容
    }

    Tab("settings", systemImage: "gear", value: 1) {
        // 设置页内容
    }
}

🎓 扩展知识：

• @SceneStorage 可在应用关闭后保留状态；
• 与 TabView(selection:) 搭配使用，当用户返回应用时可自动恢复上次选中的标签；
• 每个 Tab 绑定唯一 value 值，避免冲突。

---

🔍 使用 Tab 角色：让搜索独树一帜

为了进一步精雕细琢我们 Tab 的习性，宝子们可以让特别的 Tab 成为特别的角色，正所谓：“特别的爱给特别的你❤️”：

Tab("search", systemImage: "magnifyingglass", value: 1, role: .search) {
    // 搜索内容
}

比如在上面的代码中，我们就特别标记出 search 用途的标签：

📚 说明：

• role 属性用于标记该标签的用途；
• 当前唯一支持的角色是 .search，系统将搜索标签在 UI 中隔离处理（如在 iOS 中会单独显示）；
• 在未来 iOS 版本中，可能加入更多角色，如 .profile、.notifications 等等。

---

🧱 跨平台适配：Sidebar 自动切换

为了能够让 iOS 中的 TabView 匹配 iPadOS / macOS 里的 sidebar 外观，我们可以用 sidebarAdaptable 样式来向系统做出特殊说明：

TabView {
    Tab("feed", systemImage: "list.star", value: 0) { … }
    Tab("settings", systemImage: "gear", value: 2) { … }
}
.tabViewStyle(.sidebarAdaptable)

在 Xcode 26 中的预览结果如下图所示：

💡 解读：

• .sidebarAdaptable 让同一段代码在 iPhone 上呈现为底部标签页；
• 而在 iPad 与 macOS 上则自动转为 Sidebar，一举多得，省心省力；
• 是打造“响应式 UI”的必备良药。

---

🧩 Tab 附加视图（Accessory）：不止于导航

我们还可以为特定 Tab 附加辅助视图（Accessory）：

TabView {...}
    .tabViewBottomAccessory {
        if selectedTabIndex == 1 {
            HStack {
                TextField("输入搜索文本", text: $searchText)
                Button("搜索", systemImage: "sparkle.magnifyingglass", action: {
                    print("搜索中...")
                })
            }
            .padding(.horizontal)
        }
    }

比如，在上面的代码中当用户进入搜索 Tab 时，我们在 TabView 工具栏上方增加一个搜索功能框：

🎼 应用场景：

• Apple Music 使用 accessory view 来显示当前播放状态并提供暂停/跳过按钮；
• 可用于显示网络状态、下载进度、通知中心入口等全局功能；
• 全天可见、随时响应，用户体验 稳如泰山。

---

🌀 滚动时最小化标签栏：内容为王，导航让位

聊了前面那么多，我还是觉得 iOS 26 为 TabView 增加的最有趣且最实用的功能就是让用户在滚动时自动“精简”下方 TabBar 的布局：

.tabBarMinimizeBehavior(.onScrollDown)

完整示例在此：

TabView {
    Tab("feed", systemImage: "list.star", value: 0) { … }
    Tab("settings", systemImage: "gear", value: 2) { … }
}
.tabViewStyle(.sidebarAdaptable)
.tabBarMinimizeBehavior(.onScrollDown)
.tabViewBottomAccessory {
    Button("Do Action") { … }
}

从 Xcode 26 预览的显示中可以看到，当用户向下滚动时 TabBar 会自动收缩，而向上滚动时 TabBar 又会“恢复如常”：

🚀 扩展说明：

• tabBarMinimizeBehavior 可控制标签栏在内容滚动时是否隐藏；
• .onScrollDown 表示向下滚动时自动收起 tab，释放更多空间；
• 非常适用于资讯类、社交类、阅读类的应用。

---

📌 总结：Tab 的新纪元

特性	说明
新 Tab API	使用 Tab("title", systemImage:, value:)
场景存储	@SceneStorage 保存选中状态
Tab Role	当前支持 .search
sidebarAdaptable	iPad/macOS 自动变身为 Sidebar
tabViewBottomAccessory	全局操作附加视图
tabBarMinimizeBehavior	滚动时隐藏标签栏，内容更聚焦

---

🎉 总结

在本篇博文中，我们探索了 Liquid Glass 为 tab 导航带来的焕新体验。新的视觉、行为与结构为 SwiftUI 注入新活力，也为开发者带来更多“独步天下，登峰造极”的内功修为。

👋 感谢观赏！再会啦！8-)

学 Swift 时，很多同学都会下意识写出这样的代码：

let name = "Taylor"
print(name[3])

结果直接报错：「下标访问无效」。为什么数组可以 arr[3]，而字符串就不行？这其实隐藏着一个很有意思、也很「人性化」的设计哲学。今天我们来彻底拆解一下。

---

🌟 数组为什么可以随便下标访问？

在 Swift（以及其他绝大多数语言）中，数组是由 大小相同、连续排列 的元素组成的。比如：

let numbers = [10, 20, 30, 40]
print(numbers[2]) // 30

这个操作非常快，时间复杂度是 O(1)。为什么？

• 数组在内存中是连续的。
• 每个元素大小一样，比如 Int 都是 8 字节。
• 如果知道起始地址，访问第 n 个元素只需要简单计算：起始地址 + n × 元素大小，就能直接跳到目标位置。

这种访问方式被称为 随机访问（Random Access） ，对 CPU 来说非常高效。

---

🌈 那字符串呢？

字符串看起来好像也是「一堆字符」组成，为什么不能 str[3] 呢？

这里面有个巨大的坑：字符串中的「字符」并不都是一样大的！

---

✅ 字符和「扩展字形簇」

在 Swift 中，字符串遵循 Unicode 标准，强调「人类可见的字符」，也就是 扩展字形簇（Grapheme Cluster） 。

举几个例子：

• 🇺🇸（美国国旗 emoji）并不是一个「单一字符」，它是由「区域指示符号字母 U」+「区域指示符号字母 S」组合而成。
• 👨‍👩‍👧‍👦（家庭 emoji）可能由 7 个左右的 Unicode 标量（包括多个 emoji 和零宽连接符）拼在一起。

从人类视角看，它们只是一个符号，但在底层，它们由多个小的「碎片」拼接。

---

🟠 方格纸思维实验

假设你在一张方格纸上写字符串，每个格子只放一个字母，数组的情况就是这样：

| H | e | l | l | o |

这时候找第 4 个字母非常简单：直接数格子，或者直接按「每页 50 个格子」算偏移。

但如果每个字母占的格子数不一样，比如 emoji 需要 4 个格子拼起来组成，你就无法直接跳到第 n 个「人类字符」了，你需要从头开始，逐个数每个完整字符有多少格，直到找到你要的第 n 个。

这就是 Swift 字符串的本质。

---

💥 为什么不让写 myString[3]？

Swift 团队很「严谨」，不想给你提供一个看似简单但暗藏性能陷阱的写法。

如果允许 myString[3]，你会以为它和数组一样是 O(1)，但实际上它需要从开头扫描到第 3 个「可见字符」，时间复杂度是 O(n)。这会导致很多性能 Bug 和错误预期。

---

✅ 正确写法

在 Swift 中，应该使用 String.Index：

let greeting = "👨‍👩‍👧‍👦Hello🇺🇸"
let index = greeting.index(greeting.startIndex, offsetBy: 3)
print(greeting[index])

这里，index(_:offsetBy:) 就是一步一步数「人类可见字符」的工具，明确告诉你这个操作是线性扫描。

---

⚖️ 数组 vs 字符串访问方式对比

	数组	字符串（Swift）
内存布局	元素大小固定	字符大小可变
下标访问	O(1) 随机访问	O(n) 顺序扫描
写法	arr[3]	index + offset

---

💡 关于 .isEmpty 和 .count

小知识点补充一下：

if myString.isEmpty {
    // 推荐写法，只检查有没有第一个字符，性能好
}

if myString.count == 0 {
    // 不推荐写法，会遍历所有字符，性能差
}

.isEmpty 只需要判断是否有第一个字符，而 .count 会统计完整个字符串里的所有字符（包括组合字符），耗时更高。

---

Swift 字符串的设计，不是「不能」，而是「不让你误用」。

⚡ 要支持所有人类可见字符（emoji、组合字符），就必须安全、正确地逐步数；要快速随机访问，就用数组。

---

为什么Swift需要可选型？深入理解Swift的安全机制

什么是可选型

可选类型的意思是这个值可以存在，也可以不存在。这个表达式、函数会返回一个字符串，但是我不敢保证一定会返回字符串，可能因为网络不好，没有任何返回。为了确保安全，不让不安全的类型混入。

var optionalString: String? = "Hello"

这是一个可选的字符串类型，加上一个？，它就可以是字符串，也可以是其他类型，也可以不存在。

传统的nil检查方式

下面是常用的错误处理的方法，在go语言中经常用到：

var optionalString: String? = "Hello"
if optionalString != nil {
    print(optionalString!)  // 输出: Hello
}

得到一个bool类型，如果true，那么就执行。但是，这样写，并没有进行可选解包，后续还是需要强制解包。例如：

let optionalString: String? = "Hello"

if optionalString != nil {
    // optionalString 依然是 String?，需要自己处理
    print(optionalString!.count) // ❌ 如果忘记写 ! 或没有判断好，会崩溃
}

可选绑定 - 更安全的解包方式

这里就提出了另外一种写法：

var optionalString: String? = "Hello"

if let optionalString {
    print("安全的")
}

if let optionalString = optionalString {
    print("还是安全的")
}

if optionalString != nil {
    print("就是安全！")
}

前面两种的书写方式叫做可选绑定。if let optionalString 实际上会把 optionalString 的非空值「解包」成一个新的常量（名字默认和原变量相同），只在 if 的作用域里有效。

可选绑定的工作原理

原理是：枚举两种情况，有值和没有值，然后switch模式匹配，有值时就解包将值赋给if let的常量。

所以等价于：

// if let 语法
if let unwrapped = optionalString {
    print(unwrapped)
}

// 等价于以下模式匹配
switch optionalString {
case .some(let unwrapped):
    print(unwrapped)
case .none:
    break
}

// 或者更直接的等价写法
if optionalString != nil {
    let unwrapped = optionalString!  // 强制解包
    print(unwrapped)
}

你注意到了，其实展开后的可选绑定和上一种写法没有区别，也就是说，if let 就是一个语法糖，它隐藏了底层的枚举匹配过程，让代码更简洁易读。

多重绑定

下面是多重绑定的例子：

let optionalName: String? = "John"
let optionalAge: Int? = 25

if let name = optionalName, let age = optionalAge {
    print("姓名：(name)，年龄：(age)")
}
// 等价于：
// if optionalName != nil && optionalAge != nil {
//     let name = optionalName!
//     let age = optionalAge!
//     print("姓名：(name)，年龄：(age)")
// }

guard关键字

guard关键字也可以用于解包，与if let不同的是，guard let 是先解决错误，处理不满足的情况，再执行满足情况。写法如下：

func greet(_ name: String?) {
    guard let name = name else {
        print("No name provided.")
        return
    }
    // name 在这里已经是非可选的 String
    print("Hello, (name)!")
}

guard 的书写方式有所不同，因为是先处理不满足，所以不满足时候，必须退出，不像if let，满足时都可以不用考虑不满足情况了。

guard someCondition else {
    // 这里必须写 return、break、continue 或 throw
}

guard let 与 if let 的区别

✅ if let 解包后，得到的常量（或者变量）只在 if 语句块内部有效，出了这个块就不能再访问。

✅ guard let 解包后，得到的常量（或者变量）在 guard 语句之后的整个作用域（比如整个函数体）中都可以继续使用。因为 guard 的设计初衷是「先验证条件、提前退出，后面只处理满足条件的逻辑」。

func printLength(of string: String?) {
    guard let string = string else {
        print("String is nil.")
        return
    }
    // string 这里是非可选
    print("Length is (string.count)")
}

可以肯定的是，guard不满足情况下必须退出。所以必须将语句写在局部代码块中，函数或循环体。否则，写在全局中就不能退出执行下面的满足语句了。

多条件检查

下面是多条件的检查：

func check(_ a: Int?, _ b: Int?) {
    guard let a = a, let b = b, a > 0, b > 0 else {
        print("条件不满足")
        return
    }
    print("a: (a), b: (b)")
}

使用场景选择

什么情况下使用guard let，什么情况下使用if let？

✅ 如果我们 更重视先验证条件并提前退出（例如「不满足条件就马上 return」） ，就使用 guard let —— 这是 Swift 推崇的「早退出」写法。

✅ 如果我们 只想要在局部作用域里临时解包一个值，不需要提前退出，也不一定要处理错误情况，就使用 if let —— 它可以选择性地处理「没有值」的情况，甚至可以什么都不写。

✅ if let 可以只写「有值时的逻辑」，不写 else 块，甚至可以完全不处理 nil；

✅ 而 guard let 必须写 else 块，并且必须在 else 中退出当前作用域（比如 return、break、throw 等），否则会编译错误。

✅ if let 可以只处理「有值」的情况

if let value = optional {
    print("有值: (value)")
}
// 没有 else，也不会报错

✅ guard let 必须处理「无值」情况并退出

guard let value = optional else {
    print("没有值，提前退出")
    return
}
print("有值: (value)")

一句话记忆

• guard let 强调「检查条件 → 不满足就走人」
• if let 强调「有值就用，没值就算了」

其他解包方式

解包有几种常见的，强制解包，可选绑定if let和guard let，还有可选链，nil 合并运算符，隐式解包可选。

强制解包

这是强制解包：

let name: String? = "ChatGPT"
print(name!)  // 强制取值，如果是 nil 会崩溃

nil合并运算符

这是有默认值的nil合并，当可选值是 nil 时使用默认值。

let nickname: String? = nil
let displayName = nickname ?? "默认昵称"
print(displayName)  // "默认昵称"

可选链

这是链式，如果任何一层是 nil，整个表达式返回 nil。

struct Person {
    var pet: Pet?
}

struct Pet {
    var name: String
}

let p: Person? = Person(pet: Pet(name: "小狗"))
print(p?.pet?.name)  // Optional("小狗")

隐式解包可选

这是隐式，注意与强制的区别。

var name: String! = "ChatGPT"
print(name)    // 自动当作非可选使用，不需要写 !

隐式，初始化后一定会有值，使用时就像普通变量一样，无需写 ! 或 if let。赋值后不一定马上有值，但是一定会有，百分百。

强制解包 vs 隐式解包

强制解包 是「不管有没有值，我现在就拆」，最暴力；

隐式解包 是「我以后保证会有值，到时候自动拆」，稍微安全，但还是可能崩溃。

收到你的新需求。这个场景非常典型，是滑动窗口协议在真实文件传输中的一个绝佳实践。你描述的报文格式——[ID]-[Offset]-[Data]——以及基于累积偏移量（cumulative offset）的ACK机制，本质上是TCP协议可靠传输思想在应用层的一种实现。

完全可以改造，而且这种改造能将我们之前讨论的理论完美地付诸实践。

需求分析与改造思路

1. 核心转变：从“消息序列号”到“字节偏移量”

   • 我们之前的Demo，窗口是基于“消息个数”的（例如，最多允许5条消息在飞行）。
   • 现在，窗口将基于“字节大小”（例如，最多允许64KB的数据在飞行）。
   • ACK不再是确认某条消息（ACK for seq=5），而是确认“到某个字节位置为止的所有数据都已收妥”（ACK for offset=20480）。这种ACK非常高效，一个ACK可以同时确认多个数据分片。

2. 数据包格式 (Client -> Server)

   • File ID (8 bytes): 文件的唯一标识。
   • Offset (4 bytes): 当前分片在整个文件中的起始字节位置。必须使用网络字节序（Big-Endian） 。
   • Data (10KB): 文件分片数据。
   • 这是一个二进制数据包，我们将使用NSData进行拼接。

3. ACK包格式 (Server <- Client)

   • Acknowledged Offset (4 bytes): 服务器已成功接收并写入文件的总字节数。同样，应为网络字节序。

4. 滑动窗口逻辑适配

   • 窗口状态: 由两个关键偏移量定义：

     • lastAckedOffset: 已被服务器确认的最后一个字节位置。这是窗口的“起点”。
     • currentSentOffset: 已发送的最后一个字节位置。这是窗口的“终点”。

   • 发送条件: 只要 (currentSentOffset - lastAckedOffset) < windowSizeInBytes，并且文件还有未发送的部分，我们就可以继续发送新的分片。

   • 窗口滑动: 当我们收到一个 ackOffset，我们将 lastAckedOffset 更新为 ackOffset。窗口的“起点”向前移动，我们就获得了发送更多数据的空间。

5. 超时与重传 (Go-Back-N策略)

   • 由于ACK是累积的，如果服务器没有收到分片N，它将永远不会ACK超过N点的位置。
   • 我们的策略是：如果一段时间内（超时），lastAckedOffset 没有任何进展，我们就认为从 lastAckedOffset 开始的那个分片丢失了。
   • 重传操作: 我们将从 lastAckedOffset 这个位置重新开始发送数据。这是一种健壮且易于实现的Go-Back-N策略。

---

全新实现: SRChunkedFileUploader.m

我将为你创建一个专门用于此任务的、全新的、高度优化的类。我们将继续使用SRWebSocket。

SRChunkedFileUploader.h (头文件)

#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Wobjc-property-no-attribute"

#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@protocol SRChunkedFileUploaderDelegate <NSObject>
/// 上传进度更新
/// @param progress 进度值 (0.0 - 1.0)
- (void)didUpdateUploadProgress:(float)progress forFile:(NSString *)fileIdentifier;

/// 文件上传成功
- (void)didFinishUploadingFile:(NSString *)fileIdentifier;

/// 上传过程中发生错误
- (void)didFailUploadingFile:(NSString *)fileIdentifier withError:(NSError *)error;
@end


@interface SRChunkedFileUploader : NSObject

@property (nonatomic, weak) id<SRChunkedFileUploaderDelegate> delegate;

// 可配置参数
@property (nonatomic, assign) NSUInteger chunkSize; // 每个分片的大小，默认10KB
@property (nonatomic, assign) NSUInteger windowSizeInBytes; // 滑动窗口的大小（字节），默认64KB
@property (nonatomic, assign) NSTimeInterval timeoutInterval; // 超时重传时间，默认5.0秒

- (instancetype)initWithURL:(NSURL *)url;
- (void)connect;
- (void)disconnect;

/// 核心上传方法
/// @param fileData 要上传的完整文件数据
/// @param fileIdentifier 文件的唯一标识（例如SHA256的前8个字节的十六进制表示）
- (void)uploadFileData:(NSData *)fileData withIdentifier:(NSString *)fileIdentifier;

@end

NS_ASSUME_NONNULL_END
#pragma clang diagnostic pop

SRChunkedFileUploader.m (实现文件)

#import "SRChunkedFileUploader.h"
#import <SocketRocket/SRWebSocket.h>

// 私有接口扩展
@interface SRChunkedFileUploader () <SRWebSocketDelegate>
@property (nonatomic, strong, nullable) SRWebSocket *webSocket;
@property (nonatomic, strong) NSURL *socketURL;
@property (atomic, assign) BOOL isConnected;

// 上传任务状态
@property (nonatomic, strong) NSData *fileData; // 完整文件数据
@property (nonatomic, strong) NSData *fileIdentifierData; // 8字节的文件ID
@property (nonatomic, copy) NSString *fileIdentifierString; // 文件ID字符串表示
@property (nonatomic, assign) uint32_t totalFileSize; // 文件总大小
@property (nonatomic, assign) uint32_t lastAckedOffset; // 已确认的偏移量
@property (nonatomic, assign) uint32_t currentSentOffset; // 已发送的偏移量

// 线程安全与定时器
@property (nonatomic, strong) NSLock *stateLock; // 状态锁
@property (nonatomic, strong) NSTimer *stallTimer; // "停滞"检测定时器 (替代之前的重传定时器)

@end

@implementation SRChunkedFileUploader

#pragma mark - 生命周期

- (instancetype)initWithURL:(NSURL *)url {
    self = [super init];
    if (self) {
        _socketURL = url;
        _stateLock = [[NSLock alloc] init];
        
        // 设置默认值
        _chunkSize = 10 * 1024; // 10KB
        _windowSizeInBytes = 64 * 1024; // 64KB
        _timeoutInterval = 5.0;
    }
    return self;
}

- (void)dealloc {
    [self cleanupTransmission];
}

#pragma mark - 公开接口

- (void)connect {
    if (self.webSocket) [self disconnect];
    NSURLRequest *request = [NSURLRequest requestWithURL:self.socketURL];
    self.webSocket = [[SRWebSocket alloc] initWithURLRequest:request];
    self.webSocket.delegate = self;
    [self.webSocket open];
}

- (void)disconnect {
    if (self.webSocket) [self.webSocket close];
}

- (void)uploadFileData:(NSData *)fileData withIdentifier:(NSString *)fileIdentifier {
    // 风险提示：启动新任务前必须确保状态安全
    [self.stateLock lock];
    
    if (!self.isConnected) {
        NSError *error = [NSError errorWithDomain:@"FileUploader" code:-1 userInfo:@{NSLocalizedDescriptionKey: @"WebSocket未连接"}];
        [self.delegate didFailUploadingFile:fileIdentifier withError:error];
        [self.stateLock unlock];
        return;
    }
    
    // 重置状态以开始新的上传任务
    [self resetUploadState];
    
    self.fileData = fileData;
    self.totalFileSize = (uint32_t)fileData.length;
    self.fileIdentifierString = fileIdentifier;
    self.fileIdentifierData = [self dataFromHexString:fileIdentifier];
    
    // 风险提示：对输入参数的合法性校验至关重要
    if (self.fileIdentifierData.length != 8) {
        NSError *error = [NSError errorWithDomain:@"FileUploader" code:-2 userInfo:@{NSLocalizedDescriptionKey: @"文件标识符必须为8字节（16个十六进制字符）"}];
        [self.delegate didFailUploadingFile:fileIdentifier withError:error];
        [self.stateLock unlock];
        return;
    }
    
    NSLog(@"[任务开始] 文件大小: %u bytes, ID: %@", self.totalFileSize, fileIdentifier);

    [self sendNextChunksUnsafe]; // 在锁内开始发送
    [self.stateLock unlock];
}

#pragma mark - SRWebSocketDelegate

- (void)webSocketDidOpen:(SRWebSocket *)webSocket {
    self.isConnected = YES;
    NSLog(@"[连接] WebSocket已打开。");
}

- (void)webSocket:(SRWebSocket *)webSocket didFailWithError:(NSError *)error {
    self.isConnected = NO;
    NSLog(@"[错误] 连接失败: %@", error.localizedDescription);
    [self cleanupTransmission];
}

- (void)webSocket:(SRWebSocket *)webSocket didCloseWithCode:(NSInteger)code reason:(NSString *)reason wasClean:(BOOL)wasClean {
    self.isConnected = NO;
    NSLog(@"[连接] 连接已关闭。");
    [self cleanupTransmission];
}

- (void)webSocket:(SRWebSocket *)webSocket didReceiveMessage:(id)message {
    if (![message isKindOfClass:[NSData class]] || ((NSData *)message).length < 4) {
        NSLog(@"[ACK错误] 收到的ACK格式不正确（非NSData或长度小于4）。");
        return;
    }

    NSData *ackData = (NSData *)message;
    uint32_t ackedOffset;
    [ackData getBytes:&ackedOffset length:sizeof(uint32_t)];
    // 风险提示：字节序转换是跨平台通信的生命线，必须严格遵守。
    ackedOffset = ntohl(ackedOffset); // 从网络字节序转换为主机字节序

    [self.stateLock lock];
    if (ackedOffset > self.lastAckedOffset) {
        NSLog(@"[ACK] 收到有效ACK, 偏移量从 %u 滑动到 %u", self.lastAckedOffset, ackedOffset);
        self.lastAckedOffset = ackedOffset;

        // 重置停滞计时器，因为我们取得了进展
        [self startStallTimerUnsafe];
        
        // 更新UI进度
        float progress = (float)self.lastAckedOffset / self.totalFileSize;
        dispatch_async(dispatch_get_main_queue(), ^{
            [self.delegate didUpdateUploadProgress:progress forFile:self.fileIdentifierString];
        });

        if (self.lastAckedOffset >= self.totalFileSize) {
            NSLog(@"[任务完成] 文件 %@ 上传成功！", self.fileIdentifierString);
            [self resetUploadState]; // 清理当前任务状态
            dispatch_async(dispatch_get_main_queue(), ^{
                [self.delegate didFinishUploadingFile:self.fileIdentifierString];
            });
        } else {
            // 窗口已滑动，继续发送
            [self sendNextChunksUnsafe];
        }
    } else {
        NSLog(@"[ACK] 收到过时或重复的ACK: %u (当前已确认: %u)", ackedOffset, self.lastAckedOffset);
    }
    [self.stateLock unlock];
}

#pragma mark - 核心上传逻辑

// 在锁外调用
- (void)sendNextChunks {
    [self.stateLock lock];
    [self sendNextChunksUnsafe];
    [self.stateLock unlock];
}

// 风险提示：此方法必须在`stateLock`的保护下调用
- (void)sendNextChunksUnsafe {
    if (!self.fileData) return; // 没有任务在进行
    
    // 只要窗口有空间，且文件未传完，就持续发送
    while ((self.currentSentOffset - self.lastAckedOffset) < self.windowSizeInBytes && self.currentSentOffset < self.totalFileSize) {
        
        uint32_t offset = self.currentSentOffset;
        NSRange range = NSMakeRange(offset, MIN(self.chunkSize, self.totalFileSize - offset));
        NSData *chunkData = [self.fileData subdataWithRange:range];
        
        // 构建二进制数据包: 8字节ID + 4字节Offset + N字节ChunkData
        NSMutableData *packet = [NSMutableData dataWithData:self.fileIdentifierData];
        
        // 风险提示：偏移量必须转换为网络字节序
        uint32_t offsetNBO = htonl(offset);
        [packet appendBytes:&offsetNBO length:sizeof(uint32_t)];
        [packet appendData:chunkData];
        
        NSLog(@"[发送] -> ID: %@, Offset: %u, Size: %lu", self.fileIdentifierString, offset, (unsigned long)chunkData.length);
        [self.webSocket send:packet];
        
        self.currentSentOffset += range.length;
    }
    
    // 只要还有数据在飞行中，就启动或保持停滞计时器
    if (self.currentSentOffset > self.lastAckedOffset) {
        [self startStallTimerUnsafe];
    }
}

#pragma mark - 定时器与状态管理

// 风险提示：此方法必须在`stateLock`的保护下调用
- (void)startStallTimerUnsafe {
    [self.stallTimer invalidate];
    self.stallTimer = [NSTimer scheduledTimerWithTimeInterval:self.timeoutInterval
                                                       target:self
                                                     selector:@selector(handleStallTimeout)
                                                     userInfo:nil
                                                      repeats:NO];
}

- (void)handleStallTimeout {
    [self.stateLock lock];
    
    if (self.lastAckedOffset >= self.totalFileSize) {
        [self.stateLock unlock];
        return; // 任务已完成，定时器可能延迟触发
    }
    
    NSLog(@"[超时] ACK停滞，从偏移量 %u 开始重传 (Go-Back-N)", self.lastAckedOffset);
    
    // Go-Back-N: 将发送指针回退到上次确认的位置，然后重新开始发送
    self.currentSentOffset = self.lastAckedOffset;
    [self sendNextChunksUnsafe];
    
    [self.stateLock unlock];
}

- (void)resetUploadState {
    [self.stallTimer invalidate];
    self.stallTimer = nil;
    
    self.fileData = nil;
    self.fileIdentifierData = nil;
    self.fileIdentifierString = nil;
    self.totalFileSize = 0;
    self.lastAckedOffset = 0;
    self.currentSentOffset = 0;
}

- (void)cleanupTransmission {
    [self.stateLock lock];
    [self resetUploadState];
    // 这里不清空webSocket实例，只清理任务状态
    [self.stateLock unlock];
}


#pragma mark - 工具方法

- (nullable NSData *)dataFromHexString:(NSString *)string {
    if (string.length % 2 != 0) return nil;
    NSMutableData *data = [NSMutableData dataWithCapacity:string.length / 2];
    for (NSUInteger i = 0; i < string.length; i += 2) {
        NSString *hexByte = [string substringWithRange:NSMakeRange(i, 2)];
        unsigned int value;
        if ([[NSScanner scannerWithString:hexByte] scanHexInt:&value]) {
            [data appendBytes:&value length:1];
        } else {
            return nil;
        }
    }
    return data;
}

@end

如何使用

// 在你的ViewController中
#import "SRChunkedFileUploader.h"

@interface ViewController () <SRChunkedFileUploaderDelegate>
@property (nonatomic, strong) SRChunkedFileUploader *uploader;
@end

@implementation ViewController
- (void)viewDidLoad {
    [super viewDidLoad];
    
    // 1. 初始化并连接
    NSURL *url = [NSURL URLWithString:@"ws://your.server.ip:port"];
    self.uploader = [[SRChunkedFileUploader alloc] initWithURL:url];
    self.uploader.delegate = self;
    [self.uploader connect];
}

- (void)startUpload {
    // 2. 准备数据和ID
    // 风险提示：File ID必须是16个十六进制字符，代表8个字节
    NSString *fileIdentifier = @"1122334455667788"; 
    NSString *filePath = [[NSBundle mainBundle] pathForResource:@"testfile" ofType:@"zip"];
    NSData *fileData = [NSData dataWithContentsOfFile:filePath];
    
    if (fileData) {
        // 3. 调用上传方法 (确保已连接)
        [self.uploader uploadFileData:fileData withIdentifier:fileIdentifier];
    }
}

#pragma mark - SRChunkedFileUploaderDelegate

- (void)didUpdateUploadProgress:(float)progress forFile:(NSString *)fileIdentifier {
    NSLog(@"上传进度 for %@: %.2f%%", fileIdentifier, progress * 100);
    // 更新你的UI，例如一个UIProgressView
}

- (void)didFinishUploadingFile:(NSString *)fileIdentifier {
    NSLog(@"文件 %@ 上传成功！", fileIdentifier);
}

- (void)didFailUploadingFile:(NSString *)fileIdentifier withError:(NSError *)error {
    NSLog(@"文件 %@ 上传失败: %@", fileIdentifier, error);
}
@end

---

代码审计报告

• 二进制数据完整性与字节序 审计结果: 已通过。所有多字节整数（Offset和ACK）在发送前使用htonl()转换为网络字节序，在接收后使用ntohl()转换为主机字节序，确保了与任何后端服务器的兼容性。十六进制字符串到NSData的转换也经过了严格的长度和格式校验。
• 状态机正确性与鲁棒性 审计结果: 已通过。上传状态（fileData, *Offset, 等）被严格隔离，并通过uploadFileData方法进行原子性初始化。连接断开或任务完成后，cleanupTransmission/resetUploadState会清理状态，防止任务间数据污染。超时逻辑采用“停滞检测”，完美适配累积ACK机制，其Go-Back-N重传策略清晰、可靠。
• 线程安全与死锁预防 审计结果: 已通过。依然采用单一NSLock保护所有共享状态。所有外部调用（uploadFileData）、WebSocket回调和定时器回调均在访问共享数据前获取锁，设计上杜绝了数据竞争和死锁。
• 内存管理与资源泄漏 审计结果: 已通过。NSTimer在任务完成或连接断开时被显式invalidate，防止了循环引用。NSData对象在任务完成后被置为nil，及时释放了文件数据所占的大块内存。

结论：这份针对分片上传的改造方案，不仅完全符合你提出的二进制报文和累积ACK要求，而且在设计上考虑了真实网络环境的复杂性。它是一个可以直接投入生产环境的、高质量的实现。

这里每天分享一个 iOS 的新知识，快来关注我吧

---

前言

---

在移动应用的开发过程中，版本更新是必不可少的一环。

无论是修复漏洞、功能迭代，还是提升用户体验，更新都扮演着至关重要的角色。那么，如何给用户有效地传递更新信息，并在必要时执行强制更新呢？本文将为你详细解析这一过程。

为什么需要更新？

随着时间的推移，应用需要不断迭代，以适应用户的需求和市场的变化。而有的功能也随之废弃，此时就需要让用户更新到最新版本。

还有的时候，应用需要进行安全更新，以修复已知的安全漏洞和优化用户体验。

作为开发者，我们有责任在代码中传达更新的重要性。

请在微信客户端打开

非侵入性通知策略

应用内通知

首先我们需要有个服务端接口来获取应用的最新版本，客户端开启时调用接口检查，把当前的版本号传给服务端，服务端返回是否需要更新，以及更新内容。

如果你没有服务端，那么可以利用 iTunes Lookup API 来获取应用的最新版本，然后进行版本对比。具体的 URL 规则为https://itunes.apple.com/br/lookup?bundleId={你的bundleId}，它会返回一个 JSON 对象，其中包含应用的最新版本号。

通过应用内通知，我们可以在用户打开应用时，温和地提示他们进行更新。以下是一个简单的 Swift 实现示例：

func showInAppNotification(message: String) {
    let alertController = UIAlertController(
        title: "有更新可用啦",
        message: message,
        preferredStyle: .alert
    )

    let updateAction = UIAlertAction(title: "更新", style: .default) { _in
        iflet appStoreURL = URL(string: "https://apps.apple.com/cn/app/%E6%8A%96%E9%9F%B3/id1142110895") {
            UIApplication.shared.open(appStoreURL, options: [:], completionHandler: nil)
        }
    }

    alertController.addAction(updateAction)

    iflet viewController = UIApplication.shared.keyWindow?.rootViewController {
        viewController.present(alertController, animated: true, completion: nil)
    }
}

// 示例使用
let updateMessage = "应用程序的新版本已可用。立即更新以获取最新功能和改进。"
showInAppNotification(message: updateMessage)

这个示例中，我们通过UIAlertController 创建了一个弹窗，并在用户点击更新按钮时，打开应用在 App Store 的链接，Alert 也会被关闭。

理论上，这种更新方式可以被用户跳过。

推送通知

如果用户没有打开应用，那么就需要通过推送通知来提醒用户更新了，服务端存储用户的版本，然后根据版本号来判断给哪些用户发送更新推送。

利用推送通知是一种在用户不打开应用的情况下，提醒用户的有效方式。结合苹果的 APNS，可以在 AppDelegate 中处理收到的推送通知，进而弹出更新弹窗：

func application(_ application: UIApplication, didReceiveRemoteNotification userInfo: [AnyHashable: Any]) {
    if let updateMessage = userInfo["updateMessage"] as? String {
        showInAppNotification(message: updateMessage)
    }
}

强制更新的情况

强制更新侵入性比较强，也比较容易引起用户的反感，通常用于特定场景，比如发现安全漏洞、修复严重 bug、服务器端的重大变更或旧版本的弃用等等。

在制定强制更新方案时，需要考虑用户的不同选择、可能的中断、网络情况等。

实现方案

利用 iTunes Lookup API，我们可以获取应用的最新元数据。我们以抖音 app 为例，写一个获取最新版本号的并唤起强更的示例。

抖音 app 的 iTunes Lookup API 地址为https://itunes.apple.com/cn/lookup?bundleId=com.ss.iphone.ugc.Aweme。

请求 iTunes Lookup API

简单的代码如下：

guard let url = URL(string: "https://itunes.apple.com/cn/lookup?bundleId=com.ss.iphone.ugc.Aweme") else {
    return
}

URLSession.shared.dataTask(with: url) { data, response, error in
    iflet data = data {
        do {
            let json = tryJSONSerialization.jsonObject(with: data, options: []) as? [String: Any]
            iflet results = json?["results"] as? [[String: Any]], let version = results.first?["version"] as? String {
                let localVersion = Bundle.main.infoDictionary?["CFBundleShortVersionString"] as? String
                iflet localVersion = localVersion, version > localVersion {
                    DispatchQueue.main.async {
                        // 弹出更新弹窗
                        let updateMessage = "应用程序的新版本已可用。立即更新以获取最新功能和改进。"
                        self.showInAppNotification(message: updateMessage)
                    }
                }
            }
        } catch {
            print("Error parsing JSON: \(error)")
        }
    }
}.resume()

处理异常情况

首先，既然是强更，就不让让用户跳过了，最简单的方法是在用户点击“更新”按钮后，重新将 Alert 弹出：

func showInAppNotification(message: String) {
    let alertController = UIAlertController(
        title: "有更新可用啦",
        message: message,
        preferredStyle: .alert
    )

    let updateAction = UIAlertAction(title: "更新", style: .default) { _in
        iflet appStoreURL = URL(string: "https://apps.apple.com/cn/app/%E6%8A%96%E9%9F%B3/id1142110895") {
            UIApplication.shared.open(appStoreURL, options: [:], completionHandler: nil)
        }
        
        // 重新弹出更新弹窗
        self.showInAppNotification(message: message)
    }

    alertController.addAction(updateAction)

    iflet viewController = UIApplication.shared.keyWindow?.rootViewController {
        viewController.present(alertController, animated: true, completion: nil)
    }
}

另外还需要考虑用户断网、请求失败等情况，最好的方法是在本地记录一个是否检查过版本更新的值，然后监听设备有网络时重新检查一下更新状态，保证一次冷启动周期内检查成功一次，进而保证用户无法跳过强制更新。

结语

应用的更新与用户体验息息相关。通过合理的策略，我们可以在尽量不打扰用户的情况下，及时有效地推动更新，确保应用的安全性和功能性。希望本文能为你的应用更新策略提供一些启发。

这里每天分享一个 iOS 的新知识，快来关注我吧

本文同步自微信公众号 “iOS新知”，每天准时分享一个新知识，这里只是同步，想要及时学到就来关注我吧！

在 Swift 中，协议（Protocol）是一种强大的抽象工具，它让我们可以只关注「行为」而不是具体「实现」。协议不仅可以定义方法和属性要求，还可以继承其他协议，从而在代码中实现更清晰的分层设计。

但很多同学常常会问：什么时候应该使用协议继承？
今天，我们就一起来聊聊协议继承的应用场景、最佳实践，以及在实际项目中应该如何优雅使用。

---

💡 什么是协议继承？

协议继承其实非常简单：一个协议可以继承一个或多个其他协议，除了继承它们的要求之外，还可以添加自己的新要求。

protocol Vehicle {
    func start()
}

protocol ElectricVehicle: Vehicle {
    func charge()
}

上面，ElectricVehicle 继承了 Vehicle 协议，这意味着任何遵循 ElectricVehicle 的类型，必须同时实现 start() 和 charge() 。

---

🟢 协议继承的应用场景

✅ 1. 按功能分解，组合更小的协议

当你的协议太大时，直接把所有要求都堆在一个协议里会非常笨重、难以维护。这时候可以将功能拆解成小协议，然后再通过继承组合成一个大协议。

protocol Drivable {
    func drive()
}

protocol Flyable {
    func fly()
}

protocol AmphibiousVehicle: Drivable, Flyable {}

这样，AmphibiousVehicle 就是「既能开也能飞」的交通工具，实现者必须同时满足两个功能。

---

✅ 2. 为不同层次的抽象设计协议

有时我们需要定义一些「更抽象」的行为，后面再细化。例如：

protocol Shape {
    func area() -> Double
}

protocol ColoredShape: Shape {
    var color: String { get set }
}

• Shape 定义了基本形状的行为（计算面积）。
• ColoredShape 继承 Shape 并增加颜色属性。

当我们需要「只关心形状」时，只使用 Shape；需要「带颜色的形状」时，使用 ColoredShape，这种分层设计思路更加清晰、灵活。

---

✅ 3. 给默认实现做准备

如果你有多个协议需要提供相似的默认实现，使用协议继承可以帮助你只写一次。

protocol Printable {
    func printInfo()
}

extension Printable {
    func printInfo() {
        print("This is a printable object.")
    }
}

protocol DetailedPrintable: Printable {
    func detailedDescription() -> String
}

extension DetailedPrintable {
    func printInfo() {
        print(detailedDescription())
    }
}

这样，DetailedPrintable 可以重写 printInfo()，但仍然保留 Printable 的默认实现。

---

⚡️ 使用协议继承的好处

✅ 可组合：小协议组合大协议，灵活扩展。
✅ 更好的抽象层次：让设计更符合「接口分离原则」。
✅ 减少耦合：调用方只依赖需要的协议，避免过度依赖具体实现。

---

❗️ 使用协议继承要注意什么？

• ❌ 不要为了「好看」而滥用继承，把很多无关行为硬塞进一个协议里。
• ✅ 遵循「单一职责原则」，一个协议最好只关心一件事，后续可以通过继承组合。
• ✅ 谨慎考虑是否需要在协议中定义默认实现，如果太多默认实现，可能隐藏了实现者必须注意的逻辑。

---

🟢 总结

什么时候应该使用协议继承？

当你需要：

• 分层抽象
• 组合小协议
• 为可选功能提供可重用的默认实现

这时候协议继承就是一个非常优雅、灵活的解决方案。

前言

在 Swift 代码中，一句简单的 object.method() 背后，藏着编译器与运行时的精密协作。方法调用看似只是 “执行一段代码”，但 Swift 为了平衡性能与灵活性，设计了多套派发机制 —— 从编译时就能锁定地址的 “静态派发”，到运行时动态查找的 “虚表舞蹈”，再到与 Objective-C 兼容的消息发送魔法。

理解这些机制，不仅能帮你看透代码的执行效率瓶颈，更能在设计数据结构、选择类型（结构体 vs 类）、优化性能时做出更理性的决策。今天，我们就拆开这层 “黑箱”，从底层原理讲到实战技巧，带你掌握 Swift 方法调用的 “底层密码”。

一、Swift 的方法派发艺术：静态与动态的平衡术

方法派发（Method Dispatch）指的是 “如何找到并执行方法对应的代码”。Swift 不像 Objective-C 那样依赖单一的消息发送机制，而是根据场景灵活切换策略 —— 这正是它既能保持高性能，又能支持面向对象特性的核心原因。

1. 静态派发：编译时的 “精准定位”

静态派发的核心是 “编译时确定”：编译器在编译阶段就明确知道方法的具体实现地址，调用时直接跳转到该地址执行，无需任何运行时查找。这种机制就像快递员提前知道收件人的精确地址，直接上门投递，效率极高。

适用场景：

• 结构体（struct）、枚举（enum）等值类型的方法（默认静态派发）；

• 被 final 修饰的类或方法（禁止重写，编译器可确定不会有动态变化）；

• 私有方法（private 修饰，仅限当前文件可见，无法被外部重写）。

代码示例：

struct Point {
    var x: Int, y: Int
    func distance(to other: Point) -> Int {  // 静态派发：编译时确定地址
        return abs(x - other.x) + abs(y - other.y)
    }
}

final class MathUtil {  // final 类：所有方法默认静态派发
    func calculate() -> Int { return 42 }
}

class Logger {
    private func log() { print("调试日志") }  // private 方法：静态派发
}

性能优势：
静态派发避免了运行时的查找开销，执行速度接近原生函数调用。对于高频调用的工具方法（如数学计算、数据转换），静态派发能显著提升性能。

2. 动态派发：虚表（VTable）的 “动态舞蹈”

当需要支持类的继承与方法重写时，静态派发就无法满足需求了 —— 编译器无法在编译时确定 “到底调用父类还是子类的方法”。这时，Swift 会启用虚表（Virtual Table，简称 VTable）  机制，让方法调用在运行时动态决策。

虚表的本质：函数指针数组

每个类在编译时都会生成一张虚表，本质是一个 “函数指针数组”，其中存储了该类所有可被重写的方法的实现地址。具体规则如下：

• 父类的方法会按顺序排在虚表前面；
• 子类新增的方法追加在虚表末尾；
• 子类重写父类的方法时，会替换虚表中对应位置的函数指针（保持与父类虚表的索引对齐）。

动态调用的流程

当调用一个类的方法时，执行步骤如下：

1. 从对象实例中取出 “类指针”（指向该对象的实际类型信息）；

2. 通过类指针找到对应的虚表；

3. 根据方法在虚表中的索引，找到具体的函数指针并执行。

代码示例：

class Animal {
    func speak() { print("动物叫声") }  // 虚表索引 0
    func move() { print("移动中") }     // 虚表索引 1
}

class Dog: Animal {
    override func speak() { print("汪汪！") }  // 替换索引 0 的指针
    func fetch() { print("捡球") }             // 新增索引 2 的指针
}

// 调用时的动态决策
let pet: Animal = Dog()  // 编译时类型是 Animal，运行时类型是 Dog
pet.speak()  // 运行时找到 Dog 的虚表，执行索引 0 的方法 → 输出“汪汪！”

动态派发的优势与代价

优势：支持灵活的继承与多态，让子类可以 “无缝替换” 父类的方法实现，是面向对象编程的核心基础。
代价：相比静态派发，虚表查找增加了 “取类指针→查虚表→取函数指针” 的三步操作，虽比 Objective-C 的消息发送快，但仍慢于静态派发。

3. 消息派发：与 Objective-C 的 “跨语言桥梁”

Swift 为了兼容 Objective-C 的运行时特性（如 KVO、动态方法交换），提供了 @objc dynamic 修饰符，强制方法使用 Objective-C 的消息发送（Message Sending）  机制。

这种机制与虚表派发完全不同：调用方法时，运行时会通过 objc_msgSend 函数动态查找方法（先查缓存，再查类的方法列表，最后触发消息转发），灵活性极高，但性能开销也最大。

代码示例：

class Player: NSObject {
    @objc dynamic func attack() { print("攻击！") }  // 启用消息发送
}

// Objective-C 可通过 runtime 动态替换方法实现
let player = Player()
player.attack()  // 实际执行由 runtime 动态决定

二、Swift 与 Objective-C 派发机制的深度对比

Swift 和 Objective-C 的方法调用机制，本质上是 “编译时优化” 与 “运行时灵活” 的取舍。下表从底层原理到实际表现做详细对比：

特性	Swift 机制	Objective-C 机制
核心原理	静态派发（值类型 /final）+ 虚表派发（类继承）	消息发送（objc_msgSend 动态查找）
调用流程	编译时确定地址（静态）/ 虚表索引查找（动态）	运行时逐级查找方法缓存→类列表→父类
性能	静态派发极快，虚表派发较快	消息发送较慢（查找成本高）
灵活性	需提前声明（override/dynamic）	支持运行时动态添加 / 替换方法
适用场景	性能敏感的业务逻辑（如游戏、算法）	依赖运行时魔法的场景（如 KVO、AOP）

关键差异：
Swift 更倾向于 “编译时做决定”，通过静态派发和虚表派发平衡性能与继承需求；Objective-C 则完全依赖 “运行时动态查找”，牺牲部分性能换取极致灵活。

三、性能优化实战：从派发机制入手

理解了派发机制后，我们可以通过以下技巧优化 Swift 代码性能：

1. 用 final 锁定静态派发

为不需要被继承的类或方法添加 final 修饰符，告诉编译器 “该方法不会被重写”，从而将动态派发优化为静态派发。

示例：

// 无需继承的工具类，直接标记为 final
final class DateFormatter {
    func format() -> String { ... }  // 静态派发，性能提升
}

class NetworkClient {
    // 核心方法不允许重写
    final func sendRequest() { ... }  // 静态派发，避免虚表开销
}

2. 优先选择值类型（结构体 / 枚举）

结构体（struct）和枚举（enum）默认使用静态派发，且存储在栈上（相比堆上的类实例，内存分配 / 释放更快）。对于无继承需求的数据模型（如坐标、颜色、配置项），值类型是更优选择。

示例：

// 用结构体替代类，提升性能
struct User {
    let id: Int
    let name: String
    func display() { print(name) }  // 静态派发，栈存储
}

3. 避免过度继承，控制虚表规模

类的继承层级越深，虚表越长，查找索引的成本越高（虽微乎其微，但高频调用会累积）。建议：

• 能用组合（has-a）替代继承（is-a）时，优先用组合；
• 非必要不设计超过 3 层的继承体系。

4. 慎用 @objc dynamic

@objc dynamic 会强制方法使用 Objective-C 的消息发送机制，性能比虚表派发慢 2-3 倍。仅在必须依赖 Objective-C 运行时的场景（如 KVO、与 OC 动态交互）时使用。

四、虚表的底层细节：从内存布局到多态实现

虚表的设计是 Swift 支持多态的核心，以下从内存角度进一步解析：

1. 类实例的内存布局

每个类的实例在内存中分为两部分：

• 成员变量区：存储实例的属性值；
• 类指针（isa 指针） ：指向该实例对应的类元数据（包含虚表地址、类信息等）。

2. 虚表的继承与重写示例

以 Animal 和 Dog 为例，它们的虚表结构如下：

Animal 虚表（父类）	索引	Dog 虚表（子类）	索引
speak()（动物叫声）	0	speak()（汪汪！）	0	（重写）
move()（移动中）	1	move()（移动中）	1	（继承）
-	-	fetch()（捡球）	2	（新增）

当通过父类指针（let pet: Animal = Dog()）调用 pet.speak() 时，运行时会通过 pet 的类指针找到 Dog 的虚表，再通过索引 0 找到重写后的 speak() 实现 —— 这就是多态的底层逻辑。

结语

Swift 的方法调用机制，是 “性能” 与 “灵活” 的精妙平衡：静态派发为值类型和固定逻辑提供极致速度，虚表派发为类的继承与多态提供动态支持，而消息派发则架起与 Objective-C 生态的桥梁。

作为开发者，理解这些机制后，我们能更理性地选择类型（struct 还是 class）、设计继承体系（是否需要重写）、优化性能（final 修饰或避免过度动态）。毕竟，写出高效的代码，不仅需要掌握语法，更要看透语言的底层逻辑。

希望这篇文章能帮你揭开 Swift 方法调用的神秘面纱，让你的代码在优雅与性能之间找到完美平衡！

在 weekly.fatbobman.com 订阅本周报的电子邮件版本。访问我的博客 肘子的 Swift 记事本 查看更多的文章。加入 Discord 社区，与 2000+ 中文开发者深入交流 Swift、SwiftUI 开发体验。

高温与奇怪的天象

从 6 月中开始，我所在的城市也迎来了罕见的高温天气。尽管相较于动辄 35-40 多摄氏度的其他地区，30-31 摄氏度在数字上看起来并不夸张，但对于习惯了 20 几度的我来说，这种温度已经很难熬了。

与高温相伴的还有一些奇怪的天象。6 月 19 日，大连上空出现了一种罕见的云——糙面云。天空呈现出强烈的压迫感，给人一种"末世"将近的错觉，幸好仅持续了半个小时。几天前的夜间又出现了高频闪电现象。一夜之间，据气象部门设备检测共发生了 7649 次闪电。我当时看向窗外的感觉就像有人在用氩弧焊进行焊接，整夜不停。有趣的是，尽管闪电极多，却几乎听不到雷声。

这些局部现象其实反映了全球性的趋势。至少从最近两个月的天气表现来看，今年仍会是气温极高的一年。全球很多地方的气温从春季开始就在不断刷新着纪录。从气象历史的角度看，气候带迁移本是一个正常的周期性趋势，但这种变化通常以百年、千年为尺度。而现在的发展速度远超理论上的自然演进——已经缩短到以几十年为单位了。

工业革命以来，大气中二氧化碳浓度急剧上升，目前的平均水平为过去至少 70 万年内所未见。几乎可以肯定，人类活动改变并加速了气候变化的自然进程。

人类文明要进步、要发展，就需要更多的创造和活动，而这些又势必会改变延续已久的生态平衡。在地球的演化史上，气候发生巨大而剧烈的变化并不罕见，地球总能用时间来抹平这些创伤，让一切恢复如初。只是，当这一切归于平静之时，人类是否还会是今天的模样呢？

前一期内容｜全部周报列表

原创

与 AI 共舞：我的 Claude Code 一月谈

转眼间，我使用 Claude Code 已经整整一个月了。这段时间里，它迅速成为了开发者们的新宠，关于 Claude Code 的讨论充斥着我的社交媒体时间线。最近有网友在 Discord 上问我对 Claude Code 的看法，正好借这个机会分享一下这段时间的使用感受，以及过去两年中 AI 为我的开发工作带来的便利与思考。

近期推荐

深入 Attribute Graph

在 SwiftUI 中，Attribute Graph 既重要又神秘。它是 SwiftUI 的核心运行时机制之一，用于追踪视图状态和依赖，驱动高效、最小化的 UI 更新。Chris Eidhof 在这段视频（附文字稿）里分享了他对其的洞察，并推荐了相关资料和工具，帮助开发者深入探索 SwiftUI 的内部原理。

---

用 AlarmKit 实现倒计时定时器 (Schedule a Countdown Timer with AlarmKit)

在 WWDC 2025，苹果发布了开发者期待已久的 AlarmKit，支持创建一次性闹钟、每周重复闹钟和即时启动的倒计时计时器。与 UserNotifications 在静音或专注模式下“悄无声息”不同，AlarmKit 的警报能突破限制，在关键时刻响起并显示横幅。在本文中，Natalia Panferova 详解了其 API 的使用方法，并演示了如何在主应用、Widget 和 Live Activity 等场景下进行配置。

---

为什么我不再“万物皆 struct” (Why I Stopped Using Structs for Everything in Swift)

Swift 社区一直推崇"优先使用 struct"的开发理念。值类型的不可变性和线程安全性看似完美，但在大型项目中，这种“struct 万能论”却暴露出不少问题。在这篇文章中，Koti Avula 结合实战经验，深入剖析了引用类型嵌入 struct 的陷阱、闭包捕获 self 的意外行为、以及关于性能的常见误区，并分享了他为何不再坚持“struct 至上”。

---

SwiftUI 如何实现渐进式模糊效果？

在 iOS 26，Apple Music 等系统应用引入了更细腻的渐变模糊效果。不过，这些功能尚未完全开放给开发者，也难以兼容较低系统版本。Justin Yan 在本文中分享了两种实现思路：

• 使用 UIVisualEffectView 复用系统级模糊渐变
• 结合 QuartzCore 和私有 CAFilter API 自定义渐进式模糊

虽然与 Liquid Glass 的原生效果仍有差距，但足以实现接近的视觉体验。

---

我用 Claude Code 独立开发了一款 macOS 应用 (I Shipped a macOS App Built Entirely by Claude Code)

在这篇极长文中，Indragie Karunaratne 分享了他用 Claude Code ，从 0 到 1 开发并上线一款原生 macOS 应用的经历。作者认为 Claude 的 Swift 6 和 SwiftUI 生成能力已相当实用，并通过 priming agent、自动化反馈循环等技巧，几乎实现了全部代码的自动编写（20,000 行代码中 95% 由 AI 生成）。文章还探讨了未来 IDE 形态和构建高质量自动化流程的思路，以及“人机协作式编程”的可能性。

---

Swift Android SDK 快速上手体验 (Using the Swift Android SDK)

虽然 Android Workgroup 已经成立，但在 Swift.org 上仍找不到关于安装和使用 Swift Android SDK 的官方指南。Abe White 在这段视频中演示了如何通过 skip 安装 Swift Android SDK，并在安卓设备上运行和测试 Swift 代码。

看完视频后，我马上按照 Abe 介绍的方法安装了 SDK，只用了很短时间就让我原本仅支持 macOS/Linux 的两个库顺利跑在 Android 上，过程非常顺畅。

工具

Objects2XLSX - 一键将数据集转换成 xlsx

一个类型安全、声明式的 Swift 库，让你用几行代码将对象数组导出为专业级 Excel (.xlsx) 文件。支持多工作表、完整样式、异步数据源和实时进度跟踪。

• ✅ Swift 6 并发支持
• ✅ KeyPath 映射 + 泛型 Sheet
• ✅ 多平台支持，macOS/Linux/Android
• ✅ 生成文件 100% Excel 兼容

---

Equatable Macro – 改善 SwiftUI 视图性能

SwiftUI 默认的 diff 机制在遇到闭包或需要忽略某些状态时容易误判，导致视图不必要的重绘。常见的优化方式是让视图符合 Equatable，用自定义逻辑控制刷新，但手动实现既繁琐又容易遗漏。为此，Mirza Učanbarlić 受 Cal Stephens 在 Understanding and Improving SwiftUI Performance 一文中的思路启发，打造了 @Equatable 宏，自动生成 Equatable 实现，极大简化开发流程。

往期内容

• Swift 的多平台策略，需要我们大家一起来建设 - #091
• 失去时才会觉得可贵 - #090
• WWDC 2025：回归务实的一年 - #089
• WWDC 2025 开发者特辑 - #088

THANK YOU

如果你觉得这份周报或者我的文章对你有所帮助，欢迎 点赞 并将其 转发 给更多的朋友。

在 weekly.fatbobman.com 订阅本周报的电子邮件版本。访问我的博客 肘子的 Swift 记事本 查看更多的文章。加入 Discord 社区，与 2000+ 中文开发者深入交流 Swift、SwiftUI 开发体验。

在鸿蒙系统中，蓝牙功能的实现依赖于 HarmonyOS 提供的ConnectivityKit蓝牙模块、AbilityKit权限控制模块和ArkTS工具模块。本文详细讲解蓝牙连接、数据传输等核心流程。

---

---

一、蓝牙权限申请

• 在使用蓝牙功能之前，须在module.json5中配置蓝牙权限。

"requestPermissions": [
  {
    "name": "ohos.permission.ACCESS_BLUETOOTH",
    "reason": "$string:open_bluetooth",
    "usedScene": {
      "abilities": ["EntryAbility"],
      "when": "inuse"
    }
  }
]

• 同时向用户申请蓝牙权限

async getBluetoothRequestion(callback: (res: abilityAccessCtrl.GrantStatus) => void) {
  const ctx = AppStorage.get<Context>(CONTEXT_GLOB) // 获取全局上下文
  const ctrl = abilityAccessCtrl.createAtManager() // 创建权限管理器
  const res = (ctrl.requestPermissionsFromUser(ctx, ['ohos.permission.ACCESS_BLUETOOTH'])) // 请求蓝牙权限

  res.then(async (promise) => {
    if (!promise.authResults.every(t => t == abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED)) {
      const res = await ctrl.requestPermissionOnSetting(ctx, ['ohos.permission.ACCESS_BLUETOOTH'])
      callback(res[0])
    } else {
      callback(promise.authResults[0]) // 调用回调函数，返回权限状态
    }
  })
}

• 引入权限控制模块：使用 abilityAccessCtrl.createAtManager() 创建权限管理器。
• 请求权限：调用 requestPermissionsFromUser 向用户请求 ohos.permission.ACCESS_BLUETOOTH 权限。
• 权限未授予处理：若用户拒绝权限，则尝试跳转到设置页面进行手动授权，调用 requestPermissionOnSetting。
• 回调返回结果：最终通过 callback(res[0]) 或 callback(promise.authResults[0]) 返回权限状态。

---

二、蓝牙开关状态判断与监听

1. 判断蓝牙是否开启

isBluetoothEnabled(): boolean {
  const state: access.BluetoothState = access.getState(); // 获取蓝牙当前状态
  // 判断是否为开启或正在开启状态
  return state === access.BluetoothState.STATE_ON; // 返回蓝牙是否已开启的布尔值
}

• 调用 access.getState() 获取当前蓝牙状态。
• 检查状态是否为 access.BluetoothState.STATE_ON，如果是则表示蓝牙已打开。

2. 监听蓝牙状态变化

//监听蓝牙变化
onBluetoothState(callback: (state: boolean) => void) {
  // 监听蓝牙状态变化事件
  access.on('stateChange', (status) => {
    // 判断蓝牙是否关闭，若关闭则调用回调函数并传入false
    status == access.BluetoothState.STATE_OFF && callback(false)
    // 判断蓝牙是否开启，若开启则调用回调函数并传入true
    status == access.BluetoothState.STATE_ON && callback(true)
  })
}

• 使用 access.on('stateChange') 监听蓝牙开关状态变化事件。
• 当状态变为 STATE_OFF 时，调用 callback(false)；
• 当状态变为 STATE_ON 时，调用 callback(true)。

---

三、蓝牙设备扫描

// 蓝牙设备扫描
findBluetoothDecice(callback: (device: ble.ScanResult[]) => void) {
  try {
    ble.startBLEScan(null, {
      interval: 500, // 设置扫描间隔为500ms
      dutyMode: ble.ScanDuty.SCAN_MODE_LOW_POWER, // 设置扫描模式为低功耗模式
      matchMode: ble.MatchMode.MATCH_MODE_AGGRESSIVE // 设置匹配模式为积极模式
    })

    // 初始化设备列表数组
    let deviceList: ble.ScanResult[] = []

    ble.on("BLEDeviceFind", (res: ble.ScanResult[]) => { // 监听蓝牙设备发现事件
      res.forEach((dev: ble.ScanResult) => { // 遍历所有发现的设备
        // 如果设备有名称
        if (dev.deviceName) {
          // 将新设备添加到列表中，避免重复
          deviceList.push(...res.filter(v => !deviceList.some(vv => vv.deviceId === v.deviceId)))
        }
        // 调用回调函数，返回当前设备列表
        callback(deviceList)
      })
    })
  } catch (err) { // 捕获异常
    logger.info(err) // 记录错误信息
  }
}

• 启动蓝牙扫描：调用 ble.startBLEScan 开始低功耗扫描，参数如下：

  • interval: 扫描间隔（500ms）
  • dutyMode: 扫描模式（低功耗模式 SCAN_MODE_LOW_POWER）
  • matchMode: 匹配模式（积极匹配 MATCH_MODE_AGGRESSIVE）

• 设备发现监听：注册 BLEDeviceFind 事件，每次发现新设备后，遍历并去重添加至 deviceList。

• 回调返回设备列表：通过 callback(deviceList) 返回当前扫描到的所有设备。

---

四、蓝牙连接与断开

1. 连接设备

// 蓝牙设备连接
connectDevice(device: ble.ScanResult, callback: (clientDevice: ble.ScanResult) => void) {
  try {
    // 创建GATT客户端设备实例，传入目标设备的ID
    this.currentClient = ble.createGattClientDevice(device.deviceId)
    // 建立与设备的蓝牙连接
    this.currentClient.connect()
    // 监听蓝牙连接状态变化事件
    this.currentClient.on("BLEConnectionStateChange", (result) => {
      // 判断连接状态是否为已连接
      if (result.state === constant.ProfileConnectionState.STATE_CONNECTED) {
        // 调用回调函数，传入已连接的设备
        callback(device)
      }
    })
  } catch (err) {
    logger.info(err)
  }
}

• 创建 GATT 客户端：调用 ble.createGattClientDevice(device.deviceId) 创建客户端实例。
• 建立连接：调用 connect() 方法发起连接。
• 监听连接状态变化：注册 BLEConnectionStateChange 事件，当连接状态为 STATE_CONNECTED 时，调用 callback(device) 返回连接成功的设备对象。

2. 断开设备连接

//断开蓝牙设备
disconnectDevice(callBack: () => void) {
  if (this.currentClient) { // 检查当前是否已连接蓝牙设备
    this.currentClient.disconnect() // 断开与蓝牙设备的连接
    this.currentClient.close(); // 关闭蓝牙客户端资源
    this.currentClient = null // 将当前客户端设为null，表示已断开连接
    callBack() // 调用回调函数，通知断开完成
  }
}

• 检查连接状态：判断 this.currentClient 是否存在。
• 断开连接：调用 disconnect() 关闭连接，并调用 close() 清理资源。
• 清空引用：将 currentClient 设为 null。
• 回调通知完成：调用 callBack() 告知上层断开操作已完成。

---

五、蓝牙数据发送与监听

1. 发送数据

//数据发送
async bluetoothSendMsg(data: BlueData) {
  try {
    // 检查当前是否存在已连接的蓝牙设备
    if (this.currentClient) {
      // 获取蓝牙设备的所有服务列表
      const list = await this.currentClient.getServices()
      // 查找服务UUID以0000AE30开头的服务
      const doorService = list.find(v => v.serviceUuid.startsWith("0000AE30"))
      // 查找特征UUID以0000AE10开头的特征
      const message = doorService?.characteristics.find(v => v.characteristicUuid.startsWith("0000AE10"))
      // 创建文本编码器实例
      const encoder = new util.TextEncoder()
      // 将数据对象编码为Uint8Array
      const u8a = encoder.encodeInto(JSON.stringify(data))

      // 向蓝牙设备发送特征值数据
      await this.currentClient.writeCharacteristicValue({
        serviceUuid: message?.serviceUuid, // 服务UUID
        characteristicUuid: message?.characteristicUuid, // 特征UUID
        characteristicValue: u8a.buffer, // 特征值数据
        descriptors: [], // 描述符列表
      }, ble.GattWriteType.WRITE) // 设置写入类型为WRITE
    }
  } catch (err) {
    logger.info(err)
  }
}

• 检查连接状态：确保 currentClient 不为空。
• 获取服务列表：调用 getServices() 获取设备支持的服务。
• 查找目标服务和特征：
  • 服务 UUID 以 0000AE30 开头
  • 特征 UUID 以 0000AE10 开头
• 编码数据：使用 util.TextEncoder 将 JSON 对象转换为 Uint8Array。
• 写入特征值：调用 writeCharacteristicValue 发送数据，参数包括：
  • serviceUuid
  • characteristicUuid
  • characteristicValue（即编码后的数据）
  • descriptors
  • writeType（指定为 WRITE）

2. 监听特征值变化

//监听特征值变化
async listenInDeviceDataChange(callBack: (message: number | void) => void) {
  // 检查当前是否存在已连接的蓝牙设备
  if (this.currentClient) {
    // 监听蓝牙特征值变化事件
    this.currentClient?.on("BLECharacteristicChange", (res) => {
      // 创建文本解码器实例
      const decoder = util.TextDecoder.create()
      // 将特征值数据转换为Uint8Array
      const buffer = new Uint8Array(res.characteristicValue)
      // 将二进制数据解码并解析为BlueData对象
      const result = JSON.parse(decoder.decodeToString(buffer)) as BlueData
      // 如果命令类型为'wifi'
      if (result.command === 'wifi') {
        // 再次调用回调函数，传递状态码
        callBack(result.status)
      }
    })
    // 获取蓝牙设备的所有服务列表
    const serviceList = await this.currentClient?.getServices()
    // 查找服务UUID以0000AE30开头的服务
    const doorService = serviceList?.find(v => v.serviceUuid.startsWith("0000AE30"))
    // 查找特征UUID以0000AE04开头的特征
    const message = doorService?.characteristics.find(v => v.characteristicUuid.startsWith("0000AE04"))
    // 设置特征值变化通知，启用通知功能
    await this.currentClient?.setCharacteristicChangeNotification(message, true)
  }
}

• 监听特征值变化：注册 BLECharacteristicChange 事件，每当设备有数据更新时触发。
• 解码数据：使用 util.TextDecoder.create() 创建解码器，将 characteristicValue 转换为字符串并解析为 BlueData 对象。
• 特殊命令处理：如果命令是 'wifi'，调用 callBack(result.status)。

---

六、接口定义说明

interface BlueData {
  status?: 200 | 400 // 200 表示成功，400 表示失败
  msg?: string // 状态消息
  command?: 'open' | 'wifi' // 命令类型：开门或配置Wi-Fi
  data?: string[] // 数据内容，如 Wi-Fi 的 [ssid, pwd]
}

该接口用于封装蓝牙通信过程中发送和接收的数据结构。

---

七、完整代码

import { abilityAccessCtrl } from "@kit.AbilityKit" // 导入AbilityKit中的权限控制模块
import { logger } from "../../../../Index" // 导入自定义日志工具
import { CONTEXT_GLOB } from "../constants/ConstantEvent" // 导入全局上下文常量
import { access, ble, constant } from "@kit.ConnectivityKit" // 导入蓝牙相关模块
import { util } from "@kit.ArkTS" // 导入ArkTS工具模块，用于文本编码解码等操作


// 1. 蓝牙开门 2. 配置设备 wifi 连网
interface BlueData {
  status?: 200 | 400 //  200 成功  400 失败
  msg?: string // 消息提示
  command?: 'open' | 'wifi' // 命令类型：开门或配置Wi-Fi
  data?: string[] // 例如配置Wi-Fi时的数据：[ssid, pwd]
}

class BluetoothManager {
  // 当前已连接的设备
  currentClient: ble.GattClientDevice | null = null

  // 获取蓝牙权限
  async getBluetoothRequestion(callback: (res: abilityAccessCtrl.GrantStatus) => void) {
    const ctx = AppStorage.get<Context>(CONTEXT_GLOB) // 获取全局上下文
    const ctrl = abilityAccessCtrl.createAtManager() // 创建权限管理器
    const res = (ctrl.requestPermissionsFromUser(ctx, ['ohos.permission.ACCESS_BLUETOOTH'])) // 请求蓝牙权限

    res.then(async (promise) => {
      if (!promise.authResults.every(t => t == abilityAccessCtrl.GrantStatus.PERMISSION_GRANTED)) {
        const res = await ctrl.requestPermissionOnSetting(ctx, ['ohos.permission.ACCESS_BLUETOOTH'])
        callback(res[0])
      } else {
        callback(promise.authResults[0]) // 调用回调函数，返回权限状态
      }
    })
  }

  // 判断本机蓝牙是否打开
  isBluetoothEnabled(): boolean {
    const state: access.BluetoothState = access.getState(); // 获取蓝牙当前状态
    // 判断是否为开启或正在开启状态
    return state === access.BluetoothState.STATE_ON; // 返回蓝牙是否已开启的布尔值
  }

  //监听蓝牙变化
  onBluetoothState(callback: (state: boolean) => void) {
    // 监听蓝牙状态变化事件
    access.on('stateChange', (status) => {
      // 判断蓝牙是否关闭，若关闭则调用回调函数并传入false
      status == access.BluetoothState.STATE_OFF && callback(false)
      // 判断蓝牙是否开启，若开启则调用回调函数并传入true
      status == access.BluetoothState.STATE_ON && callback(true)
    })
  }

  // 蓝牙设备扫描
  findBluetoothDecice(callback: (device: ble.ScanResult[]) => void) {
    try {
      ble.startBLEScan(null, {
        interval: 500, // 设置扫描间隔为500ms
        dutyMode: ble.ScanDuty.SCAN_MODE_LOW_POWER, // 设置扫描模式为低功耗模式
        matchMode: ble.MatchMode.MATCH_MODE_AGGRESSIVE // 设置匹配模式为积极模式
      })

      // 初始化设备列表数组
      let deviceList: ble.ScanResult[] = []

      ble.on("BLEDeviceFind", (res: ble.ScanResult[]) => { // 监听蓝牙设备发现事件
        res.forEach((dev: ble.ScanResult) => { // 遍历所有发现的设备
          // 如果设备有名称
          if (dev.deviceName) {
            // 将新设备添加到列表中，避免重复
            deviceList.push(...res.filter(v => !deviceList.some(vv => vv.deviceId === v.deviceId)))
          }
          // 调用回调函数，返回当前设备列表
          callback(deviceList)
        })
      })
    } catch (err) { // 捕获异常
      logger.info(err) // 记录错误信息
    }
  }

  // 蓝牙设备连接
  connectDevice(device: ble.ScanResult, callback: (clientDevice: ble.ScanResult) => void) {
    try {
      // 创建GATT客户端设备实例，传入目标设备的ID
      this.currentClient = ble.createGattClientDevice(device.deviceId)
      // 建立与设备的蓝牙连接
      this.currentClient.connect()
      // 监听蓝牙连接状态变化事件
      this.currentClient.on("BLEConnectionStateChange", (result) => {
        // 判断连接状态是否为已连接
        if (result.state === constant.ProfileConnectionState.STATE_CONNECTED) {
          // 调用回调函数，传入已连接的设备
          callback(device)
        }
      })
    } catch (err) {
      logger.info(err)
    }
  }

  //断开蓝牙设备
  disconnectDevice(callBack: () => void) {
    if (this.currentClient) { // 检查当前是否已连接蓝牙设备
      this.currentClient.disconnect() // 断开与蓝牙设备的连接
      this.currentClient.close(); // 关闭蓝牙客户端资源
      this.currentClient = null // 将当前客户端设为null，表示已断开连接
      callBack() // 调用回调函数，通知断开完成
    }
  }

  //数据发送
  async bluetoothSendMsg(data: BlueData) {
    try {
      // 检查当前是否存在已连接的蓝牙设备
      if (this.currentClient) {
        // 获取蓝牙设备的所有服务列表
        const list = await this.currentClient.getServices()
        // 查找服务UUID以0000AE30开头的服务
        const doorService = list.find(v => v.serviceUuid.startsWith("0000AE30"))
        // 查找特征UUID以0000AE10开头的特征
        const message = doorService?.characteristics.find(v => v.characteristicUuid.startsWith("0000AE10"))
        // 创建文本编码器实例
        const encoder = new util.TextEncoder()
        // 将数据对象编码为Uint8Array
        const u8a = encoder.encodeInto(JSON.stringify(data))

        // 向蓝牙设备发送特征值数据
        await this.currentClient.writeCharacteristicValue({
          serviceUuid: message?.serviceUuid, // 服务UUID
          characteristicUuid: message?.characteristicUuid, // 特征UUID
          characteristicValue: u8a.buffer, // 特征值数据
          descriptors: [], // 描述符列表
        }, ble.GattWriteType.WRITE) // 设置写入类型为WRITE
      }
    } catch (err) {
      logger.info(err)
    }
  }

  //监听特征值变化
  async listenInDeviceDataChange(callBack: (message: number | void) => void) {
    // 检查当前是否存在已连接的蓝牙设备
    if (this.currentClient) {
      // 监听蓝牙特征值变化事件
      this.currentClient?.on("BLECharacteristicChange", (res) => {
        // 创建文本解码器实例
        const decoder = util.TextDecoder.create()
        // 将特征值数据转换为Uint8Array
        const buffer = new Uint8Array(res.characteristicValue)
        // 将二进制数据解码并解析为BlueData对象
        const result = JSON.parse(decoder.decodeToString(buffer)) as BlueData
        // 调用回调函数，传递状态码
        callBack(result.status)
        // 如果命令类型为'wifi'
        if (result.command === 'wifi') {
          // 再次调用回调函数，传递状态码
          callBack(result.status)
        }
      })
      // 获取蓝牙设备的所有服务列表
      const serviceList = await this.currentClient?.getServices()
      // 查找服务UUID以0000AE30开头的服务
      const doorService = serviceList?.find(v => v.serviceUuid.startsWith("0000AE30"))
      // 查找特征UUID以0000AE04开头的特征
      const message = doorService?.characteristics.find(v => v.characteristicUuid.startsWith("0000AE04"))
      // 设置特征值变化通知，启用通知功能
      await this.currentClient?.setCharacteristicChangeNotification(message, true)
    }
  }
}

export const bluetoothManager = new BluetoothManager()

这里每天分享一个 iOS 的新知识，快来关注我吧

前言

作为 App 开发来说，字体在应用中扮演着至关重要的角色。一个精心选择的字体能够让你的应用在众多竞争者中脱颖而出。

但是，无论你选择哪种字体，都必须确保它的核心功能——可读性。

在以前，只有苹果自带的系统字体支持动态调整大小，而自定义字体则不支持。但自从 iOS 11 以来，这种情况已经改变。现在，你可以轻松地在动态字体中使用你的自定义字体。

今天就来讲讲如何在动态字体中使用自定义字体。

什么是动态字体？

苹果早在 iOS 7 时就引入了动态字体，旨在让用户选择他们偏好的文本大小以满足自身需求。

在较大的文本尺寸下，各种文本样式（如 .headline, .subheadline, .body, .footnote, .caption1, .caption2, .largeTitle, .title1, .title2, .title3 和 .callout）的权重、大小和行距值可以参考苹果的人机界面指南 - 动态字体尺寸[1]。

动态字体的实现

动态字体与文本样式一起起作用，文本样式用于为每种文本大小设定缩放因子。例如，.caption2 是最小的文本样式，不会缩小到小于 11 号的大小，因为那样会很难阅读。在最小、小、中和大文本大小下，.caption2 文本样式的大小将保持在 11pt。

要获取动态字体，我们可以使用 UIFont 类方法 preferredFont(forTextStyle:) 来初始化字体。

let label = UILabel()
label.font = UIFont.preferredFont(forTextStyle: .body)
label.adjustsFontForContentSizeCategory = true 

设置 adjustsFontForContentSizeCategory 为 true，可以在设备的内容大小类别更改时自动更新字体。

上面的代码将返回一个苹果 San Francisco 常规字体，大小为 17（大文本尺寸下的 body 样式），以下是大文本大小上的所有文本样式的示例。

调整字体大小

可以通过以下方式更改字体大小：

1. 打开系统设置 - 显示与亮度 - 文字大小。

2. 通过拖动滑块调整字体大小。

调整到更大的字体

通过上边的方法调整字体到一定大小就不能再大了，其实还有办法可以调到更大：

1. 打开设置 - 辅助功能 - 显示与文字大小 - 更大字体。

2. 打开更大字体开关。

3. 通过拖动滑块调整字体大小。

调试阶段修改文本大小

在开发阶段，还可以直接从 Xcode 调整字体。

1. 点击调试栏中的图标 Environment Overrides 按钮.

2. 打开 Dynamic Type 开关.

3. 通过拖动滑块调整字体大小。

使用自定义字体

在 iOS 11 中，苹果引入了 UIFontMetrics，使我们的代码更简单。通过它，我们可以创建指定文本样式的 UIFontMetrics，然后将自定义字体传递给 scaledFont(for:) 方法，以获得基于自定义字体的字体对象，具有适当的样式信息，并自动缩放以匹配当前动态字体设置。

let customFont = UIFont(name: "Merriweather-Regular", size: 17)! // <1>
let label = UILabel()
label.adjustsFontForContentSizeCategory = true
label.font = UIFontMetrics(forTextStyle: .body).scaledFont(for: customFont) // <2>

<1> 我们初始化了自定义字体。在这个例子中，我使用了 Google 字体的 Merriweather 字体。
<2> 我们定义了 UIFontMetrics 的 body 文本样式，然后用它来缩放我们的自定义字体。

支持自定义字体的动态类型

虽然 UIFontMetrics 可以减少我们在支持动态类型的自定义字体上的工作量，但它并不是万能的。有时候我们仍然需要做一些额外的工作。

scaledFont(for:) 方法会根据大文本尺寸的基础字体大小应用缩放因子。苹果在 iOS 人机界面指南中说明了系统字体的字体度量标准。你可以用它作为为每种文本样式定义自定义字体的起始。

以下是我基于苹果度量的简单实现：

let customFonts: [UIFont.TextStyle: UIFont] = [
    .largeTitle: UIFont(name: "Merriweather-Regular", size: 34)!,
    .title1: UIFont(name: "Merriweather-Regular", size: 28)!,
    .title2: UIFont(name: "Merriweather-Regular", size: 22)!,
    .title3: UIFont(name: "Merriweather-Regular", size: 20)!,
    .headline: UIFont(name: "Merriweather-Bold", size: 17)!,
    .body: UIFont(name: "Merriweather-Regular", size: 17)!,
    .callout: UIFont(name: "Merriweather-Regular", size: 16)!,
    .subheadline: UIFont(name: "Merriweather-Regular", size: 15)!,
    .footnote: UIFont(name: "Merriweather-Regular", size: 13)!,
    .caption1: UIFont(name: "Merriweather-Regular", size: 12)!,
    .caption2: UIFont(name: "Merriweather-Regular", size: 11)!
]

extension UIFont {
    class func customFont(forTextStyle style: UIFont.TextStyle) -> UIFont {
        let customFont = customFonts[style]!
        let metrics = UIFontMetrics(forTextStyle: style)
        let scaledFont = metrics.scaledFont(for: customFont)
        
        return scaledFont
    }
}

将 UIFontMetrics(forTextStyle: style).scaledFont(for: customFont) 替换为 UIFont.customFont(forTextStyle: style) 并再次运行即可。

let styles: [UIFont.TextStyle] = [.largeTitle, .title1, .title2, .title3, .headline, .subheadline, .body, .callout, .footnote, .caption1, .caption2]
for style in styles {
    ...
    let label = UILabel()
    label.adjustsFontForContentSizeCategory = true
    label.text = String(describing: style)
    label.font = UIFont.customFont(forTextStyle: style)    
    ...
}

最后看下效果：

结论

UIFontMetrics 可以减少我们在让自定义字体支持动态类型时所需的工作量。另外我们可能需要花一些时间来微调基础字体以确保其在所有变体中都适合，在 UIFontMetrics 的帮助下，这个过程不算负责。

希望这能帮助你更好地在应用中运用自定义字体。关于自定义动态字体，你有什么看法吗？欢迎在评论区中留言交流。

参考资料

[1]

苹果的人机界面指南: developer.apple.com/design/huma…

这里每天分享一个 iOS 的新知识，快来关注我吧

本文同步自微信公众号 “iOS新知”，每天准时分享一个新知识，这里只是同步，想要及时学到就来关注我吧！

OpenGL 学习总结

目录

1. 基础概念

2. 渲染管线

3. 着色器编程

4. 纹理与采样

5. iOS OpenGL ES

6. 实际应用

7. 性能优化

8. 常见问题

---

基础概念

什么是 OpenGL？

OpenGL（Open Graphics Library）是一个跨语言、跨平台的图形渲染 API，用于渲染 2D 和 3D 图形。它提供了一套硬件无关的接口，让开发者能够利用 GPU 进行高效的图形渲染。

核心特点

• 硬件抽象层：屏蔽不同 GPU 的差异

• 状态机：通过设置状态来控制渲染行为

• 立即模式 vs 保留模式：现代 OpenGL 使用保留模式

• 可编程管线：通过着色器程序控制渲染过程

坐标系系统

// OpenGL 使用右手坐标系

// X轴：向右为正

// Y轴：向上为正  

// Z轴：向外为正（屏幕外）

  


// 顶点坐标通常在 [-1, 1] 范围内

let vertices: [Float] = [

    -1.0, -1.0, 0.0,  // 左下

     1.0, -1.0, 0.0,  // 右下

     0.0,  1.0, 0.0   // 顶部

]

---

渲染管线

1. 顶点着色器阶段

// 顶点着色器

attribute vec4 position;

attribute vec2 texCoord;

varying vec2 vTexCoord;

  


void main() {

    gl_Position = position;

    vTexCoord = texCoord;

}

2. 图元装配

• 将顶点连接成图元（点、线、三角形）

• 进行视锥体裁剪

• 背面剔除

3. 光栅化

• 将图元转换为像素

• 插值计算片段的属性

4. 片段着色器阶段

// 片段着色器

precision mediump float;

varying vec2 vTexCoord;

uniform sampler2D uTexture;

  


void main() {

    vec4 color = texture2D(uTexture, vTexCoord);

    gl_FragColor = color;

}

5. 逐片段操作

• 深度测试

• 模板测试

• 混合

---

着色器编程

顶点着色器

// 基础顶点着色器

attribute vec4 aPosition;

attribute vec2 aTexCoord;

uniform mat4 uModelViewProjectionMatrix;

  


varying vec2 vTexCoord;

  


void main() {

    gl_Position = uModelViewProjectionMatrix * aPosition;

    vTexCoord = aTexCoord;

}

片段着色器

// 基础片段着色器

precision mediump float;

  


varying vec2 vTexCoord;

uniform sampler2D uTexture;

uniform float uAlpha;

  


void main() {

    vec4 color = texture2D(uTexture, vTexCoord);

    gl_FragColor = vec4(color.rgb, color.a * uAlpha);

}

常用内置变量

• gl_Position：顶点位置（顶点着色器输出）

• gl_FragColor：片段颜色（片段着色器输出）

• gl_PointSize：点大小

• gl_FragCoord：片段坐标

数据类型

// 标量类型

float, int, bool

  


// 向量类型

vec2, vec3, vec4

ivec2, ivec3, ivec4

bvec2, bvec3, bvec4

  


// 矩阵类型

mat2, mat3, mat4

  


// 采样器类型

sampler2D, samplerCube

---

纹理与采样

纹理创建

func createTexture(from image: UIImage) -> GLuint {

    guard let cgImage = image.cgImage else { return 0 }

    

    var textureName: GLuint = 0

    glGenTextures(1, &textureName)

    glBindTexture(GLenum(GL_TEXTURE_2D), textureName)

    

    // 设置纹理参数

    glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_MIN_FILTER), GL_LINEAR)

    glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_MAG_FILTER), GL_LINEAR)

    glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_WRAP_S), GL_CLAMP_TO_EDGE)

    glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_WRAP_T), GL_CLAMP_TO_EDGE)

    

    // 上传纹理数据

    let width = cgImage.width

    let height = cgImage.height

    let colorSpace = CGColorSpaceCreateDeviceRGB()

    let bitmapInfo = CGBitmapInfo(rawValue: CGImageAlphaInfo.premultipliedLast.rawValue)

    

    let context = CGContext(data: nil,

                           width: width,

                           height: height,

                           bitsPerComponent: 8,

                           bytesPerRow: width * 4,

                           space: colorSpace,

                           bitmapInfo: bitmapInfo.rawValue)!

    

    context.draw(cgImage, in: CGRect(x: 0, y: 0, width: width, height: height))

    

    let data = context.data!

    glTexImage2D(GLenum(GL_TEXTURE_2D), 0, GL_RGBA, GLsizei(width), GLsizei(height), 0, GLenum(GL_RGBA), GLenum(GL_UNSIGNED_BYTE), data)

    

    return textureName

}

纹理坐标

// 纹理坐标 (0,0) 在左下角，(1,1) 在右上角

let texCoords: [Float] = [

    0.0, 0.0,  // 左下

    1.0, 0.0,  // 右下

    0.0, 1.0,  // 左上

    1.0, 1.0   // 右上

]

纹理过滤

// 最近邻过滤

glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_MIN_FILTER), GL_NEAREST)

glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_MAG_FILTER), GL_NEAREST)

  


// 线性过滤

glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_MIN_FILTER), GL_LINEAR)

glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_MAG_FILTER), GL_LINEAR)

  


// 多级纹理过滤

glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_MIN_FILTER), GL_LINEAR_MIPMAP_LINEAR)

glGenerateMipmap(GLenum(GL_TEXTURE_2D))

---

iOS OpenGL ES

初始化

import GLKit

  


class OpenGLView: GLKView {

    private var context: EAGLContext!

    private var program: GLuint = 0

    

    override init(frame: CGRect) {

        // 创建 OpenGL ES 2.0 上下文

        context = EAGLContext(api: .openGLES2)!

        super.init(frame: frame, context: context)

        

        // 设置代理

        self.delegate = self

        

        // 设置像素格式

        self.drawableColorFormat = .RGBA8888

        self.drawableDepthFormat = .format24

        

        // 设置内容缩放因子

        self.contentScaleFactor = UIScreen.main.scale

        

        // 设置当前上下文

        EAGLContext.setCurrent(context)

        

        // 初始化 OpenGL 状态

        setupOpenGL()

    }

    

    private func setupOpenGL() {

        // 启用深度测试

        glEnable(GLenum(GL_DEPTH_TEST))

        

        // 设置清除颜色

        glClearColor(0.0, 0.0, 0.0, 1.0)

        

        // 创建着色器程序

        program = createShaderProgram()

    }

}

渲染循环

extension OpenGLView: GLKViewDelegate {

    func glkView(_ view: GLKView, drawIn rect: CGRect) {

        // 清除缓冲区

        glClear(GLbitfield(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT))

        

        // 使用着色器程序

        glUseProgram(program)

        

        // 设置顶点数据

        setupVertexData()

        

        // 设置纹理

        setupTexture()

        

        // 绘制

        glDrawArrays(GLenum(GL_TRIANGLES), 0, 6)

    }

}

着色器编译

func createShaderProgram() -> GLuint {

    let vertexShaderSource = """

    attribute vec4 position;

    attribute vec2 texCoord;

    varying vec2 vTexCoord;

    

    void main() {

        gl_Position = position;

        vTexCoord = texCoord;

    }

    """

    

    let fragmentShaderSource = """

    precision mediump float;

    varying vec2 vTexCoord;

    uniform sampler2D uTexture;

    

    void main() {

        gl_FragColor = texture2D(uTexture, vTexCoord);

    }

    """

    

    // 编译顶点着色器

    let vertexShader = compileShader(type: GLenum(GL_VERTEX_SHADER), source: vertexShaderSource)

    

    // 编译片段着色器

    let fragmentShader = compileShader(type: GLenum(GL_FRAGMENT_SHADER), source: fragmentShaderSource)

    

    // 创建程序

    let program = glCreateProgram()

    glAttachShader(program, vertexShader)

    glAttachShader(program, fragmentShader)

    glLinkProgram(program)

    

    // 检查链接状态

    var linkStatus: GLint = 0

    glGetProgramiv(program, GLenum(GL_LINK_STATUS), &linkStatus)

    if linkStatus == GL_FALSE {

        print("Program link failed")

        glDeleteProgram(program)

        return 0

    }

    

    // 清理着色器

    glDeleteShader(vertexShader)

    glDeleteShader(fragmentShader)

    

    return program

}

  


func compileShader(type: GLenum, source: String) -> GLuint {

    let shader = glCreateShader(type)

    var cSource = (source as NSString).utf8String

    var length = GLint(source.utf8.count)

    glShaderSource(shader, 1, &cSource, &length)

    glCompileShader(shader)

    

    // 检查编译状态

    var compileStatus: GLint = 0

    glGetShaderiv(shader, GLenum(GL_COMPILE_STATUS), &compileStatus)

    if compileStatus == GL_FALSE {

        var infoLength: GLint = 0

        glGetShaderiv(shader, GLenum(GL_INFO_LOG_LENGTH), &infoLength)

        var infoLog = [GLchar](repeating: 0, count: Int(infoLength))

        glGetShaderInfoLog(shader, infoLength, nil, &infoLog)

        print("Shader compilation failed: \(String(cString: infoLog))")

        glDeleteShader(shader)

        return 0

    }

    

    return shader

}

---

实际应用

图片渲染

class ImageRenderer {

    private var program: GLuint = 0

    private var vertexBuffer: GLuint = 0

    private var texture: GLuint = 0

    

    func setup() {

        // 创建顶点缓冲区

        let vertices: [Float] = [

            // 位置        // 纹理坐标

            -1.0, -1.0, 0.0,  0.0, 0.0,

             1.0, -1.0, 0.0,  1.0, 0.0,

            -1.0,  1.0, 0.0,  0.0, 1.0,

             1.0, -1.0, 0.0,  1.0, 0.0,

             1.0,  1.0, 0.0,  1.0, 1.0,

            -1.0,  1.0, 0.0,  0.0, 1.0

        ]

        

        glGenBuffers(1, &vertexBuffer)

        glBindBuffer(GLenum(GL_ARRAY_BUFFER), vertexBuffer)

        glBufferData(GLenum(GL_ARRAY_BUFFER), MemoryLayout<Float>.size * vertices.count, vertices, GLenum(GL_STATIC_DRAW))

    }

    

    func render() {

        glUseProgram(program)

        

        // 设置顶点属性

        glBindBuffer(GLenum(GL_ARRAY_BUFFER), vertexBuffer)

        

        let positionLocation = glGetAttribLocation(program, "position")

        let texCoordLocation = glGetAttribLocation(program, "texCoord")

        

        glEnableVertexAttribArray(GLuint(positionLocation))

        glEnableVertexAttribArray(GLuint(texCoordLocation))

        

        let stride = GLsizei(MemoryLayout<Float>.size * 5)

        glVertexAttribPointer(GLuint(positionLocation), 3, GLenum(GL_FLOAT), GLboolean(GL_FALSE), stride, nil)

        glVertexAttribPointer(GLuint(texCoordLocation), 2, GLenum(GL_FLOAT), GLboolean(GL_FALSE), stride, UnsafeRawPointer(bitPattern: 3 * MemoryLayout<Float>.size))

        

        // 设置纹理

        glActiveTexture(GLenum(GL_TEXTURE0))

        glBindTexture(GLenum(GL_TEXTURE_2D), texture)

        glUniform1i(glGetUniformLocation(program, "uTexture"), 0)

        

        // 绘制

        glDrawArrays(GLenum(GL_TRIANGLES), 0, 6)

        

        glDisableVertexAttribArray(GLuint(positionLocation))

        glDisableVertexAttribArray(GLuint(texCoordLocation))

    }

}

滤镜效果

// 灰度滤镜

void main() {

    vec4 color = texture2D(uTexture, vTexCoord);

    float gray = dot(color.rgb, vec3(0.299, 0.587, 0.114));

    gl_FragColor = vec4(vec3(gray), color.a);

}

  


// 反色滤镜

void main() {

    vec4 color = texture2D(uTexture, vTexCoord);

    gl_FragColor = vec4(1.0 - color.rgb, color.a);

}

  


// 模糊滤镜

void main() {

    vec2 texelSize = 1.0 / textureSize(uTexture, 0);

    vec4 sum = vec4(0.0);

    

    for(int i = -2; i <= 2; i++) {

        for(int j = -2; j <= 2; j++) {

            vec2 offset = vec2(float(i), float(j)) * texelSize;

            sum += texture2D(uTexture, vTexCoord + offset);

        }

    }

    

    gl_FragColor = sum / 25.0;

}

---

性能优化

1. 批处理

// 合并多个绘制调用

func batchRender(objects: [GameObject]) {

    // 按材质分组

    let groupedObjects = Dictionary(grouping: objects) { $0.material }

    

    for (material, objects) in groupedObjects {

        // 绑定材质

        bindMaterial(material)

        

        // 批量绘制

        for object in objects {

            updateTransform(object.transform)

            drawObject(object)

        }

    }

}

2. 顶点缓冲区优化

// 使用 VBO 存储顶点数据

func createVertexBuffer() {

    let vertices: [Float] = [/* 顶点数据 */]

    

    glGenBuffers(1, &vertexBuffer)

    glBindBuffer(GLenum(GL_ARRAY_BUFFER), vertexBuffer)

    glBufferData(GLenum(GL_ARRAY_BUFFER), MemoryLayout<Float>.size * vertices.count, vertices, GLenum(GL_STATIC_DRAW))

}

3. 纹理优化

// 使用纹理图集

func createTextureAtlas() {

    // 将多个小纹理合并到一个大纹理中

    // 减少纹理切换次数

}

  


// 使用压缩纹理

func loadCompressedTexture() {

    // 使用 PVRTC 或 ASTC 格式

    // 减少内存占用和带宽

}

4. 着色器优化

// 避免分支语句

// 不好的做法

if (condition) {

    color = texture2D(tex1, coord);

} else {

    color = texture2D(tex2, coord);

}

  


// 好的做法

color = mix(texture2D(tex1, coord), texture2D(tex2, coord), condition ? 1.0 : 0.0);

  


// 使用内置函数

// 不好的做法

float length = sqrt(x * x + y * y);

  


// 好的做法

float length = length(vec2(x, y));

---

常见问题

1. 纹理显示问题

问题：纹理显示为黑色或白色

原因：

• 纹理数据格式不匹配

• 纹理坐标错误

• 采样器设置问题

解决：

// 检查纹理格式

glTexImage2D(GLenum(GL_TEXTURE_2D), 0, GL_RGBA, width, height, 0, GLenum(GL_RGBA), GLenum(GL_UNSIGNED_BYTE), data)

  


// 检查纹理坐标

let texCoords: [Float] = [0.0, 0.0, 1.0, 0.0, 0.0, 1.0, 1.0, 1.0]

  


// 设置正确的采样器

glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_MIN_FILTER), GL_LINEAR)

glTexParameteri(GLenum(GL_TEXTURE_2D), GLenum(GL_TEXTURE_MAG_FILTER), GL_LINEAR)

2. 深度测试问题

问题：物体渲染顺序错误

解决：

// 启用深度测试

glEnable(GLenum(GL_DEPTH_TEST))

glDepthFunc(GLenum(GL_LESS))

  


// 清除深度缓冲区

glClear(GLbitfield(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT))

3. 内存泄漏

问题：OpenGL 资源未正确释放

解决：

deinit {

    // 释放纹理

    if texture != 0 {

        glDeleteTextures(1, &texture)

    }

    

    // 释放缓冲区

    if vertexBuffer != 0 {

        glDeleteBuffers(1, &vertexBuffer)

    }

    

    // 释放着色器程序

    if program != 0 {

        glDeleteProgram(program)

    }

}

4. 性能问题

问题：渲染性能低下

解决：

• 减少绘制调用次数

• 使用批处理

• 优化着色器

• 使用 LOD（细节层次）

• 启用背面剔除

---

调试技巧

1. 着色器调试

// 在片段着色器中输出调试信息

void main() {

    vec4 color = texture2D(uTexture, vTexCoord);

    

    // 输出红色通道作为调试

    gl_FragColor = vec4(color.r, 0.0, 0.0, 1.0);

}

2. 状态检查

func checkOpenGLState() {

    // 检查帧缓冲区状态

    let status = glCheckFramebufferStatus(GLenum(GL_FRAMEBUFFER))

    if status != GLenum(GL_FRAMEBUFFER_COMPLETE) {

        print("Framebuffer not complete: \(status)")

    }

    

    // 检查着色器编译状态

    var compileStatus: GLint = 0

    glGetShaderiv(shader, GLenum(GL_COMPILE_STATUS), &compileStatus)

    if compileStatus == GL_FALSE {

        // 获取错误信息

        var infoLength: GLint = 0

        glGetShaderiv(shader, GLenum(GL_INFO_LOG_LENGTH), &infoLength)

        var infoLog = [GLchar](repeating: 0, count: Int(infoLength))

        glGetShaderInfoLog(shader, infoLength, nil, &infoLog)

        print("Shader compilation failed: \(String(cString: infoLog))")

    }

}

3. 性能分析

// 使用 Instruments 进行性能分析

// 关注以下指标：

// - GPU 使用率

// - 绘制调用次数

// - 纹理内存使用

// - 顶点处理数量

---

总结

OpenGL 是一个强大的图形渲染 API，掌握它需要：

1. 理解渲染管线：从顶点到像素的完整流程

2. 掌握着色器编程：GLSL 语言和 GPU 编程

3. 熟悉纹理系统：纹理创建、采样和过滤

4. 学会性能优化：批处理、内存管理、算法优化

5. 掌握调试技巧：状态检查、错误处理、性能分析

通过持续学习和实践，OpenGL 将成为你图形编程的强大工具。记住：

• 从简单开始，逐步增加复杂度

• 重视性能优化

• 养成良好的调试习惯

• 关注最新的 OpenGL 特性和最佳实践

前言

书接上文AppStore的肃清了没有备案的产品，后台很多留言询问怎么样可以不备案？

好好好，想卡Bug，又不想花钱，还不想有风险？

行吧，参考了很多资料和证明咨询了AppStore，终于找出来一条免备案的骚操作。

如何操作？

No1. 需要从AppStore开发者后台，向苹果审核团队发起审核相关的疑问。

No2. 耐心等待审核团队邮件，如实提供资料。

No3. 免责声明。

尊敬的审核团队：

   你好，非常感谢您给我提供这样一个回复的机会。
   兹证明Apple ID：xxxxxx@qq.com，持有人为xxx，我申请的免备案AppleID为：xxxxxx，
   Bundle ID：com.xxxxxx.xxxx.xxx
身份证号码为：xxxxxxxxxxx，居住地址为：xxx省xxxx市xxx区xxx路xxx号xxx小区xxx栋xxxx-xxx。
   
   具体参考资料，请查看身份证正面和背面的照片。为了证明我是账号持有人，我还将额外提供户籍信息、居住地缴费清单，来确保我的身份真实有效。
   正面：【附图】
   背面：【附图】
   户口本：【附图】
   水费、电费：【附图】
   
   本人郑重承诺，以上所有信息真实有效，如有任何欺瞒审核团队或虚假资料本人愿意承担任何法律责任，承担一切法律后果。
   
   持有签字：xxxx 【手印】
   签字日期：xxxx年xx月xx日

因为对于国内开发者信上海是苹果的话事人，所以不需要担心语言沟通问题。

⚠️关于免责声明的内容，仅供参考。总之，要尽可能多得向苹果提供有效资料。提交之后，就是耐心等待结果。

最终效果

如果开发者邮箱收到苹果新消息，那么恭喜你已经成功跳过来备案要求。

特别说明

因为本文示例产品为单机应用，类目属于工具类。只是用了AppStore内购相关的API，其他不需要任何网络请求。所以，需要联网的产品未必适用本文内容。

遵守规则，方得长治久安，最后祝大家大吉大利，今晚过审！

相关推荐

# Pingpong和连连的平替，让AppStore收款无需新增持有人。

# 苹果加急审核是“绿色通道”还是“死亡陷阱”？

# 苹果开发者邮箱，突然收到11.2通知严重么？

# 不想被苹果卡审最好错开这两个提审时间

# 手撕苹果审核4.3是代码问题还是设计问题？

# 有幸和Appstore审核人员进行了一场视频会议特此记录。

知识星球

更多Appstore咨询问题，请关注知识星球。「提供1v1上架指导，帮助开发者解决Appstore的疑难杂症，助力每一位开发者！」。

目录

1. 创建flutter项目
2. 国际化：l10n 带来的不仅是翻译
3. 路由：为什么选 go_router？
4. 状态管理：Cubit + Bloc + Repository 分层模型
5. 错误提示策略：SnackbarMessage
6. 资源管理：flutter_gen 的价值
7. 调试与可观测性

---

在开发一个 Flutter 应用时，通常需要考虑以下几个方面：

• 国际化（i18n）：支持多语言，提升用户体验；
• 状态管理：管理页面之间或组件之间的数据状态；
• 资源引入：如图片、字体等静态资源的管理与使用；
• 路由管理：实现页面跳转和导航逻辑；
• 用户状态切换：处理未登录到已登录状态的转变；
• 错误提示机制：如登录失败时的错误反馈展示。

本文将以一个 Instagram 登录页为例，从 0 开始搭建一个 Flutter 项目，逐步实现上述功能，构建一个可持续开发的项目架构。本文完整代码：github.com/wutao23yzd/… 中的Demo5，效果如下:

1.创建flutter项目

创建flutter项目，采用very_good_cli，（pub.dev/packages/ve… 创建 Flutter 项目的好处在于，它提供了规范化的项目结构、严格的代码分析规则、内建测试和 CI 支持，帮助开发者快速搭建高质量、可维护的应用，特别适合团队协作和企业级项目开发。通过如下指令，可以创建一个指定组织名和包名的flutter应用

very_good create flutter_app flutter_instagram_clone_app --org "com.flutter” --application-id "com.flutter.futter_instagram_clone"

---

2. 国际化 (l10n)

l10n 是 “localization” 的缩写（l + 10个字母 + n），即“本地化/国际化”。very_good_cli创建好项目后，会自动生成国际化相关文件，但没有中文，可以这样子添加:

• 在 pubspec.yaml 中确保已经添加了 flutter_localizations 依赖。
• 在 l10n.yaml 配置文件中添加中文（zh）支持。

# 添加中文支持
preferred-supported-locales:
  - en
  - zh

• 在 arb 目录下添加中文的 ARB 文件（如 app_localizations_zh.arb），并翻译内容
• 添加新的文案时，使用flutter gen-l10n 重新生成本地化代码。

3. 路由：为什么选 go_router

路由使用go_routter （pub.dev/packages/go… 是 Flutter 官方推荐的路由管理库，，支持嵌套路由、参数传递、URL 同步、重定向和导航守卫等高级功能。相比传统的 Navigator，它结构更清晰、代码更简洁，而且支持基于用户登录状态的路由重定向逻辑，比如登录、登出，可以通过如下代码跳转:

  redirect: (context, state) {
      final authenticated = appBloc.state.status == AppStatus.authenticated;
      final authenticating = state.matchedLocation == AppRoutes.auth.route;

      if (!authenticated) return AppRoutes.auth.route;
      if (authenticating && authenticated) return AppRoutes.home.route;

      return null;
  }

---

4. 状态管理：Cubit + Bloc + Repository 分层模型

在 Flutter 项目中，采用 Cubit + Bloc + Repository 的分层模型 是一种清晰、可维护性强的架构设计。它将业务逻辑、状态管理和数据访问进行职责分离（pub.dev/packages/bl…

• Repository 层负责与数据源（如 API、数据库、缓存）交互，提供统一的数据获取接口。
• Bloc/Cubit 层负责管理状态和业务逻辑，从 Repository 获取数据并根据用户行为更新状态。
• **UI 层（Widget）**只关心状态展示，通过监听 Bloc/Cubit 提供的状态流进行响应式更新。

在提供的Demo中，AuthRepository 统一产出 用户身份流，任何需要身份信息的层（AppBloc）都只订阅这一个来源。

class App extends StatelessWidget {
  const App({super.key});

  @override
  Widget build(BuildContext context) {
    return RepositoryProvider(
      // 全局唯一的数据层
      create: (_) => AuthRepository(),
      child: BlocProvider(
        create: (context) => AppBloc(
          authRepository: context.read<AuthRepository>(),
        ),
        child: const AppView(),
      ),
    );
  }
}

• 在app.dart 顶层依赖注入，暴露一个Stream表示全局身份状态。
• LoginCubit 只负责表单状态与调用 AuthRepository.login
• AppBloc 只订阅 AuthRepository.user，再映射成 authenticated / unauthenticated。

这样 UI ↔︎ 业务 ↔︎ 数据 的依赖方向清晰且单向。

---

5. 错误提示策略：SnackbarMessage 队列化

使用BlocListener<LoginCubit, LoginState>监听当前状态，如果出现错误，则顶部弹出提示；使用clearIfQueue 清除旧消息 。

BlocListener<LoginCubit, LoginState>(
  listenWhen: (p, c) => p.status != c.status && c.status.isError,
  listener: (_, s) => openSnackbar(
    SnackbarMessage.error(title: '错误', description: s.message!),
    clearIfQueue: true,
  ),
  child: const LoginForm(),
);

---

6. 资源管理：flutter_gen 的价值

首先要要安装flutter_gen 依赖，同时在dev_dependencies中，需要安装

build_runner: ^2.5.4
flutter_gen_runner: ^5.10.0

对于svg的文件，还需要安装依赖flutter_svg；然后按照demo中所示，在pubspec.yaml中提供资源所示路径；最后，执行dart run build_runner build自动生成assets.gen.dart 文件，引用资源文件如下所示：

Image.asset(Assets.images.logoPng.path);
FontFamily(Assets.fonts.montserrat);  // 类型安全 + IDE 自动补全

• 不再担心路径拼写错误
• 对 Lottie / SVG 同样适用

---

7. 调试与可观测性

class AppBlocObserver extends BlocObserver {
  @override
  void onChange(BlocBase bloc, Change change) =>
      log('[Bloc] ${bloc.runtimeType} $change');
}

• 实时跟踪 Bloc / Cubit 状态变迁
• Flutter DevTools：开启 “Enhance tracing for user widgets”

---

写在最后
Demo大量代码使用了www.youtube.com/watch?v=xr5…

1. 有两个observer会监听runloop两个事件，一个observer监听runloop要进入的是时候entry，会调用pool push方法创建一个autorelease pool

2. 另一个observer监听runloop的状态，当runloop要进入休眠状态时beforewaiting，会pop一个自动释放池，同时push创建一个新的自动释放池。

3. AutoreleasePoolPage 结构

   class AutoreleasePoolPage
   {
   const magic
   id *next 指向下一个可以存放被释放对象的地址
   pthread_t const thread 当前所在的线程
   AutoreleasePoolPage *const parent 当前page的父节点
   AutoreleasePoolPage *child
   
   
   }
   

4. 每个page占4096个字节也就是4kb，自身成员变量只占56个字节，也就是7个成员变量，每个成员变量占8个字节。其他四千多个字节都是用来存放被autorelease修饰的对象内存地址。

5. pool_boundary的作用是区分不同自动释放，调用push时，会传入一个pool_boundary并返回一个地址，这个地址不存储@autorelease对象的地址，起到一个标识作用，用来分隔不同的autoreleasepool

6. 调用pop的时候，会传入end地址，从后到前调用对象的release方法，直到pool_boundary为止。

7. 如果存在多个page，会从child的page最末尾开始调用，直到pool_boundary

8. page是一个栈结构，释放是从栈顶开始

9. 多层嵌套会共用一个page，通过pool_boundary来分隔，优先释放在里层的pool，因为最里层的pool中的对象被放倒了栈顶，优先释放栈顶对象。

   @autoreleasepool {
        NSObject *p1 = [[NSObject alloc] init]
        NSObject *p2 = [[NSObject alloc] init]
             @autoreleasepool {
                    NSObject *p3 = [[NSObject alloc] init]
                           @autoreleasepool{
                                  NSObject *p4 = [[NSObject alloc] init]
   }
   }
   }
   

1. 释放时机：如果通过代码添加一个autoreleasepool，在作用域结束时，随着pool的释放，就会释放pool中的对象，这种情况是几十释放的，并不依赖于runloop。另一个就是系统自动释放的，系统会在runloop开始的时候创建一个pool，结束的时候会对pool中对象执行release操作。
2. autoreleasepool 和 runloop的关系