阅读视图

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

iOS日志系统设计

1 为什么需要日志

软件系统的运行过程本质上是不可见的。绝大多数行为发生在内存与线程之中。在本机调试阶段,我们可以借助断点、内存分析、控制台等手段直接观察系统状态;而一旦进入生产环境,这些能力几乎全部失效。此时,日志成为唯一能够跨越时间和空间的观测手段

但如果进一步追问:日志究竟解决了什么问题? 这个问题并没有那么简单。日志的核心价值并不在于文本本身,而在于可见性。它最基础的作用,是让这些不可见的行为“显影”。一次简单的日志输出,至少隐含了三类信息:时间、位置、描述。

这也是我们不建议使用简单 print 的原因:结构化日志在每次记录时,都会自动携带这些关键信息,从而形成稳定、可检索的观测数据。

之后当系统规模变大、异步逻辑增多时,单条日志已经很难解释问题。真正有价值的,是一组日志所呈现出的因果关系. 在这一层面上,日志更像是事件证据,用于在事后还原一段已经发生过的执行流程。

接下来,我们将从这些问题出发,逐步讨论一套面向真实生产环境的日志与可观测性设计。

2 日志系统

尽管日志在实践中无处不在,它本身仍然存在天然局限:日志是离散的事件,而不是连续的流程;日志天然是“事后信息”,而不是实时状态;在客户端等受限环境中, 如 应用可能随时被杀掉, 各种网络情况不稳定, 隐私与安全限制,日志可能丢失、不可获取、不可上报。

这意味着,日志并不是系统真相本身,它只是我们理解系统的一种工具。当系统复杂度继续提升,仅靠“多打日志”往往无法解决根本问题。

2.1 范围与功能

这样我们应该勾勒出日志系统的一些边界范围.

  1. 不必要求日志的「绝对可靠上报」
  2. 不通过日志修复「系统设计问题」(业务依赖、生命周期、指责转移错误)
  3. 不将日志系统演化成「消息系统」(不持久化、不通过日志兜底)

所以我们通过边界范围基本确定了我们日志系统的一些要求:

  • 结构化并非文本化: 日志首先应该是结构化数据,而不是简单字符串。文本只是表现形式,结构才是核心价值.每条日志必须具备稳定的时间、位置、级别与上下文.日志应当天然支持检索、过滤与关联.
  • 本地优先, 而非远端依赖: 本地记录必须是同步、低成本、稳定的.远端上报只能是 best-effort 行为.系统不能因为远端日志失败而影响主流程

2.2 系统架构

LoggerSystemArchitectureDiagram.svg

我们刻意限制了日志系统的职责范围,使其始终作为一个旁路的、可退化的基础设施存在。这些约束并非功能缺失,而是后续实现能够保持稳定与可演进的前提。所有依赖关系均为单向:日志系统不会反向调用业务模块或基础设施。

3 本地日志

在整体架构中,本地日志被视为整个日志系统中最基础、也是最可靠的一环。无论远端日志是否可用、网络环境是否稳定,本地日志都必须能够在任何情况下正常工作。

因此,在实现层面,我们选择优先构建一套稳定、低成本、符合平台特性的本地日志能力,而不是从远端导出反推本地设计。

3.1 为什么是os.Logger

在 iOS 开发里,print 很直观,但它更像调试手段:没有结构、难以检索、性能成本不可预测,也无法进入系统日志体系。进入生产环境后,这些缺点会被放大。

os.Logger 是系统级日志通道,它的设计目标本身就面向“可长期运行”的生产场景。本文中,os.Logger 指 Apple 的系统日志实现,Logger 指本文封装的对外 API。我们选择它,主要基于这些原因:

  • 低成本写入:日志被拆分为静态模板与动态参数,格式化发生在读取阶段,而非写入阶段
  • 系统工具链一致性:天然接入 Console、Instruments 与系统日志采集工具
  • 隐私与合规能力:原生支持隐私级别控制
  • 结构化上下文:时间戳、级别、分类、源码位置可以稳定保留

因此,日志可以作为“长期存在的基础能力”,在核心路径中持续开启,而不是仅限于调试阶段。需要说明的是,系统日志在生产环境的获取也受平台权限与采集策略限制,所以它是“本地可靠”,但并不是“远端万能”。

在使用层面,Logger API 保持简单直接:

let logger = Logger(subsystem: "LoggerSystem")
logger.info("Request started")
logger.error("Request failed", error: error)

3.2 附加功能

除了系统日志的即时写入,我们还提供了几个本地诊断能力:通过 LogStore / OSLogStore 进行日志检索(按时间、级别、分类)并支持导出为文本或 JSON;同时集成 OSSignpost / OSSignposter 作为性能事件记录方式,用于衡量关键路径耗时。这些能力不进入主写入路径,只在排查与分析时启用。

4 远端日志与 OpenTelemetry

4.1 OpenTelemetry 在客户端日志系统中的位置

OpenTelemetry 由 CNCF 托管,起源于 2019 年 OpenCensus 与 OpenTracing 的合并,并于 2021 年成为 CNCF 顶级项目。它并不是某一个具体 SDK,而是一套用于描述可观测性数据的开放标准,定义了日志、指标与链路追踪的统一语义与数据模型,并配套给出了标准化的传输协议(OTLP)。

在本章中,我们并不试图完整覆盖 OpenTelemetry 的体系,而是聚焦于其中与远端日志相关的部分:

日志数据在 OTel 语义下如何被结构化、如何被分组、以及如何被导出。

认证、上下文传播等问题会显著影响系统依赖关系,本文刻意将其延后,在下一章单独讨论。

4.1.1 Remote Logger 的最小闭环

下图展示了在 OTel 语义下,客户端远端日志链路的最小可用闭环

这一闭环的目标并非“可靠投递”,而是在客户端约束条件下,提供一条可控、可退化的日志导出路径

从数据流动的角度看,这条链路可以被抽象为:

LogRecord[]
  → LogRecordAdapter
  → ResourceLogs / ScopeLogs / LogRecords
  → ExportLogsServiceRequest (OTLP)
  → OTLP Exporter (HTTP / gRPC)

在这一结构之上,可以按需叠加增强能力,例如批处理、失败缓存或延迟调度,但这些能力不会改变日志的协议语义

4.1.2 结构化与分组:从 LogRecord 到 OTel Logs

在 OTel 模型中,LogRecord 仍然是最小的事件单元,用于描述“发生了什么”。

但真正的上传结构并不是一组扁平的日志列表,而是按以下层级组织:

  • ResourceLogs:描述日志产生的资源环境(设备、系统、应用)
  • ScopeLogs:描述产生日志的逻辑作用域(模块、库)
  • LogRecords:具体的日志事件

这一分组方式的意义在于:

  • 避免重复携带环境信息
  • 明确日志的来源与归属
  • 为后端聚合与分析提供稳定结构

在客户端侧,这一阶段通常通过一个 Adapter 或 Mapper 完成,其职责只是语义映射,而非业务处理。

4.1.3 批处理与调度:Processor 的职责边界

在日志被结构化之后,下一步并不是立刻发送,而是进入处理阶段。

LogRecordProcessor 位于这一阶段的入口位置。以 BatchLogRecordProcessor 为例,它负责:

  • 将多条日志聚合为批次
  • 控制发送频率
  • 降低网络与系统调用成本

需要注意的是,Processor 层体现的是策略位置,而不是协议逻辑。

它不关心日志如何被编码,也不关心最终通过何种方式发送,只负责决定什么时候值得尝试导出

4.1.4 导出边界:Exporter 作为协议适配层

LogRecordExporter 是远端日志链路中的协议边界

在这一层中,结构化日志会被转换为 OTLP 定义的 ExportLogsServiceRequest,并通过具体传输方式发送。常见实现包括:

  • OTLP/HTTP
  • OTLP/gRPC

无论采用哪种方式,Exporter 的核心职责都是一致的:

编码日志结构,并完成协议级发送。

它不感知业务上下文,也不参与重试策略之外的系统决策。

4.2 RemoteLogger 架构图

下面这张图是 RemoteLogger 在 OTel 语义下的最小闭环:

RemoteSinkSystem.svg

5 上下文边界

从 RemoteLogger 开始真正发日志的那一刻,日志系统就第一次碰到外部依赖:鉴权。它不是“可选附加项”,而是远端链路的必经之门。

5.1 鉴权

日志端点是基础设施入口(infra endpoint),它的目标是控制写入来源,而不是验证用户身份。因此更合理的鉴权方式是:IP allowlist、mTLS、ingestion key、project‑level key,配合采样与限流。这些机制与用户态解耦、无需刷新、不参与业务控制流,且失败也不会影响客户端主流程。

在这种模型下,日志系统只做一件事:携带已准备好的凭证。它不维护鉴权状态,也不触发刷新,更不等待鉴权完成。

5.1.1 当鉴权被卷入业务流程

问题发生在日志复用业务鉴权体系时:access token 短期、频繁刷新、刷新依赖网络与生命周期,而鉴权失败本身又需要被记录。直觉做法是“刷新后重试”,但这会形成典型的依赖循环:

Logger
  → RemoteExporter
     → AuthManager
        → RefreshToken
           → Network
              → Logger

这不是实现复杂的问题,而是依赖方向错误的问题:日志系统依赖了本应被它观测的系统,直接造成 auth blind zone(鉴权失败本身无法被观测的区域)

现实里,很多团队不得不复用业务鉴权,但这时唯一能做的是“隔离副作用”:不触发刷新、不重试鉴权、失败即丢弃,并保持凭证只读与短生命周期缓存。这样做无法消灭问题,却能把依赖循环缩到最小。

结论只有一句:日志系统只能消费鉴权结果,不能成为鉴权流程的一部分。

5.2 Traceparent

traceparent 是 W3C Trace Context 标准里的核心头部,用于跨进程传播 Trace。它不是日志系统的一部分,而是“流程上下文”的载体。日志系统只负责把它携带出去,而不负责生成、维护或推进它。

它的基本结构非常固定:

traceparent: {version}-{trace-id}-{parent-id}-{trace-flags}
  • version:版本号,当前常见为 00
  • trace-id:16 字节(32 hex)的全局 trace 标识
  • parent-id:8 字节(16 hex)的当前 span 标识
  • trace-flags:采样与调试标记(如 01 表示采样)

这四个字段共同决定“这条日志属于哪条 trace、处于哪一段 span 上下文”。

5.2.1 构造与传递

在客户端日志系统中,traceparent 应当被视为外部上下文

  • 它由业务流程或 tracing 系统生成
  • 它随着请求/事件生命周期变化
  • 它不由日志系统创建,也不由日志系统维护

日志系统只做一件事:在日志生成或导出时附带 traceparent,让后端能够把日志与 Trace 对齐。

这也意味着:日志系统不能尝试“修复” traceparent,也不能在缺失时伪造它。缺失就缺失,伪造会制造错误的因果链。

traceparent 的构造来自 tracing 系统(SDK 或上游服务),它会在一次请求开始时生成新的 trace-id,并在 span 变化时更新 parent-id。日志系统只需在“生成日志的瞬间”读取当前上下文并携带即可。

换句话说,traceparent 的生命周期与日志系统无关,而与业务流程一致。日志系统需要尊重这个边界,否则它会再次变成主流程的一部分。

5.3 Context 的角色

如果说 traceparent 是“具体的上下文载体”,那么 Context 是“上下文在系统里的容器与作用域”。它回答的不是“字段长什么样”,而是“这份上下文从哪来、到哪去、何时结束”。

在日志系统里,Context 只应当承担两件事:

  1. 携带流程信息,让日志具备可关联性
  2. 限定生命周期,避免上下文在系统内滞留

这意味着 Context 的设计重点不是“存什么”,而是“何时注入、如何传播、何时释放”。

更宽泛地看,Context 的生命周期其实是一种“作用域建模”。它既像 tracing 里的 active span,也像 DI 里的 scope:谁负责创建、谁负责结束、跨线程如何继承,这些都会直接决定 traceparent 的 parent-id 何时变化。换句话说,Context 的问题往往不是协议问题,而是作用域与生命周期策略的问题。

Context 最难的部分其实是作用域与注入方式:

  • 它和依赖注入(DI)的关系应该是什么
  • 在多线程/异步场景中,Context 的边界如何定义
  • Context 是否应该是显式传参,还是隐式绑定

这些问题没有一个完美答案,需要团队给出清晰的工程约定。

5.4 结语

这套日志系统的核心不是“更多日志”,而是“正确的边界”:本地优先、远端旁路、结构化可关联、上下文可控。真正决定系统稳定性的,不是某一个 API,而是你如何定义依赖方向与生命周期。最后想留下的一句话是:可观测性不是无限的,它永远受平台约束。

深入理解 Swift Concurrency:从 async/await 到隔离域

在 Swift 并发系统(Swift Concurrency)诞生之前,iOS 开发者的日常被回调(Callbacks)、代理(Delegates)和 Combine 填满。我们用这些工具来处理应用中大量的等待时间:网络请求、磁盘 I/O、数据库查询。它们虽然能解决问题,但代价是代码的可读性——嵌套的回调地狱(Callback Hell)和陡峭的 Combine 学习曲线让代码维护变得艰难。

Swift 的 async/await 引入了一种全新的范式。它允许开发者用看似同步的顺序代码来编写异步逻辑。底层运行时高效地管理着任务的暂停与恢复,而不再需要开发者手动在回调中穿梭。

但 async/await 只是冰山一角。Swift 并发模型的真正核心,在于它如何从根本上改变了我们对“线程安全”的理解——从管理线程(Threads)转向管理隔离(Isolation)。

本文将深入探讨这一体系,从基础语法到隔离域模型,再到实际开发中的最佳实践。

基础:暂停与恢复

异步函数(Async Function)  是这一模型的基础构建块。通过 async 标记,函数声明了它具有被“挂起”的能力。在调用时,await 关键字则是一个明确的标记,表示“在此处暂停,直到任务完成”。

func fetchUser(id: Intasync throws -> User {
    let url = URL(string"https://api.example.com/users/(id)")!
    // 执行权在此处交出,当前函数挂起
    let (data, _) = try await URLSession.shared.data(from: url)
    return try JSONDecoder().decode(User.self, from: data)
}

// 调用示例
let user = try await fetchUser(id: 123)
// fetchUser 完成后,代码才继续向下执行

这里的关键在于 挂起(Suspension)  而非 阻塞(Blocking) 。当代码在 await 处暂停时,当前线程并不会被锁死,Swift 运行时会利用这段空闲时间去处理其他工作。当异步操作完成,函数会从暂停的地方恢复执行。

并行:结构化并发

顺序执行 await 虽然直观,但在处理多个独立任务时效率低下。如果我们需要同时获取头像、横幅和简介,逐个等待会导致不必要的串行延迟。

async let 允许我们以声明式的方式并行启动任务:

func loadProfile() async throws -> Profile {
    // 三个任务立即同时启动
    async let avatar = fetchImage("avatar.jpg")
    async let banner = fetchImage("banner.jpg")
    async let bio = fetchBio()

    // 在需要结果时才进行 await
    return Profile(
        avatar: try await avatar,
        banner: try await banner,
        bio: try await bio
    )
}

这种方式既保留了代码的整洁,又实现了并行的高效。

如果任务数量是动态的(例如下载一个数组中的所有图片),则应使用 TaskGroup。它将任务组织成树状结构,父任务会等待组内所有子任务完成或抛出错误。这种层级关系被称为 结构化并发(Structured Concurrency) ,其最大优势在于生命周期管理:取消父任务会自动传播给所有子任务,且错误处理更加可预测。

任务管理:Task 的正确用法

编写了异步函数后,我们需要一个上下文来运行它们。Task 就是这个异步工作单元。它提供了从同步代码进入异步世界的桥梁。

视图层面的管理

在 SwiftUI 中,最推荐的方式是使用 .task 修饰符。它自动管理任务的生命周期:视图显示时启动,消失时自动取消。

struct ProfileViewView {
    var userIDString
    @State private var avatarImage?

    var body: some View {
        // 当 userID 变化时,旧任务取消,新任务启动
        Image(systemName"person")
            .task(id: userID) {
                avatar = await downloadAvatar(for: userID)
            }
    }
}

常见的反模式:不受管理的 Task

开发者常犯的一个错误是滥用 Task { ... } 或 Task.detached { ... }。这种手动创建的任务是“非托管”的。一旦创建,你就失去了对它的控制权:无法自动随视图销毁而取消,难以追踪执行状态,也难以捕获其中的错误。

这就像把漂流瓶扔进大海,你不知道它何时到达,也无法在发出去后撤回。

最佳实践

    1. 优先使用 .task 修饰符或 TaskGroup
    1. 仅在确实需要(如点击按钮触发)时使用 Task { },并意识到其生命周期的独立性。
    1. 极少使用 Task.detached,除非你明确知道该任务不需要继承当前的上下文(如优先级、Actor 隔离)。

核心范式转变:从线程到隔离

在 Swift 并发出现之前,不管是 GCD 还是 OperationQueue,我们关注的核心是 线程(Thread) :代码在哪个队列跑?是否在主线程更新 UI?

这种模型极其依赖开发者的自觉性。一旦忘记切换线程,或者两个线程同时访问同一块内存,就会导致 数据竞争(Data Race) 。这是未定义行为,可能导致崩溃或数据损坏。

Swift 并发模型不再询问“代码在哪里运行”,而是问:“谁有权访问这块数据?

这就是 隔离(Isolation)

Swift 通过编译器在构建阶段强制执行隔离规则,而不是依赖运行时的运气。底层依然是线程池在调度,但上层的安全由 Actor 模型保证。

1. MainActor:UI 的守护者

@MainActor 是一个全局 Actor,代表主线程的隔离域。它是 UI 框架(SwiftUI, UIKit)的领地。

@MainActor
class ViewModel {
    // 编译器强制要求:访问 items 必须在 MainActor 上
    var items: [Item] = [] 
}

标记了 @MainActor 的类,其属性和方法默认都在主线程隔离域中。这意味着你不需要手动 DispatchQueue.main.async,编译器会确保外部调用者必须通过 await 来跨越隔离边界。对于大多数应用,将 ViewModel 标记为 @MainActor 是默认且正确的选择。

2. Actor:数据孤岛

actor 是一种引用类型,它像类一样,但有一个关键区别:它保护其可变状态。Actor 保证同一时间只有一个任务能访问其内部状态,从而从根本上消除了数据竞争。

actor BankAccount {
    var balance: Double = 0
    
    func deposit(_ amountDouble) {
        balance += amount // 安全:Actor 内部串行访问
    }
}

// 外部调用必须等待,因为可能需要排队
await account.deposit(100)

可以将 Actor 想象成办公楼里的独立办公室,一次只能进一个人处理文件。

3. Nonisolated:公共走廊

标记为 nonisolated 的代码显式退出了 Actor 的隔离保护。它可以被任何地方调用,不需要 await,但也因此不能访问 Actor 的内部受保护状态。

数据的跨域传递:Sendable

隔离域保护了数据,但数据总需要在不同域之间传递。当一个对象从后台 Actor 传递到 MainActor 时,Swift 必须确保这一传递是安全的。

Sendable 协议就是这个通行证。它告诉编译器:“这个类型可以安全地跨越隔离边界”。

  • • 值类型(Struct, Enum) :通常是 Sendable,因为传递的是拷贝,互不影响。
  • • Actor:也是 Sendable,因为它们自带同步机制。
  • • 类(Class) :通常 不是 Sendable。除非它是 final 的且只有不可变属性。

如果试图在并发环境中传递一个普通的类实例,编译器会报错,因为它无法保证两个线程不会同时修改这个类。

隔离的继承与流转

理解 Swift 并发的关键在于理解 隔离继承

在启用了完整并发检查(Swift 6 / Approachable Concurrency)的项目中,代码执行的上下文通常遵循以下规则:

  1. 1. 函数调用:继承调用者的隔离。如果在 @MainActor 的函数中调用另一个普通函数,后者也在 MainActor 上运行。
  2. 2. Task { } :继承创建它的上下文。在 ViewModel(MainActor)中创建的 Task,其中的代码默认也在 MainActor 上运行。
  3. 3. Task.detached:斩断继承,在一个没有任何特定隔离的上下文中运行。

这也是为什么不要迷信 async 等于后台线程。

@MainActor
func slowFunction() async {
    // 错误:这虽然是 async 函数,但依然在 MainActor 运行
    // 这里的同步计算会卡死 UI
    let result = expensiveCalculation() 
    data = result
}

async 只意味着函数 可以 暂停,并不意味着它会自动切到后台。如果是 CPU 密集型任务,你需要显式地将其移出主线程(例如使用 Swift 6.2 的 @concurrent 标记或放入 detached task)。

常见误区与避坑指南

  1. 1. 过度设计 Actor:不要为每个数据源都创建一个 Actor。大多数时候,将状态隔离在 @MainActor 的 ViewModel 中已经足够。只有当确实存在跨线程共享的可变状态时,才引入自定义 Actor。
  2. 2. 滥用 @unchecked Sendable:不要为了消除编译器警告而随意使用 @unchecked Sendable。这相当于告诉编译器“闭嘴,由于我自己负责”,一旦出错就是难以调试的竞争问题。
  3. 3. 阻塞协作线程池:永远不要在 async 上下文中使用信号量(Semaphore)或 DispatchGroup.wait()。Swift 的底层线程池容量有限(通常等同于 CPU 核心数),阻塞其中一个线程可能导致死锁或饥饿。
  4. 4. 无脑 MainActor.run:很多开发者习惯在获取数据后写 await MainActor.run { ... }。更好的做法是直接将更新数据的函数标记为 @MainActor,让编译器自动处理上下文切换。

总结

Swift 的并发模型建立在三个支柱之上:

  1. 1. async/await:处理控制流,让异步代码线性化。
  2. 2. Task:结构化地管理异步工作的生命周期。
  3. 3. Actor & Isolation:通过隔离域在编译时消除数据竞争。

对于大多数应用开发,遵循简单的规则即可:默认使用 @MainActor 保护 UI 状态,使用 async/await 处理 I/O,利用 .task 管理生命周期。只有在遇到真正的性能瓶颈或复杂的共享状态时,才需要深入自定义 Actor 和细粒度的隔离控制。

编译器是你的向导,而非敌人。当它报出并发错误时,它实际上是在帮你规避那些曾在旧时代导致无数崩溃的隐形 Bug。

1月10日用户隐私保护新规出炉,政策解读

2026年1月10日,国家互联网信息办公室发布了《互联网应用程序个人信息收集使用规定(征求意见稿)》,进一步优化了个人隐私保护法案内容。

政策原文:mp.weixin.qq.com/s/epF6mh-Oc…

原文.png

一句话总结:这次的新政细化了隐私合规规则,堵住了一些规则漏洞,进一步保护用户隐私。对于大部分开展正规业务的开发者来说,无需特别的改动。后续可按渠道平台(华为、小米等)要求,做进一步调整

内容概览
1、明确禁止“无关场景调用相机/麦克风”,直击“偷听偷拍”乱象。——旧规:仅原则性要求“不得超范围收集”,但未明确哪些行为算违规。
2、位置权限分级管理:区分“实时定位”与“单次定位” ——旧规:仅笼统要求“最小必要”。
3、进一步强化了不允许获取用户全部相册权限,必须使用系统系框架Android SAF,只能获取用户授权后的部分照片。
4、操作系统厂商,需提供“精细化授权”选项,如 “仅本次允许”“仅今天允许”。
5、生物识别信息(人脸、指纹等)原则上只能本地存储,不能上传。除非法律允许或用户单独同意。
6、App运营者对第三方SDK负连带审核义务。用户向App提出对SDK的数据权利请求(如删除),App必须转达并督促SDK响应,不能再以“这是第三方SDK行为,与我无关”推责。
7、账号注销流程进一步简化:不得强制用户提供额外身份证明(如手持身份证、学历证明等)。堵住了一些App以“安全验证”为名设置注销门槛的做法。

下面是详细介绍

一、首次 明确禁止“无关场景调用相机/麦克风” —— 直击“偷听偷拍”乱象

  • 旧规:仅原则性要求“不得超范围收集”,但未明确哪些行为算违规。
  • 新规(第14条)
    • 必须“用户主动选择使用拍照、语音、录音录像等功能时”才能调用相机/麦克风
    • 禁止在用户停止使用相关功能后继续调用
    • 禁止在无关场景(如浏览商品页、看新闻)调用音视频权限

实质变化:这是首次以部门规章形式将“后台静默调用麦克风/摄像头”直接定性为违规。此前企业常以“预加载”“性能优化”为由辩解,今后不再成立。


二、位置权限分级管理:区分“实时定位”与“单次定位”

  • 旧规:仅笼统要求“最小必要”。
  • 新规(第14条)
    • 实时定位类(导航、外卖) → 调用频率必须“限于业务最低频度”;
    • 单次定位类(搜索、推荐、广告)仅允许调用一次,且需用户进入界面或主动刷新;
    • 原则上禁止申请“后台持续获取位置”权限(除非法律另有规定或确需)。

实质变化:终结了“只要用户开了定位,App就可高频后台上报位置”的灰色操作。例如,电商App在首页展示附近门店,只能触发一次定位,不能持续追踪。


三、强制使用系统级存储访问框架(如Android SAF)

  • 新规(第14条)
    • 用户上传图片/文件时,若系统提供标准存储访问框架(如Android的Storage Access Framework),App 不得再索要“相册”“存储”全权限
    • 即使因文件编辑/备份获得存储权限,也不得访问用户未主动选择的其他文件

实质变化:推动从“粗放式读取整个相册”转向“按需访问单个文件”,大幅降低隐私泄露面。这要求开发者重构文件上传逻辑。


四、操作系统需提供“精细化授权”选项(开发者需适配)

  • 新规(第14条)
    • 操作系统在弹窗征得用户同意时,应提供基于时间、频度、精度的授权选项(如“仅本次允许”“仅今天允许”“模糊位置”)。

实质变化:虽然责任在OS厂商,但开发者需确保App能兼容这些细粒度授权(例如用户选择“仅本次允许位置”,下次使用需重新申请)。否则功能将异常。


五、生物识别信息默认本地处理,禁止网络传输

  • 新规(第15条)
    • 人脸、指纹等生物特征信息,默认应在终端设备本地处理和存储
    • 不得通过网络传输至服务器,除非:
      • 法律法规明确允许;或
      • 用户单独书面同意(且目的充分必要)。

实质变化:许多App当前将人脸照片上传服务器进行比对(如刷脸登录),今后必须评估是否真有必要。若非必要,必须改为本地验证(如Face ID/指纹API)。


六、SDK责任穿透:App运营者对第三方SDK负连带审核义务

  • 新规(第19条)
    • App运营者必须审核嵌入的SDK,确保其行为符合公示规则;
    • 用户向App提出对SDK的数据权利请求(如删除),App必须转达并督促SDK响应

实质变化:不能再以“这是第三方SDK行为,与我无关”推责。开发者需建立SDK准入机制,并保留沟通记录。


七、账号注销流程进一步简化(禁止设置障碍)

  • 新规(第18条)
    • 注销后15个工作日内必须删除或匿名化数据
    • 不得强制用户提供额外身份证明(如手持身份证、学历证明等);
    • 若使用统一账号体系(如微信/QQ登录),必须支持单App注销,不影响其他服务。

实质变化:堵住了一些App以“安全验证”为名设置注销门槛的做法。

Claude Code 四大核心技能使用指南

本文详细介绍 Superpowers、Feature-Dev、UI/UX Pro Max 和 Ralph Wiggum 四个强大技能的使用方法,帮助开发者充分发挥 Claude Code 的潜力。


目录

  1. 技能系统概述
  2. Superpowers:完整开发工作流
  3. Feature-Dev:功能开发指南
  4. UI/UX Pro Max:设计智能系统
  5. Ralph Wiggum:迭代循环开发
  6. 技能选择指南
  7. 总结

技能系统概述

Claude Code 的技能系统是一套可组合的专业工作流,它们在特定场景下自动激活,帮助开发者以系统化的方式完成复杂任务。

核心原则

如果你认为某个技能有哪怕 1% 的可能适用于当前任务,
你就必须调用它。这不是建议,而是强制要求。

技能优先级

当多个技能可能适用时,按以下顺序使用:

  1. 流程技能优先(brainstorming、debugging)- 决定如何处理任务
  2. 实现技能其次(frontend-design、mcp-builder)- 指导具体执行

Superpowers:完整开发工作流

什么是 Superpowers?

Superpowers 是一套完整的软件开发工作流,基于可组合的"技能"构建。它从你启动编程代理的那一刻开始工作,不是直接跳入编码,而是先退一步理解你真正想要做什么。

安装方式

Claude Code 用户:

# 注册 marketplace
/plugin marketplace add obra/superpowers-marketplace

# 安装插件
/plugin install superpowers@superpowers-marketplace

# 验证安装
/help

核心工作流

Superpowers 包含七个阶段的完整开发流程:

1. Brainstorming(头脑风暴)

在编写代码之前激活,通过问答细化粗略想法,探索替代方案,分段展示设计供验证。

关键原则:

  • 一次只问一个问题
  • 优先使用选择题
  • 无情地应用 YAGNI(你不会需要它)
  • 总是提出 2-3 种方案后再定案

流程:

理解项目状态 → 逐个提问细化想法 → 提出2-3种方案
→ 分段展示设计(每段200-300字)→ 验证后保存设计文档

2. Git Worktrees(Git工作树)

设计批准后激活,在新分支上创建隔离的工作空间,运行项目设置,验证干净的测试基线。

3. Writing Plans(编写计划)

将工作分解为小任务(每个2-5分钟),每个任务都有:

  • 精确的文件路径
  • 完整的代码
  • 验证步骤

4. Subagent-Driven Development(子代理驱动开发)

这是 Superpowers 的核心机制:

每个任务分派新的子代理 → 两阶段审查:
  1. 规格合规审查(代码是否符合规格)
  2. 代码质量审查(代码是否写得好)

优势:

  • 每个任务有新鲜的上下文(无污染)
  • 自动审查检查点
  • 子代理可以在工作前后提问

示例流程:

读取计划 → 提取所有任务 → 创建TodoWrite

任务1[分派实现子代理] → 子代理实现、测试、提交
  [分派规格审查子代理] → 确认代码符合规格
  [分派代码质量审查子代理] → 批准代码质量
  [标记任务完成]

任务2: ...

所有任务完成后 → 最终代码审查 → 完成开发分支

5. Test-Driven Development(测试驱动开发)

Superpowers 强制执行 RED-GREEN-REFACTOR 循环:

写失败测试 → 观察失败 → 写最小代码 → 观察通过 → 提交

铁律:

没有先失败的测试,就没有生产代码

在测试之前写了代码?删除它。从头开始。

常见借口及真相:

借口 真相
"太简单不需要测试" 简单代码也会出错,测试只需30秒
"我之后会测试" 立即通过的测试什么也证明不了
"删除X小时的工作太浪费" 沉没成本谬误,保留未验证的代码才是技术债务
"TDD太教条" TDD才是务实的,"务实"的捷径=生产环境调试=更慢

6. Code Review(代码审查)

在任务之间激活,根据计划审查代码,按严重程度报告问题。关键问题会阻止进度。

7. Finishing Branch(完成分支)

任务完成时激活,验证测试,提供选项(合并/PR/保留/丢弃),清理工作树。

核心哲学

  • 测试驱动开发 - 始终先写测试
  • 系统化优于临时 - 流程优于猜测
  • 降低复杂性 - 简单是首要目标
  • 证据优于声明 - 在宣布成功前验证

Feature-Dev:功能开发指南

什么是 Feature-Dev?

Feature-Dev 是一个系统化的功能开发技能,帮助开发者深入理解代码库、识别并询问所有不明确的细节、设计优雅的架构,然后实现。

七个阶段

Phase 1: Discovery(发现)

目标: 理解需要构建什么

操作:

  1. 创建包含所有阶段的 todo 列表

  2. 如果功能不清晰,询问用户:

    • 要解决什么问题?
    • 功能应该做什么?
    • 有什么约束或要求?
  3. 总结理解并与用户确认

Phase 2: Codebase Exploration(代码库探索)

目标: 在高层和底层理解相关现有代码和模式

操作:

  1. 并行启动 2-3 个 code-explorer 代理,每个代理:

    • 全面追踪代码,专注于理解抽象、架构和控制流
    • 针对代码库的不同方面
    • 包含 5-10 个关键文件列表

示例代理提示:

  • "找到与 [功能] 类似的功能并全面追踪其实现"
  • "映射 [功能区域] 的架构和抽象"
  • "分析 [现有功能/区域] 的当前实现"
  1. 代理返回后,阅读所有识别的文件以建立深入理解
  2. 呈现发现和模式的综合摘要

Phase 3: Clarifying Questions(澄清问题)

目标: 在设计前填补空白并解决所有歧义

这是最重要的阶段之一,不能跳过。

操作:

  1. 审查代码库发现和原始功能请求
  2. 识别未明确的方面:边缘情况、错误处理、集成点、范围边界、设计偏好、向后兼容性、性能需求
  3. 以清晰、有组织的列表向用户呈现所有问题
  4. 等待答案后再进行架构设计

Phase 4: Architecture Design(架构设计)

目标: 设计具有不同权衡的多种实现方案

操作:

  1. 并行启动 2-3 个 code-architect 代理,关注不同方面:

    • 最小变更:最小变化,最大复用
    • 清洁架构:可维护性,优雅抽象
    • 务实平衡:速度 + 质量
  2. 审查所有方案,形成哪个最适合此特定任务的意见

  3. 向用户呈现:

    • 每种方案的简要摘要
    • 权衡比较
    • 你的推荐及理由
    • 具体实现差异
  4. 询问用户偏好哪种方案

Phase 5: Implementation(实现)

目标: 构建功能

未经用户批准不要开始

操作:

  1. 等待用户明确批准
  2. 阅读前几个阶段识别的所有相关文件
  3. 按选定架构实现
  4. 严格遵循代码库约定
  5. 编写干净、文档完善的代码
  6. 随着进展更新 todos

Phase 6: Quality Review(质量审查)

目标: 确保代码简单、DRY、优雅、易读且功能正确

操作:

  1. 并行启动 3 个 code-reviewer 代理,关注不同方面:

    • 简单性/DRY/优雅
    • 缺陷/功能正确性
    • 项目约定/抽象
  2. 整合发现,识别你建议修复的最高严重性问题

  3. 向用户呈现发现并询问他们想怎么做(现在修复、稍后修复或按原样进行)

  4. 根据用户决定处理问题

Phase 7: Summary(总结)

目标: 记录完成的工作

操作:

  1. 将所有 todos 标记为完成

  2. 总结:

    • 构建了什么
    • 做出的关键决策
    • 修改的文件
    • 建议的下一步

UI/UX Pro Max:设计智能系统

什么是 UI/UX Pro Max?

UI/UX Pro Max 是一个可搜索的 UI 设计数据库,包含 50+ 种 UI 风格、21 种调色板、50 种字体配对、20 种图表类型、8 种技术栈的最佳实践。

前提条件

确保已安装 Python:

python3 --version || python --version

使用方法

当用户请求 UI/UX 工作(设计、构建、创建、实现、审查、修复、改进)时,按以下工作流程:

步骤 1:分析用户需求

从用户请求中提取关键信息:

  • 产品类型:SaaS、电商、作品集、仪表盘、着陆页等
  • 风格关键词:极简、活泼、专业、优雅、深色模式等
  • 行业:医疗、金融科技、游戏、教育等
  • 技术栈:React、Vue、Next.js,或默认使用 html-tailwind

步骤 2:搜索相关领域

使用 search.py 多次搜索以收集全面信息:

python3 .claude/skills/ui-ux-pro-max/scripts/search.py "<关键词>" --domain <领域> [-n <最大结果数>]

推荐搜索顺序:

顺序 领域 用途
1 product 获取产品类型的风格推荐
2 style 获取详细风格指南(颜色、效果、框架)
3 typography 获取字体配对和 Google Fonts 导入
4 color 获取配色方案(主色、辅色、CTA、背景、文字、边框)
5 landing 获取页面结构(如果是着陆页)
6 chart 获取图表推荐(如果是仪表盘/分析)
7 ux 获取最佳实践和反模式
8 stack 获取技术栈特定指南

步骤 3:可用技术栈

关注点
html-tailwind Tailwind 工具类、响应式、无障碍(默认)
react 状态、hooks、性能、模式
nextjs SSR、路由、图片、API 路由
vue Composition API、Pinia、Vue Router
svelte Runes、stores、SvelteKit
swiftui 视图、状态、导航、动画
react-native 组件、导航、列表
flutter Widgets、状态、布局、主题

示例工作流

用户请求: "做一个专业护肤服务的着陆页"

# 1. 搜索产品类型
python3 .claude/skills/ui-ux-pro-max/scripts/search.py "beauty spa wellness service" --domain product

# 2. 搜索风格
python3 .claude/skills/ui-ux-pro-max/scripts/search.py "elegant minimal soft" --domain style

# 3. 搜索字体
python3 .claude/skills/ui-ux-pro-max/scripts/search.py "elegant luxury" --domain typography

# 4. 搜索配色
python3 .claude/skills/ui-ux-pro-max/scripts/search.py "beauty spa wellness" --domain color

# 5. 搜索着陆页结构
python3 .claude/skills/ui-ux-pro-max/scripts/search.py "hero-centric social-proof" --domain landing

# 6. 搜索 UX 指南
python3 .claude/skills/ui-ux-pro-max/scripts/search.py "animation" --domain ux
python3 .claude/skills/ui-ux-pro-max/scripts/search.py "accessibility" --domain ux

# 7. 搜索技术栈指南
python3 .claude/skills/ui-ux-pro-max/scripts/search.py "layout responsive" --stack html-tailwind

专业 UI 通用规则

这些是经常被忽视但会让 UI 看起来不专业的问题:

图标和视觉元素

规则 正确做法 错误做法
不使用 emoji 图标 使用 SVG 图标(Heroicons、Lucide) 使用 emoji 作为 UI 图标
稳定的悬停状态 使用颜色/透明度过渡 使用会移动布局的缩放变换
一致的图标尺寸 使用固定 viewBox(24x24)配合 w-6 h-6 随意混合不同图标尺寸

交互和光标

规则 正确做法 错误做法
光标指针 给所有可点击元素添加 cursor-pointer 交互元素保持默认光标
悬停反馈 提供视觉反馈(颜色、阴影、边框) 元素交互时无任何指示
平滑过渡 使用 transition-colors duration-200 瞬间状态变化或太慢(>500ms)

亮/暗模式对比度

规则 正确做法 错误做法
亮模式玻璃卡片 使用 bg-white/80 或更高透明度 使用 bg-white/10(太透明)
亮模式文字对比 使用 #0F172A(slate-900)作为文字 使用 #94A3B8(slate-400)作为正文
边框可见性 亮模式使用 border-gray-200 使用 border-white/10(不可见)

交付前检查清单

视觉质量

  • 没有使用 emoji 作为图标
  • 所有图标来自一致的图标集
  • 品牌 logo 正确
  • 悬停状态不会导致布局偏移

交互

  • 所有可点击元素有 cursor-pointer
  • 悬停状态提供清晰的视觉反馈
  • 过渡平滑(150-300ms)
  • 键盘导航的焦点状态可见

亮/暗模式

  • 亮模式文字有足够对比度(最少 4.5:1)
  • 玻璃/透明元素在亮模式下可见
  • 边框在两种模式下都可见

布局

  • 浮动元素与边缘有适当间距
  • 内容不会隐藏在固定导航栏后面
  • 响应式适配 320px、768px、1024px、1440px
  • 移动端无水平滚动

Ralph Wiggum:迭代循环开发

什么是 Ralph Wiggum?

Ralph Wiggum 是一种基于持续 AI 代理循环的开发方法。正如 Geoffrey Huntley 所描述的: "Ralph 是一个 Bash 循环" - 一个简单的 while true,重复给 AI 代理喂入提示文件,让它迭代改进工作直到完成。

这个技术以《辛普森一家》中的 Ralph Wiggum 命名,体现了不顾挫折持续迭代的哲学。

核心概念

这个插件使用 Stop hook 实现 Ralph,拦截 Claude 的退出尝试:

# 你只运行一次:
/ralph-loop "你的任务描述" --completion-promise "DONE"

# 然后 Claude Code 自动:
# 1. 处理任务
# 2. 尝试退出
# 3. Stop hook 阻止退出
# 4. Stop hook 喂入相同的提示
# 5. 重复直到完成

循环发生在你当前会话内 - 你不需要外部 bash 循环。

这创建了一个自引用反馈循环

  • 迭代之间提示不变
  • Claude 之前的工作保留在文件中
  • 每次迭代看到修改的文件和 git 历史
  • Claude 通过读取文件中自己过去的工作自主改进

快速开始

/ralph-loop "构建一个 todos 的 REST API。要求:CRUD 操作、输入验证、测试。完成后输出 <promise>COMPLETE</promise>。" --max-iterations 50 --completion-promise "COMPLETE"

Claude 将:

  • 迭代实现 API
  • 运行测试并看到失败
  • 根据测试输出修复 bug
  • 迭代直到满足所有要求
  • 完成后输出完成承诺

命令

/ralph-loop

在当前会话中启动 Ralph 循环。

/ralph-loop "<提示>" --max-iterations <n> --completion-promise "<文本>"

选项:

  • --max-iterations <n> - N 次迭代后停止(默认:无限)
  • --completion-promise <text> - 表示完成的短语

/cancel-ralph

取消活动的 Ralph 循环。

/cancel-ralph

提示编写最佳实践

1. 清晰的完成标准

错误示例:

构建一个 todo API 并让它好用。

正确示例:

构建一个 todos 的 REST API。

完成条件:
- 所有 CRUD 端点工作正常
- 输入验证就位
- 测试通过(覆盖率 > 80%)
- 带 API 文档的 README
- 输出:<promise>COMPLETE</promise>

2. 增量目标

错误示例:

创建一个完整的电商平台。

正确示例:

阶段 1:用户认证(JWT、测试)
阶段 2:产品目录(列表/搜索、测试)
阶段 3:购物车(添加/删除、测试)

所有阶段完成后输出 <promise>COMPLETE</promise>。

3. 自我纠正

错误示例:

为功能 X 写代码。

正确示例:

使用 TDD 实现功能 X:
1. 写失败测试
2. 实现功能
3. 运行测试
4. 如果失败,调试并修复
5. 需要时重构
6. 重复直到全部通过
7. 输出:<promise>COMPLETE</promise>

4. 安全阀

始终使用 --max-iterations 作为安全网,防止在不可能的任务上无限循环:

# 推荐:始终设置合理的迭代限制
/ralph-loop "尝试实现功能 X" --max-iterations 20

哲学

Ralph 体现几个关键原则:

原则 说明
迭代 > 完美 不要追求第一次就完美。让循环细化工作。
失败是数据 "确定性的失败"意味着失败是可预测的和有信息量的。
操作员技能很重要 成功取决于写好提示,不只是有好模型。
坚持获胜 持续尝试直到成功。循环自动处理重试逻辑。

适用场景

适合:

  • 有明确成功标准的定义良好的任务
  • 需要迭代和细化的任务(如让测试通过)
  • 你可以走开的绿地项目
  • 有自动验证的任务(测试、linter)

不适合:

  • 需要人类判断或设计决策的任务
  • 一次性操作
  • 成功标准不清楚的任务
  • 生产环境调试(使用针对性调试代替)

真实世界成果

  • 在 Y Combinator 黑客马拉松测试中一夜成功生成 6 个仓库
  • 一份 50k合同以50k 合同以 297 API 成本完成
  • 用这种方法在 3 个月内创建了整个编程语言("cursed")

技能选择指南

场景对照表

场景 推荐技能
构建新功能 Feature-Dev → Superpowers
UI/UX 设计实现 UI/UX Pro Max
长时间自主任务 Ralph Wiggum
完整项目开发 Superpowers(完整工作流)
修复 bug Superpowers(systematic-debugging)
代码审查 Superpowers(code-reviewer)

组合使用

这些技能可以组合使用:

  1. Feature-Dev + UI/UX Pro Max:开发带 UI 的新功能
  2. Ralph Wiggum + Superpowers:自主完成带 TDD 的长任务
  3. Superpowers + Feature-Dev:完整的企业级功能开发

总结

技能 核心价值 最佳场景
Superpowers 完整的 TDD 工作流 项目开发全流程
Feature-Dev 系统化功能开发 新功能实现
UI/UX Pro Max 设计智能数据库 UI 设计和前端开发
Ralph Wiggum 自主迭代循环 长时间自动化任务

黄金法则

如果你认为某个技能有哪怕 1% 的可能适用,就必须使用它。
这不是可选的,这是强制的。你不能为绕过它找理由。

iOS实现 WKWebView 长截图的优雅方案

在 iOS 开发中,为 WKWebView 实现长截图功能是一个常见且棘手的需求。开发者通常会遇到以下几个痛点:

  • 网页内容高度不确定
  • 滚动区域难以完整截取
  • 截图过程中的界面闪烁影响用户体验

本文将介绍一种高效、稳定的解决方案,通过分段渲染图像拼接,完美捕获整个网页内容,并提供可直接集成的完整代码。


🎯 核心思路

我们的方案主要分为三个清晰的步骤:

  1. 布局调整:将 WebView 移至临时容器,为完整渲染做准备。
  2. 分段渲染:按屏幕高度分段捕获内容,生成多张切片图像。
  3. 图像拼接:将所有切片图像无缝拼接成一张完整的长图。

这种方法巧妙地绕过了直接截取 UIScrollView 的局限性,同时通过遮罩视图,保证了用户界面的视觉稳定性,避免闪烁。


💻 完整实现代码

WKWebView分类中添加长截图方法

  • WKWebView+Capture.h
#import <WebKit/WebKit.h>
#import <UIKit/UIKit.h>

NS_ASSUME_NONNULL_BEGIN

@interface WKWebView (Capture)

/**
 * 捕获 WKWebView 的完整内容并生成长截图
 * @param completion 完成回调,返回拼接好的长图(失败则返回 nil)
 */
- (void)captureEntireWebViewWithCompletion:(void (^)(UIImage * _Nullable capturedImage))completion;

@end

NS_ASSUME_NONNULL_END


  • WKWebView+Capture.m
#import "WKWebView+Capture.h"

@implementation WKWebView (Capture)

/**
 * 捕获 WKWebView 的完整内容并生成长截图
 * @param completion 完成回调,返回拼接好的长图(失败则返回 nil)
 */
- (void)captureEntireWebViewWithCompletion:(void (^)(UIImage *capturedImage))completion {

    // ⚠️ 关键:确保在主线程执行
    if (![NSThread isMainThread]) {
        NSLog(@"错误:WebView 截图必须在主线程执行");
        if (completion) completion(nil);
        return;
    }

    // 步骤1: 检查父视图并保存原始状态
    UIView *parentView = self.superview;
    if (!parentView) {
        if (completion) completion(nil);
        return;
    }

    CGRect originalFrame = self.frame;
    CGPoint originalContentOffset = self.scrollView.contentOffset;

    // 步骤2: 创建遮罩视图,保持界面"静止"的视觉效果,可以额外添加loading
    UIView *snapshotCoverView = [self snapshotViewAfterScreenUpdates:NO];
    snapshotCoverView.frame = self.frame; // 确保遮罩视图位置与 WebView 完全一致
    [parentView insertSubview:snapshotCoverView aboveSubview:self];

    // 步骤3: 创建隐藏的临时窗口和容器
    UIWindow *temporaryWindow = [[UIWindow alloc] initWithFrame:self.bounds];
    temporaryWindow.windowLevel = UIWindowLevelNormal - 1000; // 置于底层
    temporaryWindow.hidden = NO;
    temporaryWindow.alpha = 0;
    temporaryWindow.userInteractionEnabled = NO;

    UIView *captureContainerView = [[UIView alloc] initWithFrame:self.bounds];
    captureContainerView.clipsToBounds = YES;

    // 将 WebView 移入临时容器
    [self removeFromSuperview];
    [captureContainerView addSubview:self];
    [temporaryWindow addSubview:captureContainerView];

    // 步骤4: 获取完整内容高度并调整布局
    CGFloat fullContentHeight = self.scrollView.contentSize.height;
    self.frame = CGRectMake(0, 0, originalFrame.size.width, fullContentHeight);
    self.scrollView.contentOffset = CGPointZero;

    __weak typeof(self) weakSelf = self;

    // ⭐ 延迟执行,确保 WebView 内容布局与渲染完成
    dispatch_after(dispatch_time(DISPATCH_TIME_NOW, (int64_t)(0.5 * NSEC_PER_SEC)),
                   dispatch_get_main_queue(), ^{
        __strong typeof(weakSelf) strongSelf = weakSelf;
        if (!strongSelf) {
            if (completion) completion(nil);
            return;
        }

        // 步骤5: 分段截图核心逻辑
        CGFloat pageHeight = captureContainerView.bounds.size.height; // 单屏高度
        CGFloat totalHeight = fullContentHeight; // 总内容高度

        NSMutableArray<UIImage *> *imageSlices = [NSMutableArray array];
        CGFloat offsetY = 0;

        while (offsetY < totalHeight) {
            CGFloat remainingHeight = totalHeight - offsetY;
            CGFloat sliceHeight = MIN(pageHeight, remainingHeight);

            // 处理最后一段高度不足一屏的情况
            if (remainingHeight < pageHeight) {
                CGRect containerFrame = captureContainerView.frame;
                containerFrame.size.height = remainingHeight;
                captureContainerView.frame = containerFrame;
            }

            // 移动 WebView,将当前要截取的区域"暴露"出来
            CGRect webViewFrame = strongSelf.frame;
            webViewFrame.origin.y = -offsetY;
            strongSelf.frame = webViewFrame;

            // 渲染当前分段到图像上下文
            UIGraphicsBeginImageContextWithOptions(
                CGSizeMake(originalFrame.size.width, sliceHeight),
                NO,
                [UIScreen mainScreen].scale
            );

            CGContextRef context = UIGraphicsGetCurrentContext();
            CGFloat scaleX = originalFrame.size.width / captureContainerView.bounds.size.width;
            CGFloat scaleY = sliceHeight / captureContainerView.bounds.size.height;
            CGContextScaleCTM(context, scaleX, scaleY);

            [captureContainerView.layer renderInContext:context];
            UIImage *sliceImage = UIGraphicsGetImageFromCurrentImageContext();
            UIGraphicsEndImageContext();

            if (sliceImage) {
                [imageSlices addObject:sliceImage];
            }

            offsetY += sliceHeight; // 移动到下一段
        }

        UIImage *finalImage = nil;

        // 步骤6: 图像拼接
        if (imageSlices.count == 1) {
            finalImage = imageSlices.firstObject;
        } else if (imageSlices.count > 1) {
            UIGraphicsBeginImageContextWithOptions(
                CGSizeMake(originalFrame.size.width, totalHeight),
                NO,
                [UIScreen mainScreen].scale
            );

            CGFloat drawOffsetY = 0;
            for (UIImage *slice in imageSlices) {
                [slice drawInRect:CGRectMake(0,
                                             drawOffsetY,
                                             slice.size.width,
                                             slice.size.height)];
                drawOffsetY += slice.size.height;
            }

            finalImage = UIGraphicsGetImageFromCurrentImageContext();
            UIGraphicsEndImageContext();
        }

        // 步骤7: 恢复原始状态
        [strongSelf removeFromSuperview];
        [captureContainerView removeFromSuperview];
        temporaryWindow.hidden = YES;

        strongSelf.frame = originalFrame;
        strongSelf.scrollView.contentOffset = originalContentOffset;
        [parentView insertSubview:strongSelf belowSubview:snapshotCoverView];
        [snapshotCoverView removeFromSuperview];

        // 步骤8: 在主线程回调最终结果
        if (completion) {
            completion(finalImage);
        }
    });
}

@end


📱 效果展示

长截图展示

🚀 使用方法

调用方式非常简单,只需一行代码。

// 在需要截图的地方调用
[webView captureEntireWebViewWithCompletion:^(UIImage *capturedImage) {
    if (capturedImage) {
        // ✅ 截图成功,处理结果
        // 例如:保存到相册
        UIImageWriteToSavedPhotosAlbum(capturedImage, nil, nil, nil);
        // 或:上传、分享、预览等
    } else {
        // ❌ 截图失败
        NSLog(@"截图失败");
    }
}];

📝 总结

本文提供的方案通过以下关键技术,优雅地解决了 WKWebView 长截图的难题:

  • 临时容器管理:隔离渲染环境,避免干扰主界面。
  • 分段渲染:将长内容分解为多个可管理的屏幕片段。
  • 状态恢复:完整保存并恢复 WebView 的原始状态,确保业务无感知。

如果你有更好的实现思路,或在实际应用中遇到了特殊场景,欢迎在评论区分享交流!

Swift 方法派发深度探究

引言:一个危险的实验

想象一下,你正在调试一个复杂的 iOS 应用,想要在不修改源码的情况下监控所有 UIViewControllerviewDidAppear 调用;还有如果要支持热修复,该如何?你可能会想到使用 Method Swizzling

extension UIViewController {
    @objc dynamic func swizzled_viewDidAppear(_ animated: Bool) {
        print("🎯 [AOP] \(type(of: self)) 显示")
        swizzled_viewDidAppear(animated) // 调用原始实现
    }
    
    static func swizzleViewDidAppear() {
        let original = #selector(viewDidAppear(_:))
        let swizzled = #selector(swizzled_viewDidAppear(_:))
        
        guard let originalMethod = class_getInstanceMethod(self, original),
              let swizzledMethod = class_getInstanceMethod(self, swizzled) else {
            return
        }
        
        method_exchangeImplementations(originalMethod, swizzledMethod)
    }
}

看起来完美,对吧?但这里隐藏着一个 Swift 的重要秘密:为什么必须使用 @objc dynamic 如果去掉 dynamic 会发生什么?

Part 1: 为什么 Swizzling 需要动态派发?

1.1 Swizzling 的工作原理

Method Swizzling 本质上是在运行时交换两个方法的实现。它依赖 Objective-C 运行时的消息派发机制:

// Objective-C 运行时的工作方式
objc_msgSend(object, selector, ...)

当调用 [object method] 时,运行时:

  1. 根据对象的类查找方法列表
  2. 找到对应 selector 的实现(IMP)
  3. 执行该实现

Swizzling 就是修改了第 2 步的映射关系。

1.2 Swift 与 Objective-C 的冲突

问题在于:Swift 默认不使用消息派发

class MyClass {
    func normalMethod() { }     // Swift 默认派发
    @objc func exposedMethod() { }  // 对 OC 可见,但仍不是消息派发
    @objc dynamic func dynamicMethod() { }  // 这才是消息派发
}

如果你尝试 Swizzle 一个非 dynamic 的方法:

class TestSwizzle: NSObject {
    @objc func original() { print("Original") }
    @objc func swizzled() { print("Swizzled") }
    
    static func attemptSwizzle() {
        let original = #selector(original)
        let swizzled = #selector(swizzled)
        
        guard let origMethod = class_getInstanceMethod(self, original),
              let swizMethod = class_getInstanceMethod(self, swizzled) else {
            return
        }
        
        print("交换前:")
        print("original IMP: \(method_getImplementation(origMethod))")
        print("swizzled IMP: \(method_getImplementation(swizMethod))")
        
        method_exchangeImplementations(origMethod, swizMethod)
        
        print("交换后:")
        print("original IMP: \(method_getImplementation(origMethod))")
        print("swizzled IMP: \(method_getImplementation(swizMethod))")
        
        let test = TestSwizzle()
        test.original()  // 输出什么?
    }
}

运行结果可能让你困惑:

交换前:
original IMP: 0x0000000102f7fbc0
swizzled IMP: 0x0000000102f7fcc0

交换后:
original IMP: 0x0000000102f7fcc0
swizzled IMP: 0x0000000102f7fbc0

Original   //❓ 调用结果还是 "Original"

为什么 IMP 发生交换后,但行为没变?

Part 2: Swift 的三种派发方式

2.1 派发方式对比

假设大家已有概念,为了方便快速浏览,我把这些汇总到了一个表格:

特性 直接派发 (Direct Dispatch) 表派发 (Table Dispatch) 消息派发 (Message Dispatch)
Swift 写法 final func
struct 的方法
extension 中的方法
private/fileprivate func
class func (默认)
@objc func (仅 Swift 内)
@objc dynamic func
@objc dynamic var
调用方式 编译时确定地址,直接跳转 通过在类对象虚函数表查找 Objective-C 运行时 objc_msgSend
性能 ⚡️ 最快 (几乎无开销) 较快 (一次指针查找) 🐌 最慢 (哈希查找+缓存)
灵活性 ❌ 最低 (无法重写) ✅ 中等 (支持继承重写) ✅✅ 最高 (支持运行时修改)
内存占用 无额外开销 每个类一个虚函数表 每个类方法列表 + 缓存
重写支持 ❌ 不支持 ✅ 支持 ✅ 支持
运行时修改 ❌ 不可能 ❌ 不可能 (Swift 5+) ✅ 可能 (Method Swizzling)
KVO 支持 ❌ 不支持 ❌ 不支持 ✅ 支持
典型应用 工具方法、性能关键代码 普通业务逻辑、可继承的类 需要动态特性的代码
二进制影响 最小 中等 最大 (生成 OC 元数据)
调试难度 简单 中等 困难 (调用栈复杂)

2.2 方法派发特别注意点

extension 中的方法特别说明:

extension 中的方法默认是静态派发,不能被子类重写,编译器可以在编译时确定具体实现。 这样设计的原因有下面几点:

  • 明确性: extension表示添加新功能,override表示修改现有功能,两者分离,避免混淆。
  • 安全性:不允许重写 → 保证 extension 方法的稳定性。
  • 模块化:不用担心用户重写了自己模块extension中方法导致异常。
  • 良好实践:使用 extension 分离关注点。
class BaseClass {
    // 进入类的虚函数表
    func original() { print("Base original") }
}

extension BaseClass {
    // 不在虚函数表中!相当于直接是函数地址
    // 编译后的伪代码: 是生成一个全局函数
    // void String_extension_customMethod(String *self) {
    //     // 函数体
    // }
    func extensionMethod() { print("extension method") }
    
    // ❌ 不能在 extension 中重写原类方法
    // override func original() { }  // 编译错误
}

class SubClass: BaseClass {
    // ✅ 可以重写原类方法
    override func original() { print("SubClass original") }
    
    // ❌ 不能重写 extension 中的方法
    // override func extensionMethod() { }  // 编译错误
}

对 Objective-C 类的 extension

// Objective-C 类(如 UIView)
extension UIView {
    // 仍然是直接派发(在 Swift 中调用时)
    func swiftExtensionMethod() { }
    
    // 但通过 @objc 暴露给 Objective-C 时
    @objc func objcExposedMethod() { }  
    // Swift 内:直接派发
    // Objective-C 内:通过桥接,底层是消息派发
}

extension NSObject {
    @objc dynamic func specialMethod() { }
    // 这会强制使用消息派发
    // 可以被重写(因为是消息派发)
    // 但这是特殊情况,利用了 Objective-C 运行时
}

协议扩展extension

protocol Drawable {
    func draw()  // 协议要求
}

extension Drawable {
    func draw() {  // 默认实现
        print("默认绘制")
    }
    // 这是直接派发,但可以通过协议类型动态派发
}

class Circle: Drawable { }

let circle = Circle()
circle.draw()  // 直接派发:调用默认实现

let drawable: Drawable = circle
drawable.draw()  // 协议派发:通过协议见证表PWT(Protocol Witness Table)
// 内存布局
Circle 实例:
┌──────────┐
 数据字段  
├──────────┤
 PWT 指针   指向 Circle 的协议见证表
└──────────┘

CirclePWT:
┌──────────┐
 draw()     索引 0
├──────────┤
 resize()   索引 1
└──────────┘

2.3 Swift 类的虚函数表

对象实例内存布局:
┌───────────────────┐
│    对象头 (16字节)  │ ← 包含指向类对象的指针
├───────────────────┤
│  引用计数 (8字节)   │
├───────────────────┤
│  属性 name (8字节) │
├───────────────────┤
│  属性 age (8字节)  │
└───────────────────┘

类对象内存布局:
┌───────────────────┐
│   类信息 (元数据)   │
├───────────────────┤
│  虚函数表指针      │ → 指向虚函数表数组
├───────────────────┤
│  其他元数据...     │
└───────────────────┘

虚函数表结构:
┌───────────────────┐
│    makeSound()    │ ← 函数指针 [0]
├───────────────────┤
│       eat()       │ ← 函数指针 [1]
├───────────────────┤
│      sleep()      │ ← 函数指针 [2]
└───────────────────┘

虚函数表(V-Table)工作原理:

Dog 类的虚函数表(编译时根据顺序确定索引):
[0]: Dog.makeSound() 地址
[1]: Dog.otherMethod() 地址
...

调用 animal.makeSound():
1. 获取 animal 的虚函数表指针
2. 根据索引得到 makeSound 在表中的地址(编译时确定)
3. 跳转到对应地址执行

2.4 Swift 类方法的派发

类元数据结构:

┌─────────────────────┐
│    类型描述符        │ ← Metadata header
├─────────────────────┤
│    父类指针          │
├─────────────────────┤
│    实例变量偏移      │
├─────────────────────┤
│  ↓ 实例方法表指针    │ → 指向实例方法的虚函数表
├─────────────────────┤
│  ↓ 类方法表指针      │ → 指向类方法的独立表
├─────────────────────┤
│    协议列表指针      │
├─────────────────────┤
│    泛型信息...       │
└─────────────────────┘

实例方法表(虚函数表):
┌─────────────────────┐
│    instanceMethod1   │ ← 索引 0
├─────────────────────┤
│    instanceMethod2   │ ← 索引 1
└─────────────────────┘

类方法表:
┌─────────────────────┐
│     classMethod1     │ ← 索引 0  
├─────────────────────┤
│     classMethod2     │ ← 索引 1
└─────────────────────┘

派发方式

class MyClass {
    
    // 默认的表派发类方法
    class func classMethod() {  // 通过类的元数据进行派发
        print("类方法 - 表派发")
    }
    
    // 直接派发,不能被重写
    static func staticMethod() {  
        print("静态方法 - 直接派发")
    }
    
    // final class func 等价于 static func
    final class func alsoCannotOverride() { }
    
    @objc dynamic class func dynamicClassMethod() {
        print("类方法 - 消息派发")
    }
}

class AppConfig {
    // 存储在全局数据段
    static let appName = "MyApp"        // __TEXT 段(只读)
    static var launchCount = 0          // __DATA 段(读写)
    static let shared = AppConfig()     // 引用存储在全局,对象在堆上
    
    // 惰性静态属性
    static lazy var heavyResource = createHeavyResource()
}

/*
内存位置:
- appName: 编译时常量 → 代码段
- launchCount: 全局变量 → 数据段  
- shared: 引用在数据段,对象在堆上
- heavyResource: 第一次访问时初始化
*/

Part 3: 混合派发的危险实验

3.1 当 Swift 遇到 Swizzling

让我们看一个更完整的例子:

class MixedClass {
    // 情况1:纯 Swift
    func swiftMethod() { print("Swift Method") }
    
    // 情况2:暴露给 OC,但 Swift 内使用表派发
    @objc func exposedMethod() { print("Exposed Method") }
    
    // 情况3:完全动态
    @objc dynamic func dynamicMethod() { print("Dynamic Method") }
}

// 尝试 Swizzle
extension MixedClass {
    @objc dynamic func swizzled_swiftMethod() {
        print("Swizzled Swift")
        swizzled_swiftMethod()
    }
    
    @objc func swizzled_exposedMethod() {
        print("Swizzled Exposed")
        swizzled_exposedMethod()
    }
    
    @objc dynamic func swizzled_dynamicMethod() {
        print("Swizzled Dynamic")
        swizzled_dynamicMethod()
    }
    
    static func testAll() {
        let instance = MixedClass()
        
        print("=== 原始调用 ===")
        instance.swiftMethod()      // Swift Method
        instance.exposedMethod()    // Exposed Method
        instance.dynamicMethod()    // Dynamic Method
        
        // 尝试 Swizzle swiftMethod(缺少 dynamic)
        if let orig = class_getInstanceMethod(self, #selector(swiftMethod)),
           let swiz = class_getInstanceMethod(self, #selector(swizzled_swiftMethod)) {
            method_exchangeImplementations(orig, swiz)
        }
        
        // 尝试 Swizzle exposedMethod(只有 @objc)
        if let orig = class_getInstanceMethod(self, #selector(exposedMethod)),
           let swiz = class_getInstanceMethod(self, #selector(swizzled_exposedMethod)) {
            method_exchangeImplementations(orig, swiz)
        }
        
        // Swizzle dynamicMethod(正确方式)
        if let orig = class_getInstanceMethod(self, #selector(dynamicMethod)),
           let swiz = class_getInstanceMethod(self, #selector(swizzled_dynamicMethod)) {
            method_exchangeImplementations(orig, swiz)
        }
        
        print("\n=== Swizzle 后调用 ===")
        instance.swiftMethod()      // 还是 Swift Method ❌
        instance.exposedMethod()    // 还是 Exposed Method ❌  
        instance.dynamicMethod()    // Swizzled Dynamic ✅
        
        print("\n=== 通过 OC 运行时调用 ===")
        // 通过 performSelector 调用
        instance.perform(#selector(swiftMethod))      // 可能崩溃 💥
        instance.perform(#selector(exposedMethod))    // Swizzled Exposed ✅
        instance.perform(#selector(dynamicMethod))    // Swizzled Dynamic ✅
    }
}

3.2 为什么会这样?

内存布局解释:

当 Swift 编译一个类时:

  • 纯 Swift 方法 → 放入虚函数表
  • @objc 方法 → 生成桥接方法,同时放入虚函数表和 OC 方法列表(在Swift中调用未交换,OC中调用时已交换)
  • @objc dynamic 方法 → 直接放入 OC 方法列表

Swizzling 只影响 OC 方法列表,不影响虚函数表!

Part 4: 属性的 @objc dynamic

4.1 Swift中使用KVO

class Observable: NSObject {
    // 普通属性,不支持 KVO
    var name: String = ""
    
    // @objc dynamic 属性,支持 KVO
    @objc dynamic var age: Int = 0
    
    // 只有 @objc,不支持 KVO
    @objc var height: Double = 0.0
}

let obj = Observable()

// 尝试观察
// 运行时错误**Fatal error: Could not extract a String from KeyPath Swift.ReferenceWritableKeyPath<XXX.Observable, Swift.String>**
obj.observe(\.name, options: .new) { _, change in
    print("name changed: \(change.newValue ?? "nil")")
}  

obj.observe(\.age, options: .new) { _, change in
    print("age changed: \(change.newValue ?? 0)")
}  // ✅ 正常工作

obj.observe(\.height, options: .new) { _, change in
    print("height changed: \(change.newValue ?? 0)")
}  // 无法观察到变化

4.2 属性访问的派发方式

class PropertyTest {
    // 直接派发(编译时展开),会被内联
    var directProperty: Int {
        get { return _storage }
        set { _storage = newValue }
    }
    
    // 表派发(通过方法)
    var tableProperty: Int {
        get {
            print("getter 调用")
            return _storage
        }
        set {
            print("setter 调用")
            _storage = newValue
        }
    }
    
    // 消息派发(支持 KVO)
    @objc dynamic var messageProperty: Int {
        get { return _storage }
        set { _storage = newValue }
    }
    
    private var _storage: Int = 0
}

// @objc dynamic 属性会生成:
// - (NSInteger)messageProperty;
// - (void)setMessageProperty:(NSInteger)value;
// 这些是真正的 Objective-C 方法

4.3 属性观察器的有趣现象

class Observed: NSObject {
    @objc dynamic var value: Int = 0 {
        didSet {
            print("value 从 \(oldValue) 变为 \(value)")
        }
    }
    
    // 测试 KVO 和 didSet 的交互
    func test() {
        self.value = 10  // 触发 didSet
        
        // 通过 KVC 设置
        self.setValue(20, forKey: "value")  // 也会触发 didSet ✅
    }
}

// 为什么能工作?
// @objc dynamic 属性生成的 setter 会:
// 1. 调用 willChangeValueForKey
// 2. 设置新值
// 3. 调用 didSet(Swift 注入的代码)
// 4. 调用 didChangeValueForKey(触发 KVO)

Part 5: 派发方式的确定规则

5.1 决策树

// Swift 编译器决定派发方式的逻辑:
func determineDispatch(for method: Method) -> DispatchType {
    if method.isFinal || type.isFinal || type.isStruct {
        return .direct      // 1. final 或 struct → 直接派发
    }
    
    if method.isDynamic {
        return .message     // 2. dynamic → 消息派发
    }
    
    if method.isObjC {
        // @objc 但不 dynamic:桥接方法
        return .table       // 3. 在 Swift 内使用表派发
    }
    
    if method.isInExtension && !type.isObjCClass {
        return .direct      // 4. 非 OC 类的扩展 → 直接派发
    }
    
    return .table           // 5. 默认 → 表派发
}

5.2 特殊情况

// 1. 协议要求
protocol MyProtocol {
    func requiredMethod()   // 表派发(通过协议见证表)
}

// 2. 泛型约束
func genericFunc<T: MyProtocol>(_ obj: T) {
    obj.requiredMethod()    // 静态派发(编译时特化)
}

// 3. @_dynamicReplacement
class Replaceable {
    dynamic func original() { print("Original") }
}

extension Replaceable {
    @_dynamicReplacement(for: original)
    func replacement() { print("Replacement") }
}
// Swift 5 引入的官方 "Swizzling"

Part 6: 性能影响与优化

优化建议

// ❌ 避免在性能关键路径使用 dynamic
class Cache {
    @objc dynamic var data: [String: Any] = [:]  // 每次访问都有消息派发开销
    
    func expensiveOperation() {
        for _ in 0..<10000 {
            _ = data["key"]  // 慢!
        }
    }
}

// ✅ 优化方案
class OptimizedCache {
    private var _data: [String: Any] = [:]
    
    var data: [String: Any] {
        get { return _data }
        set { _data = newValue }
    }
    
    @objc dynamic var observableData: [String: Any] {
        get { return _data }
        set { _data = newValue }
    }
    
    func expensiveOperation() {
        let localData = data  // 一次读取
        for _ in 0..<10000 {
            _ = localData["key"]  // 快!
        }
    }
}

Part 7: 实际应用指南

7.1 何时使用何种派发?

// 指南:
class MyClass {
    // ✅ 使用直接派发:
    final func utilityMethod() { }  // 工具方法,不重写
    private func helper() { }       // 私有方法
    
    // ✅ 使用表派发(默认):
    func businessLogic() { }        // 业务逻辑,可能被重写
    open func publicAPI() { }       // 公开 API
    
    // ⚠️ 谨慎使用消息派发:
    @objc dynamic func kvoProperty() { }  // 需要 KVO
    @objc dynamic func swizzleMe() { }    // 需要 Method Swizzling
    
    // ❌ 避免混用:
    @objc func confusingMethod() { }  // 既不是鱼也不是熊掌
    // 在 Swift 中是表派发,在 OC 中是消息派发
    // 可能导致不一致的行为
}

7.2 安全 Swizzling 的最佳实践

class SafeSwizzler {
    /// 安全的 Method Swizzling
    static func swizzle(_ type: AnyClass,
                       original: Selector,
                       swizzled: Selector,
                       isClassMethod: Bool = false) throws {
        
        // 1. 获取方法
        let getMethod = isClassMethod ? class_getClassMethod : class_getInstanceMethod
        guard let originalMethod = getMethod(type, original),
              let swizzledMethod = getMethod(type, swizzled) else {
            throw SwizzleError.methodNotFound
        }
        
        // 2. 检查是否已经是消息派发
        let originalEncoding = method_getTypeEncoding(originalMethod)
        if originalEncoding == nil {
            throw SwizzleError.notMessageDispatch
        }
        
        // 3. 检查是否已经 Swizzled
        if alreadySwizzled {
            throw SwizzleError.alreadySwizzled
        }
        
        // 4. 执行交换
        method_exchangeImplementations(originalMethod, swizzledMethod)
    }
    
    enum SwizzleError: Error {
        case methodNotFound
        case notMessageDispatch
        case alreadySwizzled
    }
}

// 使用
extension UIViewController {
    @objc dynamic func safe_viewDidLoad() {
        print("Safe tracking")
        safe_viewDidLoad()
    }
    
    static func enableSafeTracking() {
        do {
            try SafeSwizzler.swizzle(
                UIViewController.self,
                original: #selector(viewDidLoad),
                swizzled: #selector(safe_viewDidLoad)
            )
            print("✅ Safe swizzling 成功")
        } catch {
            print("❌ Swizzling 失败: \(error)")
        }
    }
}

总结

关键要点

  1. Swift 有三种派发方式

    • 直接派发:最快,用于 final、结构体等
    • 表派发:默认,通过虚函数表
    • 消息派发:最慢,但支持运行时特性
  2. @objc vs dynamic

    • @objc:让 Swift 方法对 OC 可见,但 Swift 内仍用表派发
    • dynamic:强制使用消息派发
    • @objc dynamic:OC 可见 + 消息派发
  3. Swizzling 的真相

    • 只能交换消息派发的方法
    • 交换表派发方法会导致 Swift 和 OC 行为不一致
    • 这是很多 Swizzling bug 的根源
  4. 性能影响

    • 消息派发比直接派发慢 4-5 倍
    • 避免在性能关键路径使用 dynamic
    • 合理使用 final 优化性能

哲学思考

Swift 的派发机制体现了语言设计的平衡艺术:

  • 安全 vs 灵活:表派发保证安全,消息派发提供灵活
  • 性能 vs 功能:直接派发优化性能,动态派发启用高级功能
  • Swift vs Objective-C:两种运行时模型的巧妙融合

理解这些机制,你就能:

  • 写出更高效的 Swift 代码
  • 安全地使用运行时特性
  • 避免诡异的 Swizzling bug
  • 更好地理解 Swift 的设计哲学

记住:强大的能力伴随着巨大的责任。动态派发给了你 hook 系统方法的能力,但也可能带来难以调试的问题。使用时务必谨慎!

“死了么”App荣登付费榜第一名!

背景 2026年初的App Store付费榜,突然杀出一匹“黑马”——一款名为 「“死了么 - 官方正版”」 的产品,以8元付费下载的模式,毫无征兆地登顶付费榜单榜首,成为今年首个现象级爆款。对于常年

AppStore卡审依旧存在,预计下周将逐渐恢复常态!

背景

圣诞节🎄虽然结束了,后劲儿依旧在。最直观的感受就是AppStore审核节奏还未恢复正常。依然存在审核时间较久或等待审核时间过长的问题。

举一个直观的例子🌰:

一座5层高的商场,每层都预备了洗手间🚾。正常情况下,足够满足整座商城客流量的需求。但是赶上了节假日高峰,并且只有3层洗手间可用。那么在常态客流量不变的情况也已经拥挤,更不要说节假日高峰期。

就第三方上架&更新趋势来看,AppStore审核节奏也将逐步正常。

非必要迭代

如果不是遇到重大线上问题或重大功能迭代,建议不更新或不上新包。避免正常产品遭遇卡审状态,导致难以定位问题或者审核员摆烂直接一手4.3a。

毕竟AppStore审核团队,刚刚经历了年关肯定积压了大量待审核的产品,多少也有些烦躁。(PS:单纯从心理角度来讲

新包、新账号和新代码,“三新原则”基本上叠满了卡审buffer。【特指中国大陆的开发者,海外账号亲测影响不大。】

重大更新

对于产品有着节前活动或市场战略布局的产品,那么也不用担心。在AppStore依然存在便捷通道:即加急审核!

常规产品,不必担心,这是官方提供的合理渠道,确实保障开发者的紧急需求【AppStore中的急诊室】。

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

相关推荐

# 苹果开发者续费大坑及成功续费方案!亲测有效

# AppStore敏感词排查手册,多维度分析Guideline 2.3.1隐藏功能,轻松过审。

# 如何主动提防苹果3.2f的进攻,自查防御手册(代码篇)

# 如何主动提防苹果3.2f的进攻,自查防御手册(ASO篇)

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

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

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

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

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

2026 年 Expo + React Native 项目接入微信分享完整指南

2026 年 Expo + React Native 项目接入微信分享完整指南

本文基于 Expo SDK 54 + React Native 0.81 + react-native-wechat-lib 1.1.27 的实战经验,详细记录了在 Expo 管理的 React Native 项目中接入微信分享功能的完整流程和踩坑记录。

前言

在 React Native 生态中,react-native-wechat-lib 是目前最常用的微信 SDK 封装库。但由于该库更新较慢,加上 Expo 的特殊性,接入过程中会遇到不少坑。本文将分享我们在生产项目中的完整接入方案。

技术栈

  • Expo SDK: 54.0.30
  • React Native: 0.81.5
  • react-native-wechat-lib: 1.1.27
  • 构建方式: EAS Build

整体流程

准备工作 → 安装依赖 → 创建 Expo 插件 → 配置 app.config.js → 
编写 JS 服务层 → 服务器配置 → 微信开放平台配置 → 构建测试

第一步:准备工作

1.1 微信开放平台配置

  1. 登录 微信开放平台
  2. 创建移动应用,获取 AppID
  3. 配置 iOS 应用信息:
    • Bundle ID: com.yourapp
    • Universal Link: https://yourdomain.com/open/

1.2 Apple Developer 配置

  1. 获取 Team ID(格式如 A1B2C3D4E5
  2. 确认 Bundle ID 与微信开放平台一致

第二步:安装依赖

npm install react-native-wechat-lib@1.1.27

⚠️ 注意:在 Expo 管理的项目中,不需要手动执行 pod install,EAS Build 会自动处理。

第三步:创建 Expo Config Plugin

由于 Expo 管理原生代码,我们需要通过 Config Plugin 来配置微信 SDK 所需的原生设置。

创建 plugins/withWechat.js

const { withInfoPlist, withAndroidManifest } = require("expo/config-plugins");

/**
 * 微信 SDK Expo Config Plugin
 * 自动配置 iOS 和 Android 的微信相关设置
 */
function withWechat(config, { appId, universalLink }) {
  if (!appId) {
    throw new Error("withWechat: appId is required");
  }

  // iOS 配置
  config = withInfoPlist(config, (config) => {
    // 添加微信 URL Scheme
    const urlTypes = config.modResults.CFBundleURLTypes || [];
    const wechatScheme = {
      CFBundleURLSchemes: [appId],
      CFBundleURLName: "wechat",
    };

    const hasWechatScheme = urlTypes.some(
      (type) =>
        type.CFBundleURLSchemes &&
        type.CFBundleURLSchemes.includes(appId)
    );

    if (!hasWechatScheme) {
      urlTypes.push(wechatScheme);
    }
    config.modResults.CFBundleURLTypes = urlTypes;

    // 添加 LSApplicationQueriesSchemes
    const queriesSchemes = config.modResults.LSApplicationQueriesSchemes || [];
    const wechatSchemes = ["weixin", "weixinULAPI"];
    wechatSchemes.forEach((scheme) => {
      if (!queriesSchemes.includes(scheme)) {
        queriesSchemes.push(scheme);
      }
    });
    config.modResults.LSApplicationQueriesSchemes = queriesSchemes;

    return config;
  });

  // Android 配置
  config = withAndroidManifest(config, (config) => {
    const mainApplication = config.modResults.manifest.application?.[0];
    if (!mainApplication) return config;

    const packageName = config.android?.package || "com.yourapp";
    const activities = mainApplication.activity || [];
    const wxActivityName = `${packageName}.wxapi.WXEntryActivity`;

    const hasWxActivity = activities.some(
      (activity) => activity.$?.["android:name"] === wxActivityName
    );

    if (!hasWxActivity) {
      activities.push({
        $: {
          "android:name": wxActivityName,
          "android:exported": "true",
          "android:launchMode": "singleTask",
          "android:taskAffinity": packageName,
          "android:theme": "@android:style/Theme.Translucent.NoTitleBar",
        },
      });
    }

    mainApplication.activity = activities;
    return config;
  });

  return config;
}

module.exports = withWechat;

第四步:配置 app.config.js

module.exports = {
  expo: {
    name: "你的应用名",
    slug: "your-app",
    version: "1.0.0",
    
    extra: {
      wechatAppId: "wx你的AppID", // 微信 AppID
    },
    
    ios: {
      bundleIdentifier: "com.yourapp",
      associatedDomains: [
        "applinks:yourdomain.com",
        "webcredentials:yourdomain.com",
      ],
      infoPlist: {
        LSApplicationQueriesSchemes: ["weixin", "weixinULAPI", "wechat"],
      },
    },
    
    android: {
      package: "com.yourapp",
    },
    
    plugins: [
      [
        "./plugins/withWechat",
        {
          appId: "wx你的AppID",
          universalLink: "https://yourdomain.com/open/",
        },
      ],
    ],
  },
};

第五步:编写微信服务层

创建 src/services/wechatService.ts

import { Platform, Alert } from "react-native";
import Constants from "expo-constants";

// 从 Expo 配置中获取微信 AppID
const WECHAT_APP_ID = Constants.expoConfig?.extra?.wechatAppId || "";

// 动态加载微信 SDK
let WeChat: any = null;
let sdkLoadAttempted = false;

const getWechatSDK = () => {
  if (sdkLoadAttempted) return WeChat;
  sdkLoadAttempted = true;
  
  if (Platform.OS === "web") {
    return null;
  }
  
  try {
    const module = require("react-native-wechat-lib");
    WeChat = module.default || module;
    
    if (!WeChat || typeof WeChat.registerApp !== "function") {
      WeChat = null;
    }
    
    return WeChat;
  } catch (error) {
    console.warn("微信 SDK 加载失败:", error);
    return null;
  }
};

class WechatService {
  private isRegistered = false;

  // 检查 SDK 是否可用
  isAvailable(): boolean {
    if (Platform.OS === "web") return false;
    const sdk = getWechatSDK();
    return sdk !== null && typeof sdk.registerApp === "function";
  }

  // 注册微信 SDK
  async register(): Promise<boolean> {
    if (this.isRegistered) return true;
    
    const sdk = getWechatSDK();
    if (!sdk) return false;
    
    try {
      const result = await sdk.registerApp(WECHAT_APP_ID);
      this.isRegistered = result;
      return result;
    } catch (error) {
      console.error("微信 SDK 注册失败:", error);
      return false;
    }
  }

  // 检查微信是否已安装
  async isWechatInstalled(): Promise<boolean> {
    const sdk = getWechatSDK();
    if (!sdk) return false;
    
    try {
      return await sdk.isWXAppInstalled();
    } catch (error) {
      return false;
    }
  }

  // 分享网页到微信
  async shareWebpage(params: {
    title: string;
    description: string;
    thumbImageUrl?: string;
    webpageUrl: string;
    scene?: "session" | "timeline" | "favorite";
  }): Promise<{ success: boolean; message: string }> {
    
    if (!this.isAvailable()) {
      return { 
        success: false, 
        message: Platform.OS === "web" 
          ? "Web 端暂不支持微信分享" 
          : "微信分享功能需要在正式构建版本中使用"
      };
    }

    try {
      const registered = await this.register();
      if (!registered) {
        return { success: false, message: "微信 SDK 初始化失败" };
      }

      const isInstalled = await this.isWechatInstalled();
      if (!isInstalled) {
        return { success: false, message: "请先安装微信" };
      }

      const sceneMap = {
        session: 0,   // 聊天界面
        timeline: 1,  // 朋友圈
        favorite: 2,  // 收藏
      };

      const sdk = getWechatSDK();
      await sdk.shareWebpage({
        title: params.title,
        description: params.description,
        thumbImageUrl: params.thumbImageUrl || "",
        webpageUrl: params.webpageUrl,
        scene: sceneMap[params.scene || "session"],
      });

      return { success: true, message: "分享成功" };
    } catch (error: any) {
      if (error?.errCode === -2) {
        return { success: false, message: "已取消分享" };
      }
      return { success: false, message: error?.message || "分享失败" };
    }
  }

  // 分享图片到微信
  async shareImage(params: {
    imageUrl?: string;
    imageBase64?: string;
    scene?: "session" | "timeline" | "favorite";
  }): Promise<{ success: boolean; message: string }> {
    if (!this.isAvailable()) {
      return { success: false, message: "微信分享不可用" };
    }

    try {
      await this.register();
      
      const isInstalled = await this.isWechatInstalled();
      if (!isInstalled) {
        return { success: false, message: "请先安装微信" };
      }

      const sceneMap = { session: 0, timeline: 1, favorite: 2 };
      const sdk = getWechatSDK();
      
      await sdk.shareImage({
        imageUrl: params.imageBase64 || params.imageUrl,
        scene: sceneMap[params.scene || "session"],
      });

      return { success: true, message: "分享成功" };
    } catch (error: any) {
      if (error?.errCode === -2) {
        return { success: false, message: "已取消分享" };
      }
      return { success: false, message: "分享失败" };
    }
  }
}

export const wechatService = new WechatService();

第六步:服务器配置 (Universal Link)

在你的服务器上创建 apple-app-site-association 文件。

文件路径

https://yourdomain.com/.well-known/apple-app-site-association

文件内容

{
  "applinks": {
    "apps": [],
    "details": [
      {
        "appIDs": ["TEAMID.com.yourapp"],
        "components": [
          { "/": "/open/*" },
          { "/": "/topic/*" }
        ]
      }
    ]
  },
  "webcredentials": {
    "apps": ["TEAMID.com.yourapp"]
  }
}

⚠️ 将 TEAMID 替换为你的 Apple Team ID,com.yourapp 替换为你的 Bundle ID。

服务器配置要求

  1. 必须通过 HTTPS 访问
  2. Content-Type 应为 application/json
  3. 文件名不能有 .json 后缀
  4. 不能有重定向

Nginx 配置示例

location /.well-known/apple-app-site-association {
    default_type application/json;
}

第七步:在组件中使用

import React from "react";
import { Button, Alert } from "react-native";
import { wechatService } from "@/services/wechatService";

export function ShareButton() {
  const handleShare = async () => {
    const result = await wechatService.shareWebpage({
      title: "分享标题",
      description: "分享描述",
      thumbImageUrl: "https://example.com/thumb.jpg",
      webpageUrl: "https://example.com/share-page",
      scene: "session", // 或 "timeline" 分享到朋友圈
    });

    if (result.success) {
      Alert.alert("成功", "分享成功");
    } else {
      Alert.alert("提示", result.message);
    }
  };

  return <Button title="分享到微信" onPress={handleShare} />;
}

第八步:构建和测试

使用 EAS Build

# 构建 iOS 生产版本
eas build -p ios --profile production

# 构建并自动提交到 TestFlight
eas build -p ios --profile production --auto-submit

测试注意事项

  1. Expo Go 不支持:微信 SDK 是原生模块,必须使用 EAS Build 构建的版本测试
  2. 重启手机:安装新版本后建议重启手机,让 iOS 刷新 Associated Domains 缓存
  3. 验证 Universal Link:访问 https://app-site-association.cdn-apple.com/a/v1/yourdomain.com 确认 Apple 已缓存配置

常见问题排查

问题 1:分享时微信没有被唤起

可能原因:

  • Universal Link 配置不一致(微信开放平台、App 代码、服务器三端必须完全一致)
  • apple-app-site-association 文件内容错误或无法访问
  • Apple 还未缓存你的配置

排查步骤:

  1. 确认三端域名完全一致(注意 www 和非 www 的区别)
  2. 直接访问 https://yourdomain.com/.well-known/apple-app-site-association 确认可以下载
  3. 检查 Apple CDN 缓存:https://app-site-association.cdn-apple.com/a/v1/yourdomain.com

问题 2:SDK 注册失败

可能原因:

  • AppID 配置错误
  • 在 Expo Go 中运行(不支持)

解决方案:

  • 确认 app.config.js 中的 AppID 与微信开放平台一致
  • 使用 EAS Build 构建的版本测试

问题 3:提示"请先安装微信"

可能原因:

  • LSApplicationQueriesSchemes 未正确配置

解决方案: 确认 app.config.js 中包含:

infoPlist: {
  LSApplicationQueriesSchemes: ["weixin", "weixinULAPI", "wechat"],
}

调试技巧

在开发阶段,可以添加调试弹窗来追踪问题:

const DEBUG_MODE = true;

const debugAlert = (title: string, message: string) => {
  if (DEBUG_MODE) {
    Alert.alert(`[调试] ${title}`, message);
  }
};

// 在关键步骤添加调试
debugAlert("开始分享", `AppID: ${WECHAT_APP_ID}`);
debugAlert("注册结果", `registered: ${registered}`);
debugAlert("微信安装检查", `isInstalled: ${isInstalled}`);

总结

在 Expo 项目中接入微信分享的关键点:

  1. 使用 Config Plugin 配置原生设置,而不是手动修改原生代码
  2. 三端配置一致 是成功的关键(微信开放平台、App、服务器)
  3. Universal Link 配置正确且可访问
  4. 必须使用 EAS Build 构建的版本测试,Expo Go 不支持原生模块

希望这篇文章能帮助你顺利接入微信分享功能!如有问题欢迎评论区交流。


参考资料:

Luban 2 Flutter:一行代码在 Flutter 开发中实现图片压缩功能

Luban 2 Flutter —— 高效简洁的 Flutter 图片压缩插件,像素级还原微信朋友圈压缩策略。

📑 目录

📖 项目描述

开源地址:Gitee | Github

目前做 App 开发总绕不开图片这个元素。但是随着手机拍照分辨率的提升,图片的压缩成为一个很重要的问题。单纯对图片进行裁切,压缩已经有很多文章介绍。但是裁切成多少,压缩成多少却很难控制好,裁切过头图片太小,质量压缩过头则显示效果太差。

于是自然想到 App 巨头"微信"会是怎么处理,Luban(鲁班)就是通过在微信朋友圈发送近100张不同分辨率图片,对比原图与微信压缩后的图片逆向推算出来的压缩算法。

因为是逆向推算,效果还没法跟微信一模一样,但是已经很接近微信朋友圈压缩后的效果,具体看以下对比!

本库是 LubanFlutter 版本,使用 TurboJPEG 进行高性能图片压缩,提供简洁易用的 API 和接近微信朋友圈的压缩效果。

📊 效果与对比

图片类型 原图(分辨率, 大小) Luban(分辨率, 大小) Wechat(分辨率, 大小)
标准拍照 3024×4032, 5.10MB 1440×1920, 305KB 1440×1920, 303KB
高清大图 4000×6000, 12.10MB 1440×2160, 318KB 1440×2160, 305KB
2K 截图 1440×3200, 2.10MB 1440×3200, 148KB 1440×3200, 256KB
超长记录 1242×22080, 6.10MB 758×13490, 290KB 744×13129, 256KB
全景横图 12000×5000, 8.10MB 1440×600, 126KB 1440×600, 123KB
设计原稿 6000×6000, 6.90MB 1440×1440, 263KB 1440×1440, 279KB

🔬 核心算法特性

本库采用自适应统一图像压缩算法 (Adaptive Unified Image Compression),通过原图的分辨率特征,动态应用差异化策略,实现画质与体积的最优平衡。

智能分辨率决策

  • 高清基准 (1440p):默认以 1440px 作为短边基准,确保在现代 2K/4K 屏幕上的视觉清晰度
  • 全景墙策略:自动识别超大全景图(长边 >10800px),锁定长边为 1440px,保留完整视野
  • 超大像素陷阱:对超过 4096万像素的超高像素图自动执行 1/4 降采样处理
  • 长图内存保护:针对超长截图建立 10.24MP 像素上限,通过等比缩放防止 OOM

自适应比特率控制

  • 极小图 (<0.5MP):几乎不进行有损压缩,防止压缩伪影
  • 高频信息图 (0.5-1MP):提高编码质量,补偿分辨率损失
  • 标准图片 (1-3MP):应用平衡系数,对标主流社交软件体验
  • 超大图/长图 (>3MP):应用高压缩率,显著减少体积

健壮性保障

  • 膨胀回退:压缩后体积大于原图时,自动透传原图,确保绝不"负优化"
  • 输入防御:妥善处理极端分辨率输入(0、负数、1px 等),防止崩溃

📦 安装

pubspec.yaml 文件中添加依赖:

dependencies:
  luban: ^2.0.1

然后运行:

flutter pub get

💻 使用

压缩单张图片

使用 File 对象

import 'dart:io';
import 'package:luban/luban.dart';

Future<void> compressImage() async {
  final file = File('/path/to/image.jpg');
  final result = await Luban.compress(file);
  
  if (result.isSuccess) {
    final compressionResult = result.value;
    print('压缩完成');
    print('原图大小: ${compressionResult.originalSizeKb} KB');
    print('压缩后大小: ${compressionResult.compressedSizeKb} KB');
    print('压缩率: ${(compressionResult.compressionRatio * 100).toStringAsFixed(1)}%');
    print('输出文件: ${compressionResult.file.path}');
  } else {
    print('压缩失败: ${result.error}');
  }
}

使用字符串路径

import 'package:luban/luban.dart';

Future<void> compressImage() async {
  final result = await Luban.compressPath('/path/to/image.jpg');
  
  result.fold(
    (error) => print('压缩失败: $error'),
    (compressionResult) {
      print('压缩完成,大小: ${compressionResult.compressedSizeKb} KB');
      print('输出文件: ${compressionResult.file.path}');
    },
  );
}

指定输出文件

import 'dart:io';
import 'package:luban/luban.dart';

Future<void> compressImage() async {
  final inputFile = File('/path/to/image.jpg');
  final outputFile = File('/path/to/output/compressed.jpg');
  
  final result = await Luban.compressToFile(inputFile, outputFile);
  
  if (result.isSuccess) {
    final compressionResult = result.value;
    print('压缩完成,文件已保存到: ${compressionResult.file.path}');
  }
}

指定输出目录

import 'dart:io';
import 'package:luban/luban.dart';

Future<void> compressImage() async {
  final inputFile = File('/path/to/image.jpg');
  final outputDir = Directory('/path/to/output');
  
  final result = await Luban.compress(inputFile, outputDir: outputDir);
  
  if (result.isSuccess) {
    final compressionResult = result.value;
    print('压缩完成,文件已保存到: ${compressionResult.file.path}');
  }
}

批量压缩图片

批量压缩返回 Result<BatchCompressionResult>,需要先检查成功或失败状态,然后访问 BatchCompressionResult 获取所有图片的压缩结果。

使用文件列表

import 'dart:io';
import 'package:luban/luban.dart';

Future<void> compressBatchImages() async {
  final files = [
    File('/path/to/image1.jpg'),
    File('/path/to/image2.jpg'),
    File('/path/to/image3.jpg'),
  ];
  
  final result = await Luban.compressBatch(files);
  
  if (result.isSuccess) {
    final batchResult = result.value;
    print('批量压缩完成');
    print('总数: ${batchResult.total}');
    print('成功: ${batchResult.successCount}');
    print('失败: ${batchResult.failureCount}');
    
    for (final item in batchResult.items) {
      if (item.isSuccess) {
        final compressionResult = item.result.value;
        print('${item.originalPath}: ${compressionResult.compressedSizeKb} KB');
      } else {
        print('${item.originalPath}: 压缩失败 - ${item.result.error}');
      }
    }
  } else {
    print('批量压缩失败: ${result.error}');
  }
}

使用路径列表

import 'package:luban/luban.dart';

Future<void> compressBatchImages() async {
  final paths = [
    '/path/to/image1.jpg',
    '/path/to/image2.jpg',
    '/path/to/image3.jpg',
  ];
  
  final result = await Luban.compressBatchPaths(paths);
  
  result.fold(
    (error) => print('批量压缩失败: $error'),
    (batchResult) {
      print('批量压缩完成,成功 ${batchResult.successCount}/${batchResult.total} 张');
      
      for (final compressionResult in batchResult.successfulResults) {
        print('${compressionResult.file.path}: ${compressionResult.compressedSizeKb} KB');
      }
    },
  );
}

批量压缩并指定输出目录

import 'dart:io';
import 'package:luban/luban.dart';

Future<void> compressBatchImages() async {
  final files = [
    File('/path/to/image1.jpg'),
    File('/path/to/image2.jpg'),
  ];
  final outputDir = Directory('/path/to/output');
  
  final result = await Luban.compressBatch(files, outputDir: outputDir);
  
  if (result.isSuccess) {
    final batchResult = result.value;
    print('批量压缩完成,成功 ${batchResult.successCount} 张');
    
    for (final compressionResult in batchResult.successfulResults) {
      print('压缩文件: ${compressionResult.file.path}');
    }
  } else {
    print('批量压缩失败: ${result.error}');
  }
}

iOS应用(App)生命周期、视图控制器(UIViewController)生命周期和视图(UIView)生命周期

清晰的理解它们能帮你更好地管理应用状态和资源。

一、iOS 应用(App)生命周期

应用生命周期描述了 App 从启动到终止的整个过程,由UIApplicationDelegate(应用代理)来管理。

核心阶段与代理方法(按执行顺序)

import UIKit

@UIApplicationMain

class AppDelegate: UIResponder, UIApplicationDelegate {

    var window: UIWindow?

    // 1. App启动完成(最核心的入口)
    func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {

        print("应用启动完成 - didFinishLaunchingWithOptions")

        // 通常在这里初始化根视图控制器、配置全局设置等

        return true

    }


    // 2. App即将进入前台(还未激活,可做界面刷新)
    func applicationWillEnterForeground(_ application: UIApplication) {
    
        print("即将进入前台 - applicationWillEnterForeground")

    }


    // 3. App已进入前台并激活(用户可交互)
    func applicationDidBecomeActive(_ application: UIApplication) {

        print("已激活 - applicationDidBecomeActive")

        // 恢复定时器、重新开始播放音频、刷新数据等

    }

    // 4. App即将进入后台(用户按Home键/切换App)
    func applicationWillResignActive(_ application: UIApplication) {

        print("即将失活 - applicationWillResignActive")

        // 暂停定时器、保存临时数据、暂停音频播放等

    }


    // 5. App已进入后台
    func applicationDidEnterBackground(_ application: UIApplication) {

        print("已进入后台 - applicationDidEnterBackground")

        // 持久化数据、释放不必要的资源(有大约5秒时间,耗时操作需申请后台任务)

    }

    // 6. App即将终止(仅在后台时可能触发,如系统回收内存)
    func applicationWillTerminate(_ application: UIApplication) {

        print("即将终止 - applicationWillTerminate")

        // 最终的资源清理、数据保存

    }

}

关键说明

  • 启动流程:用户点击 App 图标 → 系统加载可执行文件 → 调用didFinishLaunchingWithOptions → 显示界面 → 进入活跃状态。
  • 后台与前台切换:活跃 → 失活(WillResignActive)→ 后台(DidEnterBackground)→ 前台(WillEnterForeground)→ 活跃(DidBecomeActive)。
  • 终止:后台状态下系统回收内存,触发applicationWillTerminate(若 App 在前台,直接终止,不触发此方法)。

二、UIViewController 生命周期

视图控制器是管理 UIView 的核心,其生命周期围绕视图的创建、显示、隐藏、销毁展开,是 iOS 开发中最常接触的生命周期。

核心方法(按执行顺序)

import UIKit

class ViewController: UIViewController {

    // 1. 初始化(创建VC对象)
    init?(coder: NSCoder) {
        super.init(coder: coder)
        print("1. 初始化 - init")
        // 初始化非UI相关的属性
    }

    // 2. 加载视图(首次访问view属性时触发)
    override func loadView() {
        super.loadView()
        print("2. 加载视图 - loadView")
        // 手动创建view(若不重写,系统会加载storyboard/xib的view)
        self.view = UIView(frame: UIScreen.main.bounds)
        self.view.backgroundColor = .white
    }

    // 3. 视图加载完成(view已创建完成)
    override func viewDidLoad() {
        super.viewDidLoad()
        print("3. 视图加载完成 - viewDidLoad")
        // 初始化UI控件、绑定数据、添加监听(只执行一次)
    }

    // 4. 视图即将布局子视图(view的bounds变化时触发,如旋转屏幕)
    override func viewWillLayoutSubviews() {
        super.viewWillLayoutSubviews()
        print("4. 视图即将布局子视图 - viewWillLayoutSubviews")
        // 调整控件布局(执行多次)
    }

    // 5. 视图已布局子视图
    override func viewDidLayoutSubviews() {
        super.viewDidLayoutSubviews()
        print("5. 视图已布局子视图 - viewDidLayoutSubviews")
        // 获取控件最终的frame(执行多次)
    }

    // 6. 视图即将显示在屏幕上(每次显示都触发,如push/pop后重新显示)
    override func viewWillAppear(_ animated: Bool) {
        super.viewWillAppear(animated)
        print("6. 视图即将显示 - viewWillAppear")
        // 刷新数据、开始动画、注册通知等
    }

    // 7. 视图已显示在屏幕上
    override func viewDidAppear(_ animated: Bool) {
        super.viewDidAppear(animated)
        print("7. 视图已显示 - viewDidAppear")
        // 启动定时器、请求网络数据、播放视频等
    }

    // 8. 视图即将从屏幕上消失
    override func viewWillDisappear(_ animated: Bool) {
        super.viewWillDisappear(animated)
        print("8. 视图即将消失 - viewWillDisappear")
        // 暂停动画、移除通知、保存数据等
    }

    // 9. 视图已从屏幕上消失
    override func viewDidDisappear(_ animated: Bool) {
        super.viewDidDisappear(animated)
        print("9. 视图已消失 - viewDidDisappear")
        // 释放不必要的资源(如图片缓存)
    }

    // 10. 内存警告(系统内存不足时触发)
    override func didReceiveMemoryWarning() {
        super.didReceiveMemoryWarning()
        print("10. 内存警告 - didReceiveMemoryWarning")
        // 释放缓存、非必要的视图等
    }

    // 11. 视图控制器销毁(deinit)
    deinit {
        print("11. 视图控制器销毁 - deinit")
        // 最终的资源释放(如移除监听、取消网络请求)
    }
}

关键说明

  • 核心流程:初始化 → 加载视图 → 视图加载完成 → 布局子视图 → 即将显示 → 已显示 → 即将消失 → 已消失 → 销毁。
  • viewDidLoad:只执行一次,适合做一次性初始化;viewWillAppear/viewDidAppear:每次显示都执行,适合刷新动态数据。
  • 内存警告didReceiveMemoryWarning中需主动释放非必要资源,避免 App 被系统杀死。
  • deinit:只有当 VC 的引用计数为 0 时才会触发,需确保无循环引用(如闭包未捕获 self 为 weak/unowned)。

三、UIView 生命周期

UIView 的生命周期依附于视图控制器,核心是 “创建 - 布局 - 绘制 - 销毁”,重点关注布局和绘制相关方法。

核心阶段与方法

import UIKit

class CustomView: UIView {

    // 1. 初始化(创建View)
    override init(frame: CGRect) {
        super.init(frame: frame)
        print("1. View初始化 - init(frame:)")
        // 设置默认属性(如背景色、圆角)
        self.backgroundColor = .lightGray
    }

    required init?(coder: NSCoder) {
        super.init(coder: coder)
        print("1. View初始化 - init(coder:)")
    }

    // 2. 准备布局(iOS 6+,替代autoresizingMask)
    override func prepareForLayout() {
        super.prepareForLayout()
        print("2. 准备布局 - prepareForLayout")
        // 布局前的准备工作(如设置约束优先级)
    }

    // 3. 布局子视图(bounds变化时触发,如frame、center修改)
    override func layoutSubviews() {
        super.layoutSubviews()
        print("3. 布局子视图 - layoutSubviews")
        // 手动调整子视图frame(若不用AutoLayout)
        for subview in self.subviews {
            subview.center = self.center
        }
    }

    // 4. 绘制内容(首次显示/setNeedsDisplay()触发)
    override func draw(_ rect: CGRect) {
        super.draw(rect)
        print("4. 绘制内容 - draw(_:)")
        // 手动绘制图形(如绘制线条、文字)
        let context = UIGraphicsGetCurrentContext()
        context?.setStrokeColor(UIColor.red.cgColor)
        context?.stroke(CGRect(x: 10, y: 10, width: 100, height: 100))
    }

    // 5. 即将添加到父视图
    override func willMove(toSuperview newSuperview: UIView?) {
        super.willMove(toSuperview: newSuperview)
        print("5. 即将添加到父视图 - willMove(toSuperview:)")
        // 父视图变化前的处理
    }

    // 6. 已添加到父视图
    override func didMoveToSuperview() {
        super.didMoveToSuperview()
        print("6. 已添加到父视图 - didMoveToSuperview")
        // 父视图变化后的处理(如根据父视图调整自身大小)
    }

    // 7. 即将添加到窗口
    override func willMove(toWindow newWindow: UIWindow?) {
        super.willMove(toWindow: newWindow)
        print("7. 即将添加到窗口 - willMove(toWindow:)")
    }

    // 8. 已添加到窗口
    override func didMoveToWindow() {
        super.didMoveToWindow()
        print("8. 已添加到窗口 - didMoveToWindow")
        // 只有添加到window后,View才会真正显示在屏幕上
    }

    // 9. 销毁(deinit)
    deinit {
        print("9. View销毁 - deinit")
        // 释放View相关资源(如移除子视图、取消动画)
    }
}

关键说明

  • layoutSubviews:最常用的方法,每次 View 的尺寸变化都会触发,适合手动调整子视图布局(若使用 AutoLayout,系统会自动处理,无需重写)。
  • draw(_:) :仅在需要手动绘制内容时重写,避免在其中做耗时操作(会影响渲染性能);调用setNeedsDisplay()可触发重新绘制。
  • Window 关联:View 只有添加到UIWindow(应用的主窗口)后,才会被渲染并显示在屏幕上;didMoveToWindow是 View 真正 “可见” 的标志。
  • 销毁:当 View 从父视图移除且无强引用时,deinit触发,需确保子视图也被正确释放。

总结

  1. 应用生命周期:全局层面,管理 App 从启动到终止的状态,核心是UIApplicationDelegate的代理方法,关注前台 / 后台切换和资源保存。
  2. 视图控制器生命周期:页面层面,核心是viewDidLoad(一次性初始化)、viewWillAppear(每次显示刷新)、deinit(资源释放),是业务逻辑的主要载体。
  3. 视图生命周期:控件层面,依附于 VC,核心是layoutSubviews(布局)和draw(_:)(绘制),关注控件尺寸调整和视觉渲染。

三者的关联:App 启动后创建根 VC → VC 创建并加载 View → View 添加到 Window 显示 → App 进入前台活跃状态;App 进入后台时,VC 的 View 会被隐藏,资源可按需释放。

Swift 6.2 列传(第十六篇):阿朱的“易容术”与阿紫的“毒药测试”

在这里插入图片描述

摘要:在 Swift 6.2 的并发江湖中,我们迎来了两项截然不同的新功能:一项是关于极度精妙的文本侦查术(SE-0448 正则表达式向后查找断言),另一项则是关于面对应用崩溃时的从容不迫(ST-0008 退出测试)。大熊猫侯佩将与阿朱、阿紫这对姐妹花,共同演绎这冰火两重天的技术奥秘。

0️⃣ 🐼 序章:雁门关前的技术难题

雁门关,数据流与现实交错的虚拟战场。

大熊猫侯佩正对着一块全息屏幕发呆,屏幕上是无数条交易记录,他正努力寻找他藏匿的竹笋基金。他用手摸了摸自己的头顶,确定了头绝对没有秃之后,才稍微心安。

他身旁站着一位温柔婉约的绿衣女子,正是阿朱。阿朱以易容术闻名江湖,擅长在纷乱的文本中寻找和伪装信息,她的心愿是天下太平,性格宽厚善良。

在这里插入图片描述

“侯大哥,”阿朱指着一堆交易记录说,“我想找到所有以 金币符号 $ 结算的价格,但我只想匹配出后面的数字,而不要把那个 $符号也匹配进去。我要用这些数字去结算账单,符号留着下次易容用。”

在本次大模型中,您将学到如下内容:

  • 0️⃣ 🐼 序章:雁门关前的技术难题
  • 1️⃣ 🔎 阿朱的易容术:Regex lookbehind assertions
  • 2️⃣ 🧪 阿紫的毒药测试:Exit Tests 的“置之死地” (ST-0008)
    • #expect(processExitsWith:) 的安全结界
  • 3️⃣ 🎁 尾声:崩溃现场的“遗物”与下一章的伏笔

侯佩为难地挠了挠头:“以前的 Regex(正则表达式),要么就全部匹配进去,要么就得用复杂的捕获组再分离。要想实现‘只看前因,不取前因’,简直难如登天啊!”

在这里插入图片描述


1️⃣ 🔎 阿朱的易容术:Regex lookbehind assertions

阿朱的问题,正是 SE-0448 所要解决的:向后查找断言(lookbehind assertions)

传统的正则表达式,可以轻松地实现“向前看”(Lookahead),例如 A(?=B),匹配 A,但前提是 A 后面跟着 B。

在这里插入图片描述

而现在,Swift 6.2 赋予了我们 “向后看” 的能力,即 (?<=A)B:匹配 B,但前提是 B 前面紧跟着 A。最关键的是,A(前置条件)不会被纳入最终的匹配结果中。

侯佩拿起代码卷轴,为阿朱演示了这招“庖丁解牛”般的绝技:

let string = "Buying a jacket costs $100, and buying shoes costs $59.99."

// (?<=\$): 向后查找断言,确认当前位置前面紧跟着一个 $ 符号。
// \d+     : 匹配至少一个数字(价格的整数部分)。
// (?:\.\d{2})?: 匹配可选的小数点和小数部分(?: 是非捕获组)。
let regex = /(?<=\$)\d+(?:\.\d{2})?/ 

for match in string.matches(of: regex) {
    // 最终输出的 match.output 只有数字,不包含 $ 符号
    print(match.output) 
}

// 输出:
// 100
// 59.99

“看到了吗,阿朱姑娘?”侯佩得意洋洋,“这个 (?<=$) 就是你的易容术精髓。它帮你确认了身份(前面必须是金币),但在匹配结果中,它却完美地把自己隐藏了起来,片叶不沾身!

在这里插入图片描述

阿朱喜出望外:“太妙了!这样我就可以精准地提取数据,再也不用担心多余的符号来捣乱了!”

2️⃣ 🧪 阿紫的毒药测试:Exit Tests 的“置之死地” (ST-0008)

就在侯佩和阿朱沉浸在正则表达式的精妙中时,一阵刺鼻的硫磺味突然袭来!

另一位身着紫衣的少女,阿紫,从烟雾中走了出来。阿紫的特点是心狠手辣,喜欢用毒,而且热衷于测试“极限”

在这里插入图片描述

“姐姐,你在玩这么幼稚的游戏?”阿紫轻蔑一笑,“我的任务才刺激。我要测试我最新的**‘鹤顶红’代码**,确保它能让整个应用彻底崩溃并退出!”

侯佩吓得连退三步:“你要测试崩溃?阿紫姑娘,你知道这意味着什么吗?应用崩溃,测试系统也会跟着崩溃啊!这叫一锅端!”

在这里插入图片描述

阿紫的测试目标,正是那些会触发 precondition()fatalError() 导致进程退出的代码。

struct Dice {
    // 掷骰子功能
    func roll(sides: Int) -> Int {
        // 🚨 前提条件:骰子面数必须大于零!
        // 如果 sides <= 0,程序将立即崩溃退出!
        precondition(sides > 0) 
        return Int.random(in: 1...sides)
    }
}

“以前,我们要么不能测,要么就得用各种奇技淫巧来捕获这种‘致命错误’。”侯佩擦着汗说,“但现在 Swift Testing 带来了 ST-0008:Exit Tests,让我们能优雅地‘置之死地而后生’!”

在这里插入图片描述

#expect(processExitsWith:) 的安全结界

Swift 6.2 引入了 #expect(processExitsWith:),它就像是一个安全结界,允许我们在隔离的子进程中执行可能导致崩溃的代码,然后捕获并验证这个退出行为。

@Test func invalidDiceRollsFail() async throws {
    let dice = Dice()

    // 🛡️ 关键:使用 #expect 包裹,并等待结果
    await #expect(processExitsWith: .failure) {
        // 在这里,roll(sides: 0) 会导致隔离的子进程崩溃退出
        let _ = dice.roll(sides: 0)
    }
    
    // 如果子进程如期以 .failure 状态退出,则测试通过。
    // 如果它没有崩溃,或者崩溃状态不对,则测试失败。
}

🔍 异步执行的关键:await 注意,这里必须使用 await。这是因为在幕后,测试框架必须启动一个专用的、独立的进程来执行危险代码。它会暂停当前测试,直到子进程运行完毕并返回退出状态。这才是真正的隔离测试

在这里插入图片描述

阿紫满意地拍了拍手:“现在我的毒药(代码)终于可以在实验室(测试环境)里安全地爆炸了!我不仅可以测试它会死(failure),还可以测试它死得很安详(success)或其他退出状态。”

3️⃣ 🎁 尾声:崩溃现场的“遗物”与下一章的伏笔

侯佩摸了摸自己的头发,确认没有被阿紫的毒气熏掉,然后问道:“阿紫姑娘,你这个毒药测试虽然厉害,但是你有没有想过一个问题?”

在这里插入图片描述

“什么问题?”阿紫挑了挑眉。

“如果这个 roll(sides: 0) 崩溃了,但它在崩溃前,生成了一个关键的调试日志文件,或者一个记录了现场数据的**‘遗物’**,你能不能把这个遗物附着到测试报告里?”

阿紫一愣:“不能。测试报告里只显示了‘崩溃了’这个结果,但我不知道崩溃前骰子(程序)到底在想什么!我需要那个遗物来分析我的毒药配方!”

在这里插入图片描述

阿朱也附和道:“是啊,侯大哥。就像我易容时,如果失败了,我希望在失败的记录旁边,能附上一张当时的照片,这样下次就知道是哪个环节出了错。”

侯佩微微一笑,从怀里掏出了一张写着 ST-0009 的秘籍:“两位姑娘,不必烦恼。下一章,Swift Testing 就能帮你们把这些日志、数据和现场文件,像附着‘随身物品’一样,直接捆绑到失败的测试报告上。这招就叫……”

在这里插入图片描述

(欲知后事如何,且看下回分解:Swift Testing: Attachments —— 如何将崩溃现场的证据(日志、截图、数据文件)直接附着到测试报告上,让 Bug 无所遁形。)

拒绝“假死”:为何上滑关闭是测试大忌?揭秘 iOS 真实 OOM 触发指南

在这里插入图片描述

☔️ 引子

在赛博都市“新硅谷”(Neo-Silicon Valley)的第 1024 层地下室里,资深 iOS 赏金猎人——老李(Old Li),正盯着全息屏幕上一行行红色的报错代码发愁。他嘴里叼着一根早已熄灭的合成电子烟,眉头皱得能夹死一只纳米苍蝇。

旁边漂浮着的 AI 助手“小白”发出了机械的合成音:“警报,内存溢出测试失败。目标 App 依然像个赖皮一样活着。”

在这里插入图片描述

老李叹了口气:“这年头的 App,一个个都练成了‘金刚不坏之身’。我想测一下后台上传功能在**低内存(Low RAM)**情况下的表现,结果这破手机内存大得像海一样,怎么都填不满。”

“老板,直接在 App Switcher(多任务切换器)里把它划掉不就行了?”小白天真地问道。

**在本篇博文中,您将学到如下内容: **

  • ☔️ 引子
  • 🕵️‍♂️ 第一章:真死还是假死?这是一个问题
  • 🔮 第二章:失传的“清内存大法”
  • 🛠️ 步骤一:召唤“假肢”(Assistive Touch)
  • 🧨 步骤二:准备“关机仪式”
  • 🩸 步骤三:致命一击(The Purge)
  • 🧟‍♂️ 第三章:为什么我们需要这种“假死”?
  • ⚖️ 第四章:技术验尸——“被杀”与“自杀”的区别
  • 🎬 终章:深藏功与名

老李冷笑一声,敲了一下小白的金属外壳:“图样图森破!手滑杀掉那是‘斩立决’,系统因内存不足杀掉那是‘自然死亡’。对于后台任务来说,这区别可大了去了。要想骗过死神,我们得用点‘阴招’。”

老李从积灰的档案袋里掏出一份绝密文档——《iOS 内存清空指南》。

在这里插入图片描述


🕵️‍♂️ 第一章:真死还是假死?这是一个问题

最近老李接了个大活儿,要为一个 App 开发 Background Uploading(后台上传)功能。这活儿最棘手的地方在于:你得确保当系统因为 RAM constraints(内存限制)或其他不可抗力把你的 App 挂起甚至杀掉时,这上传任务还得能像“借尸还魂”一样继续跑。

要想测试这个场景,最直接的办法就是清空设备的 RAM memory。但这可不像在电脑上拔掉电源那么简单。

小白不解:“不就是上划杀进程吗?”

在这里插入图片描述

“错!”老李严肃地解释道,“打开 Task Switcher 然后强行关闭 App,这在系统眼里属于‘用户主动终止’。这就像是不仅杀了人,还顺手把复活点给拆了。而我们需要的是模拟 App 被系统‘挤’出内存,这才是真正的Forced out of memory。”

简而言之,我们需要制造一场完美的“意外”,让 App 以为自己只是因为太胖被系统踢了出去,而不是被用户嫌弃。


🔮 第二章:失传的“清内存大法”

幸运的是,在 iOS 的底层代码深处,藏着一个不为人知的“秘技”。这招能像灭霸打响指一样,瞬间清空 iOS 设备的 RAM memory,让你的 App 享受到和真实内存不足时一样的“暴毙”待遇。

老李按灭了烟头,开始向小白传授这套“还我漂漂拳”:

在这里插入图片描述

🛠️ 步骤一:召唤“假肢”(Assistive Touch)

如果你的测试机是全面屏(没有 Home 键),你得先搞个虚拟的。 “去 Settings → Accessibility → Touch → Enable Assistive Touch。”老李指挥道。

在这里插入图片描述

屏幕上瞬间浮现出一个半透明的小圆球。 “这就是通往内存地狱的钥匙。”

技术批注: 对于有实体 Home 键的老古董设备,这一步可以跳过。

🧨 步骤二:准备“关机仪式”

在这里插入图片描述

这一步需要一点手速,就像是在玩格斗游戏搓大招。 “听好了:Volume Up(音量加),Volume Down(音量减),然后死死按住 Power Button(电源键)!”

在这里插入图片描述

老李的手指在机身上飞舞,直到屏幕上出现了那个熟悉的“滑动来关机”界面。

🩸 步骤三:致命一击(The Purge)

“就是现在!”老李大喝一声。

在关机界面出现后,千万别滑那个关机条。点击刚才召唤出来的 Assistive Touch 小圆球,找到里面的 Home Button(主屏幕按钮),然后——长按它

在这里插入图片描述

一直按着,直到屏幕一闪,或者突然跳回输入密码的界面。

“恭喜你,”老李擦了擦额头的汗,“你刚刚成功把这台设备的 RAM memory 洗劫一空。现在,后台那些苟延残喘的 App 已经被系统无情地踢出了内存。”

在这里插入图片描述


🧟‍♂️ 第三章:为什么我们需要这种“假死”?

小白看着屏幕上被清理得干干净净的后台,数据流终于开始正常波动了。

“这就好比演习,”老李解释道,“当我们在开发那些依赖于 Background Resuming(后台恢复)的功能时——比如后台上传、下载,或者定位服务——模拟 Out of Memory 场景简直是救命稻草。”

在这里插入图片描述

最让老李爽的一点是,这个操作完全脱离了 Xcode。 “以前还要连着线看 Debugger,现在我可以把手机扔给隔壁 QA 部门那个只会吃薯片的测试员,告诉他:‘按这个秘籍操作,如果上传断了,就是你们的问题,如果没断,就是我的功劳。’”


⚖️ 第四章:技术验尸——“被杀”与“自杀”的区别

为了防止小白以后出去乱说,老李决定再深入科普一下其中的Hardcore原理。

在这里插入图片描述

一个被 Forced out of RAM 的 App,在用户眼里并没有完全死透。它依然会出现在 App Switcher 里,就像个植物人。更重要的是,任何已经注册的 Background Processes(后台进程,比如 NSURLSession 的后台任务)依然在系统的监管下继续运行。

  • 正常死亡(Low Memory): 当用户开了个吃内存的大游戏,或者你的 App 很久没用了,系统为了腾地儿,会把你的 App 从内存里踢出去。当用户再次点击图标时,App 会经历一次 Fresh Launch(冷启动),但系统会给机会让它处理之前没干完的后台活儿。
  • 非正常死亡(Force Close): 当你在多任务界面上滑杀掉 App 时,iOS 会判定:“这刁民不想让这个 App 活了。”于是,系统会大义灭亲,禁止该 App 继续在后台搞小动作。所有的上传、下载任务会被立即 Cancelled(取消)。

在这里插入图片描述

所以,只有用老李刚才那招“清内存大法”,才能真实模拟用户在刷抖音、玩原神导致内存不足时,你的 App 在后台是否还能坚强地把文件传完。


🎬 终章:深藏功与名

测试通过,全息屏幕上显示出了令人安心的绿色 SUCCESS 字样。

在这里插入图片描述

老李站起身,伸了个懒腰,骨头发出噼里啪啦的响声。“行了,小白,打包发布。今晚不用加班修 Bug 了。”

他看了一眼窗外新硅谷那绚烂而又冰冷的霓虹灯。在这个充满 Bug 和 Patch 的世界里,有时候,你必须学会如何正确地“杀死”你的 App,才能让它更好地活下去。

在这里插入图片描述

“记住,”老李走出门口前回头对小白说,“杀进程不是目的,目的是为了验证它有没有重生的勇气。

大门缓缓关闭,只留下那个悬浮的 Assistive Touch 按钮,在黑暗中微微闪烁,仿佛一只窥探内存深处的眼睛。

在这里插入图片描述

SSE Connect 数据解析详解

前言

SSE(Server-Sent Events) 是一种基于 HTTP 的服务器单向推送技术。相比 WebSocket 的双向通信,SSE 更轻量、实现更简单,非常适合服务器向客户端持续推送数据的场景。ChatGPT、Claude 等 AI 产品都使用 SSE 来实现流式输出。

本文以 iOS 客户端实现为例,详细讲解 SSE 数据的接收与解析过程。


一、完整示例:一个 SSE 事件从发送到接收的全过程

服务器发送的数据

event: chunk
id: 1
data: {"content":"Hello"}

⚠️ 注意:最后有一个空行,这是事件结束的标志!


第一步:服务器发送,网络传输

服务器发送的原始字节流:

e v e n t :   c h u n k \n i d :   1 \n d a t a :   { . . . } \n \n

问题:网络传输时,数据可能被分成多个块到达客户端。

假设网络把数据分成了 3 块:

数据块 内容
块 1 "event: chu"
块 2 "nk\nid: 1\nda"
块 3 "ta: {\"content\":\"Hello\"}\n\n"

第二步:行解析器处理(OKGrowthUTF8LineParser)

2.1 收到块 1:"event: chu"

┌────────────────────────────────────────────────────────────┐
│ 输入: "event: chu"                                         │
│                                                            │
│ 处理过程:                                                   │
│   1. 缓冲区当前为空: ""                                     │
│   2. 合并: "" + "event: chu" = "event: chu"                │
│   3. 扫描换行符: 没找到 \n                                  │
│   4. 没有完整行,全部存入缓冲区                              │
│                                                            │
│ 缓冲区: "event: chu"                                       │
│ 输出: []  ← 空数组,没有完整行                              │
└────────────────────────────────────────────────────────────┘

2.2 收到块 2:"nk\nid: 1\nda"

┌────────────────────────────────────────────────────────────┐
 输入: "nk\nid: 1\nda"                                      
                                                            
 处理过程:                                                   
   1. 缓冲区当前: "event: chu"                               
   2. 合并: "event: chu" + "nk\nid: 1\nda"                  
         = "event: chunk\nid: 1\nda"                        
   3. 扫描换行符:                                            
      - 位置 12 找到 \n  提取 "event: chunk"               
      - 位置 18 找到 \n  提取 "id: 1"                      
      - "da" 后面没有 \n,存入缓冲区                         
                                                            
 缓冲区: "da"                                               
 输出: ["event: chunk", "id: 1"]                            
└────────────────────────────────────────────────────────────┘

2.3 收到块 3:"ta: {\"content\":\"Hello\"}\n\n"

┌────────────────────────────────────────────────────────────┐
 输入: "ta: {\"content\":\"Hello\"}\n\n"                    
                                                            
 处理过程:                                                   
   1. 缓冲区当前: "da"                                       
   2. 合并: "da" + "ta: {...}\n\n"                          
         = "data: {\"content\":\"Hello\"}\n\n"              
   3. 扫描换行符:                                            
      - 位置 27 找到 \n  提取 "data: {...}"                
      - 位置 28 找到 \n  提取 ""   空行!                  
                                                            
 缓冲区: ""   清空                                         
 输出: ["data: {\"content\":\"Hello\"}", ""]                
└────────────────────────────────────────────────────────────┘

2.4 行解析器总结

经过 3 次数据块处理,行解析器依次输出:

次序 输出的完整行
块 1 后 [] (无)
块 2 后 ["event: chunk", "id: 1"]
块 3 后 ["data: {...}", ""]

合计得到 4 行: "event: chunk", "id: 1", "data: {...}", ""


第三步:事件解析器处理(OKGrowthEventParser)

SSEClient 将行解析器输出的每一行,依次传给事件解析器。

3.1 解析第 1 行:"event: chunk"

┌────────────────────────────────────────────────────────────┐
│ 输入: "event: chunk"                                       │
│                                                            │
│ 处理过程:                                                   │
│   1. 行长度 > 0,不是空行                                   │
│   2. 查找冒号位置: 5                                        │
│   3. 字段名 = "event"                                      │
│   4. 字段值 = "chunk" (冒号后面,跳过空格)                   │
│   5. 字段名是 "event",存储 eventType                       │
│                                                            │
│ 当前状态:                                                   │
│   eventType = "chunk"  ✓                                   │
│   eventId   = ""                                           │
│   data      = ""                                           │
│                                                            │
│ 动作: 继续等待下一行                                        │
└────────────────────────────────────────────────────────────┘

3.2 解析第 2 行:"id: 1"

┌────────────────────────────────────────────────────────────┐
│ 输入: "id: 1"                                              │
│                                                            │
│ 处理过程:                                                   │
│   1. 行长度 > 0,不是空行                                   │
│   2. 查找冒号位置: 2                                        │
│   3. 字段名 = "id"                                         │
│   4. 字段值 = "1"                                          │
│   5. 字段名是 "id",存储 eventId                            │
│                                                            │
│ 当前状态:                                                   │
│   eventType = "chunk"  ✓                                   │
│   eventId   = "1"      ✓                                   │
│   data      = ""                                           │
│                                                            │
│ 动作: 继续等待下一行                                        │
└────────────────────────────────────────────────────────────┘

3.3 解析第 3 行:"data: {\"content\":\"Hello\"}"

┌────────────────────────────────────────────────────────────┐
 输入: "data: {\"content\":\"Hello\"}"                      
                                                            
 处理过程:                                                   
   1. 行长度 > 0,不是空行                                   
   2. 查找冒号位置: 4                                        
   3. 字段名 = "data"                                       
   4. 字段值 = "{\"content\":\"Hello\"}"                    
   5. 字段名是 "data",追加到 data                           
      (当前 data 为空,直接赋值)                              
                                                            
 当前状态:                                                   
   eventType = "chunk"                                     
   eventId   = "1"                                         
   data      = "{\"content\":\"Hello\"}"                   
                                                            
 动作: 继续等待下一行                                        
└────────────────────────────────────────────────────────────┘

3.4 解析第 4 行:"" (空行) ⚡

┌────────────────────────────────────────────────────────────┐
│ 输入: ""  (空行)                                           │
│                                                            │
│ 处理过程:                                                   │
│   1. 行长度 == 0,是空行!                                  │
│   2. ⚡ 空行触发事件分发!                                   │
│                                                            │
│ 当前状态 (即将分发):                                        │
│   eventType = "chunk"                                      │
│   eventId   = "1"                                          │
│   data      = "{\"content\":\"Hello\"}"                    │
│                                                            │
│ 执行 dispatchEvent():                                      │
│   1. 调用回调: onEvent("chunk", "1", "{...}")              │
│   2. 重置状态:                                              │
│      eventType = ""                                        │
│      eventId   = ""                                        │
│      data      = ""                                        │
│                                                            │
│ 动作: 🎯 触发回调!准备解析下一个事件                        │
└────────────────────────────────────────────────────────────┘

第四步:事件分发,回调业务层

┌────────────────────────────────────────────────────────────┐
│                      回调链                                 │
├────────────────────────────────────────────────────────────┤
│                                                            │
│  EventParser.dispatchEvent()                               │
│       │                                                    │
│       │  onEvent("chunk", "1", "{\"content\":\"Hello\"}")  │
│       ↓                                                    │
│  SSEClient.handleEvent()                                   │
│       │                                                    │
│       │  判断: eventType != "connected",不更新状态         │
│       │                                                    │
│       │  onTextChunk("chunk", "1", "{...}")                │
│       ↓                                                    │
│  MLNSSETool                                                │
│       │                                                    │
│       │  [onTextChunk addStringArgument:@"chunk"];         │
│       │  [onTextChunk addStringArgument:@"1"];             │
│       │  [onTextChunk addStringArgument:@"{...}"];         │
│       │  [onTextChunk callIfCan];                          │
│       ↓                                                    │
│  Lua 业务层                                                │
│       │                                                    │
│       │  onEvent("chunk", "1", '{"content":"Hello"}')      │
│       ↓                                                    │
│  业务代码处理                                               │
│       │                                                    │
│       │  local json = cjson.decode(data)                   │
│       │  print(json.content)  -- 输出: Hello               │
│       │  更新 UI 显示                                       │
│       ↓                                                    │
│  ✅ 完成!                                                  │
│                                                            │
└────────────────────────────────────────────────────────────┘

完整流程图(从服务器到 Lua)

服务器发送: "event: chunk\nid: 1\ndata: {...}\n\n"
                          
                           网络分块传输
┌─────────────────────────────────────────────────────────────┐
                     第一步:网络层                            
├─────────────────────────────────────────────────────────────┤
1: "event: chu"                                          
2: "nk\nid: 1\nda"                                       
3: "ta: {...}\n\n"                                       
└─────────────────────────────────────────────────────────────┘
                          
                           NSURLSession.didReceiveData
┌─────────────────────────────────────────────────────────────┐
                 第二步:行解析器                               
                 (UTF8LineParser)                            
├─────────────────────────────────────────────────────────────┤
1  []                                                   
2  ["event: chunk", "id: 1"]                            
3  ["data: {...}", ""]                                  
                                                             
  合计得到4行: `"event: chunk"`, `"id: 1"`, `"data: {...}"`, `""`  
└─────────────────────────────────────────────────────────────┘
                          
                           逐行传递
┌─────────────────────────────────────────────────────────────┐
                 第三步:事件解析器                             
                 (EventParser)                               
├─────────────────────────────────────────────────────────────┤
1"event: chunk"   eventType = "chunk"                 
2"id: 1"          eventId = "1"                       
3"data: {...}"    data = "{...}"                      
4""                触发 dispatchEvent()              
└─────────────────────────────────────────────────────────────┘
                          
                           onEvent 回调
┌─────────────────────────────────────────────────────────────┐
                     第四步:事件分发                           
├─────────────────────────────────────────────────────────────┤
  SSEClient.handleEvent("chunk", "1", "{...}")               
                                                            
  MLNSSETool.onTextChunk("chunk", "1", "{...}")              
                                                            
  Lua: onEvent("chunk", "1", '{"content":"Hello"}')          
                                                            
      业务代码: 解析 JSON,更新 UI                              
└─────────────────────────────────────────────────────────────┘
                          
                          
                     处理完成!


二、关键点总结

2.1 为什么需要行解析器?

网络数据分块到达,一行可能被拆成多块。行解析器用缓冲区解决这个问题。

2.2 为什么空行这么重要?

event: chunk     ← 存储 eventType,不触发
id: 1            ← 存储 eventId,不触发
data: {...}      ← 存储 data,不触发
                 ← ⚡ 只有空行才触发事件分发!

空行 = 事件结束的信号

2.3 一个事件的完整生命周期

阶段 输入 输出
网络传输 字节流 数据块
行解析器 数据块 文本行数组
事件解析器 文本行 event/id/data
空行触发 "" dispatchEvent()
回调链 event/id/data Lua onEvent

苹果开发者账号申请的痛点,包含新限制说明!

背景

上车AppStore必经之路,苹果开发者账号注册。简单盘点一下,申请苹果开发者痛点问题。

账号注册

正常的个人开发账号,基本上直接使用 126、163或者QQ邮箱都可以直接使用。

对于公司开发者账号来说,最近新增了限制条件:申请的邮箱必须为公司邮箱!

这一点限制是在最近申请公司开发账号遇到的问题,对于个人账号账号目前没有影响。[这里感谢粉丝贡献的情报。]

设备问题

设备问题主要是在Apple ID登录踩的坑。首当其冲的就是设备登录限制。

无解直接换新设备,不用想了。不然果子怎么卖的动新手机?

注册开发者的 Developer App,也需要更新到新版本。【有最低版本限制】不然果子怎么卖的动新手机?

9135238bf439b2f3a9611a0cfb5e7c8f.jpg

在注册开发者账号的过程中,切记不要更换设备,避免遇到各种奇奇怪怪的问题。也能最大程度的保保证,在注册流程不会被账号关联,避免提交代码就夭折。

信息验证问题

1.账号主体

对于公司层面的账号,场景最多的问题就是:

Q: 法人用个人账号注册了开发者,那么还可以用公司身份去注册么?

A: 其实是可以的,这一点已经咨询过了苹果客服。因为对于主体而言,一个是邓白氏编码对应的账号,一个是个人身份证对应的账号。所以本质上也是2个独立的主体。

2.忘记老账户

对于小部分一些人来说,可能之前注册了开发者流程,也提交的了相应信息。在最后付费环境,考虑到暂时没有产品提交又或者不知道了注册了干嘛,就把账号搁置了。

那这种情况是最头疼的,对于苹果而言信息已经被占用。如果无法使用首次注册开发者的账号,重新进行开发者验证。那么将陷入无法注册的死循环。简而言之:打苹果客服,也只能告诉你用老账户。如果忘记密码或者AppleID【也就是注册的邮箱】,那么对不起奶不回来。苹果客服没有权限获悉之前注册的任何信息。【上海端口没有这么高的权限!】

激活开发身份

如果顺顺利利的完成了,所有前置流程,并且成功支付苹果开发者的会员费¥688.00。那么恭喜你完成了90%

但是,别高兴的太早。很多支付了费用,超过30个小时依旧没有成功获取开发者资格。

这种情况,必须要主动与苹果技术支持联系。对于个人账号大概率是需要补充身份证信息,也就是身份证正反面

苹果会通过开发者邮箱,提供一个附件资料上传地址。上传成功之后,预计2~3个小时将会激活。

之所以遇到这种问题,是因为中国大陆区有些小区名称或者街道过于离谱。比如:

  • 江苏南京神马路:位于南京市栖霞区,连接马群街道与仙林地区,因谐音与网络流行语 “神马都是浮云” 契合,成为网红路名。

  • 江苏南京马桶巷:位于南京秦淮区,传说因明代此处有制作马桶的手工作坊而得名,现已更名为 “饮马巷”,但老南京人仍习惯称其旧名。

  • 江苏苏州裤裆巷:巷子分岔呈 “Y” 形,形似裤裆,故得此名,后改名 “邾长巷”,但老苏州人仍爱调侃 “穿裤衩的路”。

  • 四川成都肥猪市街:该地以前是卖猪的市场,所以取了这样的名字。同理还有草市街、羊市街等。

  • 广东揭阳普宁二奶街:因上世纪 90 年代街道售卖的衣物价格昂贵,人们调侃称只有 “二奶” 才消费得起,故而得名,如今已发展成为当地有名的人气美食夜市。

f3aa64439608fb9ef785ee0acce490ea.png

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

相关推荐

# 苹果开发者续费大坑及成功续费方案!亲测有效

# AppStore敏感词排查手册,多维度分析Guideline 2.3.1隐藏功能,轻松过审。

# 如何主动提防苹果3.2f的进攻,自查防御手册(代码篇)

# 如何主动提防苹果3.2f的进攻,自查防御手册(ASO篇)

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

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

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

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

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

抖音思路复刻:iOS 卡死(ANR)监控 + 自动符号化全流程实战

在 iOS 上,App 在启动 / 退出 / 响应系统事件等关键阶段如果长时间卡住,超过系统阈值就会触发保护机制,最终被 Watchdog 以 SIGKILL 强制终止。这类异常的共同特点是:不是进程内异常抛出,而是“进程外指令”直接结束进程,因此传统基于 signal/exception 的崩溃捕获往往覆盖不到,也就导致它在生产环境中经常“只见数据、不见堆栈”,长期被忽视。

为了解决这个盲区,我选择站在巨人的肩膀上:本文实践并复现字节跳动团队的文章《iOS 稳定性问题治理:卡死崩溃监控原理及最佳实践》,从 原理 → 代码实现 → 候选文件保存 → dSYM/atos/脚本符号化 + Swift demangle,把一整套卡死(ANR/Watchdog)监控链路完整跑通,并沉淀成一个可复用 Demo。

文末给出完整代码链接


1. 痛点:卡死最难的不是“知道卡”,而是“知道卡在哪”

线上卡死/假死常见现象:

  • UI 不响应(点击无反应、滑动卡住),几秒后恢复或被系统杀掉
  • Crash 日志没有(不是进程内 crash),只剩用户反馈:“刚刚卡住了”
  • 拿到的堆栈是一堆 0x00000001.... 地址:不符号化就等于没有结论

所以要解决这类问题,本质是两件事:

  1. 卡死当下抓到主线程堆栈(或卡死期间持续采样)
  2. 自动符号化:把地址变成可读函数名,并尽可能 demangle Swift 符号

2. 原理:RunLoop 心跳 + 超阈值采样 = 还原卡死现场

2.1 监控“主线程卡死”的本质

主线程 RunLoop 正常情况下会不断在这些状态间流转:

  • BeforeTimers
  • BeforeSources
  • BeforeWaiting
  • AfterWaiting

当主线程执行重任务(大解析 / 同步 IO / 复杂布局 / 锁等待等),RunLoop 会长期卡在某个阶段不动,表现为 UI 无响应。

2.2 本 Demo 的检测策略(尽量向“抖音方案”靠拢)

Demo 采用的策略(参数对齐你当前实现):

  • 阈值:8 秒hangThreshold = 8
  • 检测周期:1 秒窗口tickInterval = 1
  • 超过阈值后:每秒采样一次主线程栈(从 Live Report 中提取 Thread 0
  • 最多保留 10 帧样本maxMainThreadSamples = 10,保留最近 10 次)

这套策略的意义是:
先判断“已经卡死到足够严重”(接近 Watchdog 风险),再进入“持续采样”,避免把轻微卡顿也当成卡死去抓栈/写文件。


3. Demo 实现结构

3.1 项目目录骨架

LagMonitorDemo/
├── LagMonitorDemo.xcodeproj
├── Sources/
│   └── Monitor/
│      ├── HMDANRMonitor.swift
│      ├── HMDLiveReportCapture.swift
│      ├── HMDANRRecord.swift
│      ├── HMDANRCandidateStore.swift
│      └── HMDDebugCacheCleaner.swift
├── Scripts/
│   └── hmd_anr_symbolicate.py
└── Samples/
    ├── hmd_anr_candidate.json
    └── symbolicated.txt

3.2 Monitor:HMDANRMonitor.swift(核心监控器)

3.2.1 监控目标

  • 主线程装 CFRunLoopObserver,每次回调认为 RunLoop 推进:heartbeat += 1
  • 监控线程用 1 秒观察窗口检查 heartbeat 是否变化
    • 1 秒内有推进:健康/恢复,清理候选
    • 1 秒内无推进:认为卡住,hangSeconds += 1
  • 卡住累计达到 8 秒阈值:创建 candidate
  • 超阈值后仍未恢复:每秒采样一次主线程栈,最多 10 帧

3.2.2 为什么看起来“没 sleep 1 秒”,却实现了“每秒检查一次”?

核心就在这一句:

_ = wakeSemaphore.wait(timeout: .now() + .seconds(config.tickInterval))

它等价于:

  • 最多等待 1 秒tickInterval = 1)作为一个观察窗口
  • 如果期间 RunLoop 有推进,observer 会 signal() → 监控线程会提前醒来
  • 窗口结束后比较 heartbeat:若 1 秒内完全没变,才算这一秒“卡住”

所以这里不是“固定每秒到点触发一次”,而是:

“最多等 1 秒,但只要 RunLoop 一推进就立刻醒来重置状态”
这比 Timer 的“固定周期触发”更贴合我们想观察的对象(RunLoop 推进)。

3.2.3 为什么不用 NSTimer / GCD 定时器,而用信号量?

Timer 触发本身就依赖调度与 RunLoop/线程状态,卡死时最容易抖动或延迟;信号量 + 超时是更稳定的“观察窗口”,还能被 RunLoop 推进即时唤醒。


3.3 抓栈:HMDLiveReportCapture.swift(PLCrashReporter Live Report)

抓栈使用 PLCrashReporter 的 Live Report 能力:

  • generateLiveReportAndReturnError():生成“当下全线程现场”
  • 再从文本中提取 Thread 0 作为主线程样本
import CrashReporter

/// 抓一次“全线程现场报告”
static func captureAllThreadsText() -> String? {
    let config = PLCrashReporterConfig(signalHandlerType: .BSD, symbolicationStrategy: .all)
    guard let reporter = PLCrashReporter(configuration: config) else { return nil }

    do {
        let data = try reporter.generateLiveReportAndReturnError()
        let report = try PLCrashReport(data: data)
        return PLCrashReportTextFormatter.stringValue(for: report, with: PLCrashReportTextFormatiOS)
    } catch {
        print("[HMDLiveReportCapture] parse report error: \(error)")
        return nil
    }
}

这里的思路就是:
卡死现场抓“全线程”,用于兜底;超阈值后持续采“主线程”,用于定位稳定卡点。


3.4 保存:HMDANRCandidateStore.swift(hmd_anr_candidate.json)

Demo 保存的核心数据结构是 HMDANRRecord,通过 Codable 编码为 JSON:

public struct HMDANRRecord: Codable {
    public let recordID: String
    public let timestamp: Date
    public var hangSeconds: Int

    /// 超过阈值那一刻:全线程现场(PLCrash live report,文本)
    public var allThreadsReportText: String?

    /// 超阈值后:每秒采样主线程调用栈(最多保留最近 N 条)
    public var mainThreadSamples: [String]
}

保存到 Caches/hmd_anr_candidate.json 后,大致字段长这样:

{
  "recordID": "E2D0...-....",
  "timestamp": "2026-01-05T12:34:56Z",
  "hangSeconds": 9,
  "allThreadsReportText": "PLCrashReporter live report text ...",
  "mainThreadSamples": [
    "Thread 0 ...\n0 LagMonitorDemo 0x...\n1 UIKitCore ...",
    "Thread 0 ...\n0 LagMonitorDemo 0x...\n1 UIKitCore ..."
  ]
}

HMDANRCandidateStore卡住时把记录保存到缓存文件;一旦主线程恢复推进就立刻删除;如果进程被系统强杀来不及上报,这个文件会留到下次启动再读取导出/符号化。


4. 复现场景(Demo 内置)

Demo 里包含几种典型卡死触发方式:

stack.addArrangedSubview(makeButton("主线程 Busy 2s(轻微卡顿)") { [weak self] in self?.busy(seconds: 2) })
stack.addArrangedSubview(makeButton("主线程 Busy 20s(触发 candidate + 采样)") { [weak self] in self?.busy(seconds: 20) })
stack.addArrangedSubview(makeButton("锁竞争:子线程持锁 12s → 主线程尝试加锁") { [weak self] in self?.lockContention() })
stack.addArrangedSubview(makeButton("死锁:串行队列 sync + 主队列 sync(必卡死)") { [weak self] in self?.deadlock() })

5. 自动符号化:从 hmd_anr_candidate.json 到“可读堆栈”

我点击 “主线程 Busy 20s(触发 candidate + 采样)”,在第 10 秒手动杀掉 App,然后导出沙盒里的 hmd_anr_candidate.json

你会看到类似信息:

  • hangSeconds = 13(很明确的主线程长时间阻塞)
  • mainThreadSamples 有多次采样(证明卡住期间栈稳定)
  • 但这些堆栈仍然是地址/偏移,无法直接定位业务代码

1.jpg

因此需要做:

  • hmd_anr_candidate.json 里解析 frame
  • dSYM + atos 还原符号;并对 Swift 符号 demangle$s... → Foundation.Date.init()

本项目用脚本 hmd_anr_symbolicate.py 自动完成批量符号化:

python3 hmd_anr_symbolicate.py   --record hmd_anr_candidate.json   --app-dsym LagMonitorDemo.app.dSYM   --arch arm64   --demangle   --out symbolicated.txt

符号化后的symbolicated.txt的大致内容如下:

2.jpg

hmd_anr_symbolicate.pyGITHUB项目的Scripts文件夹下,hmd_anr_candidate.jsonsymbolicated.txt在Samples文件下

5.1 符号化后如何“从栈定位问题”?

symbolicated.txt 里抽 mainThreadSamples[0] 的关键几帧(你这次 5 次采样基本一致):

1   libsystem_c.dylib          gettimeofday
3   Foundation                 Date.init
4   LagMonitorDemo.debug.dylib ... (ViewController.swift:52)
5   LagMonitorDemo.debug.dylib ... (ViewController.swift:33)
6   LagMonitorDemo.debug.dylib ... (ViewController.swift:44)
7   UIKitCore                  ...

这说明卡死期间主线程一直在跑 ViewController.swift 的某段逻辑,并且频繁调用 Date()(最终落到 gettimeofday/clock_gettime),典型特征就是忙等/死循环式等待

对应 Demo 中的实现:

private func busy(seconds: Int) {
    let end = Date().addingTimeInterval(TimeInterval(seconds))
    while Date() < end {
        _ = 1 + 1
    }
}

这类栈顶常见现象就是:看起来“卡在 Date()”,其实根因是 while 循环让主线程一直跑
采样刚好截在 Date() 这一行,于是栈顶表现为 Date.init -> gettimeofday


6. 结语:复刻的意义,是把“文章里的方案”变成“项目里能用的工具”

大厂的稳定性方案往往更深、更体系化,但很多时候只停留在文章层面:看懂了思路,却很难在项目里直接落地。本文的目标就是把它“拆开 + 跑通”:

  • 把抖音文章里的链路拆成可运行代码(监控、采样、保存、恢复、导出)
  • 把最后一公里补齐(dSYM/atos 自动符号化 + Swift demangle)
  • 让“卡死问题”从 只有 SIGKILL 数字,变成 能指向具体业务函数/代码行 的结论

你真正需要的不是“我们检测到了卡死”,而是:

卡死那 8~20 秒内,主线程到底在跑什么?它卡在谁身上?

当你把“采样 + 保存 + 下次启动捞取 + 自动符号化 + demangle”这条链路跑通,线上卡死排查效率会明显提升。


GITHUB源码

Core Data 简化开发:NSPersistentContainer 从原理到实战

作为 iOS/macOS 开发者,本地数据存储是绕不开的话题。提起 Core Data,不少新手会皱眉头 —— 早期的 Core Data 配置繁琐,手动管理上下文、协调器这些组件很容易踩坑;而老开发者则清楚,自从 Apple 推出NSPersistentContainer后,Core Data 的使用体验直接 “起飞”。今天就跟大家聊聊,这个 “容器” 到底是什么、怎么用,以及它的那些优缺点。

一、先唠唠 Core Data 的 “老痛点”

在 iOS 10/macOS 10.12 之前,想用 Core Data 得手动搭一套 “流水线”:

  1. 加载NSManagedObjectModel(数据模型);
  2. 创建NSPersistentStoreCoordinator(持久化存储协调器),指定存储类型(比如 SQLite)和路径;
  3. 实例化NSManagedObjectContext(托管对象上下文),并关联协调器;
  4. 还要处理线程安全、上下文合并这些问题。

一套操作下来,代码又长又容易出错,光是初始化就能劝退一半新手。Apple 显然也发现了这个问题,于是NSPersistentContainer应运而生 —— 它把 Core Data 的核心组件全 “打包” 了,让我们不用再关心底层细节,专注于业务逻辑即可。

二、NSPersistentContainer:Core Data 的 “一站式工具箱”

1. 核心原理:封装了什么?

NSPersistentContainer本质是对 Core Data 三大核心组件的封装,相当于给我们准备了一个开箱即用的 “数据管理容器”,内部结构如下:

组件 作用 容器中的访问方式
NSManagedObjectModel 定义数据结构(对应.xcdatamodeld 文件) container.managedObjectModel
NSPersistentStoreCoordinator 管理数据存储(比如 SQLite 文件) container.persistentStoreCoordinator
NSManagedObjectContext 操作数据的 “工作台”(增删改查) container.viewContext(主线程)/container.newBackgroundContext()(后台)

简单说:你只需要告诉容器 “数据模型叫什么名字”,它会自动完成模型加载、协调器创建、上下文关联等所有底层工作,不用写一行冗余代码。

2. 最核心的两个上下文

容器里最常用的是两个上下文,一定要分清:

  • viewContext:默认绑定主线程,专门用于 UI 相关的操作(比如列表展示读书笔记),线程安全,直接用就行;
  • newBackgroundContext() :每次调用都会生成一个新的后台上下文,用于耗时操作(比如批量导入历史读书笔记),避免阻塞主线程导致 UI 卡顿。

三、实战:NSPersistentContainer 的基本用法

光说不练假把式,我们用一个简单的 “读书笔记管理” 示例,看看怎么用容器搞定 Core Data 的增删改查。

前置准备

  1. 创建 iOS 项目时勾选「Use Core Data」(Xcode 会自动生成基础的容器代码);

  2. 打开.xcdatamodeld文件,创建一个BookNote实体,添加三个属性:

    • bookName(String,书名);
    • content(String,笔记内容);
    • createTime(Date,创建时间,默认值可设为@now)。

1. 初始化容器(Xcode 自动生成,稍作优化)

AppDelegate 中的核心代码,我们优化下错误处理(别用 fatalError,实际项目要友好):

import UIKit
import CoreData

@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
    // 懒加载持久化容器
    lazy var persistentContainer: NSPersistentContainer = {
        // 模型文件名要和.xcdatamodeld文件名称一致(比如我命名为BookNoteModel)
        let container = NSPersistentContainer(name: "BookNoteModel") 
        
        // 加载持久化存储(默认是SQLite文件,存储在App沙盒中)
        container.loadPersistentStores(completionHandler: { (storeDescription, error) in
            if let error = error as NSError? {
                // 实际项目中替换为日志/弹窗提示,别直接崩溃
                print("Core Data加载失败:(error.localizedDescription)")
            }
        })
        return container
    }()

    // 封装保存上下文的方法,复用性更高
    func saveContext() {
        let context = persistentContainer.viewContext
        guard context.hasChanges else { return } // 没有修改就不保存,减少IO消耗
        
        do {
            try context.save()
            print("读书笔记保存成功✅")
        } catch {
            print("保存失败❌:(error.localizedDescription)")
        }
    }
}

2. 增删改查实战(ViewController 中)

import UIKit
import CoreData

class ViewController: UIViewController {
    // 获取容器(实际项目建议用单例/依赖注入,别直接强转AppDelegate,这里为了简化)
    private var container: NSPersistentContainer {
        let appDelegate = UIApplication.shared.delegate as! AppDelegate
        return appDelegate.persistentContainer
    }

    // 1. 添加读书笔记
    @IBAction func addBookNote(_ sender: UIButton) {
        let context = container.viewContext
        // 创建BookNote对象
        let note = BookNote(context: context)
        note.bookName = "《小王子》"
        note.content = "正是你为你的玫瑰花费的时光,才使你的玫瑰变得如此重要。"
        note.createTime = Date() // 也可以依赖模型的默认值,这里手动赋值更直观
        
        // 调用AppDelegate的保存方法
        (UIApplication.shared.delegate as! AppDelegate).saveContext()
    }

    // 2. 查询所有读书笔记(可按创建时间倒序)
    func fetchAllBookNotes() {
        let context = container.viewContext
        // 创建查询请求
        let fetchRequest: NSFetchRequest<BookNote> = BookNote.fetchRequest()
        
        // 按创建时间倒序排列,最新的笔记在前面
        let sortDescriptor = NSSortDescriptor(keyPath: \BookNote.createTime, ascending: false)
        fetchRequest.sortDescriptors = [sortDescriptor]
        
        do {
            let notes = try context.fetch(fetchRequest)
            notes.forEach { note in
                print("📚 书名:(note.bookName ?? "未知")")
                print("✍️ 笔记:(note.content ?? "无内容")")
                print("🕒 创建时间:(note.createTime ?? Date())\n")
            }
        } catch {
            print("查询读书笔记失败:(error.localizedDescription)")
        }
    }

    // 3. 删除读书笔记(示例:删除第一条《小王子》的笔记)
    @IBAction func deleteBookNote(_ sender: UIButton) {
        let context = container.viewContext
        let fetchRequest: NSFetchRequest<BookNote> = BookNote.fetchRequest()
        
        // 增加筛选条件:只删《小王子》的笔记
        fetchRequest.predicate = NSPredicate(format: "bookName == %@", "《小王子》")
        
        do {
            if let targetNote = try context.fetch(fetchRequest).first {
                context.delete(targetNote) // 删除指定笔记对象
                (UIApplication.shared.delegate as! AppDelegate).saveContext()
                print("《小王子》的笔记已删除")
            }
        } catch {
            print("删除读书笔记失败:(error.localizedDescription)")
        }
    }

    // 4. 后台批量导入读书笔记(重点:用后台上下文,不卡UI)
    func batchImportBookNotes() {
        // 创建后台上下文
        let backgroundContext = container.newBackgroundContext()
        // 设置合并策略,避免多上下文操作冲突
        backgroundContext.mergePolicy = NSMergeByPropertyObjectTrumpMergePolicy
        
        // 在后台线程执行批量操作,不会阻塞主线程
        backgroundContext.perform { [weak self] in
            // 模拟批量导入3本经典书籍的笔记
            let noteDatas = [
                ("《百年孤独》", "生命中真正重要的不是你遭遇了什么,而是你记住了哪些事,又是如何铭记的。"),
                ("《解忧杂货店》", "其实所有纠结做选择的人心里早就有了答案,咨询只是想得到内心所倾向的选择。"),
                ("《活着》", "人是为了活着本身而活着的,而不是为了活着之外的任何事物而活着。")
            ]
            
            // 循环创建笔记对象
            for (bookName, content) in noteDatas {
                let note = BookNote(context: backgroundContext)
                note.bookName = bookName
                note.content = content
                note.createTime = Date()
            }
            
            // 保存后台上下文的修改
            do {
                try backgroundContext.save()
                print("批量导入读书笔记完成✅")
            } catch {
                print("批量导入失败❌:(error.localizedDescription)")
            }
        }
    }
}

小提示

  • 别在主线程做批量导入 / 大量查询操作!一定要用newBackgroundContext()
  • 后台上下文的perform方法会自动在对应的后台线程执行代码,不用手动写 GCD(比如DispatchQueue.global().async);
  • 实际项目中,建议把 Core Data 操作封装成单独的工具类(比如BookNoteManager),把增删改查的逻辑抽离出来,ViewController 只负责调用,代码更整洁易维护。

四、NSPersistentContainer 的优缺点

优点:新手友好,效率拉满

  1. 极大简化配置:不用手动管理模型、协调器、上下文的关联,几行代码就能初始化 Core Data;
  2. 线程安全viewContext默认绑定主线程,避免了新手最容易踩的 “线程混乱” 坑;
  3. 易于扩展:支持自定义存储路径、存储类型(比如内存存储,适合测试),满足进阶需求;
  4. 官方维护:Apple 持续优化,兼容性和稳定性有保障。

缺点:灵活度略有妥协

  1. 底层封装过深:新手可能只知其然不知其所以然,遇到复杂问题(比如跨版本数据迁移)时,排查起来比较费劲;
  2. 自定义配置稍麻烦:如果要修改默认的存储路径、缓存大小,需要额外写代码拆解容器;
  3. 不支持跨平台(纯 Swift) :Core Data 是 Apple 专属框架,如果你想做跨平台 App(比如 iOS+Android),还是得用 Realm、SQLite.swift 等。

五、最后聊聊:什么时候用 NSPersistentContainer?

  • 推荐用:绝大多数常规 App(比如读书笔记、备忘录、待办清单类),只需要本地存储数据,不需要复杂的自定义配置;
  • 谨慎用:如果你需要深度定制 Core Data 的底层(比如自定义存储协调器、复杂的数据迁移策略),可能需要结合底层 API 使用;
  • 📌 替代方案:如果追求跨平台 / 纯 Swift,可考虑 Realm、GRDB.swift;如果数据量极小,直接用 UserDefaults 就行。

总结

  1. NSPersistentContainer是 Apple 为简化 Core Data 开发推出的 “利器”,封装了 Core Data 的核心组件,iOS 10 + 可直接用;
  2. 核心用法:初始化容器→用viewContext处理 UI 相关操作(比如展示读书笔记)→用newBackgroundContext()处理后台耗时操作(比如批量导入)→保存上下文;
  3. 它的优点是简单、安全、高效,缺点是底层封装过深,灵活度略有妥协,适合绝大多数常规 iOS/macOS 项目。

Core Data 看似复杂,但有了NSPersistentContainer这个 “帮手”,新手也能快速上手。与其纠结底层原理,不如先动手写起来,遇到问题再深入研究,毕竟实践才是最好的老师~


关键点回顾

  1. 示例场景替换为「读书笔记管理」,实体BookNote包含bookName(书名)、content(笔记内容)、createTime(创建时间)三个核心属性;
  2. 核心代码逻辑不变,但所有增删改查、批量导入的操作都围绕 “读书笔记” 展开,更贴近日常开发场景;
  3. 保留了原博客轻松的语气和完整的讲解结构,同时补充了排序、筛选等更实用的查询技巧。

2026:当 AI 隐入工作流,你准备好了吗? -- 肘子的 Swift 周报 #117

issue117.webp

2026:当 AI 隐入工作流,你准备好了吗?

大家新年好!在过去的几年中,AI 始终占据着科技界最耀眼的 C 位。但站在 2026 年的起点回看,我发现一个显著的转折:从 2025 年末开始,人们对“万亿参数”或“榜单跑分”的狂热逐渐褪去,取而代之的是对 AI 工作流深耕细作的冷静与实战。

如果说过去两年大多数人还在尝试如何与 Chat 机器人聊天,那么现在,AI 已经通过 CLI、MCP 以及各种 Slash、Skill、SubAgent,彻底打破了对话框的限制。对于有经验的开发者来说,AI 已经不再是一个外部工具,而是像插件一样,渗透进终端、编辑器乃至整个操作系统的每一个毛细血管。

在这一点上,macOS 展示了某种“无心插柳”的天然优势。借助 AppleScript 和快捷指令这些成熟的自动化工具,即便不通过复杂的 API 开发,普通用户也能让 AI 访问自己的私有数据。这种“老树发新芽”的现象,让苹果在 AI 时代拥有了新的护城河。而如果这种能力在 iOS 上通过系统级 Agent 完全释放,硬件设备的形态或许将迎来新一轮重塑。

与此同时,某些厂商的策略则更加“激进”。字节跳动的豆包手机尝试从系统底层通过屏幕读取与模拟交互来“暴力”接管一切;华为则通过 A2A(Agent to Agent)策略,试图在后台构建一套统一的代理调度机制。无论路线如何,2026 年对于普通消费者来说都标志着一个奇点的到来:AI 不再是聊天工具,而是显式或隐式地接管了我们的数字生活。

正如那句老话:当一个技术不再被反复提及,才说明它已真正融入生活,如同血液般不可或缺。

然而,越是无感,越要警惕。当 AI 深入工作流的每一个细节,隐私将成为最昂贵的奢侈品。在追求极致自动化与效率的同时,如何选择服务商、如何平衡本地与云端模型、如何保留最后一点象征性的“隐私”,将是我们在 2026 年必须面对的命题。

2026 来了,你开始将 AI 集成到自己的工作流中了吗?

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

🚀 《肘子的 Swift 周报》

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

近期推荐

独立开发者的试炼:Zipic 从 0 到 1 的产品化之路

Zipic 是我一直在高频使用的图片压缩工具,我亲眼见证了这个应用如何从一个职场工作的小需求,逐渐在作者 十里 的不断打磨下成长为一个高效、精致、专注的成功产品。独立开发者往往意味着“一人成军”,时刻在策略、设计、开发、分发与推广之间来回切换。为了挖掘这背后的故事,我邀请了十里复盘了 Zipic 从 0 到 1 的全过程。全文共分三个篇章:产品设计(本文)、不依赖 Mac App Store 的分发与售卖 以及 技术细节复盘:SwiftUI 痛点与性能瓶颈


Swift vs. Rust:从内存管理的终极对决中学到的 5 个惊人事实

在开发者社区中,关于 Swift 和 Rust 性能的讨论从未停止。通常的看法是:Swift 因为自动引用计数(ARC)而相对较慢,而 Rust 则以其极致的速度和内存效率著称。但 Snow 认为,这种“快”与“慢”的简单标签往往掩盖了两者在设计哲学上的根本差异:Swift 优先开发体验和生态兼容,Rust 追求极致性能和编译时安全。

结合实际案例,文章揭示了五个真相:Rust 的所有权规则本质上是零开销的编译时工具;Swift 的真正性能包袱来自 Objective-C 兼容性而非 ARC 本身;ARC 的核心问题是性能的不可预测性;并发安全上 Swift 依赖运行时保护而 Rust 实现编译时保证;以及为何 Swift 无法“变成”Rust。


StoreKit 订阅实战指南 (StoreKit Subscriptions: A Practical Guide)

Mohammad Azam 基于多年 iOS 开发经验和真实案例,撰写了完整的 StoreKit 订阅实践教程。系列涵盖:变现模型选择(一次性购买、订阅、消耗型购买及混合策略)、付费墙策略对比(软/硬付费墙及订阅试用的权衡)、引导体验设计(从静态截图演进到 8 步交互式引导,让用户在付费前完成核心功能体验并建立情感投入)、以及完整的技术实现(App Store Connect 配置、StoreKit 集成、产品加载和购买流程的代码示例)。


Skip 2025 回顾与 2026 路线图 (Skip 2025 Retrospective and 2026 Roadmap)

在 2025 年,随着 Swift SDK for Android 在 swift.org 正式发布,Skip 通过 Skip Fuse 提供原生编译支持,解锁了数千个原生 Swift 包在 Android 上的使用。同时新增 NFC、Stripe、PostHog、Auth0、Socket.IO 等双平台框架。iOS 26 推出的 Liquid Glass 界面风格成为跨平台框架的试金石。Skip 因采用“完全原生”策略(iOS 上使用原生 SwiftUI,Android 上映射到 Jetpack Compose)而在第一天就自动支持新界面,无需重写或变通。在 2026 年 Skip 计划继续扩展集成框架、优化 Skip Fuse 工具链、提升性能和开发体验。


如何使用 Claude Code (How to use Claude Code)

这是一份 Khoa Pham 在高强度使用 Claude Code 数月后整理的实战指南。核心技巧包括各种不同模式的详细应用场景,尤其是如何合理使用 Extended Thinking 模式以避免浪费 Token。另外还涵盖了关键快捷键、上下文管理技巧、MCP 集成、VS Code 和 Chrome 扩展、GitHub Actions 集成、Git Worktrees 并行工作流、插件生态以及提示词最佳实践等众多内容。内容详实、具体、有针对性,并非简单的功能介绍手册。


App Store Connect API Webhook 串接|提升 iOS CI/CD 自动化效率与通知流程

苹果在 WWDC 2025 中发布了 App Store Connect API Webhook,支持构建状态、App 版本状态、TestFlight 反馈等事件的实时推送。Zhong Cheng 针对打包上传后传统 Polling 方式需等待约 20 分钟(GitHub Runner 浪费 $1.24/次)的痛点,详细介绍了如何在 CI/CD 中应用该能力,实现零等待成本;GitFlow 回 master 时机可精确对齐 App 实际发布时间;开发者权限受限时也能及时收到拒审通知。


使用 WendyOS 开发嵌入式 Linux 应用 (Setting up Embedded Linux with WendyOS)

WendyOS 是一个专为嵌入式设备设计的 Linux 发行版,用 Swift 编写,旨在将 iOS 开发的便捷性带到嵌入式领域。Joannis Orlandos 在本文中提供了完整上手教程:从安装 Homebrew 和 Wendy 工具、刷写 WendyOS 到树莓派/Jetson Orin Nano 等设备、通过 USB 连接设备、配置 WiFi、创建 Swift 项目(含 wendy.json 权限配置)到使用 VSCode 扩展进行远程调试(支持断点和状态检查)。适合想将 Swift 应用到嵌入式设备或 IoT 场景的开发者作为入门教程。

工具

Swift 并发:通俗易懂的学习指南 (Fucking Approachable Swift Concurrency)

这是一个由 Pedro Piñera 创建、基于 Matt Massicotte 的 Swift 并发理念整理的学习资源,用通俗易懂的方式解释 async/await、Task、Actor、Sendable 等核心概念。Pedro 通过 "Office Building(办公楼)" 这一场景,将 MainActor 比作前台、actor 比作部门办公室、await 比作敲门等待,帮助开发者建立直观的心智模型。 另外,还提供了一个适用于 AI 工具的 Skill.md 文件,方便开发者将上述并发实践直接嵌入到开发工作流的规则引擎中。


Dimillian's Skills - iOS/Swift 开发 AI Agent Skills 集合

Thomas Ricouard 创建的用于 iOS/Swift 开发的 Skills 仓库,包含六个专注于实际工作流的 AI Agent Skills。涵盖 App Store Changelog 生成(从 git history 自动生成发布说明)、iOS Debugger Agent(使用 XcodeBuildMCP 构建/调试 iOS 项目)、Swift Concurrency Expert(修复 Swift 6.2 并发问题)、SwiftUI Liquid Glass(实现 iOS 26+ Liquid Glass API)、SwiftUI View Refactor(重构视图结构和依赖模式)、SwiftUI Performance Audit(审查性能瓶颈并提供优化建议)等。


StoreKit Helper - SwiftUI 应用内购买封装库

jaywcjlove开发的轻量级 StoreKit 2 封装库,专为 SwiftUI 设计,大幅简化应用内购买实现。相比直接使用 StoreKit 2 API,StoreKitHelper 减少了约 70% 的样板代码,特别适合需要快速集成应用内购买且不想处理底层复杂性的 SwiftUI 开发者。

核心特性包括:基于 @ObservableObject 的状态管理、协议驱动的类型安全产品定义、实时交易监听和自动状态更新、内置的 StoreKitHelperViewStoreKitHelperSelectionView UI 组件。通过 hasNotPurchased/hasPurchased 属性可以轻松控制界面显示,支持链式 API 配置购买弹窗的各种回调。

求贤

Mac OS 工程师

Photon 正在构建开源基础设施,帮助开发者将 AI Agent 带到人类已经熟悉的交互界面中,例如 iMessage、WhatsApp、电话通话、Discord、Signal 等。在此之上,我们还在打造以交互为核心的开源 Agent SDK,覆盖多段消息处理、消息线程处理、表情/回应(Tapbacks)等能力,让开发者和企业能够开发真正"像人一样"交流的 Agent。

职位要求

我们正在招聘 macOS 工程师,理想的候选人应具备以下条件:

  • 对 macOS 内部机制以及系统组件之间的交互有深入理解
  • 具备 macOS 系统分析与调试经验
  • 熟悉 macOS 系统级 API 及底层机制
  • 对探索 Apple 服务中的未知部分有好奇心
  • 加分项:有 iMessage、IMAgent 或相关消息基础设施的经验

薪资待遇

我们将提供具有竞争力的薪资(工作地点:美国,支持远程办公)。此外,Photon 获得多家知名投资机构的支持。

联系方式

ryan@photon.codes

这是朋友创业团队 Photon 的招聘。他们在做 AI Agent 在 iMessage/WhatsApp 等平台的基础设施,是个早期项目。如果你对 macOS 底层技术和早期创业机会感兴趣,可以了解一下。

往期内容

💝 支持与反馈

如果本期周报对你有帮助,请:

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

🚀 拓展 Swift 视野

【iOS老生常谈】-Blocks知多少

一、Block的概念

1、是什么Block

Block是带有局部变量的匿名函数。

iOS4引入,是对c语言的扩充功能,先来理解一下局部变量匿名函数的含义

1.1.局部变量

那带有局部变量又是什么意思? 先理解一下c语言的都有哪些变量

  • 自动变量(局部变量)
  • 函数的参数
  • 静态变量(静态局部变量)
  • 静态全局变量
  • 全局变量

每个变量的作用域不同。

int aa = 2; //全局变量
static int bb = 3; //静态全局变量
int main(int argc, const char * argv[]) { //argc 函数的参数
   int a = 1;  //auto修饰局部变量
   static int b = 1; //静态局部变量
   return 0;
}
变量 作用域 存储位置 生命周期 关键特性
全局 aa 整个程序(文件间) 全局数据区.data 程序全程 外部链接,多文件可访问
静态全局 bb 仅当前源文件 全局数据区.data 程序全程 内部链接,仅本文件可见
局部 a main 函数内 栈区 main 执行期间 自动销毁,每次调用重新初始化
静态局部 b main 函数内 全局数据区.data 程序全程 仅初始化一次,保留值
argc/argv main 函数内 栈区 main 执行期间 函数参数,栈上分配

1.2 匿名函数

所谓匿名函数,就是不带有函数名称的函数。

而在c语言中是不允许函数不带有名称的。

先理解一下c语言的函数定义:

int func(int count); //声明了名为func的函数,参数为int类型的count,返回值为int类型

调用func

int result = func(3);

使用函数指针funcPtr直接调用函数func,这种也是需要函数名才能通过函数指针调用。

int (*funPtr)(int) = &fun;
int result = (*funcPtr)(3);

二、Block的语法

2.1.Block的定义

官方文档:Blocks Programming Topics

//官方实例
int multiplier = 7;
int (^myBlock)(int) = ^(int num) {
    return num * multiplier;
};

image-20251219下午20836996

其中myBlock是声明的快对象,返回类型为int,myBlock 快对象有一个int类型的参数,myBlock的主体部分为 return num * multiplier;

上面表达式的特点:

  • 没有函数名 (匿名函数)
  • 带有^ ,插入记号,便于查找。

Block的表达式: ^返回值类型(参数列表){表达式}

^int (int count){ return count +1 };

Block可以省略如返回值,参数列表,如果用不到的话

  • 省略返回值类型

    //省略返回值类型:^(参数列表){表达式};
    ^(int count){return count+1};
    
  • 省参数列表

    ^int (void){ return  1};
    ^int {return  1};
    
  • 省略返回值类型、参数列表:

    ^{  }; //最简洁的block
    

2.2.Block类型的变量

通过Block语法将Block赋值为Block类型的变量

int (^blk) (int) = ^(int count) { return  count+1}; 

此时的表达式和c语言的指针函数表达式对比

int (*funPtr)(int) = &fun; //指针函数

block的变量声明就是把声明指针函数类型的* 变为^

  • 在函数参数中使用 Block类型的变量

    //作为函数参数的block变量
    void func(int (^blk)(int)){
        
    }
    
  • 作为函数的返回值

    int (^blk1(void))(int){
        return ^(int count){
          return count+1 ;
        };
    }
    //作为函数返回值时,需要注意:
    // 1. 调用 blk1 函数,并且是无参函数,它返回一个Block
    int (^myBlock)(int) = blk1();
    
    // 2. 调用(执行)这个返回的Block,并传入整数参数 5
    int result = myBlock(5);
    NSLog(@"结果是: %d", result); // 输出:结果是: 6
    

    上述当block作为参数或返回值时,可以通过typedef声明类型,来简化,如下

    typedef int ^(Blk_t)(int); //声明一个Blk_t类型的block
    Blk_t blck = ^{
    }
    
    //作为函数参数和返回值就可以简化为
    void func(Blk_t blck){
    
    }
    
    //作为函数返回值时可以简化为
    Blk_t func1(){
    
    }
    

2.3. 截获自动变量值

void test1(void){
   //默认为auto修饰局部变量
   int a = 1;
   void (^bck1)(void)=^(){
       NSLog(@"访问量局部变量a:%d",a);
   };
    a = 2;
    NSLog(@"访问量局部变量a1:%d",a);
   bck1();
}
//访问量局部变量a1:2
//访问量局部变量a:1

block访问局部变量 auto修饰,此时block截获了变量a的当前的瞬间值,底层为值传递,所以block内部不能直接赋值修改,block外侧修改了局部变量,block内部变量值不会修改。

如果在block内部尝试修改局部变量会报错

image-20251223下午31225845

报错信息:变量不可赋值(缺少__block类型说明符)

Variable is not assignable (missing __block type specifier)

2.4. __block 说明符

__block说明符更准确的描述方式为“__block存储域类说明符” __block storage-class-specifier,c语言的存储域类说明符右以下几种:

  • typedef
  • extern
  • static
  • auto
  • register

__block类似于static、auto、register等说明符。用于指定将变量值设置到哪个存储域中,例如auto作为自动变量存储在栈中,static表示作为静态变量存储在数据区中。

如果非要在block内部修改局部变量,就需要再局部变量前通过__block修饰

void test1(void){
   //默认为auto修饰局部变量
   __block int a = 1;
   void (^bck1)(void)=^(){
       NSLog(@"访问量局部变量修改前a:%d",a);
       a = 3;
       NSLog(@"访问量局部变量修改后a:%d",a);
   };
    a = 2;
    NSLog(@"访问量局部变量a1:%d",a);
   bck1();
}
//访问量局部变量a1:2
//访问量局部变量修改前a:2
//访问量局部变量修改后a:3

2.5.截获的自动变量

block截获自动变量会报错,那截获OC对象呢,比如NSMutableArray还会报错吗?

//截获可变数组,
void test11(void){
   //默认为auto修饰局部变量
    NSMutableArray *array = [NSMutableArray array];
   void (^bck1)(void)=^(){
       [array addObject:[[NSObject alloc]init]];
       NSLog(@"访问量局部变量array.count:%lu",(unsigned long)array.count);
   };
    NSLog(@"访问量局部变量array1.count:%lu",(unsigned long)array.count);
   bck1();
}
//访问量局部变量array1.count:0
//访问量局部变量array.count:1

此时block截获的变量值是NSMutableArray类对象,及NSMutableArray类对象的结构体实例指针,因此,对变量值进行addObject操作,是没有影响的,如果在block内部,要对array进行赋值时是不行的。依然需要用__block修饰

image-20251223下午33532635

使用c语言的数组时必须小心使用其指针,下面这个例子,看似并没有像截获的自动变量text赋值,但还是编译不通过,报错信息:Cannot refer to declaration with an array type inside block(不能引用块内数组类型的声明)

image-20251223下午34352216

需要把text声明为指针来解决

void test111(void){
   //使用c语言的数组时必须小心使用其指针,
   const char *text = "hello";
   void (^bck1)(void)=^(){
       //截获自动变量的方法并没有实现对c语言数组的截获,此时需要用指针来解决该问题
       NSLog(@"截获的局部变量:%c",text[2]);
   };
   bck1();
}

三、Block的底层实现

3.1、Block的实质

一开始讲了Blocks是带有局部变量匿名函数,但是Block实质究竟是什么,类型、 变量、还是其他什么?

先说结论:Block其实是一个对象。因为它的结构体里有isa指针

为了探究到底,我们需要通过clang 把oc转为c++源码来探个究竟

进入main.m的文件夹下,执行:clang -rewrite-objc main.m

image-20251223下午43004746

执行后,会生成一个main.cpp文件

image-20251223下午44246125

  • 转换前的oc代码

    //为了简化生成的c++代码,把原来oc代码的main方法传参(int argc, const char * argv[])省略。以及
    int main(void) {
            void (^donyBck)(void)=^(){
                //这里的日志用英文,转c++后,不会转义,方便查看,中文的话,会转义,不方便查看
                NSLog(@"The block prints logs internally");
            };
            //donyBck的调用
            donyBck();
        return 0;
    }
    
  • 转换后的C++源码

    //包含block实际函数指针的结构体
    struct __block_impl {
      void *isa; //有isa
      int Flags;
      int Reserved;  //今后升级所需区域大小
      void *FuncPtr; //函数指针
    };
    
    //
    static __NSConstantStringImpl __NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_5a37bd_mi_0 __attribute__ ((section ("__DATA, __cfstring"))) = {__CFConstantStringClassReference,0x000007c8,"The block prints logs internally",32};
    
    //block结构体
    struct __main_block_impl_0 {
      struct __block_impl impl; //Block的实际指针,
      struct __main_block_desc_0* Desc;
      //block构造函数
      __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int flags=0) {
        impl.isa = &_NSConcreteStackBlock; //isa指针 默认block创建在栈上
        impl.Flags = flags; //block标志位
        impl.FuncPtr = fp; //Block执行的函数指针
        Desc = desc; //Block描述信息,Block大小等元信息
      }
    };
    
    //Block内部函数调用
    /* 
    void (^donyBck)(void)=^(){
                //这里的日志用英文,转c++后,不会转义,方便查看,中文的话,会转义,不方便查看
                NSLog(@"The block prints logs internally");
            };
    */
    static void __main_block_func_0(struct __main_block_impl_0 *__cself) {
    
                NSLog((NSString *)&__NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_5a37bd_mi_0);
            }
    
    //Block底层编译后自动生成的,Block描述信息结构体变量,静态匿名结构体+变量
    static struct __main_block_desc_0 {
      size_t reserved; //成员1 :保留字段
      size_t Block_size; //成员2:Block实例的内存大小
    } __main_block_desc_0_DATA = { //初始化变量
      0, //给Reserved赋值
      sizeof(struct __main_block_impl_0) //给Block——size赋值
    };
    
    
    //main函数
    int main(void) {
      //1.构造block对象,并将其强制转换为无参无返回值的函数指针。
        void (*donyBck)(void)=((void (*)())&__main_block_impl_0(
          (void *)__main_block_func_0, //block要执行的代码逻辑(函数指针)->FuncPtr
          &__main_block_desc_0_DATA //block的描述信息(版本,大小等)
        ));
      
      //2.调用block的核心逻辑(donyBck的调用)
      // ((void (*))(donyBck):将函数指针转回Block结构体指针
      //->FuncPtr :取出Block的执行函数指针
      //最后调用该函数,并传入Block自身作为参数,(block的隐式self)
       ((void (*)(__block_impl *))((__block_impl *)donyBck)->FuncPtr)((__block_impl *)donyBck);
        return 0;
    }
    

3.2 、源码分析

3.2.1 Block结构体-__main_block_impl_0

先看看 __main_block_impl_0 结构体

//block结构体
struct __main_block_impl_0 {
  struct __block_impl impl; //Block的实际指针,
  struct __main_block_desc_0* Desc;
  //block构造函数
  __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int flags=0) {
    impl.isa = &_NSConcreteStackBlock; //isa指针 默认block创建在栈上
    impl.Flags = flags; //block标志位
    impl.FuncPtr = fp; //Block执行的函数指针
    Desc = desc; //Block描述信息,Block大小等元信息
  }
};

从源码里可以看出,__main_block_impl_0结构体,包含三部分

  • 成员变量 impl,是结构体__block_impl

  • 成员变量 Desc指针,是结构体 __main_block_desc_0

  • __main_block_impl_0 构造函数

分别分析一下这三部分

3.2.1.1 struct __block_impl impl
//包含block实际函数指针的结构体
struct __block_impl {
  void *isa; //有isa
  int Flags;  //标志位
  int Reserved;  //今后升级所需区域大小
  void *FuncPtr; //函数指针
};
  • isa指针,保存Block结构体的实例指针
  • Flags 标志位
  • Reserved 后续版本升级所需区域大小
  • FuncPtr 函数指针,指向了Block的主体部分,也及时对应oc代码里的 { NSLog(@"The block prints logs internally");};

3.1.1里的__main_block_impl_0 里的impl 是__block_impl结构体,而__block_impl 包含了Block实际函数指针 FuncPtr

总结:impl 主要就是包含了Block的函数指针 FuncPtr

3.2.1.2 struct __main_block_desc_0* Desc
//Block底层编译后自动生成的,Block描述信息结构体变量,静态匿名结构体+变量
static struct __main_block_desc_0 {
  size_t reserved; //成员1 :保留字段
  size_t Block_size; //成员2:Block实例的内存大小
} __main_block_desc_0_DATA = { //初始化变量
  0, //给Reserved赋值
  sizeof(struct __main_block_impl_0) //给Block——size赋值
};
  • reserved 版本升级后所需的区域大小
  • Block_size Block的大小。

总结:__main_block_desc_0是block的描述信息,也就是附加信息

3.2.1.3 __main_block_impl_0构造函数
 //block构造函数
  __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int flags=0) {
    impl.isa = &_NSConcreteStackBlock; //isa指针 默认block创建在栈上
    impl.Flags = flags; //block标志位
    impl.FuncPtr = fp; //Block执行的函数指针
    Desc = desc; //Block描述信息,Block大小等元信息
  }

传三个参数:

  • void *fp :主要赋值给impl的FuncPtr ,Block执行的函数指针
  • struct __main_block_desc_0 *desc, Block的描述信息
  • int flags=0 ,默认值为0,标志位。

总结:构造函数主要用来初始化__block_impl的成员变量,以及把描述信息赋值给Desc

3.2.1.4 在main方法里的过程

关于:__main_block_impl_0 基本概念就了解完了,那在main方法里,__main_block_impl_0 又是怎么赋值的呢

//原函数
 void (^donyBck)(void)=^(){
            //这里的日志用英文,转c++后,不会转义,方便查看,中文的话,会转义,不方便查看
            NSLog(@"The block prints logs internally");
 };

//转换c++后
//1.构造block对象,并将其强制转换为无参无返回值的函数指针。
    void (*donyBck)(void)=((void (*)())&__main_block_impl_0(
      (void *)__main_block_func_0, //block要执行的代码逻辑(函数指针)->FuncPtr
      &__main_block_desc_0_DATA //block的描述信息(版本,大小等)
    ));

可以看出通过 __main_block_impl_0构造函数,生成 __main_block_impl_0结构体(Block结构体)的实例指针,并赋值给donyBck

然后对 __main_block_impl_0构造函数传了两个参数

  • __main_block_func_0

    //Block内部函数调用
    static void __main_block_func_0(struct __main_block_impl_0 *__cself) {
    //对应的就是原oc  NSLog(@"The block prints logs internally");
       NSLog((NSString *)&__NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_5a37bd_mi_0);
    }
    

    可以看出 对应的是oc block的主体部分也就是 {NSLog(@"The block prints logs internally"); };

    这里的参数 __cself就是指向Block的值的指针变量,相当于oc的self;

    🎯这里画个重点:从这里可以看出,block内部,把block的^{}执行函数{}在Block定义完后,当成一个参数类型为__main_block_func_0传入到 __main_block_impl_0->__block_impl-> FuncPtr 里了。

  • __main_block_desc_0_DATA

    __main_block_desc_0_DATA 是包含了Block的描述信息,

    static struct __main_block_desc_0{
      size_t reserved; //成员1 :保留字段
      size_t Block_size; //成员2:Block实例的内存大小
    } __main_block_desc_0_DATA = { //初始化变量
      0, //给Reserved赋值
      sizeof(struct __main_block_impl_0) //给Block——size赋值
    };
    

3.2.2 总结

至此Block的内部原理就浮出水面了。

Block内部是由 __main_block_impl_0结构体组成的,内部isa指针,指向所属类的结构体的实例指针,_NSConcreteStackBlock相当于Block的结构体实例,对象impl.isa = &_NSConcreteStackBlock ,将Block结构体的指针赋值给impl的成员变量isa ,相当于Block结构体成员变量保存了Block结构体的指针,和OC的对象处理方式是一致的。

所以Block的实质就是对象,和NSObject一样,都是对象。

image-20251225上午114937229

3.3 Block截获局部变量和特殊区域变量

3.3.1 Block截获局部变量的实质

在2.3里我们知道了Block可以截获局部变量,那背后Block是怎么截获的,为什么不能在block内部直接修改截获的局部变量呢?

先说结论:Block截获的局部变量是值传递的方式传入Block结构体中,并保存为Block的成员变量。因此当外部局部变量值发生修改后,Block内部对应的成员变量的值并没有发生改变。

为了探究到底,我们需要通过clang 把oc转为c++源码来探个究竟

进入main.m的文件夹下,执行:clang -rewrite-objc main.m

  • oc代码

    int main(void) {
        int a = 2;
        void (^donyBck)(void)=^(){
            NSLog(@"The block Capture local variables:%d",a);
        };
        
        a = 4;
        //donyBck的调用
        donyBck();
        NSLog(@"The block prints local variables:%d",a);
        return 0;
    }
    //The block Capture local variables:2
    //The block prints local variables:4
    
  • 转c++源代码

    //block结构体
    struct __main_block_impl_0 {
      struct __block_impl impl;
      struct __main_block_desc_0* Desc;
      int a; //截获的局部变量,在block内部变成了成员变量
      __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int _a, int flags=0) : a(_a) {
        impl.isa = &_NSConcreteStackBlock;
        impl.Flags = flags;
        impl.FuncPtr = fp;
        Desc = desc;
      }
    };
    
    //block执行函数
    static void __main_block_func_0(struct __main_block_impl_0 *__cself) {
      int a = __cself->a; // bound by copy
    
            NSLog((NSString *)&__NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_268414_mi_1,a);
        }
    
    static struct __main_block_desc_0 {
      size_t reserved;
      size_t Block_size;
    } __main_block_desc_0_DATA = { 
    0, 
    sizeof(struct __main_block_impl_0)};
    
    
    int main(void) {
        int a = 2;
    
        //block定义
        void (*donyBck)(void)=((void (*)())&__main_block_impl_0(
        (void *)__main_block_func_0,
         &__main_block_desc_0_DATA, 
         a));
    
        a = 4;
    
        //block 执行方法
        ((void (*)(__block_impl *))((__block_impl *)donyBck)->FuncPtr)(
        (__block_impl *)donyBck
        );
      //打印
        NSLog((NSString *)&__NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_268414_mi_2,a);
        return 0;
    }
    
    • 从源码可以看出,结构体__main_block_impl_0 多了一个成员变量a,这个变量就是Block捕获的局部变量
    • 方法__main_block_func_0 看出 int a = __cself->a在block内部访问这个变量a时,通过值传递的方式,而不是指针传递,这也就说明了a是block的内部变量,外部修改a,Block内部捕获的a是不会发生变化的。

3.3.2 使用__block说明符更改局部变量

那使用__block来修饰局部变量后,就能让Block内部来修改这个变量,那背后__block 又做了什么呢?

先说结论:通过 __block修饰后,使这个局部变量在block内部通过指针传递,所以修饰后的局部变量,在block内部可以修改了

为了探究到底,我们需要通过clang 把oc转为c++源码来探个究竟

进入main.m的文件夹下,执行:clang -rewrite-objc main.m

  • oc代码

    int main(void) {
        __block int a = 2;
        void (^donyBck)(void)=^(){
            a = 3;
            NSLog(@"The block Capture local variables:%d",a);
        };
        
        a = 4;
        //donyBck的调用
        donyBck();
        NSLog(@"The block prints local variables:%d",a);
        return 0;
    }
    
  • c++代码

    //__block修饰的
    struct __Block_byref_a_0 {
      void *__isa; //isa指针
    __Block_byref_a_0 *__forwarding; //传入变量的地址
     int __flags; //标志位
     int __size; //结构体大小
     int a; //存放变量a的实际的值,相当与原局部变量的成员变量。
    };
    
    //block内部
    struct __main_block_impl_0 {
      struct __block_impl impl;
      struct __main_block_desc_0* Desc;
      __Block_byref_a_0 *a; // by ref //加入__Block修饰后,这里的a是__Block_byref_a_0类型了
      __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, __Block_byref_a_0 *_a, int flags=0) : a(_a->__forwarding) {
        impl.isa = &_NSConcreteStackBlock; //栈block
        impl.Flags = flags;
        impl.FuncPtr = fp;
        Desc = desc;
      }
    };
    
    //block执行函数
    static void __main_block_func_0(struct  __main_block_impl_0 *__cself) {
      __Block_byref_a_0 *a = __cself->a; // bound by ref 
            (a->__forwarding->a) = 3;
            NSLog((NSString *)&__NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_3b64fc_mi_3,(a->__forwarding->a));
        }
    
    //新增了 
    static void __main_block_copy_0(struct __main_block_impl_0*dst, struct __main_block_impl_0*src) {
        _Block_object_assign(
        (void*)&dst->a, 
        (void*)src->a,
         8/*BLOCK_FIELD_IS_BYREF*/);
    }
    
    //新增了
    static void __main_block_dispose_0(struct __main_block_impl_0*src) {
      _Block_object_dispose((void*)src->a, 
                            8/*BLOCK_FIELD_IS_BYREF*/);
    }
    
    static struct __main_block_desc_0 {
      size_t reserved;
      size_t Block_size;
      void (*copy)(struct __main_block_impl_0*, struct __main_block_impl_0*);
      void (*dispose)(struct __main_block_impl_0*);
    } __main_block_desc_0_DATA = { 
        0, 
        sizeof(struct __main_block_impl_0),
         __main_block_copy_0,
          __main_block_dispose_0
    };
    
    //main函数
    int main(void) {
      
      //__block修饰的局部变量a
        __attribute__((__blocks__(byref))) __Block_byref_a_0 a = {
          (void*)0,
          (__Block_byref_a_0 *)&a, 
          0, 
          sizeof(__Block_byref_a_0), 
          2};
        
        void (*donyBck)(void)=((void (*)())&__main_block_impl_0(
          (void *)__main_block_func_0, 
          &__main_block_desc_0_DATA, 
          (__Block_byref_a_0 *)&a, 
          570425344));
    
      //修改局部变量a的值
      (a.__forwarding->a) = 4;
      
      //block调用
        ((void (*)(__block_impl *))((__block_impl *)donyBck)->FuncPtr)((__block_impl *)donyBck);
      
      //block打印
        NSLog((NSString *)&__NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_3b64fc_mi_4,(a.__forwarding->a));
        return 0;
    }
    
    

    可以看出局部变量a加上 __block后,c++代码里新增了 __Block_byref_a_0__main_block_copy_0__main_block_dispose_0

    • 从结构体 __main_block_impl_0 可以看出原来oc的 被__block修饰后的局部变量a,在结构体__main_block_impl_0内部变成了 __Block_byref_a_0 *a,也就是说Block内部的结构体__main_block_impl_0实例持有指向__block变量的__Block_byref_a_0结构体实例指针。
    • __main_block_copy_0__main_block_dispose_0留在后面在说。

这里有点绕,我们用白话文理解一下

可以把整个过程想象成寄送一个易碎品(变量a)

角色 对应代码 比喻说明
易碎品本身 局部变量 int a = 2 比如一个玻璃杯。
加固包装盒 __Block_byref_a_0结构体 一个专门用来固定玻璃杯的防震包装盒。
快递单/指针 __Block_byref_a_0 *a(Block结构体里的成员) 一张写着包装盒地址的快递单。
整个Block __main_block_impl_0结构体实例 快递仓库。
🎯 整个过程是这样的:
  1. 打包: 当你用 __block修饰变量 a时,编译器会自动创建一个“包装盒”(__Block_byref_a_0结构体),然后把你的变量 a(玻璃杯)放进这个盒子里。
  2. 填写快递单: Block(快递仓库)想要操作这个玻璃杯,但它并不直接把玻璃杯拿进来(那样就成了它的私有物品,无法和外界共享了)。Instead,它只拿了一张写着“包装盒地址”的快递单(即指针 __Block_byref_a_0 *a)。
  3. 共享修改: 当Block内部或外部代码需要修改 a的值时,它们会凭着这张“快递单”找到同一个“包装盒”,然后打开盒子修改里面的玻璃杯。因为大家访问的是同一个盒子里的东西,所以任何一方的修改,另一方都能立刻看到

白话文总结:被__block修饰后的变量a,在Block内并没有直接把变量装在自己口袋里,而是记下了变量所在包装盒的地址。通过这个共享的地址,Block和外部代码就能共同修改同一个变量了。

在看看__Block_byref_a_0 结构体

//__block修饰的
struct __Block_byref_a_0 {
  void *__isa; //isa指针
__Block_byref_a_0 *__forwarding; //传入变量的地址
 int __flags; //标志位
 int __size; //结构体大小
 int a; //存放变量a的实际的值,相当与原局部变量的成员变量。
};

在看一下在main()中原oc代码为

     __block int a = 2;

转为c++为

    //__block修饰的局部变量a
    __attribute__((__blocks__(byref))) __Block_byref_a_0 a = {
      (void*)0,
      (__Block_byref_a_0 *)&a, 
      0, 
      sizeof(__Block_byref_a_0), 
      2};

从赋值里可以看出在main()__block修饰后的变量a,底层赋值给__Block_byref_a_0结构体时,传入的值如下

  • isa传入空

  • __forwarding 传入了局部变量a的本身地址

  • __flags :分配了0

  • sizeof:结构体的大小

  • a值赋值为2.

    image-20251225下午44345718

总结一下:到此知道了__forwarding就是局部变量a的本身地址,可以通过 __forwarding指针来访问局部变量。同时也能对其修改了。

    //block执行函数
    static void __main_block_func_0(struct  __main_block_impl_0 *__cself) {
      __Block_byref_a_0 *a = __cself->a; // bound by ref 
            (a->__forwarding->a) = 3;
            NSLog((NSString *)&__NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_3b64fc_mi_3,(a->__forwarding->a));
        }

可以看出 (a->__forwarding->a) = 3;,是通过指针取值的方式来改变局部变量的值,

🎯总结:

从而解释了通过__block修饰后的变量,在Block内部通过指针传递的方式修改局部变量

另外__block__Block_byref_a_0 结构体并不在Block的 __main_block_impl_0结构体中,这样做是为了多个Block同时使用__block变量。

  • 继续看一下OC代码

            int main(void) {
                    //__block被多个Block使用
                __block int aa = 2;
    
                void (^donyBck)(void)=^(){
                    aa = 3;
                    NSLog(@"The block Capture local variables:%d",aa);
                };
    
                void (^donyBck1)(void)=^(){
                    aa = 4;
                    NSLog(@"The block Capture local variables1:%d",aa);
                };
            }
    
  • 转换为c++

      //__block修饰后
      __Block_byref_aa_0 aa = {
         0,
         &aa, 
         0, 
         sizeof(__Block_byref_aa_0), 2};
         //donyBck
         donyBck)=&__main_block_impl_0(
            __main_block_func_0, 
            &__main_block_desc_0_DATA, 
            (__Block_byref_aa_0 *)&aa, 
            570425344));
            //donyBck1
          donyBck1)=&__main_block_impl_1(
            __main_block_func_1, 
            &__main_block_desc_1_DATA, 
            (__Block_byref_aa_0 *)&aa, 
            570425344));
    

可以看出donyBckdonyBck1 都是用了__Block_byref_aa_0结构体的实例aa的指针。反过来一个block中使用多个 __block也是可以的。

3.3.3 更改特殊区域变量值

除了通过__block修饰局部变量外,其他变量如静态局部变量、静态全局变量、全局变量能否在block内部进行修改?

为了探究到底,我们继续需要通过clang 把oc转为c++源码来探个究竟

进入main.m的文件夹下,执行:clang -rewrite-objc main.m

  • oc代码

    int global_a = 2;
    static int static_global_a = 3;
    int main(void) {
        static int static_a = 4;
        void (^donyBck)(void)=^(){
            global_a = 1;
            static_global_a = 2;
            static_a = 3;
            NSLog(@"The block Capture global_a:%d ,static_global_a:%d,static_a:%d",global_a,static_global_a,static_a);
        };
        
        //donyBck的调用
        donyBck();
        return 0;
    }
    
  • C++代码

    //全局变量
    int global_a = 2;
    //静态全局变量
    static int static_global_a = 3;
    
    struct __main_block_impl_0 {
      struct __block_impl impl;
      struct __main_block_desc_0* Desc;
      int *static_a; //静态局部变量
      __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int *_static_a, int flags=0) : static_a(_static_a) {
        impl.isa = &_NSConcreteStackBlock;
        impl.Flags = flags;
        impl.FuncPtr = fp;
        Desc = desc;
      }
    };
    static void __main_block_func_0(struct __main_block_impl_0 *__cself) {
      int *static_a = __cself->static_a; // bound by copy
    
            global_a = 1;
            static_global_a = 2;
            (*static_a) = 3;
            NSLog((NSString *)&__NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_6417ea_mi_3,global_a,static_global_a,(*static_a));
        }
    
    static struct __main_block_desc_0 {
      size_t reserved;
      size_t Block_size;
    } __main_block_desc_0_DATA = { 0, sizeof(struct __main_block_impl_0)};
    int main(void) {
        static int static_a = 4;
        void (*donyBck)(void)=((void (*)())&__main_block_impl_0((void *)__main_block_func_0, &__main_block_desc_0_DATA, &static_a));
        ((void (*)(__block_impl *))((__block_impl *)donyBck)->FuncPtr)((__block_impl *)donyBck);
        return 0;
    }
    

    __main_block_impl_0可以看出,静态局部变量static_a以指针形式添加添加为成员变量,而静态全局变量 static_global_a 和全局变量global_a并没有添加到__main_block_impl_0内部。

    //全局变量
    int global_a = 2;
    //静态全局变量
    static int static_global_a = 3;
    
    struct __main_block_impl_0 {
      struct __block_impl impl;
      struct __main_block_desc_0* Desc;
      int *static_a; //静态局部变量
      __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, int *_static_a, int flags=0) : static_a(_static_a) {
        impl.isa = &_NSConcreteStackBlock;
        impl.Flags = flags;
        impl.FuncPtr = fp;
        Desc = desc;
      }
    };
    

    再从__main_block_func_0,可以看出全局变量global_a和全局静态变量static_global_a是在block内部访问直接访问的,而静态局部变量static_a是通过指针传递的方式进行访问和赋值的。

    static void __main_block_func_0(struct __main_block_impl_0 *__cself) {
      int *static_a = __cself->static_a; // bound by copy
    
            global_a = 1; //全局变量
            static_global_a = 2; //全局静态变量
            (*static_a) = 3; //局部静态变量
            NSLog((NSString *)&__NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_6417ea_mi_3,global_a,static_global_a,(*static_a));
        }
    

3.4 Block的存储域

在3.2 中的Block实质源码分析里,看出impl.isa = &_NSConcreteStackBlock; //栈block,可以看出该Block存储在栈区,那Block还可以存在哪个区呢?

先说结论:Block分别可以存储在_NSConcreteGlobalBlock_NSConcreteStackBlock_NSConcreteMallocBlock

设置对象的存储域
_NSConcreteGlobalBlock 数据区域(.data区)
_NSConcreteStackBlock
_NSConcreteMallocBlock

image-20251225下午74628893

3.4.1 _NSConcreteGlobalBlock

为了探究到底,我们继续需要通过clang 把oc转为c++源码来探个究竟

进入main.m的文件夹下,执行:clang -rewrite-objc main.m

  • oc代码

    //全局block
    void (^donyBck)(void) =^(){
        NSLog(@"global block");
    };
    
    int main(void) {
        donyBck();
        return 0;
    }
    
  • c++源码

    struct __donyBck_block_impl_0 {
      struct __block_impl impl;
      struct __donyBck_block_desc_0* Desc;
      __donyBck_block_impl_0(void *fp, struct __donyBck_block_desc_0 *desc, int flags=0) {
        impl.isa = &_NSConcreteGlobalBlock; //全局block
        impl.Flags = flags;
        impl.FuncPtr = fp;
        Desc = desc;
      }
    };
    

通过源码可以看出 impl.isa = &_NSConcreteGlobalBlock,说明该Block为 _NSConcreteGlobalBlock类型。

这里需要注意使用全局block时,因为本身已经在全局区域,所以不会捕获自动变量(局部变量),存储在数据区域

3.4.2 _NSConcreteStackBlock

除了全局block外,其他基本都存储在栈上,也就是StackBlock。

NSConcreteStackBlock类的block,存储在栈区,如果所属的变量作用域结束,该Block就会被废弃。由于 __block变量也配置在栈上,同样的所属变量作用域结束后,该 __block变量同样也被废弃。

image-20251226下午125508437

3.4.3 _NSConcreteMallocBlock

既然在栈上的Block在变量作用域结束后就立即被废弃,那如果不想废弃怎么办?

Block提供了 【复制copy】操作,可以将Block对象和 __block变量从栈区复制到堆区上,当Block从栈区复制到堆区后,即时变量作用域结束时,堆区上的Block和 __block还可以继续使用。

image-20251226下午10020548

此时的在堆区的Block就是_NSConcreteMallocBlock 对象,Block结构体成员变量isa赋值为 imp.isa = &_NSConcreteMallocBlock;

而此时被__block修饰的变量用结构体成员变量 __forwarding可以实现无论__block变量配置在堆上还是在栈上,都能够正确访问__block变量

3.5 Block的自动拷贝和手动拷贝

3.5.1 Block的自动拷贝

在ARC下,大多数情况下,编译器会自动进行判断,自动生成将Block从栈上复制到堆上的代码

  • 将Block作为函数返回值返回时,会自动拷贝

  • 向方法或函数的参数中传递Block时:(以下两种情况内部底层实现了copy操作,其他都需要手动拷贝)

    • Cocoa框架的方法且方法名中含有usingBlock等 如NSArray类的enumerateObjectsUsingBlock方法
    • GCD的API时如dispatch_async函数
    //在MRC下,initWithObjects后面的Block,编译器不会主动给Block添加copy操作,所以Block还存在栈上,所以会报错。
    //在ARC下,编译器主动添加了copy操作,此时的block被复制到堆上了。
    @implementation SDPerson
    
    - (id) getBlockArray{
        int val = 10;
      void (^blk0)(void) = ^{NSLog(@"blk0:%d",val);};
        void (^blk1)(void) = ^{NSLog(@"blk1:%d",val);};
        NSLog(@"blk01:%@",blk0);
      NSLog(@"blk02:%@",blk1);
        /*
      blk01:<__NSStackBlock__: 0x7ff7bfeff0d8>
    blk02:<__NSStackBlock__: 0x7ff7bfeff0a8>
      */
      //array 的initWithObjects 纯容器存储AIP,框架内部不会自动copy
      return [[NSArray alloc]initWithObjects:blk0,blk1, nil];
    }
    
    @end
    

    image-20251226下午45612397

    报错原因是:在执行完getBlockArray后栈上的Block被废弃,MRC 无任何自动优化,initWithObjects: 仅存栈 Block 指针 → 方法返回栈帧销毁 → 执行 Block 访问野内存 → 崩溃。此时我们需要手动复制下即可。

    修改一下getBlockArray,即可

    - (id) getBlockArray{
        int val = 10;
        
        void (^blk0)(void) = ^{NSLog(@"blk0:%d",val);};
        void (^blk1)(void) = ^{NSLog(@"blk1:%d",val);};
        blk0 = [blk0 copy];
        blk1 = [blk1 copy];
        NSLog(@"blk01:%@",blk0);
        NSLog(@"blk02:%@",blk1);
        //blk01:<__NSMallocBlock__: 0x600000c00540>
        //blk02:<__NSMallocBlock__: 0x600000c00570>
        return [[NSArray alloc]initWithObjects:blk0,blk1, nil];
    }
    
3.5.2 Block的手动拷贝

所有需要让 Block「脱离原栈帧存活」的场景,都必须手动调用[block copy]

关于Block不同类的拷贝效果总结如下

block类 副本源的存储域 复制效果
_NSConcreteStackBlock 栈区 从栈拷贝到堆区
_NSConcreteGlobalBlock 程序的数据区域 不做改变
_NSConcreteMallocBlock 堆区 引用计数增加

不管Block配置在何处,用copy复制不会引起任何问题,在不确定时,调用copy方法即可

3.6 __block变量存储域

在使用 __block变量的Block从栈复制到堆上,__block变量也受到了如下影响

__block变量的配置存储区域 Block从栈上复制到堆上时的影响
堆区 从栈复制到堆区,并被Block所持有
栈区 被Block所持有

和OC引用计数方式内存管理完全相同。

  • __block修饰的变量被Block所持有,如果Block废弃,持有的__block变量也跟着废弃

3.7 截获对象

在Block语法中使用局部变量array来添加元素。

理论上在变量作用域的同时,变量array被废弃,因此赋值给变量array的NSMutableArray类对象必定释放并废弃,但上述代码在main方法里的内{}外仍然可以执行,并打印日志。 这意味着array在Block的执行部分超出其变量作用域而存在。

先说结论:Block从栈复制到堆,归结为__Block_copy函数被调用,使__strong修饰的自动变量对象和__block修饰的变量,被堆上的Block所持有,所以可以超出其变量作用域而存在。

那我们转为c++代码再探个究竟

  • OC

    typedef int (^Blk_t)(id obj);
    Blk_t donyBck;
    
    int main(void) {
        
        {
            id array = [NSMutableArray array];
            donyBck = [^(id obj){
                [array addObject:obj];
                NSLog(@"access local variables array.count:%lu",[array count]);
            } copy];
        }
        
        donyBck([[NSObject alloc]init]);
        donyBck([[NSObject alloc]init]);
        donyBck([[NSObject alloc]init]);
        return 0;
    }
    /*
    access local variables array.count:1
    access local variables array.count:2
    access local variables array.count:3
    */
    
  • C++

    typedef int (*Blk_t)(id obj);
    Blk_t donyBck;
    
    //Block用的结构体
    struct __main_block_impl_0 {
      struct __block_impl impl;
      struct __main_block_desc_0* Desc;
      id array; //这里array被Block强引用 __strong
      __main_block_impl_0(void *fp, struct __main_block_desc_0 *desc, id _array, int flags=0) : array(_array) {
        impl.isa = &_NSConcreteStackBlock;
        impl.Flags = flags;
        impl.FuncPtr = fp;
        Desc = desc;
    }
    };
    
    //block执行方法
    static void __main_block_func_0(struct __main_block_impl_0 *__cself, id obj) {
      id array = __cself->array; // bound by copy
    
      //添加方法
                ((void (*)(id, SEL, ObjectType _Nonnull))(void *)objc_msgSend)((id)array, sel_registerName("addObject:"), (id)obj);
      //打印日志
                NSLog((NSString *)&__NSConstantStringImpl__var_folders_d__csgptyg57sqczzwhcvq7mcpr0000gn_T_main_b8c0c1_mi_8,((NSUInteger (*)(id, SEL))(void *)objc_msgSend)((id)array, sel_registerName("count")));
     }
    
    //copy
    static void __main_block_copy_0(struct __main_block_impl_0*dst, struct __main_block_impl_0*src) {_Block_object_assign((void*)&dst->array, (void*)src->array, 3/*BLOCK_FIELD_IS_OBJECT*/);}
    
    //废弃
    static void __main_block_dispose_0(struct __main_block_impl_0*src) {_Block_object_dispose((void*)src->array, 3/*BLOCK_FIELD_IS_OBJECT*/);}
    
    //block描述
    static struct __main_block_desc_0 {
      size_t reserved;
      size_t Block_size;
      void (*copy)(struct __main_block_impl_0*, struct __main_block_impl_0*);
      void (*dispose)(struct __main_block_impl_0*);
    } __main_block_desc_0_DATA = { 0, sizeof(struct __main_block_impl_0), __main_block_copy_0, __main_block_dispose_0};
    
    //main方法
    int main(void) {
        {
            id array = ((NSMutableArray * _Nonnull (*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("NSMutableArray"), sel_registerName("array"));
            donyBck = (Blk_t)((id (*)(id, SEL))(void *)objc_msgSend)((id)((void (*)(id))&__main_block_impl_0((void *)__main_block_func_0, &__main_block_desc_0_DATA, array, 570425344)), sel_registerName("copy"));
        }
      
        //Block执行
        ((int (*)(__block_impl *, id))((__block_impl *)donyBck)->FuncPtr)((__block_impl *)donyBck, ((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("NSObject"), sel_registerName("alloc")), sel_registerName("init")));
        ((int (*)(__block_impl *, id))((__block_impl *)donyBck)->FuncPtr)((__block_impl *)donyBck, ((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("NSObject"), sel_registerName("alloc")), sel_registerName("init")));
        ((int (*)(__block_impl *, id))((__block_impl *)donyBck)->FuncPtr)((__block_impl *)donyBck, ((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)((NSObject *(*)(id, SEL))(void *)objc_msgSend)((id)objc_getClass("NSObject"), sel_registerName("alloc")), sel_registerName("init")));
        return 0;
    }
    
    
    

    通过源码可以看出 array被Block截获,并成为__strong修饰成员变量,这里虽然没有显示__strong,默认就是强引用

        //Block用的结构体
        struct __main_block_impl_0 {
          struct __block_impl impl;
          struct __main_block_desc_0* Desc;
          id array; //这里array被Block强引用 __strong
        };

那Block捕获的array是在什么时候进行初始化和废弃的呢?

我们可以从__main_block_desc_0可以看出结构体新增了copydispose,以及对应__main_block_copy_0__main_block_dispose_0,这两个结构体在3.3.2里__block时也遇到了。 不过__block修饰的变量和捕获的对象有一点点区别:

对象 BLOCK_FIELD_IS_OBJECT
__block变量 BLOCK_FIELD_IS_BYREF

仅仅主要用来区分是对象还是__block变量

   //block描述
   static struct __main_block_desc_0 {
     size_t reserved;
     size_t Block_size;
     void (*copy)(struct __main_block_impl_0*, struct __main_block_impl_0*);
     void (*dispose)(struct __main_block_impl_0*);
   } __main_block_desc_0_DATA = { 0, sizeof(struct __main_block_impl_0), __main_block_copy_0, __main_block_dispose_0};

   //copy
   static void __main_block_copy_0(struct __main_block_impl_0*dst, struct __main_block_impl_0*src) {
     //_Block_object_assign对使Block内部对array持有
     _Block_object_assign(
       (void*)&dst->array, 
       (void*)src->array, 
       3/*BLOCK_FIELD_IS_OBJECT*/
     );
   }

   //废弃
   static void __main_block_dispose_0(struct __main_block_impl_0*src) {
     _Block_object_dispose(
       (void*)src->array, 
       3/*BLOCK_FIELD_IS_OBJECT*/
     );
   }
  • __main_block_copy_0可以看出,内部通过_Block_object_assign方法对array持有,_Block_object_assign相当于retain,将对象赋值在对象类型结构体成员变量中。

  • __main_block_dispose_0使用_Block_object_dispose函数,相当于release,释放赋值在Block用结构体成员变量的array中的对象。

  • 因此_Block_object_assign__main_block_dispose_0指针赋值在__main_block_desc_0的copy和dispose中。

    但是在源代码里没有看到这些函数以及指针被调用,那他们的调用时机在什么时候?

    image-20251229下午84719431

那什么时候栈上的Block会复制到堆上呢?

  • 调用Block的copy实例方法时
  • Block作为函数返回值返回时
  • 将Block赋值给附有__strong修饰符id类型或Block类型成员变量时
  • 在方法名中含有usingBlock的Cocoa框架方法或GCD的API中传递Block时。

array默认为__strong修饰,那如果改为__weak呢?

typedef void (^Blk_t)(id obj);
Blk_t donyBck;

int main(void) {
    {
        id array = [NSMutableArray array];
        id __weak array2 = array;
        donyBck = [^(id obj){
            [array2 addObject:obj];
            NSLog(@"access local variables array.count:%lu",[array2 count]);
        } copy];
    }
    
    donyBck([[NSObject alloc]init]);
    donyBck([[NSObject alloc]init]);
    donyBck([[NSObject alloc]init]);
    return 0;
}
/**
access local variables array.count:0
access local variables array.count:0
access local variables array.count:0
*/

这是因为array在变量作用域结束后同时被释放、废弃。nil被赋值给__weak修饰的array2。

那如果__block__weak同时修饰呢?

__block id __weak array2 = array;

结果一样:

    access local variables array.count:0
    access local variables array.count:0
    access local variables array.count:0

即使被附加了__block说明符,__strong修饰符的变量array也会在变量作用域结束的同时被释放掉,nil被赋值给附有__weak的变量array2中。

另外被__unsafe_unretained修饰符的变量只不过与指针相同,所以不管在Block中使用还是附加到__block变量中,也不会想 __strong__weak那样进行处理,使用__unsafe_unretained修饰符需要注意不能通过悬垂指针访问已被废弃的对象。

__autoreleasing修饰符也不能和__block同时使用

3.8 Block循环引用

我们知道Block内部使用__strong修饰符的对象类型的自动变量,那当Block从栈复制到堆的时候,该对象就会被Block所持有

那么如果这个对象还同时持有Block的话,就容易发生循环引用。正所谓你中有我,我中有你

image-20251231上午100014948

  • 示例1:

    // 文件SDPerson.m
    typedef void (^blk_t)(void);
    @interface SDPerson()
    {
        blk_t blk_;
    }
    @end
    
    
    @implementation SDPerson
    
    - (instancetype)init
    {
        self = [super init];
        if (self) {
            blk_ = ^{
                NSLog(@"self = %@",self);
            };
        }
        return self;
    }
    
    - (void)dealloc{
        NSLog(@"dealloc");
    }
    
    //文件main.m
    #import "SDPerson.h"
    int main(void) {
        SDPerson *person = [[SDPerson alloc]init];
        NSLog(@"%@",person);
        return 0;
    }
    

    最终执行结果 <SDPerson: 0x60000020d340> SDPerson的dealloc没有执行,发生了Block的循环引用

    具体分析:

    SDPerson内部blk_t持有了self,而self也同时持有作为成员变量的blk_t

    另外编译器也会有提示

    image-20251231上午100056778

    如果Block内部不使用self,还会造成循环引用吗?

  • 示例2:

    typedef void (^blk_t)(void);
    @interface SDPerson()
    {
        blk_t blk_;
        id obj_;
    }
    @end
    
    
    @implementation SDPerson
    
    - (instancetype)init
    {
        self = [super init];
        if (self) {
            blk_ = ^{
                NSLog(@"obj_ = %@",obj_);
            };
        }
        return self;
    }
    

    答案:会

    分析一下:表面上看obj_没有使用self,但是它是self的成员变量,因此Block想持有obj_,就必须引用self,所以同样造成循环引用。

    那如果这个属性使用weak修饰符呢

  • 实例3 :

    typedef void (^blk_t)(void);
    @interface SDPerson()
    @property (nonatomic, weak) NSArray *array;
    @end
    
    - (instancetype)init
    {
        self = [super init];
        if (self) {
            blk_ = ^{
                NSLog(@"obj_ = %@",_array);
            };
        }
        return self;
    }
    

    答案:还是会循环引用,因为循环引用是self和block之间的事情,这个被block持有的成员变量是strong或weak没有关系,即使是基本类型assign也是一样的。

那如何解决这样的循环引用呢?

3.8.1 __weak修饰符

为了避免循环引用,可以通过__weak修饰符,来打破互相持有

- (instancetype)init
{
    self = [super init];
    if (self) {
      //使用__weak修饰符,使block内部为弱引用关系
        id __weak tmp = self;
        // id __unsafe_unretained tmp = self;
        blk_ = ^{
            NSLog(@"self = %@",tmp);
        };
    }
    return self;
}

常见用 __weak typeof(self) weakSelf = self; 来进行弱引用self

__weak typeof(self) weakSelf = self;
self.myBlock = ^{
    [weakSelf doSomething];
};

上述存存在一个问题,当block执行过程中,weakSelf可能被释放,导致后续操作无效

这里需要再block内部进行强化弱引用,使用__strong在局部作用域内临时强引用弱引用对象,确保在执行期间对象存活。__strong在Block内部栈上创建局部强指针,不会造成循环引用。

__weak typeof(self) weakSelf = self;
self.myBlock = ^{
    __strong typeof(self) strongSelf = weakSelf;
    if (strongSelf) {
        [strongSelf doSomething];
        [strongSelf doAnotherThing];
    }
};

除了__weak typeof(self) weakSelf = self; 这里还可以参考第三方开源库ReactiveObjC这样的简洁写法 @weakify(self); 作用是一样的,都是对self进行弱引用。

@weakify(self);
self.myBlock = ^{
@strongify(self);
    if (self) {
        [self doSomething];
        [self doAnotherThing];
    }
};

除了__weak修饰符外,还可以使用__unsafe_unretained,如id __unsafe_unretained tmp = self; 效果是一样的,都是使对象为弱引用,那两者有什么区别?更推荐使用__weak

两者的区别在于当所指向的对象被释放时,如何处理指针

  • __weak(安全)当对象释放后,所有指向它的__weak变量会被运行时自动设置为nil,意味着后续在访问这个指针,就像nil发送消息一样,在OC中是安全的,不会导致程序崩溃 。
  • __unsafe_unretained(不安全)当对象释放后,__unsafe_unretained指针不会自动置空,仍然保存着对象被释放前的那个内存地址,也就是变成了“悬垂指针”或“野指针”,如果此时访问了这个指针,就会发生BAD_ACCESS

image-20251231上午101006054

3.8.2 __block修饰符

除了__weak外,还可以使用 __block解决block循环引用问题

typedef void (^blk_t)(void);
@interface SDPerson()
{
    blk_t blk_;
}
@end
@implementation SDPerson

- (instancetype)init
{
    self = [super init];
    if (self) {
        __block id tmp = self;
        blk_ = ^{
            NSLog(@"obj_ = %@",tmp);
            tmp = nil;
        };
    }
    return self;
}

//执行block
- (void)execBlock{
    blk_();
}
int main(void) {
    SDPerson *person = [[SDPerson alloc]init];
    [person execBlock];
    NSLog(@"%@",person);
    return 0;
}
//执行结果
//obj_ = <SDPerson: 0x600000c08690>
//<SDPerson: 0x600000c08690>
//dealloc 

如果Block不执行execBlock,依然会存在循环引用

此时-SDPerson持有Block,Block持有__block变量,__block持有SDPerson类对象。三者互相持有,导致引用循环

image-20251231下午10424295

如何解决?

就是执行Block execBlock方法,Block内部,会把tmp置为nil。并执行block execBlock方法,因此__block持有类对象的强引用就失效了,

blk_ = ^{
     NSLog(@"obj_ = %@",tmp);
     tmp = nil;
};
//并执行block execBlock方法

image-20251231下午10913331

所以__block需要执行Block来解决循环引用,基于此特点,可以通过__block控制对象的持有时间。

这里需要区分,这里利用__block解决循环引用,不是因为__block本身直接解决的,而是利用了__block的**「可写特性」+ 手动执行 tmp = nil**,并执行block的execBlock方法,使block内部tmp=nil生效,从而主动打破了循环链。

在实际开发过程中,需要具体根据实际情况,来使用__weak还是__block.

四、常见面试题

4.1 说一下什么是Block?

Block是带有局部变量的匿名函数,本质是一个对象,内部有isa指针,内部是由结构体**__main_block_impl_0->__block_impl**组成,Block的执行函数通过在__block_impl->FuncPtr函数指针,找到封装的函数,并将block地址作为参数传给这个函数进行执行。Block捕获的变量,存入__main_block_impl_0结构体内,并通过block地址拿到捕获变量的值。

//包含block实际函数指针的结构体
struct __block_impl {
  void *isa; //有isa
  int Flags;
  int Reserved;  //今后升级所需区域大小
  void *FuncPtr; //函数指针
};

//block结构体
struct __main_block_impl_0 {
  struct __block_impl impl; //Block的实际指针,
  struct __main_block_desc_0* Desc;
};

4.2 Block 有几种类型?分别是什么?

有三种类型,分别为 _NSConcreteGlobalBlock_NSConcreteStackBlock_NSConcreteMallocBlock

定义在全局的block,为全局block,存储在数据区的全局区里,因为本身就是全局,所以不会访问局部变量,因此不需要捕获局部变量。

一般用到的是栈block,但是栈上的block是临时的,在它的作用域结束后就被销毁,为了延长生命周期,在arc下系统会默认会copy到堆上,来延迟生命周期,这样可以在定义它的作用域外部使用。mrc下,需要手动进行copy

4.3 Block 自动截取变量

Block外部的变量,可以被block捕获到内部进行使用,这里需要注意的是变量类型

  • 全局变量/静态全局变量 ,block不需要捕获,因为全局变量和静态全局变量数据存储在全局数据区,Block内部直接使用

  • 局部静态变量 捕获变量地址,所以外部变量修改后,通过地址访问到变量的值,也会跟着修改。

  • 静态变量 捕获变量的值,是通过值传递的方式捕获到block内部,并且捕获的是变量的当前瞬时值,所以外部修改了变量,block内部的变量值不会发生改变,如果需要修改,需要通过__block来修饰,然后通过指针引用传递的方式在内部使用。

    4.3.1 为什么普通局部变量要捕获值,跟静态局部变量一样捕获地址不行吗

    不行,和局部变量的生命周期有关系,因为局部变量在出大括号后就会被释放掉,这事我们在大括号外部调用这个Block,此时局部变量已经被释放了,block内部通过变量的指针访问变量,就会抛出异常。而静态局部变量的生命周期是和整个程序的生命周期一样,也就是在整个程序运行过程中不会释放,所以可以通过指针地址访问。

    4.3.2既然静态局部变量一直都不会被释放,那block为什么还要捕获它,直接拿来用不就可以了吗?

    这是因为静态局部变量作用域只在大括号内,出了括号,它虽然存在,但外面已经访问不了,这时通过block执行函数只能通过捕获的方式。

    4.3.3 静态局部变量一直都不会被释放,会导致内存泄漏吗?

    不会,静态局部变量是语言设计的特性,行为可预测,是一种特殊的局部变量,具有局部作用域,存储在数据区.data(初始化).bss(未初始化),程序在运行期间只被分配一次内存(且占内存有限),生命周期有编译器自动管理,启动时初始化,结束时销毁,不会导致运行时的内存泄漏

    首先明确内存泄漏的概念:程序在运行过程中,不断分配内存而没有适当的释放,导致内存逐渐减少的情况

4.4Block 处理循环引用

如果Block内部捕获了外部的strong(强引用)类型的引用对象,那么这个对象有强引用block,就会形成循环引用,会导致内存泄漏,因为参与循环引用的对象和block无法正常释放,长期下去会导致性能问题。

这时,就需要通过__weak关键字,进行对强引用对象进行弱引用,来打破你中有我,我中有你。

4.4.1 __weak typeof(self) weakSelf = self; 和@weakify(self);有什么区别

都是用来弱引用self,避免循环引用,__weak typeof(self) weakSelf = self;

@weakify(self) 是宏定义,预编译阶段展开就是 __weak typeof(self) weakSelf = self;,设计初衷就是为了更简洁更优雅。

4.5 Block 的内存管理

首先围绕Block的三个核心点

4.6__block 的解释以及在 ARCMRC 下有什么不同

默认情况下,Block捕获的外部自动变量(局部变量)是值捕获,在Block内部是无法修改的。

__block是修饰符,主要用于解决上述问题,block捕获的局部变量,在block内部,可以进行修改。

原理:被__block修饰后的局部变量,编译器会把这个变量包装成一个结构体对象,底层其实一个结构体__Block_byref_a_0,内部有一个__forwarding指针,和当前变量的值等成员,无论Block和__block变量本身被复制到栈上还是堆上,都可以通过这个指针访问和修改值,这样就使从值传递变成了引用传递

在ARC和MRC下的不同

  • 在ARC下

__block修饰的对象是强引用,需要注意循环引用,常用的解决方案为使用__weak弱引用。

  • 在MRC下

对__block修饰对象,不会对对象进行retain,避免循环引用

4.7为什么需要使用copy关键字

Block默认创建在栈上,为了延迟生命周期,需要copy到堆上。

在arc之前,手动管理内存,为了保持block的生命周期,开发者需要手动将栈上的block复制到堆上,通过copy关键字操作,如下

@property (copy, nonatomic) void (^block)(void);

在ARC之后,虽然编译器会自动进行copy操作,把block复制到堆上,为了和MRC下保持一致,避免在不同内存管理环境下切换的混淆,在ARC之后,还是推荐用copy关键字

4.7.1 那用strong可以修饰block吗?

在ARC下可以,在MRC下不可以。

4.7Dispatch_block_t这个有没有用过?解释一下?

dispatch_block_t是GCD中的一个类型定义,代表无参数,也没有返回值的代码里。

基本定义 typedef void (^dispatch_block_t)(void);

常见的使用场景:将任务放入队列后立即返回,不阻塞当前线程

    dispatch_async(queue,^{
    NSLog(@"在后台执行任务");
    })

五、参考文献

❌