iOS 17 之后，SwiftUI 迎来了一个非常关键但又容易被低估的 API —— .visualEffect。

如果你曾经在 ScrollView 里被 GeometryReader 折磨过，那这篇文章基本可以当作你的“解放指南”。

---

一、.visualEffect 是什么？

一句话概括：

.visualEffect 是一个“不参与布局、只在最终渲染阶段生效”的视觉修饰器。

它允许你：

• 拿到视图在屏幕中的真实几何位置
• 根据滚动位置 / 距离中心点 / 是否即将离屏
• 对视图做 缩放、模糊、位移、透明度 等视觉变化

👉 非常适合用来实现 系统级滚动动效。

---

二、API 结构与核心签名

.visualEffect { content, geometryProxy in
    content
}

参数说明：

• content：原始 View
• geometryProxy：视图最终渲染后的几何信息
• 返回值：一个新的 View（只影响视觉，不影响布局）

---

三、为什么它能“替代” GeometryReader？

1️⃣ 传统 GeometryReader 的问题

GeometryReader { geo in
    let y = geo.frame(in: .global).minY
    Text("Hello")
}
.frame(height: 100)

常见问题：

• 会参与布局，影响父视图尺寸
• 在 ScrollView 中容易引发布局异常
• 性能与可维护性都不理想

---

2️⃣ .visualEffect 的优势

对比项	GeometryReader	visualEffect
是否参与布局	✅ 是	❌ 否
是否影响尺寸	会	不会
滚动性能	一般	很好
系统推荐	❌	✅

结论：能用 .visualEffect 的地方，基本不该再用 GeometryReader。

---

四、Demo 1：滚动缩放（最经典）

效果

• Cell 越靠近屏幕中心 → 越大
• 离中心越远 → 缩小

示例代码

ScrollView {
    VStack(spacing: 40) {
        ForEach(0..<20) { index in
            Text("Item (index)")
                .font(.largeTitle)
                .frame(maxWidth: .infinity)
                .padding()
                .background(.blue.opacity(0.2))
                .visualEffect { content, geo in
                    let minY = geo.frame(in: .global).minY
                    let scale = max(0.85, 1 - abs(minY) / 1000)

                    return content.scaleEffect(scale)
                }
        }
    }
}

---

五、Demo 2：滚动模糊（系统级质感）

使用场景

• 卡片列表
• 背景元素
• 音乐 / 专辑封面

.visualEffect { content, geo in
    let y = geo.frame(in: .scrollView).minY
    let blur = min(abs(y) / 40, 12)

    return content.blur(radius: blur)
}

---

六、Demo 3：视差位移（Parallax）

.visualEffect { content, geo in
    let y = geo.frame(in: .global).minY

    content.offset(y: -y * 0.2)
}

常见于：

• Banner
• 大图 Header
• Apple Music / App Store 首页

---

七、Demo 4：缩放 + 透明度（App Store 风格）

.visualEffect { content, geo in
    let frame = geo.frame(in: .scrollView)
    let distance = abs(frame.midY - 300)
    let scale = max(0.85, 1 - distance / 1000)

    return content
            .scaleEffect(scale)
            .opacity(scale)
}

---

八、.visualEffect vs .scrollTransition

.scrollTransition { content, phase in
    content.scaleEffect(phase.isIdentity ? 1 : 0.9)
}

对比项	visualEffect	scrollTransition
几何自由度	⭐⭐⭐⭐⭐	⭐⭐
API 简洁度	⭐⭐⭐	⭐⭐⭐⭐⭐
是否仅限滚动	❌	✅

scrollTransition 是封装好的方案，visualEffect 是底层利器。

---

九、使用时的注意事项

1️⃣ 只做“视觉处理”

不要在 .visualEffect 中：

• 修改状态
• 触发网络请求
• 写业务逻辑

---

2️⃣ 坐标空间要选对

.global        // 全局屏幕
.scrollView    // 推荐：滚动容器
.local         // 本地

👉 滚动相关效果，优先使用 .scrollView

---

十、总结

SwiftUI 布局完成 → .visualEffect 介入 → 最终视觉变换

你可以把它理解为：

“官方支持、不破坏布局的 GeometryReader + Transform”

---

如果你觉得这篇文章有帮助

欢迎 👍 / 收藏 / 评论交流

1. 为什么需要 async/await

在移动开发里，“并发/异步”几乎无处不在：网络请求、图片下载、文件读写、数据库操作……它们都有一个共同特点：

• 耗时（如果你在主线程里死等，会卡 UI）
• 结果稍后才回来（你必须用某种方式“拿到结果”）

传统的并发模型大多是“回调式”的：用 completion、delegate、通知等在未来某个时间点把结果交还给你。 这套方案能跑，但会带来两个典型挑战（你参考资料里也点出来了）：

1. 代码维护性差：异步回调让代码阅读“跳来跳去”，不线性
2. 容易出现数据竞争（Data Races）：共享可变状态在并发下很容易出 Bug，而且难复现、难排查

Swift 从 5.5 开始引入新并发框架，async/await 先解决第一个核心痛点：让异步代码看起来像同步代码一样顺畅，并且把错误处理变得更自然。

---

2. 先复习 4 个基础概念

2.1 同步 vs 异步（描述“函数怎么返回”）

• 同步（Synchronous）：函数执行完才返回 例子：let x = add(1, 2)，拿到结果才能往下走
• 异步（Asynchronous）：函数把任务“丢出去”，结果以后再给你 所以你必须用 completion / delegate / async/await 等方式拿结果

2.2 串行 vs 并行/并发（描述“一组任务怎么跑”）

• 串行（Serial）：一次只执行一个任务，完成一个再下一个
• 并发/并行（Concurrent/Parallel）：同一段时间内可能执行多个任务 （本文不严格区分并发与并行；你只要知道：会“同时处理多个任务”就行）

---

3. 回调式异步的典型痛点：回调地狱 + 错误处理难看

用“头像加载”来说明： 步骤：拿 URL → 下载数据（加密）→ 解密 → 解码成图片

3.1 回调地狱（Callback Hell）

class AvatarLoader {
    func loadAvatar(token: String, completion: @escaping (UIImage) -> Void) {
        fetchAvatarURL(token: token) { url in
            self.fetchAvatar(url: url) { data in
                self.decryptAvatar(data: data) { data in
                    self.decodeImage(data: data) { image in
                        completion(image)
                    }
                }
            }
        }
    }

    func fetchAvatarURL(token: String, completion: @escaping (String) -> Void) { /* ... */ }
    func fetchAvatar(url: String, completion: @escaping (Data) -> Void) { /* ... */ }
    func decryptAvatar(data: Data, completion: @escaping (Data) -> Void) { /* ... */ }
    func decodeImage(data: Data, completion: @escaping (UIImage) -> Void) { /* ... */ }
}

阅读体验像在“走迷宫”：你要不停地进回调、出回调，脑子要同时记住很多上下文。

3.2 错误处理会让代码更糟

异步回调常见的写法是 completion(value, error) 或者 Result。 但在多层嵌套里，错误传递会越来越啰嗦，漏掉某个分支的 completion 也很常见。

---

4. async/await 的核心：把“异步代码”写成“线性代码”

4.1 先看效果：一眼就能读懂

class AvatarLoader {
    func loadAvatar(token: String) async throws -> UIImage {
        let url = try await fetchAvatarURL(token: token)
        let encryptedData = try await fetchAvatar(url: url)
        let decryptedData = try await decryptAvatar(data: encryptedData)
        return try await decodeImage(data: decryptedData)
    }

    func fetchAvatarURL(token: String) async throws -> String { /* ... */ }
    func fetchAvatar(url: String) async throws -> Data { /* ... */ }
    func decryptAvatar(data: Data) async throws -> Data { /* ... */ }
    func decodeImage(data: Data) async throws -> UIImage { /* ... */ }
}

你会发现：

• 代码像同步一样从上到下执行（“直线式”）
• 错误处理回到了熟悉的 throws + try + do/catch
• 逻辑清晰、可维护性大幅提升

---

5. 语法规则：你只需要掌握这 3 条

5.1 async：声明“这个函数可能会挂起”

func fetch() async -> Int { 42 }

含义：它是“异步函数”，执行过程中可能暂停（挂起），等待某些事情完成（比如网络返回、IO 完成）。

5.2 await：调用 async 函数时必须写

let value = await fetch()

await 表示：这里是一个潜在挂起点（potential suspension point）。 意思是：运行到这里，可能会“先停一下”，等结果准备好再继续往下走。

5.3 await 只能出现在“异步上下文”里

异步上下文主要有两类：

1. async 函数体内部
2. Task 闭包内部

---

6. 一个关键认知：挂起的是“函数”，不是“线程”

这是很多新手最容易误解的地方：

• await 不是“把当前线程卡住等待”
• 它是“把当前函数挂起”，让出执行权
• 等条件满足后，再恢复执行（恢复时可能换了线程）

你可以把它想象成：

你在排队取号（await），你人可以先离开去做别的（线程去执行别的任务），等叫到你号了你再回来继续办理（函数恢复执行）。

结论：在 async/await 的世界里，别强依赖“我现在一定在某个线程上”。

---

7. 为什么“锁 + await”容易出事：一个经典坑

一个很典型的示例：

let lock = NSLock()

func test() async {
    lock.lock()
    try? await Task.sleep(nanoseconds: 1_000_000_000)
    lock.unlock()
}

for _ in 0..<10 {
    Task { await test() }
}

问题在哪里？

• 在 lock.lock() 后遇到了 await
• 函数可能挂起并发生线程切换
• 其他任务也想拿锁，但锁可能被“拿着不放”
• 结果就是：很容易出现死锁/饥饿等难排查问题

经验法则：

不要在持有锁的期间跨过 await。 如果你需要保护共享可变状态，优先考虑 actor或让状态只在单一执行上下文里修改。

---

8. 真正能上手的代码：用 URLSession 写一个 async 网络请求

iOS 15+（Swift 5.5+）开始，URLSession 已经提供了 async API，例如：

let (data, response) = try await URLSession.shared.data(from: url)

我们做一个“获取用户信息”的示例（包含错误处理）：

8.1 定义模型与错误

import Foundation

struct User: Decodable {
    let id: Int
    let name: String
}

enum NetworkError: Error {
    case invalidURL
    case invalidResponse
    case httpStatus(Int)
}

8.2 写一个 async 网络层

final class APIClient {
    func fetchUser(id: Int) async throws -> User {
        guard let url = URL(string: "https://example.com/users/\(id)") else {
            throw NetworkError.invalidURL
        }

        let (data, response) = try await URLSession.shared.data(from: url)

        guard let http = response as? HTTPURLResponse else {
            throw NetworkError.invalidResponse
        }
        guard (200...299).contains(http.statusCode) else {
            throw NetworkError.httpStatus(http.statusCode)
        }

        return try JSONDecoder().decode(User.self, from: data)
    }
}

这一段代码的阅读体验就是“同步式”的：构建 URL → await 拿数据 → 校验 → decode。

---

9. 在 UIViewController 里怎么调用 async 并更新 UI？

这是 iOS 开发里最常见的落地问题：

async 方法不能直接在普通函数里 await，那我怎么从按钮点击里发请求？

答案：用 Task { } 把它放进异步上下文里。

9.1 示例：点击按钮加载用户并刷新 label

import UIKit

final class UserViewController: UIViewController {

    private let api = APIClient()
    private let label = UILabel()

    override func viewDidLoad() {
        super.viewDidLoad()
        view.backgroundColor = .white

        label.numberOfLines = 0
        label.frame = CGRect(x: 20, y: 100, width: 320, height: 200)
        view.addSubview(label)

        loadUser()
    }

    private func loadUser() {
        // 进入异步上下文
        Task { [weak self] in
            guard let self else { return }

            do {
                let user = try await api.fetchUser(id: 1)

                // 更新 UI：回到主线程（MainActor）
                await MainActor.run {
                    self.label.text = "用户：\(user.name)\nID：\(user.id)"
                }

            } catch {
                await MainActor.run {
                    self.label.text = "加载失败：\(error)"
                }
            }
        }
    }
}

你只要记住一句话就够了：

• 耗时工作放在 Task 里 await
• UI 更新放在 MainActor（主线程语义）里做

---

10. 从旧代码迁移：把 completion 回调包装成 async

很多项目里已经有大量回调式 API，你不可能一夜之间全改掉。Swift 提供了“续体（Continuation）”做桥接。

10.1 假设你有旧接口

final class LegacyService {
    func fetchText(completion: @escaping (Result<String, Error>) -> Void) {
        DispatchQueue.global().asyncAfter(deadline: .now() + 1) {
            completion(.success("hello async/await"))
        }
    }
}

10.2 用 withCheckedThrowingContinuation 包装

extension LegacyService {
    func fetchText() async throws -> String {
        try await withCheckedThrowingContinuation { continuation in
            fetchText { result in
                switch result {
                case .success(let text):
                    continuation.resume(returning: text)
                case .failure(let error):
                    continuation.resume(throwing: error)
                }
            }
        }
    }
}

10.3 使用方式

Task {
    do {
        let text = try await LegacyService().fetchText()
        print(text)
    } catch {
        print("error:", error)
    }
}

---

11. 入门阶段的最佳实践清单

1. 不要在持锁期间跨 await（容易死锁/逻辑卡住）
2. UI 更新统一回到 MainActor（避免主线程问题）
3. 能用 throws 就别用 Optional+error 乱传：错误路径更清晰
4. 从入口处就结构化：async 函数调用 async 函数，别层层回调
5. 迁移旧代码用 Continuation：逐步改，不要一次性重构到崩

---

12. 小结

到这里，你已经具备了 async/await 的“可用级理解”：

• async：这个函数可能挂起
• await：潜在挂起点，只能在异步上下文使用
• async/await 让异步代码“线性可读”，错误处理回到 throws
• 挂起的是函数，不是线程；await 前后可能换线程
• iOS 里用 Task {} 进入异步上下文，用 MainActor 更新 UI
• 旧回调接口可以用 withCheckedThrowingContinuation 平滑迁移

---

概述

在 Objective-C 开发中，协议（Protocol）是实现接口抽象和多态的重要机制。然而，编译器对协议实现的检查有时存在局限性，特别是在动态运行时和复杂的继承关系中。本文将介绍一个完整的协议一致性检查解决方案，涵盖基础实现、功能扩展。

完整代码

// ProtocolConformanceChecker.h
#import <Foundation/Foundation.h>

NS_ASSUME_NONNULL_BEGIN

@interface ProtocolConformanceChecker : NSObject

/**
 验证对象是否完整实现了指定协议

 @param objc 要验证的对象
 @param protocol 要验证的协议
 @param checkOptionalMethods 是否检查可选方法
 @param checkClassMethods 是否检查类方法
 */
+ (void)assertObjC:(id)objc
  conformsToProtocol:(Protocol *)protocol
checkOptionalMethods:(BOOL)checkOptionalMethods
  checkClassMethods:(BOOL)checkClassMethods;

@end

NS_ASSUME_NONNULL_END

// ProtocolConformanceChecker.m
#import "ProtocolConformanceChecker.h"
#import <objc/runtime.h>

@interface _ProtocolMethodInfo : NSObject
@property (nonatomic, copy) NSString *methodName;
@property (nonatomic, copy) NSString *typeEncoding;
@property (nonatomic, assign) BOOL isRequired;
@property (nonatomic, assign) BOOL isInstanceMethod;
@end

@implementation _ProtocolMethodInfo
@end

@implementation ProtocolConformanceChecker

#pragma mark - 主验证方法

+ (void)assertObjC:(id)objc
  conformsToProtocol:(Protocol *)protocol
checkOptionalMethods:(BOOL)checkOptionalMethods
  checkClassMethods:(BOOL)checkClassMethods {

    // 1. 获取所有需要检查的方法
    NSArray<_ProtocolMethodInfo *> *allMethods =
        [self getAllMethodsForProtocol:protocol
                  checkOptionalMethods:checkOptionalMethods
                    checkClassMethods:checkClassMethods];

    // 2. 验证每个方法的实现
    NSMutableArray<NSString *> *unconformsMethods = [NSMutableArray array];

    for (_ProtocolMethodInfo *methodInfo in allMethods) {
        if (![self object:objc implementsMethod:methodInfo]) {
            NSString *methodDesc = [self formatMethodDescription:methodInfo];
            [unconformsMethods addObject:methodDesc];
        }
    }

    // 3. 报告验证结果
    [self reportValidationResultForObject:objc
                      unconformsMethods:unconformsMethods];
}

#pragma mark - 私有辅助方法

+ (NSArray<_ProtocolMethodInfo *> *)getAllMethodsForProtocol:(Protocol *)protocol
                                        checkOptionalMethods:(BOOL)checkOptionalMethods
                                          checkClassMethods:(BOOL)checkClassMethods {

    NSMutableArray<_ProtocolMethodInfo *> *allMethods = [NSMutableArray array];

    // 获取必需方法
    [allMethods addObjectsFromArray:
        [self getMethodsForProtocol:protocol
                         isRequired:YES
                  checkClassMethods:checkClassMethods]];

    // 获取可选方法（如果需要）
    if (checkOptionalMethods) {
        [allMethods addObjectsFromArray:
            [self getMethodsForProtocol:protocol
                             isRequired:NO
                      checkClassMethods:checkClassMethods]];
    }

    return [allMethods copy];
}

+ (NSArray<_ProtocolMethodInfo *> *)getMethodsForProtocol:(Protocol *)protocol
                                             isRequired:(BOOL)isRequired
                                      checkClassMethods:(BOOL)checkClassMethods {

    NSMutableArray<_ProtocolMethodInfo *> *methods = [NSMutableArray array];

    // 获取当前协议的方法
    [methods addObjectsFromArray:
        [self getMethodsForSingleProtocol:protocol
                               isRequired:isRequired
                        checkClassMethods:checkClassMethods]];

    // 递归获取继承协议的方法
    unsigned int protocolListCount;
    Protocol * __unsafe_unretained _Nonnull * _Nullable protocols =
        protocol_copyProtocolList(protocol, &protocolListCount);

    for (unsigned int i = 0; i < protocolListCount; i++) {
        [methods addObjectsFromArray:
            [self getMethodsForProtocol:protocols[i]
                             isRequired:isRequired
                      checkClassMethods:checkClassMethods]];
    }

    if (protocols) free(protocols);

    return [methods copy];
}

+ (NSArray<_ProtocolMethodInfo *> *)getMethodsForSingleProtocol:(Protocol *)protocol
                                                   isRequired:(BOOL)isRequired
                                            checkClassMethods:(BOOL)checkClassMethods {

    NSMutableArray<_ProtocolMethodInfo *> *methods = [NSMutableArray array];

    // 检查实例方法
    unsigned int instanceMethodCount;
    struct objc_method_description *instanceMethodDescriptions =
        protocol_copyMethodDescriptionList(protocol,
                                         isRequired,
                                         YES,  // 实例方法
                                         &instanceMethodCount);

    for (unsigned int i = 0; i < instanceMethodCount; i++) {
        _ProtocolMethodInfo *info = [_ProtocolMethodInfo new];
        info.methodName = NSStringFromSelector(instanceMethodDescriptions[i].name);
        info.typeEncoding = [NSString stringWithUTF8String:instanceMethodDescriptions[i].types];
        info.isRequired = isRequired;
        info.isInstanceMethod = YES;
        [methods addObject:info];
    }

    if (instanceMethodDescriptions) free(instanceMethodDescriptions);

    // 检查类方法（如果需要）
    if (checkClassMethods) {
        unsigned int classMethodCount;
        struct objc_method_description *classMethodDescriptions =
            protocol_copyMethodDescriptionList(protocol,
                                             isRequired,
                                             NO,  // 类方法
                                             &classMethodCount);

        for (unsigned int i = 0; i < classMethodCount; i++) {
            _ProtocolMethodInfo *info = [_ProtocolMethodInfo new];
            info.methodName = NSStringFromSelector(classMethodDescriptions[i].name);
            info.typeEncoding = [NSString stringWithUTF8String:classMethodDescriptions[i].types];
            info.isRequired = isRequired;
            info.isInstanceMethod = NO;
            [methods addObject:info];
        }

        if (classMethodDescriptions) free(classMethodDescriptions);
    }

    return [methods copy];
}

+ (BOOL)object:(id)objc implementsMethod:(_ProtocolMethodInfo *)methodInfo {
    if (methodInfo.isInstanceMethod) {
        // 检查实例方法
        Method method = class_getInstanceMethod([objc class],
                                              NSSelectorFromString(methodInfo.methodName));
        if (!method) return NO;

        // 检查方法签名是否匹配
        const char *typeEncoding = method_getTypeEncoding(method);
        return strcmp(typeEncoding, methodInfo.typeEncoding.UTF8String) == 0;
    } else {
        // 检查类方法
        Method method = class_getClassMethod([objc class],
                                           NSSelectorFromString(methodInfo.methodName));
        if (!method) return NO;

        // 检查方法签名是否匹配
        const char *typeEncoding = method_getTypeEncoding(method);
        return strcmp(typeEncoding, methodInfo.typeEncoding.UTF8String) == 0;
    }
}

+ (NSString *)formatMethodDescription:(_ProtocolMethodInfo *)methodInfo {
    NSString *methodType = methodInfo.isInstanceMethod ? @"实例方法" : @"类方法";
    NSString *requirement = methodInfo.isRequired ? @"必需" : @"可选";

    return [NSString stringWithFormat:@"%@ [%@, %@]",
            methodInfo.methodName,
            methodType,
            requirement];
}

+ (void)reportValidationResultForObject:(id)objc
                    unconformsMethods:(NSArray<NSString *> *)unconformsMethods {

    if (unconformsMethods.count == 0) {
        return; // 验证通过
    }

    NSString *errorMessage = [NSString stringWithFormat:
        @"%@ 未实现以下方法:\n%@",
        objc,
        [unconformsMethods componentsJoinedByString:@"\n"]];

    // 使用断言，在调试时中断执行
    NSAssert(NO, @"%@", errorMessage);

    // 生产环境记录日志
#ifdef RELEASE
    NSLog(@"Protocol Conformance Error: %@", errorMessage);
#endif
}

@end

流程图

核心功能特性

1. 完整的协议继承链检查

系统采用递归算法遍历协议的所有父协议，确保检查完整的继承关系：

// 递归获取继承协议的方法
unsigned int protocolListCount;
Protocol **protocols = protocol_copyProtocolList(protocol, &protocolListCount);
for (unsigned int i = 0; i < protocolListCount; i++) {
    [self getMethodsForProtocol:protocols[i]
                     isRequired:isRequired
              checkClassMethods:checkClassMethods];
}

2. 灵活的方法检查配置

支持四种检查模式的任意组合：

// 使用示例 - 完整检查
[ProtocolConformanceChecker assertObjC:myObject
                    conformsToProtocol:@protocol(MyProtocol)
               checkOptionalMethods:YES   // 检查可选方法
                 checkClassMethods:YES];  // 检查类方法

// 使用示例 - 最小检查
[ProtocolConformanceChecker assertObjC:myObject
                    conformsToProtocol:@protocol(MyProtocol)
               checkOptionalMethods:NO    // 不检查可选方法
                 checkClassMethods:NO];   // 不检查类方法

3. 详细的方法签名验证

不仅检查方法是否存在，还验证方法签名（Type Encoding）是否完全匹配：

+ (BOOL)object:(id)objc implementsMethod:(_ProtocolMethodInfo *)methodInfo {
    const char *typeEncoding = method_getTypeEncoding(method);
    return strcmp(typeEncoding, methodInfo.typeEncoding.UTF8String) == 0;
}

实现细节解析

方法信息封装

使用轻量级的内部类封装方法信息，提高代码的可读性和可维护性：

@interface _ProtocolMethodInfo : NSObject
@property (nonatomic, copy) NSString *methodName;      // 方法名
@property (nonatomic, copy) NSString *typeEncoding;    // 类型编码
@property (nonatomic, assign) BOOL isRequired;         // 是否必需
@property (nonatomic, assign) BOOL isInstanceMethod;   // 是否为实例方法
@end

内存管理规范

严格遵守 Objective-C 运行时内存管理规范：

// 正确释放运行时分配的内存
if (instanceMethodDescriptions) free(instanceMethodDescriptions);
if (protocols) free(protocols);

清晰的错误报告

提供详细的错误信息，快速定位问题：

+ (NSString *)formatMethodDescription:(_ProtocolMethodInfo *)methodInfo {
    NSString *methodType = methodInfo.isInstanceMethod ? @"实例方法" : @"类方法";
    NSString *requirement = methodInfo.isRequired ? @"必需" : @"可选";

    return [NSString stringWithFormat:@"%@ [%@, %@]",
            methodInfo.methodName,
            methodType,
            requirement];
}

执行流程详解

步骤1：方法收集阶段

步骤2：方法验证阶段

步骤3：结果报告阶段

使用场景示例

场景一：单元测试中的协议验证

// 验证 Mock 对象是否完整实现协议
- (void)testDataSourceProtocolConformance {
    // 创建 Mock 对象
    id mockDataSource = [OCMockObject mockForProtocol:@protocol(UITableViewDataSource)];

    // 验证协议实现
    [ProtocolConformanceChecker assertObjC:mockDataSource
                        conformsToProtocol:@protocol(UITableViewDataSource)
                   checkOptionalMethods:NO    // UITableViewDataSource 只有必需方法
                     checkClassMethods:NO];   // 数据源协议通常只有实例方法

    // 执行测试逻辑
    // ...
}

场景二：框架初始化验证

// 确保框架提供的基类正确实现协议
@implementation MyNetworkManager

+ (void)initialize {
    if (self == [MyNetworkManager class]) {
        // 验证类是否实现必要的协议
        [ProtocolConformanceChecker assertObjC:self
                            conformsToProtocol:@protocol(MyNetworkProtocol)
                       checkOptionalMethods:YES    // 检查所有可选方法
                         checkClassMethods:YES];   // 检查类方法
    }
}

@end

场景三：关键路径的防御性检查

// 在设置代理时进行验证
- (void)setDelegate:(id<MyCustomDelegate>)delegate {
    // 只在调试模式下进行完整验证
#ifdef DEBUG
    if (delegate) {
        [ProtocolConformanceChecker assertObjC:delegate
                            conformsToProtocol:@protocol(MyCustomDelegate)
                       checkOptionalMethods:YES    // 检查可选方法
                         checkClassMethods:NO];    // 代理协议通常只有实例方法
    }
#endif

    _delegate = delegate;
}

最佳实践

1. 调试与测试阶段

// 在单元测试中全面验证
- (void)testProtocolImplementation {
    [ProtocolConformanceChecker assertObjC:testObject
                        conformsToProtocol:@protocol(RequiredProtocol)
                   checkOptionalMethods:YES
                     checkClassMethods:YES];
}

2. 生产环境使用

// 使用条件编译控制检查行为
- (void)setupComponent:(id)component {
#ifdef DEBUG
    // 调试模式下进行全面检查
    [ProtocolConformanceChecker assertObjC:component                        conformsToProtocol:@protocol(ComponentProtocol)                   checkOptionalMethods:YES                     checkClassMethods:NO];
#else
    // 生产环境下可选择性检查或记录日志
    if ([component conformsToProtocol:@protocol(ComponentProtocol)]) {
        // 基础检查通过
    } else {
        NSLog(@"Warning: Component does not conform to protocol");
    }
#endif
}

扩展可能性

1. 批量验证支持

// 扩展：支持批量验证多个协议
+ (void)assertObjC:(id)objc
conformsToProtocols:(NSArray<Protocol *> *)protocols
checkOptionalMethods:(BOOL)checkOptionalMethods
  checkClassMethods:(BOOL)checkClassMethods;

2. 自定义验证回调

// 扩展：支持自定义验证结果处理
typedef void(^ValidationCompletion)(BOOL success, NSArray<NSString *> *errors);

+ (void)validateObjC:(id)objc
  conformsToProtocol:(Protocol *)protocol
checkOptionalMethods:(BOOL)checkOptionalMethods
  checkClassMethods:(BOOL)checkClassMethods
         completion:(ValidationCompletion)completion;

3. Swift 兼容性扩展

// 扩展：更好的 Swift 兼容性
NS_SWIFT_NAME(ProtocolConformanceChecker.validate(_:conformsTo:checkOptional:checkClass:))
+ (void)swift_validateObject:(id)objc
          conformsToProtocol:(Protocol *)protocol
       checkOptionalMethods:(BOOL)checkOptionalMethods
         checkClassMethods:(BOOL)checkClassMethods;

总结

本文介绍了一个简洁高效的 Objective-C 协议一致性检查工具。通过深入理解 Objective-C 运行时机制，我们实现了一个能够全面验证协议实现的解决方案。

核心优势：

• ✅ 完整性：支持完整的协议继承链检查
• ✅ 灵活性：可配置的检查选项满足不同场景需求
• ✅ 准确性：严格的方法签名验证确保实现正确性
• ✅ 简洁性：去除了复杂的缓存逻辑，代码更易于理解和维护
• ✅ 实用性：清晰的错误报告帮助快速定位问题

适用场景：

• 单元测试和集成测试
• 框架和库的初始化验证
• 关键路径的防御性编程
• 协议实现的调试和验证

通过合理运用这个工具，可以在早期发现协议实现的问题，提高代码质量，减少运行时错误，构建更加健壮的 Objective-C 应用程序。

在 Objective-C 中，字典对象（Dictionary）用于存储键值对（Key-Value Pairs）。它类似于其他语言中的 Map、Hash 或关联数组。

字典分为两类：

1. NSDictionary：不可变字典。创建后不能添加、删除或修改元素。
2. NSMutableDictionary：可变字典。可以随时增删改查。

---

1. 核心规则

• 键（Key）：通常是字符串（NSString），必须是唯一的。
• 值（Value）：可以是任何对象（NSNumber, NSString, NSArray 等），但不能是 nil。
• 无序性：字典内部存储是无序的，遍历时的顺序不一定等同于插入顺序。

---

2. 快速入门：语法糖（推荐写法）

现代 Objective-C 推荐使用 @ 符号来简化操作：

// 创建不可变字典
NSDictionary *dict = @{@"name": @"张三", @"age": @25};

// 读取值
NSString *name = dict[@"name"]; // 结果: 张三

---

3. 学习代码案例

下面的代码涵盖了从创建到遍历的所有基础操作：

#import <Foundation/Foundation.h>

int main(int argc, const char * argv[]) {
    @autoreleasepool {
        // --- 1. 创建不可变字典 (NSDictionary) ---
        NSDictionary *person = @{
            @"id": @101,
            @"name": @"Jack",
            @"city": @"Shanghai"
        };
        
        NSLog(@"字典大小: %lu", person.count);
        NSLog(@"Jack 的城市: %@", person[@"city"]);


        // --- 2. 创建可变字典 (NSMutableDictionary) ---
        NSMutableDictionary *mDict = [NSMutableDictionary dictionary];
        
        // 添加/修改键值对
        mDict[@"brand"] = @"Apple";      // 语法糖写法
        [mDict setObject:@"M3 Max" forKey:@"cpu"]; // 传统写法
        mDict[@"ram"] = @"64GB";
        
        NSLog(@"修改前: %@", mDict);
        
        // 更新值
        mDict[@"ram"] = @"128GB"; 
        
        // 删除值
        [mDict removeObjectForKey:@"brand"];
        
        NSLog(@"修改后: %@", mDict);


        // --- 3. 字典的遍历 ---
        // 方式 A: 快速遍历 (遍历的是所有的 Key)
        NSLog(@"--- 开始快速遍历 ---");
        for (NSString *key in mDict) {
            NSLog(@"键: %@, 值: %@", key, mDict[key]);
        }
        
        // 方式 B: Block 遍历 (效率更高，推荐)
        [mDict enumerateKeysAndObjectsUsingBlock:^(id key, id obj, BOOL *stop) {
            NSLog(@"Block遍历 -> Key: %@, Value: %@", key, obj);
            // 如果想停止遍历，可以设置 *stop = YES;
        }];
    }
    return 0;
}

---

4. 常见操作与对比

操作	语法
判断键是否存在	if (dict[@"key"]) { ... } (如果不存在会返回 nil)
获取所有键	NSArray *keys = [dict allKeys];
获取所有值	NSArray *values = [dict allValues];
清空字典	[mDict removeAllObjects];

---

5. 开发者避坑指南（重点）

A. 永远不要插入 nil

字典的键和值都不能为 nil。如果你向字典插入 nil，程序会直接 Crash（崩溃）。

• 错误示例：mDict[@"test"] = someObject; // 如果 someObject 是 nil，崩！
• 解决办法：如果确实需要表示“空”，请使用 [NSNull null] 对象： mDict[@"test"] = [NSNull null];

B. 键的唯一性

如果你向 NSMutableDictionary 插入一个已经存在的键，旧的值会被直接覆盖。

C. 字典与数组的选择

• 数组 (NSArray)：通过索引（0, 1, 2...）访问，适合有序列表。
• 字典 (NSDictionary)：通过有意义的键（"userId", "token"）访问，适合存储属性信息，查找速度比数组遍历快得多。

D. 数字处理

字典只能存对象。如果你想存数字 10，不能直接写 10，必须包装成 NSNumber：

• ❌ dict[@"score"] = 100; // 编译错误
• ✅ dict[@"score"] = @100; // 正确

总结

• 不可变用 @{...}。
• 可变用 NSMutableDictionary。
• 取值用 dict[key]。
• 防崩溃：在存入变量前，先检查该变量是否为 nil。

在 Objective-C 中，分类 (Category) 和 协议 (Protocol) 是实现代码解耦、扩展功能和组件化开发的核心工具。

---

一、 分类 (Category)

分类允许你在不修改原始类代码、不使用继承的情况下，动态地为现有的类添加新方法。

1. 核心作用

• 扩展系统类：给 NSString, NSArray 等添加自定义工具方法。
• 分解大型类：将一个庞大的 .m 文件按功能拆分成多个小文件（如 User+Login.m, User+Profile.m）。

2. 代码案例：给 NSString 增加一个校验邮箱的功能

NSString+Email.h (声明)

#import <Foundation/Foundation.h>

@interface NSString (Email)
// 声明一个新方法
- (BOOL)isEmailFormat;
@end

NSString+Email.m (实现)

#import "NSString+Email.h"

@implementation NSString (Email)
- (BOOL)isEmailFormat {
    NSString *emailRegex = @"[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,4}";
    NSPredicate *emailTest = [NSPredicate predicateWithFormat:@"SELF MATCHES %@", emailRegex];
    return [emailTest evaluateWithObject:self];
}
@end

使用方法：

#import "NSString+Email.h"

NSString *myMail = @"test@example.com";
if ([myMail isEmailFormat]) {
    NSLog(@"这是一个有效的邮箱");
}

3. 注意事项

• 只能添加方法，不能添加成员变量（可以通过“关联对象”实现，但属于进阶内容）。
• 方法覆盖：如果分类中的方法名与原类重复，分类的方法会“覆盖”原类。建议分类方法名加上前缀（如 my_isEmailFormat）。

---

二、 协议 (Protocol)

协议定义了一套方法列表，但不负责实现。任何类都可以声明“遵守”这个协议并实现其中的方法。它类似于 Java 或 C# 中的 Interface（接口）。

1. 核心关键字

• @required：必须实现的方法（默认）。
• @optional：可选实现的方法。

2. 代码案例：定义一个“管家”协议

HouseKeeperProtocol.h

#import <Foundation/Foundation.h>

@protocol HouseKeeperProtocol <NSObject>

@required
- (void)cleanRoom; // 必须打扫房间

@optional
- (void)cookDinner; // 可以选择是否做饭

@end

Person.h (类声明遵守协议)

#import "HouseKeeperProtocol.h"

// 在类名后用 <> 表示遵守协议
@interface Person : NSObject <HouseKeeperProtocol>
@end

Person.m (实现协议方法)

@implementation Person

- (void)cleanRoom {
    NSLog(@"正在用吸尘器打扫...");
}

// cookDinner 是可选的，可以不写
@end

---

三、 协议的高级用法：委托模式 (Delegate)

这是协议在 iOS 开发中最常用的场景（如 TableView 的点击事件）。

// 1. 定义协议
@protocol DownloadDelegate <NSObject>
- (void)downloadDidFinish:(NSString *)filePath;
@end

// 2. 在下载器类中定义 delegate 属性
@interface Downloader : NSObject
@property (nonatomic, weak) id<DownloadDelegate> delegate; 
- (void)start;
@end

@implementation Downloader
- (void)start {
    NSLog(@"下载中...");
    // 3. 通知代理对象
    if ([self.delegate respondsToSelector:@selector(downloadDidFinish:)]) {
        [self.delegate downloadDidFinish:@"/path/to/file"];
    }
}
@end

---

四、 分类 vs 协议：怎么选？

特性	分类 (Category)	协议 (Protocol)
主要目的	扩展：给现有类增加功能	规范：定义一套行为准则
方法实现	必须在分类的 .m 中实现	协议本身不实现，由遵守它的类实现
状态存储	不允许添加成员变量	不涉及变量，只涉及方法
使用场景	比如想给所有 UIButton 加一个抖动动画	比如定义“凡是能飞的物体（鸟、飞机）都要有 fly 方法”

总结

• 如果你想让某个现有的类“更强大”，用 Category。
• 如果你想让不同的类“遵守同一种约定”或者实现“回调通知”，用 Protocol。

复杂度分析（Complexity Analysis）是计算机科学的核心理论之一，由Donald Knuth在《计算机程序设计艺术》中系统阐述，后经Robert Sedgewick、Thomas H..

前言 1. 为什么需要配置开发环境？ 良好的开发环境是学习数据。根据Stack Overflow 2023年开发者调查和IEEE Software Engineering Standards：....

目前手游 iOS SDK 普遍使用手动集成方案。但随着近几年出海热，SDK 需要集成大量第三方库，如 AppsFlyer、Firebase、Admob、Facebook、Twitter、AppLovin 等等。其中一些三方库不支持 CocoaPods 集成，所以我也都使用手动集成。

因为不同的游戏需要接入的第三方库不一样，当用不到的时候，SDK 里就需要剔除相关代码，不然编译也会报错。我的解决方案是通过宏来进行开关隔离，比如：

#define AppsFlyer 1

#if AppsFlyer
// 调用相关接口
#endif

像这样通过设置 AppsFlyer 为 1 或者 0 来启用和关闭相关代码，关闭时编译器会过滤掉这些代码。此外，当不同的游戏接入的 SDK 出现一些问题需要测试时，就需要频繁改参数、改宏开关。这些操作相当繁琐，所以我都是每个包复制一份 SDK 代码进行设置，用空间换方便。

复制 SDK 时三方库也会复制，三方库可占空间了。以苹果那金子般的内存，过不了多久电脑存储空间就不够用了，必须定期清理。

随着 SDK 趋近稳定，三方库也需要保持更新，我计划将 SDK 改用 CocoaPods 集成。这样不用每次都生成 SDK 副本，也方便研发接入。

最开始是计划把 SDK 里的三方库相关代码拆分成单独的库，让它们单独去依赖对应的三方库，提供接口给 SDK 调用。这样不同的游戏用到哪个三方库就导入对应的库，不再用 SDK 内部宏定义开关。

因为之前从未用 Pod 来管理自己的库，我以为这个事应该很快弄完，结果意外的折腾了好长时间……

我遇到的问题主要归为两类：

1. 依赖导致的链接和配置错误；
2. 重复引用警告（即把依赖的三方库代码也编译到我的拆分库里，而游戏工程通过 Pod 也会引入一份）。

以下是我将封装层从静态库改成动态库再改成源码依赖的过程和遇到的问题。

1. 静态库阶段

我首先把 SDK 里的三方库相关代码拆分成了一个个静态库，相当于把需要用到的三方库接口封装了一层。为什么不用动态库？因为我不想要 ipa 包里的 Framework 里有太多自定义库。如果是静态库，那这些代码会编译到主二进制里。

在静态库开发工程里测试编译都正常，但在验证 podspec 时报各种错误。原因是依赖各种类型的三方库导致的复杂的链接和配置错误，还要掺杂不同编程语言。折腾了两三天最终放弃了，改为动态库。

注：podspec 文件就是库的配置和导入说明书，需要在里面设置库的名称、版本、支持系统版本、库文件位置、系统库和三方库依赖，以及一些工程配置如 Other Link Flag 的设置等。把这个文件成功发布到 Pod 后，大家就可以通过 Pod 来引入你的库了。

2. 动态库阶段

把拆分库改成动态库后，就少了很多链接和配置错误。有一部分三方库并未提供 Pod 引入，只提供了下载链接，这种就无法自动保持更新了，只能我手动去替换三方库。

理论上可以在 podspec 里直接把三方库的下载链接设置为它们官网的下载链接，前提是他们链接保持不变并且里面的文件路径不改。但是这样我感觉不太稳，所以还是手动替换更新。

此外，我的库都是用 OC 写的，有一部分三方库是用 Swift 写的或者混合了 Swift，这种情况需要在 build setting 里调整一些设置。还好有 AI 可以问，不然有得折腾了。

SDK 内部之前会调用很多三方库代码，但是我希望这些三方封装层独立于 SDK，即 SDK 不要依赖这些库。于是原本在 SDK 内部调用的接口就放到外部由研发来调用，后面发现外部接入变得复杂了好多。而且很多接口跟研发也没什么关系，这样做增加了他们的接入难度，和旧版 SDK 接入变化很大。

我把这个情况问了下 AI，AI 给的方案是通过代理实现：即把 SDK 用到的三方库封装层方法定义成一个协议，让封装层自行选择实现协议里的方法。在 SDK 内部调用实现了相关协议方法的代理，代理指定由研发在外部初始化封装层后设置。

当然这个操作后面也省略了，改成在 SDK 内部通过特定方法在判断三方封装层类存在时创建封装层实例并设置为代理。经过这些操作，SDK 接口对比旧版变化就比较小了。

objectivec

// 通过运行时设置代理
SEL sharef = NSSelectorFromString(@"shared");
// AppsFlyer
if (NSClassFromString(SDK_APPSFLYER)) {
    self.appsFlyerDelegate = [NSClassFromString(SDK_APPSFLYER) performSelector:sharef];
}

从前面到这里，我的库的开发工程都是用 CocoaPod 来引入的三方库。CocoaPod 会在我编译拆分库的 Target 生成 framework 文件时，把依赖的三方库代码和文件都打包进来。这样一来，当我发布到 Pod 后用 SDK Demo 工程测试时会报警告，内容是三方库在我的拆分库里也有实现代码。在试了 AI 给的很多解决方法都没能解决这个问题后，我只能在库开发工程里移除了 Pods，将三方库改为手动导入，以此避免三方库打进我的封装库里。

这里面有个意外就是 VKID 库（俄罗斯微信）仍然得用 Pods 来引入，因为它是以纯 Swift 源码导入的。我在手动导入 Swift 源码时会报缺失某个代码文件，用 Pod 就正常，按住 command 能找到这个文件代码，但我看不到它在哪——根本没有路径……

此时我也发现在 OC 动态库里依赖的三方 Swift 库会被打包进来，设置为 Do not embed 也没有用。AI 确认了这一点并建议我改回静态库……

无奈我最终只能把封装库改成用 Pod 源代码引入，而且要改就把所有三方封装库都改成源码引入算了。

3. 源代码阶段

当我把其他封装库都成功发布到 Pod 官方后，最后轮到 VKID 时又报错了。Swift 写的 VKID 并未提供 OC 调用的接口，我在封装层用 @objc 做了下桥接，然后用 OC 写的一个 Manager 类来调用转接口，很合理吧？这样就不行，podspec 验证不通过。

折腾来折腾去，最终 AI 给出的方案是把封装层的 Swift 拆分出来单独成库，不要跟 OC 混合在一起。果然拆开后就验证通过了，成功发布到 Pod 官方。

关于库签名和隐私文件

之前是动态库的时候，需要把单独编译成的真机和模拟器 framework 合并成 xcframework，然后再对这些库进行签名。动态库签名是苹果近两年的要求，不签名提包会被打回。改成源码导入后就省去这些麻烦了。

此外，这种源码库的隐私文件要不要加暂时不确定。理论上不用，我暂未提包测试过，但 AI 建议加上，看了下一些三方库也是加了的。

关于 AI

我用到的 AI 主要是 DeepSeek 和 Gemini，都是免费的版本。之前用 AI 养成习惯开新对话，这次咨询的问题比较复杂，我会在一个对话里继续来回问很多次，发现 AI 变强好多，问到后面还会记得前面的推理。

说句题外话，AI编程都出来这么久了，Xcode仍然没有官方支持AI，真是低人一等。随便用一下其他AI编程工具，感觉都不是一个时代的东西。苹果公司的AI部门貌似内斗严重，至今拿不出像样的东西。

数据结构与算法是计算机科学的基础，是软件工程师的核心技能。本文详解 工业界应用 学习资源与工具 学习建议等知识

前言

配置Podfile时，如果结合一些优化选项，能大大的提升开发效率。本文是为使用cocoapod管理组件库提供一个podfile优化设置的最佳实践。

install! 'cocoapods',
    # 禁用输入输出路径
    disable_input_output_paths: true,
    
    # 增量安装（只更新变化的 Pods）
    incremental_installation: true,
    
    # 为每个 Pod 创建独立项目
    generate_multiple_pod_projects: true,
    
    # 生成确定性的 UUID（便于缓存）
    deterministic_uuids: true,
    
    # 锁定 Pod 项目 UUID
    lock_pod_sources: true,
    
    # 保留 Pod 的原始文件结构
    preserve_pod_file_structure: true,
    
    # 共享编译方案
    share_schemes_for_development_pods: true,
    
    # 禁用代码签名（用于开发 Pods）
    disable_code_signature_for_development_pods: true

🚀 一、构建性能优化类

1. disable_input_output_paths: true

• 基本说明： 默认情况下，CocoaPods 会为每个 Pod 生成输入输出路径映射文件，这些文件告诉 Xcode 如何查找和链接 Pod 中的资源文件（如图片、xib、storyboard 等），设置 disable_input_output_paths: true 会禁用这个功能。

# 1.默认为false，即CocoaPods 会为每个 Pod 创建 .xcconfig 文件包含类似：
FRAMEWORK_SEARCH_PATHS = $(inherited) "${PODS_CONFIGURATION_BUILD_DIR}/AFNetworking"
LD_RUNPATH_SEARCH_PATHS = $(inherited) '@executable_path/Frameworks' '@loader_path/Frameworks'
# 2.设置true时，不使用复杂的路径映射，使用更简单的框架搜索路径。

• 好处：

  • 构建速度显著提升：增量构建速度提升 30-50%，全量构建也有 10-20% 的提升
  • 减少系统开销：减少 Xcode 构建系统对大量文件的监控和检查

• 原理：

  1. 绕过依赖验证：CocoaPods 默认会验证每个源文件的输入输出路径，确保编译正确性。启用此选项后，跳过这些验证
  2. 减少文件系统操作：避免为每个资源文件创建和维护路径映射记录
  3. 简化构建图：构建系统不需要跟踪复杂的文件依赖关系图

• 缺点：

  1. 依赖检查失效：可能掩盖 Podspec 配置错误，如资源文件路径错误
  2. 构建确定性下降：在极端情况下可能导致缓存不一致问题
  3. 调试困难：当资源文件找不到时，错误信息不够明确，排查困难
  4. Podspec 质量要求高：要求所有 Pod 的 spec 文件必须正确配置资源路径

• 推荐场景：

  • 大型项目（Pod 数量 > 15）
  • CI/CD 流水线环境
  • Podspec 质量可靠且经过充分测试

• 验证是否生效：

  # 检查生成的 Pods.xcconfig 文件
  grep -r "input.xcfilelist\|output.xcfilelist" Pods/
  # 如果生效，应该找不到相关配置
  

2. generate_multiple_pod_projects: true

• 基本说明： CocoaPods 1.7.0+ 引入的功能，改变传统的单 Pods.xcodeproj 结构，为每个 Pod 生成独立的 Xcode 项目文件。

# 传统方式（generate_multiple_pod_projects: false）：
Pods/
  └── Pods.xcodeproj          # 单个项目文件
        ├── Target: Alamofire
        ├── Target: SDWebImage
        └── ...
        
# 新方式（generate_multiple_pod_projects: true）：
Pods/
  ├── Alamofire.xcodeproj     # 独立项目文件
  ├── SDWebImage.xcodeproj    # 独立项目文件
  ├── ...                     # 其他Pod项目文件
  └── Pods.xcodeproj          # 仅包含聚合Target

• 好处：

  • 并行编译支持：Xcode 可以同时编译多个独立项目，充分利用多核 CPU
  • 增量编译优化：修改一个 Pod 不会触发其他 Pod 重新编译
  • 模块化清晰：每个 Pod 的构建配置完全独立，避免相互干扰
  • 缓存效率提升：构建产物可以按 Pod 单独缓存和复用

• 原理：

  1. 项目结构重构：将 monolithic 的单项目拆分为多个子项目
  2. 构建图优化：Xcode 可以更好地分析依赖关系，实现并行构建
  3. 配置隔离：每个 Pod 有独立的构建设置，减少配置冲突

• 缺点：

  1. Xcode 索引变慢：项目文件增多导致 Xcode 索引时间增加 20%
  2. 内存占用增加：Xcode 需要同时加载多个项目，内存使用增长明显
  3. 初次生成耗时：首次 pod install 时间增加约 10%

• 推荐场景：

  • Pod 数量较多（> 20个）的大型项目
  • 需要频繁进行增量构建
  • 项目采用模块化架构设计

3. incremental_installation: true

• 基本说明： CocoaPods 1.11.0+ 引入的增量安装功能，仅更新变更的 Pod 配置，跳过未变更的部分。

# 普通 pod install 流程：
1. 解析整个 Podfile 和 Podspec
2. 生成所有 Pod 的项目配置
3. 写入 Pods.xcodeproj
4. 更新所有相关文件

# 增量安装流程（incremental_installation: true）：
1. 计算 Podfile/Podspec 的哈希值
2. 与上次缓存对比，识别变更的 Pod
3. 仅重新生成变更 Pod 的配置
4. 保留未变更 Pod 的项目状态，只重新编译有变化的 Pod

• 好处：

  • 编译时间大幅减少：pod install或pod update导致的pod库编译时间减少 40-70%
  • 磁盘 I/O 减少：避免大量文件的重复写入

• 原理：

  1. 哈希比对：计算 Podfile、Podspecs 和本地文件的哈希值
  2. 变更检测：仅处理哈希值发生变化的 Pod
  3. 状态缓存：在 Pods/.incremental_cache 目录保存安装状态
  4. 智能更新：保持未变更 Pod 的项目引用不变

• 缺点：

  1. 状态管理复杂：缓存状态可能损坏，需要手动清理
  2. 首次无优势：新环境或清理缓存后首次运行无优化效果
  3. 依赖条件：必须同时启用 generate_multiple_pod_projects: true
  4. 调试困难：缓存不一致时可能出现难以复现的问题

• 推荐场景：

  • 开发环境中频繁执行 pod install
  • CI/CD 流水线，有良好的缓存策略
  • 项目 Pod 依赖稳定，不频繁变动

• 用法：

  install! 'cocoapods',
    generate_multiple_pod_projects: true,
    incremental_installation: true
  

• 缓存清理：

  # 清理增量缓存（遇到问题时）
  rm -rf Pods/.incremental_cache
  
  # 完整重置
  rm -rf Pods Podfile.lock Pods/.incremental_cache
  pod install
  

🏗️ 二、模块化与架构类

4. generate_target_xcconfig_fragments: true

• 基本说明： 为每个 Target 生成独立的 .xcconfig 配置文件片段，而不是将所有配置合并到全局文件。

# 传统方式（generate_target_xcconfig_fragments: false）：
Pods/
  └── Target Support Files/
        └── Pods-YourApp.xcconfig     # 所有Pod配置合并到一个文件
              ├── # Alamofire 设置
              ├── # SDWebImage 设置  
              └── # 其他所有Pod设置

# 新方式（generate_target_xcconfig_fragments: true）：
Pods/
  └── Target Support Files/
        ├── Pods-YourApp.xcconfig          # 主配置文件
        ├── Pods-YourApp.alamofire.xcconfig   # Alamofire配置片段
        ├── Pods-YourApp.sdwebimage.xcconfig  # SDWebImage配置片段
        └── ...                              # 其他Pod配置片段

• 好处：

  • 配置隔离清晰：每个 Pod 的编译设置独立管理
  • 调试方便：可以单独查看和修改某个 Pod 的配置
  • 避免全局污染：减少配置冲突的可能性
  • 易于覆盖：主项目可以针对特定 Pod 进行配置覆盖

• 原理：

  1. 配置分片：将原本合并的配置拆分为多个文件
  2. 引用链：主 .xcconfig 通过 #include 引用各个片段
  3. 按需加载：Xcode 只加载需要的配置片段

• 缺点：

  1. 文件数量激增：每个 Pod 对应一个配置文件，管理稍复杂
  2. 配置覆盖复杂：主项目需要覆盖特定 Pod 配置时步骤更多
  3. Xcode 界面混乱：项目导航器中 .xcconfig 文件数量明显增加
  4. 初学者困惑：配置结构更复杂，学习成本增加

• 推荐场景：

  • 需要精细控制各个 Pod 编译选项的项目
  • 中大型团队，需要明确的配置责任划分
  • 频繁调试和修改 Pod 编译设置的场景

5. deterministic_uuids: true

• 基本说明： 控制 Xcode 项目文件中各种元素 UUID 的生成方式，确保每次 pod install 生成相同的 UUID。

# 非确定性UUID（默认，deterministic_uuids: false）：
# 每次 pod install 生成随机UUID：
PBXProject UUID: "A1B2C3D4-E5F6-7890-ABCD-EF1234567890"  # 每次不同
PBXGroup UUID: "B2C3D4E5-F678-9012-3456-7890ABCDEF12"     # 每次不同

# 确定性UUID（deterministic_uuids: true）：
# 基于内容哈希生成固定UUID：
PBXProject UUID: "8F9A1B2C-3D4E-5F67-89AB-CDEF01234567"  # 始终相同
PBXGroup UUID: "9A1B2C3D-4E5F-6789-01AB-23456789CDEF"     # 始终相同

• 好处：

  • 版本控制稳定：极大减少 .pbxproj 文件的合并冲突
  • CI/CD 一致性：不同机器、不同时间生成的产物完全一致
  • 可重复构建：确保构建过程的确定性
  • 团队协作顺畅：避免因 UUID 变化导致的文件变动

• 原理：

  1. 哈希生成：基于文件路径、类型等属性计算哈希值
  2. UUID 派生：从哈希值派生成固定格式的 UUID
  3. 内容寻址：相同内容始终生成相同 UUID

• 缺点：

  1. UUID 泄露风险：通过 UUID 可能推断出项目内部结构
  2. 迁移成本：从非确定性切换到确定性需要重生成所有项目文件
  3. 工具兼容性：某些第三方工具可能依赖随机 UUID 的特性
  4. 历史问题：已有的项目切换时可能遇到历史遗留问题

• 推荐场景：

  • 团队协作项目，多人同时修改 Podfile
  • CI/CD 流水线，需要确保构建一致性
  • 大型项目，.pbxproj 文件经常产生合并冲突
  • 项目初期就开始使用，避免中途切换

• 用法：

  install! 'cocoapods',
    deterministic_uuids: true
  

• 迁移步骤：

  # 从非确定性切换到确定性的完整步骤
  1. 备份当前 Pods 目录
  2. 修改 Podfile 添加 deterministic_uuids: true
  3. 清理旧项目文件：
     rm -rf Pods Podfile.lock
  4. 重新安装：
     pod install
  5. 提交所有变更到版本控制
  

💾 三、缓存与存储优化类

6. share_schemes_for_development: true

• 基本说明： 为开发中的 Pod 自动生成和共享 Xcode schemes，方便直接运行和调试 Pod 代码。

# 未启用时（默认）：
# Pod 的 scheme 通常不可见或需要手动创建
# 只能通过主项目间接调试 Pod 代码

# 启用后（share_schemes_for_development: true）：
# 每个 Pod 自动生成开发 scheme：
Alamofire.xcodeproj
  └── xcshareddata/xcschemes/
        └── Alamofire.xcscheme      # 自动生成，可直接运行
SDWebImage.xcodeproj
  └── xcshareddata/xcschemes/
        └── SDWebImage.xcscheme     # 自动生成，可直接运行

• 好处：

  • 直接调试 Pod：可以在 Xcode 中直接运行和测试 Pod 代码
  • 开发体验好：便于修改和验证第三方库
  • 单元测试方便：可以直接运行 Pod 自带的测试
  • 学习第三方库：通过运行示例代码快速理解库的使用

• 原理：

  1. Scheme 生成：为每个 Pod 的 Target 创建对应的 .xcscheme 文件
  2. 共享配置：将 scheme 放在 xcshareddata 目录，供所有用户使用
  3. 构建配置：配置适当的构建目标和运行环境

• 缺点：

  1. Scheme 污染：Xcode Scheme 列表可能变得非常长
  2. 性能开销：每个 Pod 生成 scheme 增加 pod install 时间约 5-10%
  3. 命名冲突：不同 Pod 可能有相同 Target 名称，导致 scheme 名称冲突
  4. 维护负担：需要管理大量 scheme 文件

• 推荐场景：

  • 需要频繁修改和调试 Pod 代码的项目
  • 开发自定义 Pod 或 Fork 第三方库时
  • 学习和研究第三方库实现原理
  • 需要直接运行 Pod 的测试用例

• 用法：

  install! 'cocoapods',
    share_schemes_for_development: true
      # 只为特定 Pod 启用 scheme 共享
      pod 'MyCustomPod', :share_schemes_for_development => true
      pod 'OtherPod'  # 默认不共享 scheme
  

7. preserve_pod_file_structure: true

• 基本说明： 保持 Pod 的原始文件目录结构，而不是将文件扁平化处理。

# 默认情况（preserve_pod_file_structure: false）：
# Pod 文件被扁平化到单个目录
Pods/Alamofire/
  ├── AFNetworking.h
  ├── AFURLSessionManager.h
  ├── AFHTTPSessionManager.h
  └── ... 所有.h和.m文件在同一层级

# 启用后（preserve_pod_file_structure: true）：
# 保持原始目录结构
Pods/Alamofire/
  ├── Source/
  │   ├── Core/
  │   │   ├── AFURLSessionManager.h
  │   │   └── AFURLSessionManager.m
  │   └── Serialization/
  │       ├── AFURLRequestSerialization.h
  │       └── AFURLResponseSerialization.h
  └── UIKit+AFNetworking/
      └── AFImageDownloader.h

• 好处：

  • 结构清晰：便于查看和理解第三方库的组织结构

• 原理：

  1. 结构保持：在 Pods/ 目录中镜像 Pod 的原始文件结构
  2. 引用路径保持：头文件引用路径保持不变
  3. 资源保持：资源文件保持原始相对路径

• 缺点：

  1. 头文件搜索路径复杂：需要配置更复杂的 Header Search Paths
  2. 构建优化失效：某些构建优化（如预编译头）可能失效
  3. 可能暴露内部结构：某些 Pod 的内部结构可能不希望被查看
  4. 项目导航稍乱：Xcode 中文件层级更深，导航稍麻烦

• 推荐场景：

  • 学习和研究第三方库代码结构
  • 某些 Pod 必须保持特定目录结构才能工作
  • 需要精确控制头文件包含路径的项目

🛡️ 四、稳定性与兼容性类

8. warn_for_multiple_dependency_sources: true

• 基本说明： 检测并警告同一个 Pod 从多个源引入的情况，避免潜在的版本冲突。

# 可能产生警告的场景：
# Podfile 配置：
pod 'Alamofire', '~> 5.0'           # 从官方源
pod 'Alamofire', :git => 'https://github.com/Alamofire/Alamofire.git'  # 从Git源

# 安装时警告：
[!] 'Alamofire' is sourced from `https://github.com/CocoaPods/Specs.git` 
    and `https://github.com/Alamofire/Alamofire.git` in `MyApp`.

• 好处：

  • 提前发现问题：在安装阶段发现潜在的依赖冲突
  • 避免运行时问题：防止同一库的不同版本被链接
  • 配置清晰：确保依赖来源明确和一致
  • 维护友好：便于理解和维护复杂的依赖关系

• 原理：

  1. 源追踪：记录每个 Pod 的安装来源（Specs repo、Git、本地路径等）
  2. 冲突检测：检查同一 Pod 是否有多个不同来源
  3. 警告输出：在 pod install 过程中输出明确的警告信息

• 缺点：

  1. 警告噪声：某些合法场景（如测试不同分支）也会产生警告
  2. 可能误报：复杂依赖图可能产生误警告
  3. 配置繁琐：需要显式指定 source 来消除警告

• 推荐场景：

  • 复杂的多源依赖项目
  • 团队协作，确保依赖配置一致
  • 长期维护的项目，需要清晰的依赖管理

• 消除警告：

  # 明确指定 source 消除警告
  source 'https://github.com/CocoaPods/Specs.git'
  
  pod 'Alamofire', '~> 5.0'
  
  # 或者显式指定不同名称
  pod 'Alamofire', :git => 'https://github.com/Alamofire/Alamofire.git', :branch => 'feature'
  

9. deduplicate_targets: true

• 基本说明： 自动检测和合并项目中重复的 Target，减少冗余配置。

# 重复Target示例：
# 多个Pod依赖同一个库的不同版本
pod 'JSONKit', '~> 1.4'
pod 'AFNetworking', '~> 4.0'  # AFNetworking 内部依赖 JSONKit ~> 1.5

# 未启用去重时：
Pods.xcodeproj
  ├── Target: JSONKit (1.4)
  └── Target: JSONKit (1.5)  # 重复的Target

# 启用去重后：
Pods.xcodeproj
  └── Target: JSONKit (1.5)  # 自动选择较高版本，合并为一个

• 好处：

  • 避免重复链接：防止同一库被多次链接到最终产物
  • 减少冲突：避免符号重复定义的链接错误

• 原理：

  1. 依赖分析：分析所有 Pod 的依赖关系图
  2. 版本冲突解决：按照语义化版本规则解决版本冲突
  3. Target 合并：将相同的库合并到单个 Target
  4. 引用更新：更新所有依赖引用指向合并后的 Target

• 缺点：

  1. 合并风险：自动合并可能掩盖重要的版本差异
  2. 调试困难：难以确定实际使用的是哪个版本
  3. 意外行为：可能意外使用非预期的版本
  4. 控制权丧失：自动决策可能不符合项目需求

• 推荐场景：

  • 依赖关系复杂的项目
  • 希望保持项目结构简洁
  • 信任 CocoaPods 的版本冲突解决策略

• 版本冲突策略：

  # CocoaPods 的版本选择策略：
  # 1. 严格版本要求优先
  # 2. 较高版本优先（在兼容范围内）
  # 3. 显式指定的版本优先于传递依赖
  
  # 可以通过:dependency 控制
  pod 'MyPod', '~> 1.0'
  pod 'OtherPod', :dependency => ['MyPod', '~> 1.1']  # 强制使用特定版本
  

10. lock_pod_sources: true

• 基本说明： 锁定 Pod 的源信息，确保每次安装使用相同的源代码版本。

# Podfile.lock 中锁定的源信息：
PODS:
  - Alamofire (5.6.1)
  - SDWebImage (5.15.0)

EXTERNAL SOURCES:
  MyCustomPod:
    :git: https://github.com/company/MyCustomPod.git
    :commit: a1b2c3d4e5f678901234567890abcdef12345678  # 锁定具体commit
  AnotherPod:
    :path: ../LocalPods/AnotherPod  # 锁定本地路径

• 好处：

  • 构建确定性：确保不同时间、不同环境的构建结果一致
  • 避免意外更新：防止 Git 仓库更新导致不可预期的变化
  • 安全可控：锁定已知可工作的版本，减少风险
  • 团队一致性：确保团队成员使用相同的代码版本

• 原理：

  1. 源信息记录：在 Podfile.lock 中记录每个 Pod 的精确来源
  2. 哈希锁定：对于 Git 源，记录具体的 commit SHA
  3. 路径锁定：对于本地路径，记录完整路径信息
  4. 严格校验：安装时严格校验源信息是否匹配

• 缺点：

  1. 安全更新延迟：需要手动更新锁定的依赖
  2. 锁文件膨胀：Podfile.lock 可能变得很大
  3. 团队同步成本：锁文件变更需要团队协调更新
  4. 灵活性降低：无法自动获取最新修复或特性

• 推荐场景：

  • 生产环境构建
  • 需要严格可重复构建的项目
  • 团队协作，确保环境一致
  • 对稳定性要求极高的项目

• 更新策略：

  # 更新特定 Pod 到最新版本
  pod update Alamofire
  
  # 更新所有 Pod（谨慎使用）
  pod update
  
  # 检查可用更新但不实际更新
  pod outdated
  

⚙️ 五、实验性/高级功能类

11. use_frameworks! :linkage => :static

• 基本说明： 将动态框架改为静态链接，改变库的链接方式和运行时行为。

# 不同链接方式对比：
# 1. 动态框架（默认，use_frameworks!）：
#    运行时加载，多个App可共享，支持热更新
#    文件: Alamofire.framework (包含二进制和资源)

# 2. 静态框架（use_frameworks! :linkage => :static）：
#    编译时链接，直接嵌入App二进制
#    文件: libAlamofire.a (静态库) + 头文件

# 3. 静态库（不使用use_frameworks!）：
#    传统静态库方式
#    文件: libAlamofire.a + 头文件 + 资源bundle

• 好处：

  • 启动速度提升：减少动态库加载时间，冷启动速度提升 10-30%
  • 包体积可能减小：去除动态框架的封装开销
  • 部署简化：不需要关心动态库的签名和部署
  • 兼容性更好：避免动态库版本冲突问题

• 原理：

  1. 链接方式改变：从动态链接（@rpath）改为静态链接
  2. 二进制合并：库代码直接嵌入主二进制，而不是单独的文件
  3. 符号解析：所有符号在链接时解析，而不是运行时

• 缺点：

  1. 二进制兼容性问题：某些 Pod 明确要求动态链接
  2. 符号冲突风险：静态链接可能暴露私有符号导致冲突
  3. 调试信息缺失：崩溃堆栈可能不清晰
  4. 动态库依赖问题：依赖动态库的 Pod 无法使用
  5. Swift 运行时问题：某些 Swift 特性可能受影响

• 兼容性检查清单： ✅ 支持：

  • 纯 Swift Pod，不依赖 Objective-C 动态特性
  • 不包含 vendored_frameworks
  • 不依赖资源包（或者资源处理正确）
  • 不包含 pre_install/post_install 钩子修改链接设置

  ❌ 不支持：

  • 包含 s.vendored_frameworks 的 Pod
  • 依赖动态系统框架的 Pod
  • 使用 @objc 动态派发的复杂场景
  • 需要运行时加载的插件式架构

• 推荐场景：

  • 对启动性能要求极高的 App
  • 希望简化部署流程
  • Pod 都经过兼容性验证
  • 新项目，可以从开始就规划静态链接

• 用法：

  # 全局启用静态框架
  use_frameworks! :linkage => :static
  
  # 或针对特定 Pod
  use_frameworks!
  pod 'DynamicPod'  # 使用动态框架
  pod 'StaticPod', :linkage => :static  # 使用静态框架
  

• 兼容性测试命令：

  # 检查哪些Pod可能有问题
  pod install --verbose | grep -i "static\|dynamic\|linkage"
  
  # 测试构建
  xcodebuild -workspace App.xcworkspace -scheme App clean build
  

12. skip_pods_project_generation: true

• 基本说明： 跳过 Pods 项目的生成，直接将 Pod 文件作为源文件集成到主项目中。

# 传统方式（skip_pods_project_generation: false）：
App.xcworkspace
  ├── App.xcodeproj
  └── Pods.xcodeproj  # 独立的Pods项目

# 跳过生成（skip_pods_project_generation: true）：
App.xcworkspace
  └── App.xcodeproj   # 所有Pod文件直接作为源文件加入
        ├── Source/
        │   └── App files...
        └── Pods/     # Pod文件作为项目的一部分
            ├── Alamofire/
            ├── SDWebImage/
            └── ...

• 好处：

  • 极简项目结构：只有一个 Xcode 项目文件
  • 构建配置统一：所有代码使用相同的构建设置
  • 无需 workspace：可以直接打开 .xcodeproj 文件工作
  • 某些场景简单：对于非常简单的项目可能更直观

• 原理：

  1. 项目结构扁平化：不生成独立的 Pods.xcodeproj
  2. 文件直接引用：将 Pod 文件直接添加到主项目的文件引用树
  3. 配置合并：Pod 的构建设置合并到主项目配置中

• 缺点：

  1. 高级功能丧失：无法单独编译、测试、分析 Pod
  2. 调试极其困难：难以设置 Pod 代码的断点和调试
  3. 社区支持差：使用人数少，问题排查资源稀缺
  4. 升级风险高：CocoaPods 版本更新可能破坏此功能
  5. 与生态不兼容：很多工具和插件假设 Pods 项目存在
  6. 配置冲突：Pod 与主项目的构建设置可能冲突

• 强烈建议： 仅用于：

  • 原型验证或概念验证项目
  • 极其简单的个人项目（Pod 数量 < 3）
  • 短期存在的测试项目

  绝不用于：

  • 生产环境项目
  • 团队协作项目
  • 长期维护的项目
  • 包含复杂 Pod 依赖的项目

• 退出策略：

  # 从 skip_pods_project_generation 切换回标准模式的步骤：
  1. 备份项目
  2. 修改 Podfile，移除 skip_pods_project_generation: true
  3. 清理所有 Pod 相关文件：
     rm -rf Pods Podfile.lock App.xcworkspace
  4. 从主项目中移除所有 Pod 文件引用
  5. 重新安装：
     pod install
  6. 验证构建是否正常
  

🔍 监控与验证方法

性能监控脚本

#!/bin/bash
# monitor_pods_performance.sh

echo "=== CocoaPods 性能监控 ==="

# 1. 测量 pod install 时间
echo "1. 测量 pod install 时间:"
time pod install 2>&1 | grep real

# 2. 检查生成的项目结构
echo -e "\n2. 项目结构统计:"
echo "独立项目文件数: $(find Pods -name "*.xcodeproj" | wc -l)"
echo "Xcconfig 文件数: $(find Pods -name "*.xcconfig" | wc -l)"

# 3. 检查增量缓存
echo -e "\n3. 增量缓存状态:"
if [ -d "Pods/.incremental_cache" ]; then
  echo "增量缓存已启用，大小: $(du -sh Pods/.incremental_cache | cut -f1)"
else
  echo "增量缓存未启用"
fi

# 4. 构建时间测试
echo -e "\n4. 构建时间测试 (clean build):"
xcodebuild clean -workspace App.xcworkspace -scheme App 2>/dev/null
time xcodebuild -workspace App.xcworkspace -scheme App -showBuildTimingSummary 2>&1 | tail -5

配置验证命令

# 验证各优化是否生效
pod install --verbose 2>&1 | grep -E "(incremental|deterministic|multiple.*project)"

# 检查生成的 UUID 是否确定
grep -r "projectReferences" Pods/Pods.xcodeproj/project.pbxproj | head -1

# 验证静态链接
otool -L App.app/App | grep -v "@rpath\|/usr/lib\|/System"

⚠️ 问题排查指南

问题现象	可能原因	解决方案
构建失败：符号找不到	disable_input_output_paths: true + Podspec 配置错误	1. 临时禁用该选项测试 2. 检查问题 Pod 的 spec 文件 3. 确保资源文件路径正确
Xcode 卡顿严重	generate_multiple_pod_projects: true + 项目过多	1. 减少项目生成粒度 2. 升级 Xcode 和硬件 3. 关闭 Xcode 的某些索引功能
增量安装后构建异常	增量缓存损坏	1. 清理缓存：rm -rf Pods/.incremental_cache 2. 完整重建：rm -rf Pods Podfile.lock; pod install
版本控制频繁冲突	未启用 deterministic_uuids: true	1. 启用确定性 UUID 2. 团队统一执行完整重建

智能体时代的强化学习：AReaL框架与Agent最佳实践

以 RL 打造 Agent

两个核心”暴论”

1. Agent是未来五年AGI时代最重要的事。
2. 强化学习是构建Agent最关键的技术。

强化学习的历史发展与突破

强化学习的早期认知

大多数人对强化学习的认知来源于：

• AlphaGo：DeepMind用强化学习训练围棋智能体，击败李世石和柯洁
• OpenAI打Dota：2019年用强化学习击败两届世界冠军OG
• 其他游戏AI：腾讯打王者荣耀、星际争霸等

当年的强化学习智能体主要都是打游戏的，与大模型驱动的AGI时代似乎没有太大关系。

强化学习与大模型的结合转折点

2020-2022年的关键变化

GPT-3 API的问题：

• 2020年OpenAI推出GPT-3 API时存在严重问题
• 例子：输入”explain the moon landing to a six year old in a few sentences”
• GPT-3会输出重复内容：”explain the serious gravity, explain the serious relative, explain blah blah blah”
• 原因：大模型训练基于next token prediction，但用户给的是指令（instruction following problem）

注: “Next Token Prediction”（下一个 token 预测）是大语言模型（LLM）的核心机制。简单来说，它的意思是：给定一段文本的前面部分，模型预测接下来最可能出现的“token”是什么。

RLHF技术的突破：

• OpenAI花了两年时间解决这个问题
• 2022年推出InstructGPT，采用RLHF（Reinforcement Learning from Human Feedback）技术
• 方法：找人标注数据，判断哪些回答遵从指令，哪些不遵从
• 训练奖励模型，然后用强化学习让模型探索获得最高分数的回答
• 结果：同样的基座模型，有没有强化学习决定了好用还是不好用

注: RLHF（Reinforcement Learning from Human Feedback，基于人类反馈的强化学习）是一种用于对齐大语言模型（LLM）的技术。它的核心目标是：让模型的输出更符合人类的偏好、价值观和意图，而不仅仅是“语法正确”或“统计上常见”。

强化学习推动AGI产品发展的三个阶段

• 第一阶段：2022年ChatGPT
  

  • 由RLHF技术引爆，让大家第一次感受到AGI能力
  • 强化学习捅破了窗户纸，让AGI能力真正可用

• 第二阶段：2024年推理模型（Reasoning Model）
  

  • 也称为思考模型（Thinking Model）
  • 特点：给模型一个问题后，它会先想一会，输出大量thinking token
  • 例子：帮我算个24点，思考模型(比如 deepseek)会先在”草稿纸”上写10分钟(输出thinking token)，然后给答案
  • 技术：也是强化学习驱动，模型自己探索如何思考, 思考什么，自己判断答案对不对, 也就产生了推理模型
  • 训练范式与RLHF类似，但判断标准可能不同

• 第三阶段：2025年Agent模型
  

  • 基于Agent的强化学习技术
  • 代表产品：ChatGPT Deep Research 等

Agent产品的发展与特点

成功的Agent产品案例

• ChatGPT Deep Research
  • 2024年第一个比较成功的Agent产品
  • 功能：给它一个topic，帮你做研究
  • 工作流程：
    • 花很多时间思考
    • 调用工具，在网上搜索很多topic
    • 可能运行20分钟到1小时
    • 最终给出非常详实、有大量引用和reference的报告
• Manus /ChatGPT Agent / Kimi Agent Mode
  • 功能更丰富，可以帮你做PPT
  • 在Sandbox（沙盒）环境中工作：
    • 读取PDF文件
    • 在阅读器中打开PDF
    • 存储PDF文件
    • 编辑和创建文件
    • 在虚拟机中进行各种操作

Agent能力的演进

从Deep Research到Manus的发展体现了Agent能力的进步：

• Deep Research：除了对话，可以调用搜索工具、浏览器工具，将信息放在Context Window中处理
• Manus：更进一步，加上了Sandbox工程AI，相当于有了自己的电脑

AI的能力演进：

1. 有了脑子（大模型）
2. 有了草稿纸和笔（Context Window）
3. 有了一台自己的电脑（Sandbox）

产品发展趋势分析

• 用户交互的变化
  • ChatGPT时代：需要很长的prompt，详细描述要做什么
  • Agent时代：用户说的话越来越抽象，越来越少
• AI能力的变化
  
  • ChatGPT：1秒钟给出文本输出
  • Thinking Model：1-2分钟思考后给出答案
  • Agent Model：1小时处理复杂任务，主动行动
  • 未来: 牛马 AI, AI一直在做事, 主动帮人安排
• 从Reactive到Proactive的转变
  
  • 传统模式：用户告诉AI做什么（Reactive）
  • 未来趋势：AI主动准备，告诉用户要不要（Proactive）
  • 例子：OpenAI的ChatGPT Plus每天主动推送早报等内容

未来愿景

理想的AI助手具体技术化来讲：

• 信息模糊处理：人很难把想做的事讲清楚
• 个性化：每个人的需求不一样
• 主动规划：主动安排和执行任务
• 提前工作：AI不需要休息，可以一直工作

什么是好的 Agent 团队

• 组织 AI 化
• 技术栈完整
• 持续高速0-1 创新, 高效迭代

为什么Agent需要RL(强化学习)

市面上Agent 有各种 framework, 这些框架主要通过拖拉拽的方式构建Agent工作流，但对于复杂的Agent问题存在局限性。

强化学习解决的三大核心问题

问题一：处理不确定性和冲突信息

• 案例：阿里CTO是谁？
  

  • 阿里和蚂蚁有很多子公司，每个公司都有CTO
  • 搜索”蚂蚁CTO”会得到很多不同的结果
  • 需要AI去理解和判断才能做出正确回答

• 案例：退票问题
  

  • 用户说”退票”，但上下文可能很不确定
  • 退什么票？需要AI主动提问澄清

问题二：长期记忆和个性化

• 案例：美团小美推荐
  
  • 我说”要吃晚饭，要清淡点”
  • AI推荐白灼生菜等蔬菜
  • 但我从来不点蔬菜，喜欢吃肉
  • “清淡点”对我可能意味着”清淡点的肉”
  • 需要从很长的记录中挖掘个性化信息

问题三：海量工具和模型选择

• 案例：Reddit上的模型组合使用
  
  • Claude写代码很聪明但Context Window短且贵
  • Gemini写代码不够聪明但Context Window长且便宜
  • 用户发现可以用Claude调用Gemini：让Gemini读代码，然后扔给Claude写
  • 相当于”聪明的人指挥体力无限的傻子干活”
  • 这种最佳实践应该由AI自己探索出来，而不是人工定义规则

强化学习的统一解决方案

强化学习可以用统一的框架解决这些复杂问题：

• 让AI在环境中自己探索
• 涌现出处理复杂任务的能力
• 比规则和Workflow更灵活和强大

搜索智能体案例深度分析-看似简单的问题实际很复杂

问题案例：伦敦奥运会中国金牌数

表面上的简单：

• 问题：伦敦奥运会中国拿多少块金银铜牌？
• 看起来很简单，百度搜索就能找到答案
• 官网显示：中国队拿了38块金牌，是2012年历史第二高的成绩

实际的复杂性：

• 正确答案应该是39枚金牌
• 原因：2012年伦敦奥运会女子田径竞走项目
• 中国派出三位选手，当时拿了第3、4、5名
• 后来第1、2名被查出禁药，被剥夺奖牌资格
• 11年后（2023年），中国选手获得了补发的金牌
• 所以现在问中国奥运会金牌数，答案应该是39枚

现有产品的表现
测试了多个产品：

• DeeSeek：搜出38枚金牌
• ChatGLM：38枚金牌
• ChatGPT：搜到了39枚金牌的信息，说”有一些资料显示数字略有差异，39枚金牌”，但最后结论还是38枚金牌（因为大量信息都是38枚）
• ChatGPT Agent Mode：会答对

传统方法vs强化学习方法

传统Multi-Agent System方法

需要构建复杂的多智能体系统：

• 搜索Agent
• 核查Agent
• 调用知识的Agent
• 检验Agent
• 需要很长很复杂的流程

强化学习方法

极简设计：

• 一个模型
• 两个工具：搜索工具 + 点击网页工具
• 让模型在环境中循环探索

实际效果：

• 第5轮搜到39枚金牌的新闻
• 开始疯狂核查
• 经过60多轮迭代
• 最终确定正确答案是39枚金牌
• 还具有泛化能力，可以添加更强的工具
• 32B模型可以在准确度上超越商用产品

强化学习的两大优势

1. 简单: 简化Agent的workflow, 不需要复杂的多智能体系统设计
2. 涌现: 让AI涌现出复杂的多步推理能力, 通过探索自动获得复杂能力

Agent RL 的核心难点

强化学习面临的三大挑战

要做好强化学习，必须解决三个问题：

1. 缺Infra和算法：强化学习算法运算速度很慢很慢
2. 缺数据：训练数据的获取和质量, 强化学习的数据是很缺很缺德, 预训练数据可以在网上扒, 但强化学习的数据不太能直接网上扒
3. 缺环境：Sandbox等执行环境的构建

如何全栈解决 Agent RL 的难点

Infra(基础设施)和算法优化

速度慢的根本原因

强化学习的三个流程：

1. 生成：让模型在环境中交互生成数据
2. 评分：用奖励模型计算奖励
3. 训练：放到训练集中训练

复杂性分析：

• 涵盖了三种完全不同的计算模块
• 预训练只有训练，SFT只有训练，评测只有评测
• 强化学习包含：训练、评测、在线生成、Sandbox等
• 是一个算法编排了多种完全不同计算模式的复杂系统

算法与系统协同设计的重要性

为什么需要协同设计：

• 强化学习算法创新很容易碰到系统瓶颈
• 四个系统模块(推理/训练/环境/算法整合)中任何一个打满都会成为瓶颈
• 强化学习算法很容易打到系统瓶颈

团队组织建议：

• 做算法的同学需要了解Infra
• 做Infra的同学需要了解算法
• 最好能坐在一起工作, 这是加快创新节奏的重要方式

具体的性能瓶颈

搜索智能体的统计数据：

• 平均搜索时间：要调用 google 搜索引擎, 一个batch 5-10分钟
• 长尾效应严重：特别难的prompt需要1-2小时
• 问题：如果每个batch都要等最慢的那个，一天24小时只能更新12-24次
• 导致大量CPU/GPU等待时间

AReaL的解决方案：异步架构

核心思想：推理不能等

• 一部分卡不停地做推理，没有等待
• 训练也没有等待，有数据就训练
• 中间用随时更新参数的方式
• 如果推理到一半需要更新参数，就停下来更新，然后用新参数继续rollout
• 实现完全没有系统资源浪费

技术创新：

• 系统上做异步调整
• 算法上做相应调整以适应异步更新
• 在Agent场景上实现5倍加速，且没有效果损失

训练数据问题

数据稀缺的问题

• 预训练可以直接从网上获取数据
• 强化学习的训练数据不能直接从网上获取
• 一般问题都跟简单, 用户提出的复杂问题很少，难以挖掘复杂问题的测试集

数据合成解决方案

Agenic合成数据方法：

1. 从网页上获取答案（搜索比较简单，从答案开始）
2. 从答案构造问题
3. 不断让问题变得更加复杂
4. 评估问题，保证问题和答案匹配正确
5. 难度检查：问题不能太难也不能太简单，需要适合强化学习自我提升的难度
6. 构造出适合的训练数据

开源贡献：

• 数据、代码和脚本都已开源
• 帮助社区训练更好的Agent产品

环境构建 - Aworld 项目

• 主要是Sandbox等执行环境的构建
• 未来会开源更多的Sandbox项目
• 帮助大家训练更好的Agent产品

让更多人用 RL 训练更好的 Agent

AReaL团队发展历程与经验总结

团队发展时间线

• 2020年：开始做开源学术项目，多智能体强化学习框架
• 2022年：第一个大规模游戏场景可用的强化学习分布式训练框架
• 2023年：当时最快的RLHF框架
• 2024年：开始做AReaL，专注Agent AI

技术循环的有趣观察

回到原点的循环：

• 2025年的强化学习与当年打游戏很像
• 有个大模型在”玩游戏”（Sandbox可以是浏览器或电脑）
• 遇到的问题与打游戏类似：有黑盒环境，很慢，不能修改游戏规则
• 五年后技术回到了当年的原点
• 系统设计和算法技术都有循环

重要的经验教训

技术需要两个条件才能发挥价值：

1. 技术需要对的时间
   • 强化学习如果在2022年以前，大家很难感知到价值
   • 不是大家的错，而是技术没有在对的时间被感知
2. 技术需要好的产品承载
   • 强化学习技术如果不是因为ChatGPT、RLHF、Agent model，大家可能也感知不到
   • 技术本身可能没有价值，需要好的产品去承载才能发挥更大价值

团队理念：

• 技术一定要产品化, 所有技术同学都应该尽可能把技术产品化
• 希望创造能够实现AGI的Agent产品, 成为支持产品持续进化的平台

总结与展望

核心观点回顾

1. Agent是AGI时代最重要的事情：从产品发展趋势和技术演进可以看出Agent的重要性
2. 强化学习是Agent的最关键技术：能够统一解决Agent面临的复杂问题，让AI涌现出复杂能力

技术发展趋势

• 从简单的对话模型到能够主动行动的Agent
• 从Reactive到Proactive的转变
• 从规则驱动到强化学习驱动的智能涌现
• 算法与系统协同设计的重要性日益凸显

未来展望

• Agent产品将越来越智能和主动
• 强化学习技术将在Agent领域发挥更大作用
• 需要更好的基础设施、数据和环境支持
• 技术产品化是实现价值的关键路径

商汤科技”从炫技到实用：AI 产品价值闭环”演讲大纲及内容整理

AI 企业落地现状分析

MIT 调研数据

• 95% 的企业 AI 落地失败：MIT 调研显示，过去一年多超过 95% 的企业侧 AI 落地项目失败，只有 5% 的企业在 PNL（损益表）上看到了 AI 的价值
• 技术与企业节奏错配：技术发展过快，企业在节奏和决心上存在错配
• 自建效率低下：企业自建 AI 解决方案的成功效率是外部专业供应商的 1/3
• 前台应用效果不佳：虽然期望 AI 在前台工作带来价值，但现在证明有效的主要是后台自动化
• 员工与管理层利益冲突：CEO 希望 AI 降本增效，但员工担心失业，会自己采购 AI 工具而不使用企业内部的 AI 系统

企业 AI 探索历程

• 早期阶段：全参数微调、预训练（算力要求高）
• 中期发展：微调、强化学习
• 当前状态：不再关注模型本身，转向各种 Agent（营销 Agent、客服 Agent、数据 Agent 等）

智能体（Agent）的定义与现状

Gartner 报告对智能体的严格定义

• 智能体洗白现象：许多低代码产品、RPA 产品重新包装为智能体概念
• 非智能体的产品：
  • 模型本身不是智能体
  • RPA 不是智能体
  • 仅结合 RAG 的产品不是智能体
  • 简单的意图分发 chatbot 不是智能体

真正智能体的核心特征

• 完整闭环：感知 → 思考 → 决策 → 行动 → 反思
  • 思考：面向任务主动选择规划路径
  • 反思：过程中发现问题及时修正
• 企业客户不关心技术黑盒，只关心端到端的解决方案和确定性的高精度结果

C 端与 B 端的差异
Agent 看上去效果很好, 但是要抽卡, C 端声量高，但企业侧落地率低

• B 端要求：
  • 确定性、高精度场景
  • 不接受”抽卡”式的随机结果
  • 需要在高精度下解决企业问题

大模型解决的核心问题

• 开放式场景：大模型主要解决开放式场景问题
• 确定性场景不适用：规则明确、容错率低的场景不建议使用大模型, AI 无法生成100%正确的答案
• 传统信息化的局限：如果场景非常确定，传统企业信息化建设已能满足需求, 不需要用大模型, 但AI 可以改善交互体验，但会带来精度下降和不确定性, 是不符合企业要求的, 看下来目前 AI 对企业侧还没有完全 ready

市场机遇与政策支持

政策红利

• 人工智能+ 政策：类比 10 年前的”互联网+”政策，催生了 BAT 等头部企业
• 具体目标：2027 年实现 70% 以上的终端智能和智能体应用
• 市场空间：政策落地后将有配套实施政策，市场需求旺盛
• 供给不足：供给侧还无法完全解决市场需求, 有巨大的空间
• 蓝海机遇：怎么为企业和个人提供巨大的商业化价值

不同层级的价值需求

企业 AI 价值价值是什么?

• 企业层面：管理价值，战略部署实施，标准程度低但企业价值高
• 团队层面：协同价值，解决部门间沟通协同、部门墙等问题
• 个人层面：降本增效，包容程度高但企业价值低

从下到上, AI 对企业的价值越高; 从上到下, 标准化程度越高

• 效率瓶颈：企业效率瓶颈不在个人，而在部门间协同
• 沟通策略：与不同层级人员沟通需要针对其关注点

价值实现的挑战

中国开源模型发展迅速,许多企业开始自己部署开源模型（如文心一言、千问等）

• 采购额度低：上半年公开招投标的大模型一体机采购额仅 1400 万
• 热度与实际落地的差距：虽然 AI 热度很高，但企业真正大额采购和使用的比例很低
• 根本原因：企业需要的不是模型本身，而是场景化的价值和可量化的提升

商汤的 AI 原生产品策略

• 能力工程：底层技术能力
• 数据飞轮：数据处理和循环利用
• 交互优化：用户体验提升
• 工作流协作：企业流程整合

合作伙伴策略

• 行业 Know-how：与垂直领域合作伙伴结合
• 专业分工：商汤专注底层 AI 能力，合作伙伴提供行业专业知识
• 创业趋势：越来越多行业专家选择 AI 创业，寻求专业 AI 公司合作

AI 面向个人使用工具的愿景

• PC 时代：Office 套件，基于电脑能力实现专业模板和原子化能力
• 互联网时代：云协同，垂直场景工具（如 figma）
• AI 时代：跨平台、跨数据源，从过程交付到价值交付

AI 时代的特点

• 数据处理能力：处理大量非结构化、结构化数据
• 知识关联：强大的知识关联能力
• 场景适配：复杂场景、多样场景的理解和适配
• 人机协同：结果导向的人机协同工作模式

商汤数据分析智能体产品

产品整体图

• 2024年1月：发布国内第一个数据分析智能体, (那时候还没有智能体这个概念)
• 核心发现：大模型具有强大的工具调用能力
• 技术能力：
  • 调用本地电脑和沙盒
  • 代码编写能力
  • 数据可视化
  • 文件分析

给跟大模型离的不是那么近的用户群体做推广

• 真实用户：老师、学生、医生、制造业管理者、大巴司机等
• 用户特点：日常工作中与 AI 接触不多，但发现产品能实际解决问题
• 产品迭代：从 1.0 对话框产品模式到 2.0 针对简单/复杂场景数据分析能力，计划年底推出 3.0, 仍需要平衡模型与用户体验

产品精度保证

技术路径选择

为什么不选择 ChatBI/Text2SQL：

• SQL 局限性：SQL 主要用于数据库查询，不适合业务数据分析
• 精度问题：SQL 语言数据量有限，模型精度只有 80% 多，企业无法接受
• 数据库依赖：需要成熟数据库，但很多企业数据以表格、文档、图片形式存在, 即使头部公司的数据库建设也不完善

对于企业用户推广:

• 客户验证：头部客户几百个真实用户实测
• 用户角色：运营、商务等业务人员
• 精度要求：95% 以上准确率，保证企业侧可用性

C 端到 B 端的转化路径

• 增量价值：数据分析为员工提供增量价值，不会威胁工作
• 实际案例：销售人员用于商机动态管理和查询
• 采购动机：业务部门主动要求私有化部署或系统对接
• 正向激励：帮助员工更好管理工作，对 KPI 和职业发展有正向作用

突破传统模式

• 自下而上：业务部门主动找到产品方
• 打破壁垒：解决自顶向下和自底向上的矛盾

技术精度突破

• 百分百准确率：大模型做不到 100%, 但是在语义相对清晰的情况下，大模型调用工具可达到 100% 准确率
• 适用场景：
  • 持续计算
  • 数据匹配
  • 数理计算
  • 异常检测
• 前提条件：用户语义相对清晰

企业问题解决

• 系统连接：连接企业系统和本地数据
• 行业知识结合：结合企业和行业 Know-how 进行深度分析
• 数仓集成：与企业数据仓库结合

失败案例分析

金融公司财务部门推广失败：

• 容忍度低：财务数字绝对不能出错, 场景容忍度非常低
• 专业性高：财务人员操作极其专业，10 秒能解决的问题觉得 AI 太慢
• 用户反馈差：导致后续无人使用

成功场景特征

• 增量价值明显：对用户有明显的增量价值
• 容忍度较高：场景容忍度比较高
• 适用场景：
  • 企业运营：趋势分析报告、供应链管理
  • 商务产品：不是非黑即白的工作环节
  • 数据分析能力不强的业务人员

传统 BI 的问题

• 低代码困境：
  • 专业开发人员觉得拖拉拽太复杂，宁可写代码
  • 业务人员觉得拖拉拽太复杂，宁可找人帮忙
• 定位模糊：既要又要还要，导致上不下的产品定位

产品功能优化

二次编辑能力

• 核心需求：AI 生成结果不是 100%，但最终交付必须是 100%
• 支持格式：Excel、PPT、文本等可二次编辑文档
• 表格编辑：针对格式、数字、颜色等的二次编辑功能

用户体验优化, 相比精度提升 1-2 个点，快速编辑功能用户感知更强, 显著提高用户黏性

任务规划模块（2.0 功能）

开发背景

• 用户调研发现：60% 用户满意，40% 觉得不可用
• 不可用原因：
  • 用户不知道自己的需求
  • 分析数据不全
  • 无法给出更好的分析结果

解决方案

• 意图完善：判断用户意图是否完整，意图不完整的话, 通过引导式方式帮助用户明确需求
  • 数据补充：通过数据调用、联网检索等获取更多专业数据
• 任务拆解：帮助用户做分析思路大纲拆解,用户确认后给出最终结果

任务规划的产品理念

• 像向领导汇报工作一样，先确认需求再执行
• 解决一句话生成复杂结果但需求不清晰的问题
• 避免等待很长时间后发现结果不符合预期

商业模式与合作策略

• 商汤优势：算法、ToB 交付能力
• 商汤劣势：垂直领域行业 Know-how
• 策略选择：专注行业适应性强的通用场景

行业覆盖

• 通用性强：数据分析流程相对通用，类似代码
• 广泛应用：教育、医疗、金融、零售等各行各业
• 合作模式：与合作伙伴结合行业 Know-how，商汤提供技术底层

AI vs 传统 BI 的差异

• 定位差异:
  • AI 不是要代替 BI, AI 主要是做数据库清洗整合、跨系统融合, 在已有数据要素基础上，结合行业 Know-how 做深度分析
• 推动方式差异:
  • 传统 BI：IT 部门牵头
  • AI 方案：业务部门发起，IT 部门配合落地部署

解决的问题:

• 平台与业务部门协调：解决过去平台和业务部门关系不友好的问题
• 双赢结果：帮助平台部门完成 KPI，帮助业务部门找到有用产品

客户案例分析

头部消费电子公司案例

• 时间线：2023年7月接触，年底正式上线
• 业务痛点：
  • SMB 部门大量业务运营数据分散在各系统
  • 业务人员不擅长 Python 数据分析
  • IT 提单需要 2 周到 1 个月才能生成报告, 业务很难快速发展

解决方案与效果

• 实施周期：1 个月系统设计，2 个月内完全上线 POC，月底付费
• 人力投入：仅需 2 人，传统 BI 可能需要 10 人以上
• 效果提升：
  • 分析周期缩短 90% 以上
  • 超过 70% 业务人员明显受益

企业服务方法论

• 头部企业服务流程
  1. 业务部门试用：优先找业务部门
  2. 需求收集：收集业务需求
  3. 内部部署：与 IT 人员共同构建平台
  4. 种子用户测试：内部招募种子用户
  5. 大批量上线：测试成功后大规模推广
• 小企业服务模式
  • 轻量化推广：相对简化的推广流程 saas

时间优化, 从最早的 3 个月缩短到最快 2 个月, 但私有化还是很难

市场推广策略

客户沟通重点

• 不谈技术：不讲模型、不讲 benchmark
• 关注价值：重点讲案例、效率提升、收入增长

客户选择标准

• 有资金实力：有预算支持
• IT 实力：有一定的 IT 实施能力
• 合作意愿：愿意共建和探索
  比如金山

市场推广节奏

• 当前阶段：头部企业和C 端用户为主
• 中腰部市场：预计 2026-2027 年才会完全起来
• 策略重点：与行业最强企业合作，打造标杆案例后向下推广

总结与展望

• 从炫技到实用：AI 产品必须解决实际问题，创造可量化价值
• 场景选择关键：选择合适的应用场景比技术本身更重要
• 价值闭环：从技术能力到用户价值到商业价值的完整闭环

Swift、SwiftUI 与 SwiftData：走向成熟的 2025

在过去的几天里，我回顾了这一年来 Swift、SwiftUI 以及 SwiftData 的演进。总的感觉是：惊喜虽不算多，但“成熟感”却在不经意间扑面而来。

毋庸置疑，Swift 今年的重头戏在于改善并发编程的体验。尽管新增的选项和关键字在短期内又给开发者带来了不小的困扰，但经过这几个月的讨论与实践，社区已经显现出逐渐总结出新范式实践路径的趋势。我不认为新范式被确立且广泛接受会是一个简单、迅速的过程，但或许再过一两年，开发者对 Swift 的讨论重心将从并发转向跨平台，届时 Swift 也将迈入全新的发展阶段。

今年 SwiftUI 的更新重心大多集中在 Liquid Glass 的适配上。受限于系统初期的实现，显示效果起初并不尽如人意，但在 iOS 26.2 版本发布后，性能与稳定性都有了显著改善。坦率地说，对于今年 SwiftUI 没有引入更多革命性的新功能，我个人是挺高兴的。这让框架团队和开发者都能获得一点喘息之机，去进一步消化这个框架。在现阶段，解决遗留问题、优化性能与稳定性，远比一味堆砌新特性更有意义。

“变化较小”在 SwiftData 身上体现得尤为明显。但我认为 SwiftData 今年的表现尤为值得肯定，特别是许多改进与新功能都向下适配到了更早的系统版本。真希望它在三年前初次发布时，就能具备现在的状态。尽管 SwiftData 目前仍缺失一些关键功能，但对于相当比例的项目而言，它已经足以胜任。有了这个稳固的基础，其未来几年在性能与功能上的提高非常值得期待。

对于 2025 年 Swift 三件套的交出的答卷，我个人是满意的，不知你的感受如何？

这是本年度的最后一期周报，由衷感谢各位一年的陪伴与厚爱。

祝大家新年快乐，Happy Coding!

本期内容 | 前一期内容 | 全部周报列表

🚀 《肘子的 Swift 周报》

每周为你精选最值得关注的 Swift、SwiftUI 技术动态

• 📮 立即订阅 | weekly.fatbobman.com 获取完整内容
• 👥 加入社区 | Discord 与 2000+ 开发者交流
• 📚 深度教程 | fatbobman.com 探索 200+ 原创文章

活动

iOS Conf SG 2026

下个月（1 月 21 日 - 23 日），iOS Conf SG 将在新加坡举行。我也将前往现场，并作为嘉宾进行主题为 “Using SwiftUI as a Language” 的演讲——不仅关于代码，更是关于思维方式的转换。

如果你也在附近，或者计划前往，欢迎来现场打招呼！组委会专门为我的读者提供了优惠：Fatbobman 读者专属九折优惠链接

近期推荐

我和 CloudKit 的这八年：从开源 IceCream 到商业应用实战

我一直认为，所谓的苹果生态是由很多的硬件、软件、服务、人文、气质等综合构建起来的。在这其中，CloudKit 无疑是非常重要的一环。而且对于开发者来说，用好 CloudKit 不仅可以给用户更好的体验，也能低成本的为自己的应用带来创新。

IceCream 作者 Cai Yue 分享他与 CloudKit 八年的开发历程：从 2017 年开源 IceCream 并获得 Apple 官方认可，到将 CloudKit 应用于 Music Mate 和 Setlists 等商业项目的实战经验。文章深入探讨了 CloudKit 的核心优势、关键局限以及进阶玩法。

---

Swift 2025 年度总结 (What's new in Swift: December 2025 Edition)

这是一篇面向 Swift 社区的年度收官综述文章，由 Tim Sneath 和 Dave Lester 撰写，系统回顾了 2025 年 Swift 生态在语言特性、平台覆盖与社区建设方面的关键进展。

文章不仅总结了 Swift 6.2 在并发模型上通过更温和的默认策略降低使用门槛，同时继续推进 C++ 互操作与内存安全能力；更重要的是，从 Android、WASM、Windows、BSD、嵌入式到 AWS 等方向的持续投入，反复强化了一个清晰信号——Swift 已不再只是围绕 Apple 平台展开的语言。

或许你未必会认同其中的每一项变化，但在迈入第二个十年后的第一个年头里，Swift 依然交出了一份相当扎实的答卷。

---

关于 SwiftUI 的讨论 (My PM insisted we switch to SwiftUI for a massive legacy app rewrite. The result is exactly what you'd expect)

几天前无意间在 Reddit 上看到的帖子，作者对 PM 轻易选择 SwiftUI 有所抱怨，认为其无法胜任他们一个七年前开发的应用转换。对于这个观点我不置可否，但评论区的走向却出乎意料——绝大多数参与者都坚定地站在了 SwiftUI 的一边。

大量开发者认为：

• SwiftUI 本身已经足够成熟，问题出在实施方式上
• 应该渐进式迁移，而不是一次性重写
• 避开 SwiftUI 的弱项——比如可以保留 UIKit 导航，只迁移视图层
• 多个大型项目（10+ 年历史）已成功完成迁移

这个帖子展现了一个出乎我预料的现实：SwiftUI 在实际生产环境中的采用率比我们想象的高得多；开发者社区对 SwiftUI 的信心已经建立。在 2025 年底，“SwiftUI 难堪大任”的论调或许已经站不住脚了。

作为 SwiftUI 框架的推崇者，我既喜欢该框架，也很清楚它仍有很长的路要走。如果你仍在犹豫是否应该在 SwiftUI 上下功夫，或许可以看一下我在去年写的《几个常见的关于 SwiftUI 的误解》——这篇文章讨论的很多误解，恰好在这次 Reddit 讨论中得到了印证。

---

非 Sendable 优先设计 (Non-Sendable First Design)

随着 Swift 6 时代的到来，开发者逐渐养成了一种惯性：要么让类型符合 Sendable，要么给它套上 @MainActor 或 actor。在这篇文章中，Matt Massicotte 提出了一个极具启发性的哲学：“非 Sendable 优先设计”。

这一思路的关键在于对“隔离（Isolation）”的重新认识：隔离本身是一种约束。当一个类型被标记为 @MainActor，它实际上就失去了在非 UI 环境下进行同步调用的自由度。相比之下，一个非隔离、非 Sendable 的普通类型反而具有更高的通用性——它可以被任意 Actor 持有，并在其内部安全地进行同步访问，同时也更容易遵循 Equatable 等基础协议，而无需处理跨隔离域带来的复杂性。

随着 Swift 引入 NonisolatedNonsendingByDefault，这种“非 Sendable 优先”的设计路径不再像过去那样笨重或别扭，反而逐渐显现出其优势：以更少的隔离、换取更清晰的语义与更低的架构负担。这或许并非适用于所有场景，但在 Swift 6 之后，它已经成为一种值得认真考虑的、符合语言直觉的“减法”方案。

---

使用 Registry 加速依赖解析 (Resolving Swift Packages faster With Registry from Tuist)

传统的 SPM 依赖解析是基于 Git URL 的，Xcode 需要克隆整个 Git 仓库来获取版本信息和代码，这在依赖较多（如 Firebase）时非常耗时。而 Registry 是苹果定义的另一种规范：通过包的标识符（ID）直接下载特定版本的归档文件，跳过了繁重的 Git 操作。Tuist 最近宣布将其 Swift Package Registry 功能向所有开发者开放，最大的变化是现在无需登录或创建 Tuist 账号即可使用。

Lee Young-jun 实测发现，使用 Registry 后，依赖解析（Installation）时间缩短至原来的约 35%；但项目生成与构建阶段并未获得同等收益，甚至略有回退。在 GitHub Actions 中配合缓存使用时，二次构建的依赖安装时间则从 53s 降至 11s，优势主要体现在 CI 场景。

总体来看，Tuist Registry 并非“全流程加速器”，而是一个专注于依赖解析与缓存友好性的优化点。如果你的项目依赖数量庞大、CI 成本较高，它值得优先尝试。

---

iOS Timer 与 DispatchSourceTimer 选择与安全封装技巧｜有限状态机防止闪退

很多开发者在处理 DispatchSourceTimer 时，最头疼的就是它那“易碎”的状态：调用顺序稍有不对便会引发闪退。ZhgChgLi 在本文中针对这种极其敏感的状态管理提出了工程化的解决方案。文章详尽列举了导致崩溃的五大常见场景（如重复 resume、suspend 状态下直接释放等），并分享了如何利用有限状态机 (FSM) 封装操作，从逻辑层屏蔽非法调用，同时配合私有串行队列确保多线程环境下的调用安全。

这是一篇引导读者从“写代码”转向“做设计”的实战案例。它不仅讲清了 GCD 定时器的正确使用方式，更展示了如何借助设计模式，将一个“危险”的底层 API，封装为语义清晰、使用安全、可长期维护的工业级组件。在 Swift Concurrency 日益成为主流的今天，理解并优雅地封装这些底层 GCD 工具，依然是高级 iOS 开发者的重要基本功。

工具

ml-sharp：照片秒变 3D 场景

苹果在上周开源了 SHARP (Sharp Monocular View Synthesis)，一个能在不到 1 秒内将单张 2D 照片转换为 3D 场景的 AI 模型（模型大小 2.8 GB）。相比之前的最佳模型，视觉质量提升 25-34%，速度提升 1000 倍。

社区普遍认为 SHARP 可能用于未来版本的空间照片功能。目前 iOS 26 的 Spatial Scenes 使用 Neural Engine 进行深度重建，而 SHARP 采用更先进的 3D Gaussian Splatting 技术，质量显著提升。

模型支持 CPU/CUDA/MPS 运行，已有开发者在 M1/M2/M3 Mac 上成功运行。输出的 .ply 文件兼容各种 3DGS 查看器，Vision Pro 用户可通过 Metal Splatter 直接查看效果。

尽管苹果在通用语言大模型上不如竞争对手惊艳，但在垂直场景的 AI 模型上，凭借硬件深度整合与明确的应用导向，依然展现出强大的竞争力。

---

MaterialView: 突破 NSVisualEffectView 限制的毛玻璃视图

Oskar Groth (Sensei 作者)开源了 MaterialView，一个能够突破 NSVisualEffectView 限制的高度可定制毛玻璃视图库。通过逆向 Control Center 的实现，Oskar 实现了对模糊半径、饱和度、亮度和色调的完全控制，并撰写了详细的技术文章讲解实现原理。

与系统原生材质只能“选类型”不同，MaterialView 将模糊效果彻底参数化，允许开发者精确控制模糊半径、饱和度、亮度、tint 颜色与混合模式，并支持 active / inactive / emphasized / accessibility 等状态配置。这使得它非常适合用于侧边栏、浮层面板、工具窗口等对视觉一致性要求极高的场景。

该库同时支持 SwiftUI 与 AppKit，并提供了一个可实时调参的 Demo App，方便快速探索不同材质组合的效果。

需要注意的是，它依赖部分未公开的 Core Animation 能力（如 CABackdropLayer、CAFilter 等）。尽管这些 API 多年来相当稳定，但仍存在未来系统版本变动的潜在风险。

往期内容

• 周日小插曲 - #115
• 挖掘“沉默的专家”- #114
• 当 Android 手机『强行兼容』AirDrop - #113
• 毕业 30 年同学群：一场 AI 引发的“真假难辨”危机 - #112

💝 支持与反馈

如果本期周报对你有帮助，请：

• 👍 点赞 - 让更多开发者看到
• 💬 评论 - 分享你的看法或问题
• 🔄 转发 - 帮助同行共同成长

---

🚀 拓展 Swift 视野

• 📮 邮件订阅 | weekly.fatbobman.com 获取独家技术洞察
• 👥 开发者社区 | Discord 实时交流开发经验
• 📚 原创教程 | fatbobman.com 学习 Swift/SwiftUI 最佳实践

Lua 5.5.0 已经正式发布。所以，skynet 的 Lua 版本也随之升级。

skynet 维护了一份修改版的 Lua ，允许在多个虚拟机之间共享函数原型。这可以节省初始化 Lua 服务的时间，减少内存占用。

跨虚拟机共享函数原型最困难的部分是函数原型会引用常量字符串，而 Lua 在处理短字符串时，需要在虚拟机内部做 interning 。所以 skynet 的这个 patch 主要解决的是正确处理被 interning 的短字符串和从外部导入的函数原型中包含的字符串共存的问题。具体方法记录在这篇 blog 中。

这个 patch 的副产品是允许在多个 Lua VM 间共享常量表。打了这个 patch 后，就可以使用 skynet.sharetable 这个库共享只读常量表了。

这次 Lua 5.5 的更新引入了 external strings 这个特性，已经大幅度提升了 Lua 加载字节码的速度。我比较倾向于在未来不再依赖额外的 patch 减少维护成本。所以建议新项目避免再使用共享常量表，减少对 patch 过的 Lua 版本的依赖。

---

Lua 5.5 基本上兼容 Lua 5.4 ，我认为绝大多数 skynet 项目都不需要特别改动。但在升级后，还是建议充分测试。注意：更新仓库后，需要用 make cleanall 清除 lua 的编译中间文件，强制 Lua 重新编译。直接 make clean 并不清理它们。

Lua 5.5 有几处更新我认为值得升级：

1. 增加了 global 关键字。对减少拼写错误引起的 bug 很有帮助。skynet 自身代码暂时还没有使用，但后续会逐步添加。

2. 分代 GC 的主流程改为步进式进行。过去版本如果采用分代模式，对于内存占用较大的服务，容易造成停顿。所以这类服务往往需要切换为步进模式。升级到 Lua 5.5 后，应该就不需要了。

3. 新的不定长参数语法 ...args 可以用 table 形式访问不定长参数列表。以后可以简化一部分 skynet 中 Lua 代码的实现。

摘要：在并发编程的江湖里，当一个位高权重的任务被迫等待一个无名小卒时，会发生什么？Swift 6.2 带来的 Task Priority Escalation APIs 就像是香香公主那惊心动魄的美貌，能让原本慵懒的后台任务瞬间“鸡犬升天”。本文将借大熊猫侯佩与香香公主的沙漠奇遇，为您解析 SE-0462 的奥秘。

0️⃣ 🐼 序章：回疆的慢车与急惊风

回疆，赛里木湖畔的数字荒原。

这里是系统资源的边缘地带，网络带宽如同细细的涓流。大熊猫侯佩正蹲在一块虚拟的岩石上，第 10086 次尝试刷新他的“高德地图导航”。

“这该死的路痴属性……”侯佩焦躁地拍了拍自己圆润的脑袋，顺手摸了一把头顶那倔强的黑毛，“还好，发际线依然坚挺，绝对没有秃。只是这下载速度，比蜗牛爬还慢。”

在他的视野里，代表下载任务的进度条（Task）是一个穿着破烂羊皮袄的老头，正赶着一辆破破烂烂的牛车，在 background（后台）优先级的泥潭里慢悠悠地挪动。

突然，天地变色。远处的数据流卷起狂沙，一支装备精良、杀气腾腾的皇家骑兵队（高优先级任务）呼啸而来，却被这辆破牛车死死挡在了单行道上。

骑兵队的为首者刚要发怒，却见那破牛车旁，不知何时站了一位白衣少女。她鬓边插着一朵天山雪莲，肌肤胜雪，虽然只是静静站着，却让周围狂暴的 CPU 周期瞬间变得温柔起来。

她是香香公主。

当那位皇家骑兵统领（Main Actor）看到香香公主竟然也在等待这辆牛车时，他立刻下令：“传令下去！给这破车换上法拉利的引擎！全军护送！谁敢让公主多等一秒，提头来见！”

刹那间，那辆原本属于 background 优先级的牛车，瞬间获得了 high 优先级的加持，快得连影子都看不清。

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

• 0️⃣ 🐼 序章：回疆的慢车与急惊风
• 1️⃣ 🚀 什么是任务优先级提升？
• 2️⃣ 🕵️‍♂️ 监控飞升：withTaskPriorityEscalationHandler
• 3️⃣ 🎛️ 手动干预：escalatePriority(to:)
• 4️⃣ 🐢 vs 🐇：自动还是手动？
• 5️⃣ 🛑 尾声：失控的无名氏

侯佩目瞪口呆，嘴里的竹笋掉在了地上：“这就叫……一人得道，鸡犬升天？这难道就是传说中的 Priority Escalation（优先级提升）？”;)

---

1️⃣ 🚀 什么是任务优先级提升？

在 Swift 的并发世界里，这叫 “优先级反转（Priority Inversion）”的自动消解。

香香公主（高优先级任务）需要等待那个破老头（低优先级任务）的结果（比如 Data Race 里的锁，或者是 await 一个结果）。如果系统不干预，高贵的公主就要在这个“低贱”的队列里无限期等待，这显然不符合皇家（UI 响应性）的体面。

于是，Swift 运行时会自动把那个老头的优先级提升，让他暂时拥有和公主一样的地位，直到他把事情做完。

SE-0462 赋予了我们监控这种“飞升”现象的能力，甚至允许我们手动干预。

2️⃣ 🕵️‍♂️ 监控飞升：withTaskPriorityEscalationHandler

“虽然飞升很爽，但那个赶车的老头得知道自己被‘提拔’了啊，不然他还以为自己在逛花园呢。”侯佩捡起竹笋，若有所思。

Swift 6.2 引入了 withTaskPriorityEscalationHandler，让任务能够感知自己是否“被动”变强了。

侯佩看着香香公主正在试图从一个慢速服务器获取最新的食谱（她最近想学做竹笋炒肉喂侯佩），于是写下了这段代码：

// 创建一个中等优先级 (medium) 的任务
let newsFetcher = Task(priority: .medium) {
    // 🛡️ 使用处理程序包裹你的业务逻辑
    try await withTaskPriorityEscalationHandler {
        // 这里是任务原本要做的苦力活
        // 比如去下载一个 JSON 数据
        let url = URL(string: "https://hws.dev/messages.json")!
        let (data, _) = try await URLSession.shared.data(from: url)
        return data
    } onPriorityEscalated: { oldPriority, newPriority in
        // 🚨 这里的闭包会在优先级发生变化时被调用
        print("天哪！公主在等我！我的优先级从 \(oldPriority) 飞升到了 \(newPriority)！")
        print("兄弟们，抄家伙，开足马力干活了！")
    }
}

香香公主眨着那双清澈如水的眼睛，好奇地问：“侯大哥，这意思是，一旦有人催这个任务，它自己就会知道？”

“没错。”侯佩解释道，顺便摆了一个自以为很帅的 Pose，“这就好比我在睡觉，如果只是普通人叫我，我理都不理；但如果是你叫我，我脑子里的这个 onPriorityEscalated 就会立刻触发，瞬间从‘死猪模式’切换到‘舔狗模式’……啊不，是‘战斗模式’。”

3️⃣ 🎛️ 手动干预：escalatePriority(to:)

通常情况下，优先级提升是自动发生的（比如高优先级任务 await 了低优先级任务）。但有时候，我们作为架构师，需要扮演“陈家洛”的角色，手动去推一把。

Swift 6.2 允许我们使用 escalatePriority(to:) 来手动提升某个任务的优先级。

// 侯佩看着下载进度条太慢，实在忍不住了
// 他决定动用特权，手动把优先级拉满
newsFetcher.escalatePriority(to: .high)

香香公主有些担忧：“可是，如果我们把它提升到了 high，后来又觉得不重要了，能把它降回去吗？”

侯佩摇了摇头，神色变得严肃起来（虽然脸上还粘着竹笋渣）：“妹子，江湖路是一条不归路。在 Swift 的任务调度里，优先级只能升，不能降。”

💡 技术要点： 你的 onPriorityEscalated 回调可能会被触发多次。比如从 low 升到 medium，再从 medium 升到 high。但这就像武功境界，一旦突破，就回不到从前了。这是为了防止系统调度的震荡。

4️⃣ 🐢 vs 🐇：自动还是手动？

香香公主看着那些在数据流中奔跑的任务，问道：“那我们是不是应该把所有任务都手动设为最高级？这样大家都很开心呀。”

侯佩叹了口气，语重心长地说：“傻丫头，如果人人都是 VIP，那就没有 VIP 了。如果所有任务都是 high，那 CPU 就会像陷入‘红花会’内乱一样，谁也抢不到资源。”

官方建议（Note）： 任务优先级提升通常是自动发生的，而且 Swift 做得很棒。虽然这个 API 给了我们手动的权力，但在绝大多数情况下，还是应该顺其自然，无为而治。除非你真的遇到了特殊的性能瓶颈。

就像香香公主的美，不需要刻意修饰，自然就能引得千军万马为之驻足。

5️⃣ 🛑 尾声：失控的无名氏

夕阳西下，赛里木湖波光粼粼。

经过优先级的调整，数据终于下载完成了。侯佩看着手里高清的地图，终于确认了自己的位置——好吧，他离目的地还有三千公里，果然又走反了。

就在这时，系统中突然窜出一个黑影！

那是一个失控的后台任务（Rogue Task），它像是个疯子一样在内存里乱窜，消耗着宝贵的电量，却又不干正事。

“站住！”侯佩大喝一声，想要通过代码杀掉这个进程，“你是哪个部门的？叫什么名字？”

然而，那个任务只是留下一串乱码，继续狂奔。侯佩尴尬地发现，他创建这个任务的时候，忘记给它起名字了。在调试器里，它只是一个冷冰冰的内存地址。

“这就尴尬了，”侯佩挠了挠头，看着香香公主投来的疑惑目光，“我想教训它，却连它叫‘阿猫’还是‘阿狗’都不知道。”

香香公主轻轻一笑，指着下一章的预告说：“侯大哥，别急，听说下一招能给它们每人发一张身份证。”

（欲知后事如何，且看下回分解：Task Naming —— 也就是给任务起个响当当的绰号，好让你在它闯祸时能指名道姓地骂它。）

做独立产品这件事，说起来容易，真动手了才知道水有多深。这是一个独立开发者将职场小需求变成主力产品的真实故事。我们将跟随 Zipic 作者十里的视角，一起回顾产品从 0 到 1 的全过程。本篇聚焦产品设计与决策思考。

Mac App Store 固然使用简单，但可能并不适合所有的产品。本文中，我们将跟随 Zipic 作者十里的视角，来解决一款 macOS 独立应用的分发与售卖问题。

图片压缩软件还有什么技术难点？本文充满了硬核、实用的 macOS 开发经验，从 SwiftUI 的组件适配到 Core Graphics 的底层应用，从 Raycast 扩展的集成到 PDF 压缩的实现，不仅解决了性能瓶颈，更让原生体验达到了极致。