阅读视图

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

iOS 深度解析

掘金 iOS

忆江南

2026年3月2日 18:07

1. iOS 启动流程

1.1 启动的宏观阶段划分

iOS App 的启动可分为两个大阶段：pre-main 阶段（main 函数执行之前）和 post-main 阶段（main 函数执行之后到首帧渲染完成）。

冷启动（Cold Launch）：App 完全不在内存中，需要从磁盘加载所有资源，经历完整的 pre-main 和 post-main 流程。
热启动（Warm Launch）：App 进程虽然被终止，但部分数据仍然在系统内核的页缓存中（page cache），此时 dyld 加载速度会更快。
恢复启动（Resume）：App 只是从后台切回前台，不涉及进程创建，严格意义上不算"启动"。

1.2 Pre-main 阶段详解

1.2.1 内核阶段（Kernel）

当用户点击 App 图标时，系统通过 launchd 进程（PID=1）fork 出一个新的进程。内核为新进程完成以下工作：

创建进程：分配 PID，创建虚拟内存空间（每个进程都有独立的 4GB/16EB 虚拟地址空间）。
ASLR（Address Space Layout Randomization）：生成一个随机偏移值（slide），将 Mach-O 的加载基地址随机化，防止固定地址攻击。ASLR 是在内核层面实现的，每次启动 slide 不同。
加载可执行文件：将 Mach-O 的头部和 Load Commands 映射到虚拟内存中（注意是映射，不是全部读入物理内存，利用的是 mmap 和按需缺页机制）。

1.2.2 dyld 阶段（Dynamic Linker）

dyld（dynamic link editor）是 Apple 的动态链接器，它是第一个在用户态运行的代码。Apple 在 iOS 13/macOS 11 之后将 dyld 升级到了 dyld3 和后来的 dyld4，引入了启动闭包（Launch Closure）机制。

dyld 的核心工作流程：

a) 加载动态库（Load Dylibs）

dyld 根据 Mach-O 的 LC_LOAD_DYLIB 等 Load Commands，递归地加载所有依赖的动态库。每个动态库自身也可能依赖其他动态库，形成一棵依赖树。系统共享库（如 UIKit、Foundation）通过 dyld shared cache（共享缓存）提前合并优化，存放在 /System/Library/Caches/com.apple.dyld/ 下，加载速度极快。

动态库的加载过程：

解析 Mach-O Header，验证魔数（Magic Number）、CPU 架构、文件类型。
读取 Load Commands，确定各 Segment（__TEXT、__DATA、__LINKEDIT）的内存映射方式。
调用 mmap() 将文件内容映射到虚拟内存。
由于使用了 Copy-on-Write（COW）技术，只读段可以被多个进程共享物理内存。

b) Rebase（基址重定位）

由于 ASLR 的存在，Mach-O 中所有写死的内部指针地址都需要加上 slide 偏移量。这个过程就是 Rebase。

Rebase 主要操作 __DATA 段中的指针。现代的 chained fixups（链式修正）格式将 rebase 信息直接编码在指针值中，减少了 __LINKEDIT 的大小，也加速了处理。

Rebase 的性能瓶颈不在于计算（加法操作极快），而在于 Page Fault：当访问尚未加载到物理内存的虚拟页时，会触发缺页中断，内核需要从磁盘读取对应的页并进行解密验证（如果开启了代码签名验证）。

c) Bind（符号绑定）

Bind 处理的是对外部动态库符号的引用。App 中调用的 NSLog、objc_msgSend 等函数，在编译时并不知道它们的真实地址，需要在运行时通过符号名查找。

Lazy Binding（懒绑定）：大部分外部函数调用使用懒绑定，第一次调用时才通过 dyld_stub_binder 查找真实地址并回填到 __DATA.__la_symbol_ptr（Lazy Symbol Pointer）中，后续调用直接跳转，不再走 dyld。
Non-Lazy Binding（非懒绑定）：部分符号（如 Objective-C 类引用、全局变量指针）需要在启动时立即绑定，存放在 __DATA.__nl_symbol_ptr（Non-Lazy Symbol Pointer）中。
Weak Binding（弱绑定）：__attribute__((weak)) 修饰的符号需要搜索所有已加载的镜像来确定是否有强定义覆盖，开销较大。

d) dyld3/dyld4 的 Launch Closure

dyld3 引入了 Launch Closure（启动闭包）机制——将首次启动时的解析结果（依赖关系、rebase/bind 信息、初始化顺序等）序列化保存到磁盘。后续启动时直接读取闭包文件，跳过大量解析工作。

dyld4 进一步引入了 PrebuiltLoaderSet，对 App 的启动路径做了更激进的预计算。

1.2.3 Objective-C Runtime 初始化

dyld 在完成所有动态库的加载和绑定后，会调用注册的初始化函数。ObjC Runtime 的初始化是其中最重要的一步：

map_images：当新的 Mach-O 镜像被映射到内存时调用。Runtime 解析 __DATA.__objc_classlist、__DATA.__objc_catlist（Category 列表）、__DATA.__objc_protolist（Protocol 列表）等 section，将类、分类、协议注册到全局表中。
类的实现（Realize）：将类从磁盘格式转换为运行时格式，设置 superclass 指针、method list、ivar layout 等。这个过程是懒加载的——只有第一次使用类时才会 realize。
Category 的附加：将 Category 中的方法、属性、协议"织入"到对应的类中。方法会被插入到方法列表的前面，这就是 Category 能"覆盖"原类方法的原因。
load_images：调用所有类和 Category 的 +load 方法。调用顺序：先按编译顺序调用父类的 +load，再调用子类的，最后调用 Category 的。+load 在所有类完成注册后、任何 +initialize 之前执行。

1.2.4 C++ 静态初始化器

所有标记了 __attribute__((constructor)) 的函数以及 C++ 全局对象的构造函数会在此阶段被调用。它们通过 __DATA.__mod_init_func section 记录。

1.2.5 执行 main 函数

完成以上所有步骤后，dyld 调用 App 可执行文件的入口点，即 main() 函数。

1.3 Post-main 阶段详解

1.3.1 UIApplicationMain

main() 函数通常只做一件事：调用 UIApplicationMain()。这个函数完成：

创建 UIApplication 单例对象。
创建 App Delegate 对象。
启动主线程的 RunLoop（CFRunLoopGetMain()）。
加载 Info.plist，如果指定了 Main Storyboard，则加载并实例化初始 ViewController。

1.3.2 Application Lifecycle Callbacks

按照 iOS 13+ 的 Scene-based Life Cycle（多窗口架构）：

application:didFinishLaunchingWithOptions: — App 级别的初始化入口。
scene:willConnectToSession:options: — Scene 连接。
sceneWillEnterForeground: — 即将进入前台。
sceneDidBecomeActive: — 已激活，用户可交互。

1.3.3 首帧渲染（First Frame Render）

首帧渲染标志着用户可以看到 App 的实际界面。系统在第一次 CATransaction commit 时将渲染树提交给 Render Server（一个独立进程 backboardd），完成 GPU 合成并上屏。

Apple 的 App Launch Instrument 以 CA::Transaction::commit() 中第一帧绘制完成作为启动结束的标志。

1.4 Mach-O 文件格式补充

Mach-O 是 macOS/iOS 的可执行文件格式，理解它对理解启动流程至关重要：

区域	内容
Header	魔数、CPU 类型、文件类型（MH_EXECUTE/MH_DYLIB）、Load Commands 数量
Load Commands	描述文件布局的元数据：段的位置和大小、动态库依赖、入口点、代码签名位置等
__TEXT	只读、可执行：机器码（`__text`）、ObjC 方法名（`__objc_methname`）、字符串常量（`__cstring`）等
__DATA	可读写：全局变量、ObjC 类数据、符号指针表等
__DATA_CONST	启动后只读：ObjC 类列表、协议列表等（rebase/bind 后被 `mprotect` 设为只读）
__LINKEDIT	动态链接器使用的元数据：符号表、字符串表、rebase/bind 操作码、代码签名等

2. 启动优化

2.1 度量体系

2.1.1 Apple 官方指标

TTID（Time to Initial Display）：App 进程创建到第一帧渲染完成的时间。Apple 建议冷启动控制在 400ms 以内。
MetricKit：MXAppLaunchMetric 提供生产环境的启动耗时数据（p50/p90/p99）。
DYLD_PRINT_STATISTICS：设置此环境变量可在控制台输出 pre-main 阶段各步骤的耗时。

2.1.2 自建度量

在 +load 或进程创建时记录起始时间戳，在首帧 viewDidAppear: 或 CADisplayLink 回调中记录结束时间戳，差值即为端到端启动时间。注意要使用 mach_absolute_time() 或 clock_gettime_nsec_np(CLOCK_MONOTONIC_RAW) 获取高精度时间，避免使用 NSDate（会受 NTP 校时影响）。

2.2 Pre-main 阶段优化

2.2.1 减少动态库数量

每个自定义动态库都会增加 dyld 的加载、rebase、bind 开销。Apple 建议自定义动态库不超过 6 个。

优化手段：

将多个小型动态 framework 合并为一个。
能用静态库的场景优先使用静态库（静态库在编译链接阶段就合并到了主二进制中，不增加 dyld 的运行时负担）。
使用 xcframework 统一管理多架构，避免重复链接。

2.2.2 减少 ObjC 元数据

减少类和 Category 的数量：每个 ObjC 类都需要在 map_images 阶段注册到 Runtime 的全局类表中，每个 Category 都需要被合并到宿主类。大量无用的类会拖慢这个过程。
清理无用代码：使用 LinkMap 文件分析各模块大小，结合 AppCode 的 Inspect Code 或开源工具（如 fui、periphery）找出未使用的类和方法。
Swift 优势：Swift 的结构体和枚举不经过 ObjC Runtime，不产生 map_images 的注册开销。能用 Swift 值类型代替 ObjC 类的场景应优先考虑。

2.2.3 消灭 +load 方法

+load 方法在启动的极早期串行执行（持有 Runtime 的全局锁），任何耗时操作都会直接阻塞启动。

替代方案：

+initialize：懒加载，在类第一次收到消息时调用，且只调用一次（线程安全由 Runtime 保证）。将初始化逻辑从 +load 迁移到 +initialize 可以将开销延后到实际使用时。
__attribute__((constructor)) 也应减少：与 +load 类似，在 main() 之前执行。

2.2.4 二进制重排（Binary Reordering）

原理：App 启动时并非所有代码都会被立即执行。由于虚拟内存的分页机制（iOS 上每页 16KB），启动时执行的函数如果分散在不同的页中，会导致大量 Page Fault。每次 Page Fault 需要从磁盘读取一页并进行代码签名验证（对于加密的 App），耗时约 0.1~~0.3ms。如果启动路径上有 2000 次 Page Fault，累计开销可达 200~~600ms。

做法：

使用 Clang 的 SanitizerCoverage（-fsanitize-coverage=func,trace-pc-guard）编译代码，在每个函数入口插入回调，记录启动路径上所有被调用的函数及其顺序。
生成 Order File（.order 文件），按启动调用顺序列出函数符号。
在 Xcode 的 Build Settings 中设置 Order File 路径，链接器会按指定顺序排布函数，使启动路径上的函数尽量集中在连续的页中，减少 Page Fault。

效果：对于大型 App，Page Fault 次数可减少 30%~~70%，带来 100~~300ms 的启动提升。

2.2.5 dyld3/dyld4 闭包缓存

现代 iOS 系统已默认使用 dyld3 闭包。开发者能做的是确保不破坏闭包缓存的有效性——每次 App 更新后首次启动闭包需要重新生成，这属于不可避免的开销。

2.3 Post-main 阶段优化

2.3.1 任务分级与延迟加载

将 didFinishLaunchingWithOptions: 中的初始化任务按优先级分为三类：

优先级	任务类型	执行时机
P0	崩溃监控、AB 实验框架	`didFinishLaunching` 最前面，同步执行
P1	网络库初始化、用户登录态恢复	`didFinishLaunching` 中异步执行
P2	分享 SDK、推送注册、非首屏功能	首帧渲染后延迟执行（通过 RunLoop idle 或延时 dispatch）

关键原则：首帧渲染前只做必须做的事。

2.3.2 首页渲染优化

缓存上次的首页截图：在启动时展示缓存截图（skeleton screen 或快照），让用户感知到"已打开"，待真实数据加载完成后替换。
减少首页视图层级：使用 Instruments 的 View Debugger 分析视图层级深度，减少不必要的嵌套。
避免首帧同步网络请求：使用本地缓存数据渲染首帧，网络数据到达后差量更新。

2.3.3 子线程预加载

将不需要在主线程执行的初始化任务放到并发队列中并行执行：

数据库初始化和预热。
预加载常用的图片资源到内存缓存。
预建立 HTTP/2 连接（TCP + TLS 握手）。

注意：UIKit 操作必须在主线程，CoreData 的 NSManagedObjectContext 要注意线程隔离。

2.3.4 启动任务调度框架

大型 App 通常会搭建启动任务调度框架，支持：

声明式地定义任务、依赖关系和线程要求。
自动拓扑排序确定执行顺序。
并行执行无依赖关系的任务。
监控每个任务的耗时，自动上报异常。

2.4 持续劣化防护

CI 卡口：在 CI 流水线中集成启动耗时测试（使用 XCTest + MetricKit 或自定义打点），设置阈值，超标则阻断合入。
LinkMap 体积监控：监控二进制体积增长（尤其是 __DATA 段的增长），它与 rebase/bind 耗时正相关。
+load 扫描：通过静态分析工具在编译期扫描新增的 +load 方法。

3. 网络优化

3.1 网络请求的全链路分析

一次 HTTPS 请求的完整链路：

DNS 解析 → TCP 三次握手 → TLS 握手 → 请求发送 → 服务器处理 → 响应接收 → 数据解析

每个环节都有优化空间。

3.2 DNS 优化

3.2.1 传统 DNS 的问题

解析延迟：首次解析需要递归查询根域名服务器 → 顶级域名服务器 → 权威域名服务器，耗时 50~200ms，极端情况下可达数秒。
DNS 劫持：运营商 LocalDNS 可能返回篡改的 IP 地址，将用户引导到广告页或错误服务器。
调度不精准：运营商 DNS 的出口 IP 与用户的实际 IP 可能不在同一地区，导致 CDN 调度到非最优节点。
DNS 缓存不可控：系统 DNS 缓存（res_9_getaddrinfo）的 TTL 由服务端控制，App 无法主动管理。

3.2.2 HTTPDNS

HTTPDNS 通过 HTTP/HTTPS 协议直接向 DNS 服务商（如阿里云 HTTPDNS、腾讯云 HTTPDNS）发送域名解析请求，绕过运营商 LocalDNS。

核心优势：

防劫持：使用 HTTPS 通道加密传输，运营商无法篡改。
精准调度：可以携带客户端真实 IP（EDNS Client Subnet），CDN 能调度到最优节点。
可控缓存：App 自主管理 DNS 缓存和预解析策略。

实现要点：

预解析：App 启动时对常用域名发起预解析，将结果缓存在本地。
缓存策略：本地维护 IP 缓存池，设置合理的 TTL。TTL 过期后异步刷新，期间仍使用旧 IP（"乐观缓存"策略），避免解析等待。
降级机制：HTTPDNS 服务异常时自动降级到系统 DNS。
SNI 问题：使用 HTTPDNS 后，HTTPS 请求的 Host 头是 IP 地址，需要手动设置 SNI（Server Name Indication）字段为原始域名，否则 TLS 握手会因证书不匹配而失败。在 NSURLSession 中需要实现 URLSession:didReceiveChallenge:completionHandler: 代理方法处理证书验证。

3.2.3 DNS-over-HTTPS (DoH) / DNS-over-TLS (DoT)

iOS 14+ 原生支持 DoH/DoT（通过 NEDNSSettingsManager），但这是系统级别的配置，App 级别的定制灵活性不如 HTTPDNS。

3.3 连接优化

3.3.1 连接复用

HTTP/1.1 Keep-Alive：在同一个 TCP 连接上串行发送多个请求，避免每次请求都建立新连接。但存在 队头阻塞（Head-of-Line Blocking） 问题——前一个请求未完成时后续请求必须等待。
HTTP/2 多路复用（Multiplexing）：在单个 TCP 连接上并行发送多个请求/响应，通过帧（Frame）和流（Stream）的概念实现真正的并发。一个连接可以同时承载上百个请求。但 TCP 层的队头阻塞依然存在——一个丢包会阻塞整个连接上的所有流。
HTTP/3 (QUIC)：基于 UDP，在传输层消除了队头阻塞。每个流独立进行丢包重传，互不影响。同时集成了 TLS 1.3，握手延迟更低（0-RTT/1-RTT）。iOS 15+ 的 NSURLSession 默认支持 HTTP/3。

3.3.2 预连接（Pre-connect）

在用户可能发起请求之前，提前完成 TCP + TLS 握手，使后续请求可以直接发送数据。

实现方式：使用 NSURLSession 的连接预热 API，或自行管理连接池。

3.3.3 连接迁移（Connection Migration）

传统 TCP 连接以四元组（源 IP、源端口、目的 IP、目的端口）标识，当用户从 WiFi 切换到蜂窝时，源 IP 变化导致连接断开。QUIC 使用 Connection ID 标识连接，网络切换时连接不中断，实现无缝迁移。

3.4 数据传输优化

3.4.1 数据压缩

Gzip/Brotli：在 HTTP 响应头中设置 Content-Encoding: gzip/br。Brotli 压缩率比 gzip 高 15~25%，特别适合文本类数据。NSURLSession 自动处理 gzip 解压。
Protocol Buffers / FlatBuffers：使用二进制序列化替代 JSON。Protobuf 体积比 JSON 小 3~~10 倍，解析速度快 20~~100 倍。适用于高频接口和大数据量场景。
增量更新（Delta Sync）：只传输变化的部分，而非全量数据。可以使用 JSON Patch（RFC 6902）或自定义 diff 算法。

3.4.2 请求合并与批处理

将多个小请求合并为一个批量请求，减少网络往返次数（RTT）。例如将 10 个独立的埋点上报请求合并为 1 个批量请求。

3.4.3 精简数据

按需请求字段：使用 GraphQL 或接口的 fields 参数，只请求客户端真正需要的字段，减少无用数据传输。
分页加载：对列表类数据实施分页，避免一次加载全量数据。

3.5 缓存策略

3.5.1 HTTP 缓存

强缓存：Cache-Control: max-age=3600 和 Expires 头。在有效期内直接使用本地缓存，不发起网络请求。
协商缓存：ETag / If-None-Match 或 Last-Modified / If-Modified-Since。客户端携带标识请求服务器，若资源未变则返回 304，节省传输带宽。
NSURLSession 的缓存策略：通过 NSURLRequest.cachePolicy 控制，NSURLCache 自动管理磁盘和内存缓存。

3.5.2 业务层缓存

将接口返回数据持久化到本地（SQLite、文件），优先展示缓存数据，网络数据到达后更新 UI（"先展示后刷新"策略）。
对于不频繁变化的数据（如配置信息），使用较长的本地缓存有效期。

3.6 弱网优化

超时策略：针对不同网络质量动态调整超时时间。WiFi 下 15s，4G 下 20s，3G/2G 下 30s。
重试策略：指数退避（Exponential Backoff）+ 抖动（Jitter）。避免重试风暴压垮服务器。只对幂等请求（GET、PUT）重试，POST 请求需要业务层保证幂等性。
网络质量检测：通过 NWPathMonitor（Network Framework）实时监听网络状态变化，结合 RTT、丢包率估算网络质量，动态降级（如切换到低分辨率图片）。
多通道竞速：在 WiFi 和蜂窝同时可用时，并行发起请求，取先返回的结果。NSURLSessionConfiguration.multipathServiceType 支持 MPTCP（Multipath TCP）。

3.7 安全层优化

TLS 1.3：将握手往返从 2-RTT（TLS 1.2）减少到 1-RTT，支持 0-RTT 恢复（PSK，Pre-Shared Key）。iOS 12.2+ 默认支持。
证书固定（Certificate Pinning）：在 App 内预埋服务器证书的公钥哈希，防止中间人攻击。需要注意证书轮换的运维流程。
OCSP Stapling：服务器在 TLS 握手时主动提供证书状态（是否被吊销），避免客户端额外查询 OCSP 服务器。

3.8 监控体系

URLSessionTaskMetrics（iOS 10+）：提供每个请求的详细时间线——DNS 解析时间、连接建立时间、TLS 握手时间、请求发送时间、响应接收时间等。这是做网络性能分析的核心数据源。
端到端监控指标：成功率、平均耗时、P99 耗时、DNS 解析耗时、首字节时间（TTFB）、错误类型分布等。
网络链路追踪：在请求头中注入 Trace ID，贯穿客户端 → CDN → 网关 → 后端服务，实现全链路问题定位。

4. RunLoop

4.1 RunLoop 的本质

RunLoop 本质上是一个 事件循环（Event Loop） 机制。它让线程在没有任务时进入休眠（不消耗 CPU），在有任务时被唤醒处理事件。没有 RunLoop 的线程执行完任务就会退出；有了 RunLoop，线程可以常驻内存，随时响应事件。

RunLoop 与线程是一一对应的关系：

主线程的 RunLoop 在 UIApplicationMain 中自动创建和启动。
子线程的 RunLoop 默认不创建，需要手动调用 [NSRunLoop currentRunLoop] 或 CFRunLoopGetCurrent() 时才会懒加载创建。
RunLoop 保存在一个全局的 CFMutableDictionaryRef 中，以 pthread_t 作为 key。

4.2 RunLoop 的核心架构

4.2.1 三大核心对象

a) CFRunLoopSource（输入源）

Source0（非端口事件源）：不能主动唤醒 RunLoop，需要手动调用 CFRunLoopSourceSignal() 标记为待处理，再调用 CFRunLoopWakeUp() 唤醒 RunLoop。触摸事件、performSelector:onThread: 等使用 Source0 分发。
Source1（端口事件源）：基于 Mach Port，能主动唤醒 RunLoop。系统内核通过 Mach Port 发送消息来通知事件，如硬件事件（触摸/锁屏/摇晃）首先由 IOKit 通过 Mach Port 传递给 SpringBoard，再由 SpringBoard 通过 Mach Port 分发给对应的 App 进程。App 内部的 Source1 接收到事件后，通常会封装成 Source0 在主线程 RunLoop 中处理。

b) CFRunLoopTimer（定时器源）

基于时间的触发器，与 NSTimer 是 toll-free bridged 的。Timer 的触发时间并非绝对精确——它依赖于 RunLoop 的运行状态。如果 RunLoop 正在处理一个耗时任务，Timer 的回调会被延迟到当前任务完成后才执行。Timer 有一个 tolerance（容差）属性，系统可以在 fireDate ± tolerance 范围内选择最佳触发时机以节能。

c) CFRunLoopObserver（观察者）

可以监听 RunLoop 的状态变化：

状态	含义
`kCFRunLoopEntry`	即将进入 RunLoop
`kCFRunLoopBeforeTimers`	即将处理 Timer
`kCFRunLoopBeforeSources`	即将处理 Source
`kCFRunLoopBeforeWaiting`	即将进入休眠
`kCFRunLoopAfterWaiting`	刚从休眠中唤醒
`kCFRunLoopExit`	即将退出 RunLoop

4.2.2 RunLoop Mode

RunLoop 在某一时刻只能运行在一个 Mode 下。每个 Mode 包含独立的 Source/Timer/Observer 集合。切换 Mode 时，当前 Mode 下的 Source/Timer/Observer 不会被处理。

常用 Mode：

kCFRunLoopDefaultMode（NSDefaultRunLoopMode）：默认 Mode，App 空闲时运行在此 Mode。
UITrackingRunLoopMode：ScrollView 滑动时切换到此 Mode。这就是为什么 NSTimer 在 Default Mode 下注册时，滑动 ScrollView 期间 Timer 不触发——因为 RunLoop 此时运行在 Tracking Mode 下。
kCFRunLoopCommonModes（NSRunLoopCommonModes）：这不是一个真正的 Mode，而是一个"模式集合"的标记。被标记为 Common 的 Source/Timer/Observer 会被同步到所有被标记为 Common 的 Mode 中。默认情况下 Default Mode 和 Tracking Mode 都是 Common Mode。将 Timer 添加到 Common Modes 可以让它在滑动时也能触发。

4.3 RunLoop 的运行机制（核心循环）

RunLoop 的核心运行逻辑（简化版）：

通知 Observer：即将进入 RunLoop（kCFRunLoopEntry）。
通知 Observer：即将处理 Timer（kCFRunLoopBeforeTimers）。
通知 Observer：即将处理 Source0（kCFRunLoopBeforeSources）。
处理所有待处理的 Source0 事件。
如果有 Source1（Mach Port 消息）待处理，跳转到步骤 9 直接处理。
通知 Observer：即将进入休眠（kCFRunLoopBeforeWaiting）。
休眠，等待唤醒。线程通过 mach_msg() 系统调用陷入内核态，让出 CPU。可以被以下事件唤醒：
- Mach Port 消息到达（Source1 事件、Timer 触发、CFRunLoopWakeUp() 调用）。
- 超时（RunLoop 有一个超时参数）。
- 被外部手动唤醒。
通知 Observer：刚从休眠中被唤醒（kCFRunLoopAfterWaiting）。
处理唤醒事件：
- 如果是 Timer 到期：处理 Timer 回调。
- 如果是 dispatch_main_queue 的 block：执行 block（GCD 派发到主队列的任务通过 RunLoop 的 Source1 唤醒主线程执行）。
- 如果是 Source1 事件：处理 Source1 回调。
判断是否需要退出（Mode 中没有任何 Source/Timer、被外部停止、超时等）。
如果不退出，跳转到步骤 2 继续循环。
通知 Observer：即将退出 RunLoop（kCFRunLoopExit）。

4.4 RunLoop 与系统功能的关系

4.4.1 AutoreleasePool

主线程 RunLoop 注册了两个 Observer 与 AutoreleasePool 配合：

第一个 Observer 监听 kCFRunLoopEntry（优先级最高，保证在所有回调之前）：调用 _objc_autoreleasePoolPush() 创建自动释放池。
第二个 Observer 监听 kCFRunLoopBeforeWaiting（优先级最低，保证在所有回调之后）：调用 _objc_autoreleasePoolPop() 释放旧池中的对象，再调用 _objc_autoreleasePoolPush() 创建新池。同时监听 kCFRunLoopExit：调用 _objc_autoreleasePoolPop() 做最终释放。

这意味着主线程上被 autorelease 的对象会在每次 RunLoop 循环即将休眠时被释放。

4.4.2 事件响应

硬件事件（触摸）传递链：

硬件产生中断 → IOKit.framework 封装为 IOHIDEvent。
通过 Mach Port 传递给 SpringBoard 进程。
SpringBoard 判断前台 App，通过 Mach Port 传递给 App 进程。
App 主线程 RunLoop 的 Source1 被唤醒，回调 __IOHIDEventSystemClientQueueCallback()。
Source1 内部触发 Source0（__UIApplicationHandleEventQueue()）。
Source0 中进行 Hit Test、手势识别、UIResponder 事件分发。

4.4.3 UI 刷新

setNeedsLayout、setNeedsDisplay 等调用不会立即触发布局/绘制，而是标记为"需要更新"。主线程 RunLoop 注册了一个 Observer 监听 kCFRunLoopBeforeWaiting 和 kCFRunLoopExit，在回调中遍历所有标记了需要更新的视图，执行实际的 layout、display、render 操作，最终打包提交给 Render Server。

这就是 Core Animation 的 Transaction 机制。

4.4.4 GCD 与 RunLoop

当调用 dispatch_async(dispatch_get_main_queue(), block) 时，libDispatch 会唤醒主线程的 RunLoop（通过向 RunLoop 的 dispatch port 发送 Mach 消息），RunLoop 在循环中检测到 dispatch port 有消息后，会调用 _dispatch_main_queue_callback_4CF() 来执行 block。

4.4.5 performSelector:afterDelay:

performSelector:withObject:afterDelay: 实际上是创建了一个 Timer 添加到当前线程的 RunLoop 中。如果当前线程没有 RunLoop（子线程默认没有），这个方法不会执行。

4.5 RunLoop 的实际应用

常驻子线程：为子线程创建 RunLoop 并添加一个永不触发的 Port（防止 RunLoop 因没有 Source/Timer 而退出），使线程常驻内存，随时可以接收任务。AFNetworking 2.x 和 SDWebImage 早期版本都使用过这个技巧。
NSTimer 滑动不停：将 Timer 添加到 NSRunLoopCommonModes。
卡顿监控：通过 Observer 监听 RunLoop 状态，检测主线程 Source 处理或休眠前等待是否超时（详见卡顿监控章节）。
线程保活（Thread Keep-Alive）：网络库中用于在子线程持续接收回调。
任务拆分：将大量计算任务拆分成小块，每次 RunLoop 循环处理一块，避免长时间阻塞主线程（类似协程的思想）。

5. Runtime

5.1 Runtime 的本质

Objective-C Runtime 是一个用 C/C++/汇编编写的运行时库，它实现了 ObjC 的面向对象特性和动态性。ObjC 是一门动态语言——许多决定（调用哪个方法、对象是什么类型）被推迟到运行时。

核心思想：消息发送（Messaging）。ObjC 中的方法调用 [obj method] 会被编译器转换为 objc_msgSend(obj, @selector(method))，由 Runtime 在运行时查找并执行对应的实现。

5.2 对象模型

5.2.1 对象（id / objc_object）

每个 ObjC 对象本质上是一个结构体，其第一个成员是 isa 指针，指向该对象所属的类。

从 ARM64 开始，Apple 使用了 Tagged Pointer 和 Non-pointer ISA 优化：

Tagged Pointer：对于 NSNumber、NSDate、短字符串等小对象，指针本身就直接存储了对象的值，不需要在堆上分配内存。判断方法：指针的最高位（ARM64）或最低位（x86_64）为 1 则是 Tagged Pointer。Tagged Pointer 不是真正的对象，没有 isa、没有 retain/release 开销，内存效率和访问速度极高。

Non-pointer ISA（优化的 isa）：在 64 位系统上，isa 不再是单纯的类指针。64 位中只有 33~44 位用于存储类地址，其余位存储了：

引用计数（extra_rc，19 位，存储引用计数减 1 的值）。当 extra_rc 溢出时，将一半的引用计数转存到 SideTable 的 RefcountMap 中，has_sidetable_rc 标志位置 1。
是否有关联对象（has_assoc）。
是否有 C++ 析构函数（has_cxx_dtor）。
是否使用了弱引用（weakly_referenced）。
是否正在释放（deallocating）。

5.2.2 类（objc_class）

类也是一个对象（元类的实例），继承自 objc_object。关键成员：

isa：指向元类（metaclass）。
superclass：指向父类。
cache：方法缓存（cache_t），使用哈希表存储最近调用的方法，加速消息发送。
bits / class_rw_t：
- class_ro_t（Read-Only）：编译期确定的只读数据——方法列表、属性列表、ivar 列表、协议列表、实例大小等。存储在 Mach-O 的 __DATA_CONST 段中。
- class_rw_t（Read-Write）：运行时创建的可读写数据，包含对 class_ro_t 的引用，以及运行时动态添加的方法、属性、协议列表。
- class_rw_ext_t：iOS 14+ 优化，只有在类被运行时修改过（如添加了 Category、使用了 class_addMethod）时才会创建 class_rw_ext_t，约 90% 的类不需要，节省大量内存（Apple 称全系统节省约 14MB）。

5.2.3 元类（Metaclass）

实例对象的 isa → 类对象。
类对象的 isa → 元类对象。
元类对象的 isa → 根元类（NSObject 的元类）。
根元类的 isa → 自身。
根元类的 superclass → NSObject 类。

这个链条解释了为什么实例方法存储在类中，类方法存储在元类中——消息发送总是沿着 isa 链查找方法。

5.3 消息发送机制（objc_msgSend）

5.3.1 快速查找（缓存查找）

objc_msgSend 是用汇编语言编写的（ARM64），追求极致性能。

执行流程：

判断 receiver 是否为 nil（Tagged Pointer 的特殊处理）。
通过 receiver 的 isa 找到类对象。
在类的 cache_t（方法缓存）中查找 SEL 对应的 IMP。cache_t 是一个开放寻址的哈希表，使用 SEL 的地址值做 mask 运算得到索引，查找效率接近 O(1)。
如果命中缓存（Cache Hit），直接跳转到 IMP 执行——整个过程几十纳秒，纯汇编实现。

5.3.2 慢速查找（方法列表查找）

缓存未命中时，进入 C/C++ 实现的 lookUpImpOrForward 函数：

在当前类的 class_rw_t 中搜索方法列表。方法列表已按 SEL 地址排序（在类 realize 时排序），使用二分查找，时间复杂度 O(log n)。
如果未找到，沿 superclass 链向上逐级查找父类的方法列表（每级都先查缓存再查方法列表）。
如果一直到 NSObject（根类）都未找到，进入消息转发流程。
如果找到了，将 SEL→IMP 的映射写入当前类的 cache_t（注意是写入最初接收消息的类的缓存，不是找到方法的那个父类的缓存）。

5.3.3 方法缓存（cache_t）的实现细节

哈希表使用 掩码（mask） 而非取模，因为 mask 可以用位与运算（& mask）替代除法，更快。
缓存容量始终是 2 的幂次，初始容量为 4（ARM64）。
当缓存使用率超过 3/4（75%） 时，容量翻倍并清空所有旧缓存（而非 rehash），因为 Apple 认为缓存的时间局部性很强，旧缓存大概率不再需要。
类在第一次收到消息时分配缓存。

5.4 消息转发机制（Message Forwarding）

当消息发送的快速查找和慢速查找都未找到方法实现时，进入消息转发的三个阶段：

5.4.1 第一阶段：动态方法解析（Dynamic Method Resolution）

Runtime 调用：

实例方法：+resolveInstanceMethod:
类方法：+resolveClassMethod:

在这个方法中，类有机会动态地为 SEL 添加一个 IMP（通过 class_addMethod）。如果返回 YES 且添加了方法，Runtime 会重新执行消息发送流程。

应用场景：@dynamic 属性的实现、Core Data 的 NSManagedObject 动态生成属性的 getter/setter。

5.4.2 第二阶段：快速转发（Fast Forwarding / Forwarding Target）

Runtime 调用 -forwardingTargetForSelector:。

在这个方法中，可以返回另一个对象来处理这条消息（消息转发给备用接收者）。这一步效率很高，因为直接对新对象执行 objc_msgSend，不需要创建 NSInvocation。

应用场景：多重代理（将消息转发给多个对象）、组合模式的简化实现。

5.4.3 第三阶段：完整转发（Normal Forwarding）

Runtime 依次调用：

-methodSignatureForSelector:：返回方法的类型签名（NSMethodSignature），描述参数类型和返回值类型。
-forwardInvocation:：接收一个封装了完整调用信息的 NSInvocation 对象，可以修改目标、参数、甚至调用多次。

这是最灵活但最慢的阶段，NSInvocation 的创建涉及堆分配和参数拷贝。

如果以上三个阶段都未处理，最终调用 -doesNotRecognizeSelector:，抛出经典的 "unrecognized selector sent to instance" 异常。

5.5 Method Swizzling

通过 Runtime 函数交换两个方法的 IMP，实现 AOP（面向切面编程）。

核心 API：

method_exchangeImplementations：交换两个 Method 的 IMP。
class_replaceMethod：替换某个 SEL 的 IMP。
method_setImplementation：设置某个 Method 的 IMP。

陷阱与最佳实践：

必须在 +load 中执行（或用 dispatch_once 保证只执行一次），避免竞态条件。
必须调用原始实现：Swizzle 后的方法中要调用"看似递归实际不是"的原始方法（因为 IMP 已经交换了）。
父类方法问题：如果当前类没有实现目标方法（继承自父类），直接交换会影响父类。正确做法是先 class_addMethod 尝试添加，成功则只需 class_replaceMethod 替换父类的实现到当前类的新 SEL，失败（说明当前类已有实现）才 method_exchangeImplementations。
_cmd 问题：Swizzle 后方法内部的 _cmd 值是交换后的 SEL，可能导致日志、KVO 等依赖 _cmd 的逻辑出错。

5.6 关联对象（Associated Objects）

通过 objc_setAssociatedObject / objc_getAssociatedObject 为已存在的类动态添加"属性"（实际是绑定的键值对）。

内部存储结构：

全局维护一个 AssociationsManager（自带锁），内部是一个 AssociationsHashMap：

AssociationsHashMap: { 对象地址(disguised_ptr_t) → ObjectAssociationMap }
ObjectAssociationMap: { key(const void*) → ObjcAssociation(policy + value) }

关联对象不存储在对象本身的内存中，而是存储在全局的哈希表中，以对象地址为 key。
对象销毁时（dealloc），Runtime 检查 isa 的 has_assoc 标志位，如果为 1，则调用 _object_remove_associations() 清除该对象的所有关联对象。
关联策略：OBJC_ASSOCIATION_ASSIGN（弱引用）、OBJC_ASSOCIATION_RETAIN_NONATOMIC（强引用，非原子）、OBJC_ASSOCIATION_COPY_NONATOMIC（拷贝）等，语义与 property 属性一致。

5.7 Category 的实现原理

Category 在编译后生成 category_t 结构体，包含：方法列表、属性列表、协议列表（但没有 ivar 列表，这就是 Category 不能添加实例变量的原因——实例变量列表在编译期确定，存储在 class_ro_t 中，不可修改）。

加载过程：

在 map_images 阶段，Runtime 遍历所有镜像的 __objc_catlist section，收集所有 Category。
调用 attachCategories() 将 Category 的方法列表倒序插入到类的方法列表数组的前面（使用 attachLists 的 ATTACH_EXISTING 方式）。
因此，后编译的 Category 的方法会排在最前面，最先被找到——这就是 Category "覆盖"原类方法的真相（原方法仍然存在，只是排在后面不会被优先找到）。

多个 Category 有同名方法时：取决于编译顺序（Build Phases → Compile Sources 中的文件顺序），最后编译的 Category 的方法排在最前面。

5.8 Weak 引用的实现

全局 Weak 表：Runtime 维护一个全局的 SideTable（实际上是一个 StripedMap，包含 64 个 SideTable 以减少锁竞争），每个 SideTable 包含：

spinlock_t：自旋锁，保护并发访问。
RefcountMap：存储对象的额外引用计数（extra_rc 溢出时使用）。
weak_table_t：弱引用表，核心结构。

weak_table_t 是一个哈希表，以对象地址为 key，value 是 weak_entry_t，包含所有指向该对象的 weak 指针的地址。

weak 指针的赋值过程：

调用 objc_initWeak()（或 objc_storeWeak()）。
如果旧值非 nil，从旧对象的 weak_entry_t 中移除该 weak 指针。
如果新值非 nil，将该 weak 指针注册到新对象的 weak_entry_t 中。

对象销毁时清除 weak 引用：

dealloc → _objc_rootDealloc → rootDealloc → object_dispose → objc_destructInstance。
objc_destructInstance 中：清除关联对象 → 清除弱引用（weak_clear_no_lock）→ 清除 SideTable 引用计数。
weak_clear_no_lock：遍历对象的 weak_entry_t 中所有 weak 指针地址，将它们全部置为 nil。

这就是 weak 指针在对象销毁后自动变为 nil 的底层机制。

5.9 KVO 的底层实现

KVO（Key-Value Observing）完全依赖 Runtime 实现：

当对某个对象的属性添加 KVO 观察时，Runtime 动态创建一个该对象所属类的子类（命名为 NSKVONotifying_OriginalClass）。
将对象的 isa 指向这个动态子类（isa swizzling）。
动态子类重写了被观察属性的 setter 方法，在 setter 中插入：
- willChangeValueForKey: → 调用原始 setter → didChangeValueForKey:。
- didChangeValueForKey: 内部触发 observeValueForKeyPath:ofObject:change:context: 回调。
动态子类还重写了 class 方法（返回原类而非 NSKVONotifying_ 前缀的子类，对外隐藏 KVO 的实现细节），以及 dealloc（清理观察）和 _isKVOA（标识 KVO 类）。

6. 卡顿监控

6.1 卡顿的定义与原理

iOS 设备的屏幕刷新率通常为 60Hz（ProMotion 设备最高 120Hz），意味着每帧的渲染时间预算为 16.67ms（60fps）或 8.33ms（120fps）。如果主线程在一帧的时间内未完成 UI 更新的所有工作（布局计算、绘制、图层合成提交），就会导致掉帧（Frame Drop），用户感知为卡顿。

渲染流水线（Render Pipeline）：

App 进程（CPU）                      Render Server（GPU）
┌─────────────────┐                  ┌──────────────────┐
│ Layout          │                  │ 图层树解码       │
│ Display (Draw)  │ ──Commit──────→  │ 纹理上传         │
│ Prepare         │   Transaction    │ 合成渲染         │
│ Commit          │                  │ 显示             │
└─────────────────┘                  └──────────────────┘
        ← 一帧 16.67ms →                 ← 一帧 16.67ms →

CPU 和 GPU 是流水线式工作的。CPU 在当前帧完成布局和绘制后提交给 GPU，GPU 在下一帧完成合成渲染。任一环节超时都会导致掉帧。

6.2 卡顿的常见原因

CPU 侧

复杂布局计算：Auto Layout 的约束求解是多项式时间复杂度，视图层级深、约束多时开销显著。
文本计算与渲染：NSAttributedString 的排版（Text Kit / Core Text）、行高计算、折行计算。
图片解码：UIImage 在首次渲染时才进行解码（从 PNG/JPEG 压缩格式解码为位图），大图的解码可能耗时数十毫秒。
对象创建与销毁：大量对象的 alloc/dealloc（尤其涉及 ARC 的 retain/release 操作和 SideTable 锁竞争）。
数据库/文件 I/O：主线程同步读写磁盘。
锁等待：主线程等待子线程持有的锁。

GPU 侧

离屏渲染（Offscreen Rendering）：cornerRadius + masksToBounds、shadow、mask、group opacity 等会触发离屏渲染，GPU 需要额外创建帧缓冲区。
过度绘制（Overdraw）：大量重叠的不透明图层导致 GPU 重复渲染。
大图纹理：超大图片上传到 GPU 的纹理缓存，占用大量显存和带宽。
图层爆炸：大量 CALayer 导致合成开销增大。

6.3 卡顿监控方案

6.3.1 方案一：RunLoop Observer 监控

原理：主线程的所有任务都在 RunLoop 中执行。通过监听 RunLoop 的状态变化，检测两个关键时间间隔：

kCFRunLoopBeforeSources 到 kCFRunLoopBeforeWaiting（Source 处理阶段）：如果这个间隔过长，说明 Source0 事件处理耗时过久（如触摸事件处理中有耗时操作）。
kCFRunLoopAfterWaiting 到下一次 kCFRunLoopBeforeWaiting（被唤醒后的处理阶段）：如果这个间隔过长，说明被唤醒后的任务处理耗时过久。

实现思路：

在主线程注册一个 CFRunLoopObserver，监听所有状态变化。
在 Observer 回调中记录状态变化的时间戳和当前状态。
创建一个子线程，用信号量（dispatch_semaphore）定期检测（如每 50ms 一次）主线程 RunLoop 是否长时间停留在某个状态。
如果连续多次（如 3 次）检测到主线程处于同一个状态超过阈值（如 250ms），判定为卡顿。
在子线程中抓取主线程的调用堆栈。

卡顿判定策略：

超过 1 帧（16ms）：微卡顿，通常不记录。
超过 3 帧（50ms）：轻微卡顿。
超过 250ms：明显卡顿，需要记录堆栈。
超过 3s：严重卡顿（ANR），需要立即上报。

6.3.2 方案二：子线程 Ping（心跳检测）

原理：子线程定期向主线程发送一个"心跳"任务（通过 dispatch_async 派发到主队列），如果主线程在规定时间内未能执行该任务，则认为主线程被阻塞。

实现思路：

子线程设置一个 flag 为 false，通过 dispatch_async(dispatch_get_main_queue(), ^{ flag = true; }) 发送心跳。
子线程等待一段时间（如 500ms 或 1s）。
检查 flag：如果仍为 false，说明主线程在此期间一直忙碌，判定为卡顿。
抓取主线程堆栈。

优缺点比较：

RunLoop Observer 方案更精确，能定位到具体的 RunLoop 阶段，但实现复杂。
心跳检测方案简单可靠，但只能检测到"主线程忙"，无法区分是哪种任务导致的。

6.3.3 方案三：CADisplayLink 帧率监控

利用 CADisplayLink 的回调计算实际帧率。CADisplayLink 会在每次屏幕刷新前调用回调，如果两次回调的间隔超过 16.67ms，说明发生了掉帧。

局限性：只能检测掉帧的发生和严重程度，无法直接获取卡顿原因的堆栈信息。通常作为辅助监控手段，与上述方案配合使用。

6.3.4 方案四：基于 MetricKit（iOS 14+）

MXHangDiagnostic 提供系统级别的卡顿诊断信息，包括卡顿时长和调用堆栈。MXCPUExceptionDiagnostic 报告 CPU 异常使用情况。

优点是零性能开销（系统在后台采集），缺点是数据延迟（次日推送），适合线上监控而非实时调试。

6.4 堆栈采集

卡顿检测到后，最关键的是采集主线程的调用堆栈，用于定位卡顿的根因。

6.4.1 基于 mach_thread API

使用 task_threads() 获取所有线程列表，通过 thread_get_state() 获取目标线程（主线程）的寄存器状态（包含 PC、FP、LR 等），然后沿着 Frame Pointer（FP）链回溯调用栈，结合 DWARF 调试信息或 dSYM 文件符号化。

6.4.2 基于 backtrace() / backtrace_symbols()

标准 POSIX 接口，但只能获取当前线程的堆栈，无法跨线程采集。

6.4.3 基于 PLCrashReporter

开源的崩溃报告库，提供了安全的跨线程堆栈采集能力（信号安全、锁安全），是业界常用方案。

6.5 堆栈聚合与分析

调用树合并：将多次采集的堆栈按调用路径合并成火焰图/调用树，识别热点函数。
符号化：将内存地址转换为函数名+偏移量，需要对应版本的 dSYM 文件。使用 atos 命令或 dwarfdump 工具。
去噪：过滤系统框架的堆栈帧（如 CFRunLoopRunSpecific、mach_msg_trap），聚焦业务代码。

6.6 治理策略

文本异步计算：使用 NSAttributedString 的 boundingRectWithSize: 在子线程预计算文本高度。
图片异步解码：在子线程用 CGBitmapContextCreate + CGContextDrawImage 强制解码图片，主线程直接使用解码后的位图。
预排版/预计算：Cell 的高度、布局信息在数据到达时在子线程预计算完成，主线程直接使用。
按需加载：屏幕外的 Cell 不进行复杂渲染。
减少离屏渲染：用 UIBezierPath + CAShapeLayer 替代 cornerRadius + masksToBounds；用 shadowPath 替代自动计算的阴影。
异步绘制：使用 drawRect: 在后台线程绘制位图，再赋值给 CALayer.contents（参考 Texture/AsyncDisplayKit 框架的思想）。

7. AFNetworking

7.1 整体架构

AFNetworking 是 iOS/macOS 上最流行的网络库。目前主流版本为 AFNetworking 4.x，完全基于 NSURLSession（3.x 开始移除了 NSURLConnection 支持）。

核心架构分层：

┌────────────────────────────────────────────┐
│           AFHTTPSessionManager            │  ← 最高层：便捷 HTTP 接口
│     (GET/POST/PUT/DELETE 等快捷方法)       │
├────────────────────────────────────────────┤
│           AFURLSessionManager             │  ← 核心层：Session 管理
│   (NSURLSession delegate 的完整实现)       │
├────────────────────────────────────────────┤
│  AFURLRequestSerialization                │  ← 请求序列化
│  (HTTP/JSON/PropertyList Request)         │
├────────────────────────────────────────────┤
│  AFURLResponseSerialization               │  ← 响应反序列化
│  (HTTP/JSON/XML/Image/PropertyList)       │
├────────────────────────────────────────────┤
│  AFSecurityPolicy                         │  ← 安全策略（HTTPS/证书验证）
├────────────────────────────────────────────┤
│  AFNetworkReachabilityManager             │  ← 网络状态监听
└────────────────────────────────────────────┘

7.2 AFURLSessionManager 深入解析

7.2.1 核心职责

AFURLSessionManager 是整个库的心脏，它：

持有并管理一个 NSURLSession 实例。
实现了 NSURLSessionDelegate、NSURLSessionTaskDelegate、NSURLSessionDataDelegate、NSURLSessionDownloadDelegate 四个协议的所有关键方法。
维护一个 mutableTaskDelegatesKeyedByTaskIdentifier 字典，将每个 NSURLSessionTask 映射到一个 AFURLSessionManagerTaskDelegate 对象，实现任务级别的回调隔离。

7.2.2 线程安全设计

使用 NSLock（名为 lock）保护 mutableTaskDelegatesKeyedByTaskIdentifier 字典的并发访问。
NSURLSession 的 delegate 回调在一个专用的串行 OperationQueue（operationQueue.maxConcurrentOperationCount = 1）上执行，保证回调的串行化，避免多线程问题。
完成回调（success/failure block）默认 dispatch 到主队列（completionQueue 默认为 dispatch_get_main_queue()），保证 UI 更新的线程安全。开发者也可以自定义 completionQueue 和 completionGroup。

7.2.3 任务代理（AFURLSessionManagerTaskDelegate）

每个 NSURLSessionTask 对应一个 AFURLSessionManagerTaskDelegate 实例，它负责：

收集响应数据：在 URLSession:dataTask:didReceiveData: 中将接收到的数据追加到 mutableData 中。
跟踪上传/下载进度：通过 NSProgress 对象提供 KVO 兼容的进度更新。
任务完成时：根据 responseSerializer 反序列化响应数据，在 completionQueue 上回调 success/failure block。

7.2.4 KVO 与通知机制

AFNetworking 大量使用了 KVO 和 NSNotification：

对 NSURLSessionTask 的 state 属性进行 KVO 观察，当任务状态变为 completed 时自动清理。
任务 resume/suspend/complete 时发送全局通知（如 AFNetworkingTaskDidResumeNotification），方便外部监听（如网络活动指示器 AFNetworkActivityIndicatorManager）。
使用 Method Swizzling 交换了 NSURLSessionTask 的 resume 和 suspend 方法，在调用时发送通知。这是因为 NSURLSession 不对 task 的 state 变化发送 KVO 通知，AF 需要自己实现。

7.3 请求序列化（AFURLRequestSerialization）

7.3.1 AFHTTPRequestSerializer

基础的 HTTP 请求序列化器：

设置通用 HTTP Header（User-Agent、Accept-Language、Authorization 等）。
将参数字典编码为 URL query string（GET/HEAD/DELETE）或 HTTP body（POST/PUT/PATCH）。
参数编码规则：对键值对进行百分号编码（Percent Encoding），嵌套字典和数组使用方括号语法（key[subkey]=value、key[]=value）。
multipartFormData：支持 multipart/form-data 编码，用于文件上传。内部使用 AFMultipartBodyStream（自定义的 NSInputStream 子类）实现流式上传，避免将整个文件载入内存。

7.3.2 AFJSONRequestSerializer

继承自 AFHTTPRequestSerializer，将参数字典使用 NSJSONSerialization 编码为 JSON 格式放入 HTTP Body，设置 Content-Type 为 application/json。

7.4 响应序列化（AFURLResponseSerialization）

响应序列化器负责验证响应的合法性并将数据转换为目标格式。

7.4.1 验证机制

所有序列化器都继承自 AFHTTPResponseSerializer，它的 validateResponse:data:error: 方法检查：

HTTP 状态码是否在 acceptableStatusCodes（默认 200~299）范围内。
响应的 Content-Type 是否在 acceptableContentTypes 集合中。

如果验证失败，生成对应的 NSError（AFURLResponseSerializationErrorDomain），并将响应数据放入 error.userInfo[AFNetworkingOperationFailingURLResponseDataErrorKey] 中，方便调试。

7.4.2 AFJSONResponseSerializer

使用 NSJSONSerialization 将 Data 解析为字典/数组。支持自动移除 JSON 中的 NSNull 值（removesKeysWithNullValues 属性）。

7.4.3 AFImageResponseSerializer

将 Data 解码为 UIImage。支持自动解压（inflate）——在子线程强制解码图片位图，避免在主线程首次渲染时的解码开销（与 SDWebImage 的思路一致）。

7.5 安全策略（AFSecurityPolicy）

7.5.1 三种验证模式

模式	说明	安全级别
`AFSSLPinningModeNone`	使用系统默认的证书链验证	低
`AFSSLPinningModeCertificate`	将服务器证书与 App 内预埋的证书进行完整比对	最高
`AFSSLPinningModePublicKey`	只比对证书中的公钥（Public Key）	高（推荐）

7.5.2 证书验证流程

获取服务器返回的证书链（SecTrustRef）。
设置锚点证书（Anchor Certificates）为 App 预埋的证书。
调用 SecTrustEvaluateWithError() 进行系统级证书链验证。
根据 Pinning Mode：
- Certificate Mode：逐一比对证书的 DER 编码数据。
- PublicKey Mode：提取证书的公钥数据进行比对。
validatesDomainName：是否验证证书中的域名与请求域名匹配。

7.5.3 公钥固定的优势

比证书固定更灵活——即使服务器更换了证书（只要使用相同的密钥对），App 无需更新。

7.6 网络可达性（AFNetworkReachabilityManager）

基于 SCNetworkReachability（SystemConfiguration 框架），监听网络状态变化。

核心流程：

使用 SCNetworkReachabilityCreateWithAddress 或 SCNetworkReachabilityCreateWithName 创建 reachability 引用。
设置回调函数，当网络状态变化时触发。
将 reachability 引用加入 RunLoop（CFRunLoopGetMain()）以持续监听。
回调中解析 SCNetworkReachabilityFlags，判断：
- 是否可达（kSCNetworkReachabilityFlagsReachable）。
- 是否通过 WWAN（kSCNetworkReachabilityFlagsIsWWAN）。

注意：SCNetworkReachability 检测的是"是否有网络路径"，不是"是否能真正连通互联网"。飞行模式能检测到，但连上 WiFi 但无法上网的情况检测不到。

7.7 与 Alamofire 的对比

Alamofire 是 AFNetworking 作者在 Swift 生态下的重写，核心思想一致但做了现代化改进：

对比维度	AFNetworking	Alamofire
语言	Objective-C	Swift
并发模型	GCD + NSOperationQueue	Swift Concurrency (async/await)
请求构建	Mutable URL Request	链式调用 + Request 协议
响应处理	Block 回调	Result + async/await
拦截器	需自行封装	内置 `RequestInterceptor` 协议
重试	需自行实现	内置 `RetryPolicy`

8. SDWebImage

8.1 整体架构

SDWebImage 是 iOS 上最广泛使用的图片加载和缓存库。其核心设计哲学是将复杂的图片加载流程封装为简洁的 API（如 sd_setImageWithURL:），同时提供高度可定制的扩展点。

架构分层：

┌──────────────────────────────────────────────────┐
│              UIView+WebCache                     │  ← 最上层：UIKit 扩展
│  (UIImageView / UIButton 的分类方法)              │
├──────────────────────────────────────────────────┤
│              SDWebImageManager                   │  ← 核心调度器
│  (协调缓存查找和网络下载)                          │
├──────────────┬───────────────────────────────────┤
│ SDImageCache │  SDWebImageDownloader             │  ← 缓存 / 下载
│ (内存+磁盘)   │  (网络下载管理)                    │
├──────────────┴───────────────────────────────────┤
│ SDWebImageDownloaderOperation                    │  ← 下载操作
│ (基于 NSURLSessionDataTask 的下载单元)             │
├──────────────────────────────────────────────────┤
│ SDImageCoder / SDImageTransformer                │  ← 编解码 / 变换
│ (PNG/JPEG/GIF/WebP/HEIF 编解码, 圆角/缩放等)      │
└──────────────────────────────────────────────────┘

8.2 加载流程全景

当调用 [imageView sd_setImageWithURL:url] 时，完整的执行流程：

Step 1：取消旧任务 取消该 UIImageView 上一次尚未完成的图片加载任务（通过关联对象存储的 operation key）。这避免了 Cell 复用场景下的图片错乱问题。

Step 2：设置占位图 如果提供了 placeholder，立即在主线程设置占位图。

Step 3：查询缓存 SDWebImageManager 调用 SDImageCache 查询缓存：

内存缓存查询：SDMemoryCache（基于 NSCache）中以 URL 的 MD5/SHA256 哈希为 key 查找。命中则直接返回。
磁盘缓存查询：如果内存未命中，在串行 I/O 队列（ioQueue）中异步查询磁盘缓存。磁盘缓存使用文件存储，文件名为 URL 的 MD5 哈希值。查询过程包括：
1. 检查文件是否存在（fileExistsAtPath:）。
2. 读取文件数据。
3. 对图片进行解码（从 PNG/JPEG 数据解码为位图）。
4. 将解码后的图片写入内存缓存（回填）。

Step 4：网络下载 如果缓存完全未命中（或设置了 SDWebImageRefreshCached 选项），启动网络下载：

SDWebImageDownloader 创建或复用一个 SDWebImageDownloaderOperation。
同一个 URL 的多次请求会被合并（Coalescing）——只发一次网络请求，结果回调给所有等待者。这通过 URLOperations 字典（以 URL 为 key）实现。
下载操作基于 NSURLSessionDataTask。

Step 5：图片处理 下载完成后：

在子线程进行图片解码（Decode）。
如果设置了 SDImageTransformer（如圆角、缩放、高斯模糊），在子线程执行变换。
将处理后的图片同时写入内存缓存和磁盘缓存。

Step 6：回调主线程 在主线程设置 imageView.image，触发 UI 更新。支持渐变动画（SDWebImageTransition）。

8.3 缓存机制深入解析

8.3.1 内存缓存（SDMemoryCache）

继承自 NSCache，具备以下特性：

自动淘汰：当系统内存紧张时，NSCache 会自动释放对象。开发者可以设置 countLimit（最大数量）和 totalCostLimit（最大总开销，以图片像素数为 cost）。
线程安全：NSCache 内部使用锁保护，可以在任意线程安全访问。
弱引用表（mapTable）：SDWebImage 额外维护了一个 NSMapTable（weakToStrongObjects），当 NSCache 因内存压力淘汰了某张图片时，如果该图片仍被某个 UIImageView 持有（强引用），通过 mapTable 仍然可以找到它，避免不必要的重新解码/下载。

8.3.2 磁盘缓存（SDDiskCache）

存储格式：原始的图片数据（未解码的 PNG/JPEG/WebP 数据），不是解码后的位图。这大幅减少了磁盘空间占用。
文件命名：URL 的 MD5 哈希值作为文件名，避免特殊字符问题。
过期策略：默认缓存保留 1 周（maxDiskAge = 60 * 60 * 24 * 7）。
容量限制：可设置 maxDiskSize（最大磁盘缓存大小），超限时按最近最久未使用（LRU） 策略淘汰——根据文件的 NSFileModificationDate（修改日期）排序，优先删除最旧的文件，直到缓存大小降至限制的一半。
清理时机：
- App 进入后台时（UIApplicationDidEnterBackgroundNotification）触发异步清理。
- App 终止时（UIApplicationWillTerminateNotification）触发清理。
- 开发者手动调用 clearDiskOnCompletion:。

8.3.3 缓存 Key 的计算

默认使用完整的 URL 字符串作为缓存 key。开发者可以通过 SDWebImageManager 的 cacheKeyFilter block 自定义 key 生成逻辑（例如去除 URL 中的 token 参数，使相同内容的不同签名 URL 共享缓存）。

如果使用了 SDImageTransformer，变换后的图片使用 originalKey + transformerKey 作为缓存 key，与原图分开缓存。

8.4 图片解码机制

8.4.1 为什么需要预解码

UIImage 的 imageWithData: 创建的图片是未解码的——它只是持有压缩的图片数据。只有在图片首次被渲染到屏幕上时（CALayer 的 display 方法中），Core Animation 才会调用解码器将其解码为位图。这个解码发生在主线程，可能导致掉帧。

SDWebImage 的策略是在子线程提前解码（Force Decode / Decompressing），将位图缓存到内存中，主线程直接使用解码后的位图，消除主线程解码开销。

8.4.2 解码实现

解码的核心步骤：

创建 CGBitmapContext（位图上下文），指定颜色空间、每像素字节数、Alpha 通道信息。
使用 CGContextDrawImage 将 CGImageRef 绘制到上下文中——这一步触发实际的解码。
从上下文中获取解码后的 CGImageRef，创建新的 UIImage。

内存占用计算：一张 1000×1000 的图片解码后占用 1000 × 1000 × 4 bytes = 4MB（RGBA 格式，每像素 4 字节）。因此，SDWebImage 提供了 SDImageCoderDecodeScaleDownLimitBytes 选项，对超大图片进行降采样后再解码，避免内存暴涨。

8.4.3 渐进式解码（Progressive Decoding）

对于 JPEG 等支持渐进式加载的格式，SDWebImage 可以在下载过程中边下载边解码。每接收一段数据就解码一次，UI 上展示从模糊到清晰的渐进效果。

通过 SDImageCoderProgressiveCoder 协议实现，每次调用 updateIncrementalData:finished: 更新数据并产生部分解码的图片。

8.4.4 编解码器架构（SDImageCoder）

SDWebImage 5.x 使用了协议化的编解码器架构：

SDImageCoder 协议定义了 canDecodeFromData:、decodedImageWithData:、encodedDataWithImage: 等方法。
内置编解码器：SDImageIOCoder（PNG/JPEG/TIFF/GIF 静图）、SDImageGIFCoder（GIF 动图）、SDImageAPNGCoder（APNG）。
可扩展：通过 SDImageCodersManager 注册自定义编解码器，如 SDImageWebPCoder（WebP 支持）、SDImageHEICCoder（HEIC 支持）。
解码器按注册的逆序遍历（后注册的优先），调用 canDecodeFromData: 判断哪个解码器能处理当前数据格式。

8.5 下载机制深入

8.5.1 SDWebImageDownloader

维护一个 NSOperationQueue（downloadQueue），控制最大并发下载数（默认 6）。
支持 LIFO（后进先出）和 FIFO（先进先出）两种执行顺序。LIFO 适合瀑布流场景——用户快速滑动时，最新可见的 Cell 的图片优先下载。通过设置 Operation 之间的依赖关系实现 LIFO。
支持 HTTP Header 自定义、认证（URLCredential）、超时配置等。

8.5.2 SDWebImageDownloaderOperation

继承自 NSOperation，内部封装了一个 NSURLSessionDataTask。

关键设计：

回调合并：使用 callbackBlocks 数组存储所有对同一 URL 的下载回调。当下载完成时，遍历数组逐一回调。
后台下载：支持 App 进入后台后继续下载（通过 UIApplication.beginBackgroundTaskWithExpirationHandler:）。
响应数据拼接：在 URLSession:dataTask:didReceiveData: 中将数据追加到 NSMutableData（imageData），下载完成后一次性交给解码器。
取消机制：调用 cancel 时取消 NSURLSessionDataTask，从 callbackBlocks 中移除对应的回调。如果所有回调都被移除，则取消整个下载任务。

8.5.3 URL 请求去重（Coalescing）

SDWebImageDownloader 维护一个 URLOperations 字典（以 URL 为 key，以 SDWebImageDownloaderOperation 为 value）。当新请求到来时：

如果该 URL 已有进行中的下载操作，直接将新的回调添加到现有 Operation 的 callbackBlocks 中，不创建新的网络请求。
如果没有，创建新的 Operation 并加入队列。

这种设计在列表场景下极为高效——同一张头像被多个 Cell 引用时，只会发起一次网络请求。

8.6 UIView+WebCache 的设计

通过 ObjC Runtime 的关联对象机制，为 UIImageView 等视图绑定当前的加载操作。

核心流程：

调用 sd_setImageWithURL: 时，先通过 sd_cancelCurrentImageLoad 取消当前关联的旧操作。
使用 objc_setAssociatedObject 将新的 SDWebImageCombinedOperation 关联到视图上。
加载完成或 Cell 复用时，通过 objc_getAssociatedObject 获取并取消/检查操作状态。

这解决了经典的 Cell 复用导致图片错乱问题：当 Cell 被复用时，旧 Cell 的下载完成回调中设置的图片会被忽略（因为旧操作已被取消）。

8.7 动图支持

8.7.1 GIF / APNG

SDWebImage 使用 SDAnimatedImageView（继承自 UIImageView）播放动图。其内部实现：

使用 CADisplayLink 驱动动画帧切换。
按需解码：不一次性解码所有帧（一个 GIF 可能有数百帧，全部解码会占用大量内存），而是维护一个帧缓存（NSMutableDictionary），预解码当前帧附近的若干帧（预取缓冲区），按需释放远离当前播放位置的帧。
帧缓冲区大小根据可用内存动态调整。

8.7.2 WebP / HEIF

通过可插拔的编解码器支持：

SDImageWebPCoder：使用 libwebp 库进行 WebP 编解码。
SDImageHEICCoder：使用系统 ImageIO 框架进行 HEIF 编解码（iOS 11+）。

8.8 性能优化细节

异步 I/O：磁盘缓存的所有读写操作都在专用的串行 ioQueue 上异步执行，不阻塞主线程。
解码降采样：对于超大图片（如 4000×3000 的相机照片），先使用 CGImageSourceCreateThumbnailAtIndex 进行降采样到目标显示尺寸，再解码。这比先解码再缩放效率高得多——直接操作压缩数据，内存峰值大幅降低。
内存警告响应：监听 UIApplicationDidReceiveMemoryWarningNotification，立即清空内存缓存（NSCache 的 removeAllObjects）。
URL 黑名单：对于下载失败的 URL（非超时错误），加入 failedURLs 集合，短期内不再重试，避免无效请求浪费资源（可通过 SDWebImageRetryFailed 选项关闭此行为）。
Prefetch（预加载）：SDWebImagePrefetcher 支持批量预加载图片到缓存中，适用于已知用户即将浏览的内容（如下一页的列表数据）。

8.9 SDWebImage 5.x 的架构升级

SDWebImage 5.x 相比 4.x 做了大量架构优化：

特性	4.x	5.x
编解码	硬编码在内部	协议化（SDImageCoder）
缓存	固定实现	协议化（SDImageCache Protocol）
下载	固定实现	协议化（SDImageLoader Protocol）
变换	需第三方库	内置 SDImageTransformer
动图	FLAnimatedImage 依赖	内置 SDAnimatedImage
指标	无	SDImageLoadIndicator

协议化设计使得每个组件都可以被替换为自定义实现，极大提升了灵活性。

总结

上述八个知识点构成了 iOS 开发中性能优化与底层原理的核心体系：

启动流程和启动优化帮助我们理解 App 从点击图标到用户可见的完整链路，并从 pre-main 和 post-main 两个阶段系统性地优化启动速度。
网络优化覆盖了从 DNS 到数据传输、从连接管理到弱网对抗的全链路优化策略。
RunLoop 是 iOS 事件驱动模型的基石，理解它才能理解触摸事件、Timer、UI 刷新等核心机制的运作方式。
Runtime 是 Objective-C 动态性的根基，消息发送、方法缓存、消息转发、KVO、Category 等特性都建立在它之上。
卡顿监控将 RunLoop 和性能分析结合，提供了从检测到治理的完整方案。
AFNetworking 和 SDWebImage 作为两个最经典的第三方库，它们的架构设计、线程安全策略、性能优化思路值得深入学习和借鉴。

移动端开发稳了？AI 目前还无法取代客户端开发，小红书的论文告诉你数据

掘金 iOS

恋猫de小郭

2026年3月2日 16:09

近期，由小红书联合多伦多大学等高校的研究人员发布了《SWE-Bench Mobile》（2602.09540）论文，内容主要是评估 LLM 智能体在处理真实生产级移动端应用开发任务时的能力，并提出了首个针对该领域的基准测试——SWE-Bench Mobile。

这个论文对比之前那些简单的需求场景，明显更具备说服力，最重要的是，用真实的数据给目前的 AI 狂热浇一浇冷水。

目前的编程基准测试大多集中在孤立的算法问题，而 SWE-Bench 则是关注 GitHub 上的 Bug 修复，然而真实的工业级移动端开发汪汪更为复杂：

多模态输入：开发者需要根据产品需求文档（PRD）和 Figma 设计稿等来写代码
复杂的工程环境：中大厂的移动端代码库通常规模巨大（ 5GB 以上），且涉及 Swift 与 Objective-C 混编、特定系统 API 及复杂的 UI 交互，还有编译环境影响
任务类型多样化：不限于 Bug 修复，更多是功能开发和 UI 增强

所以研究团队从目前小红书自己的真实产品流水线中提取了 50 个具有代表性的开发任务，构建了该基准测试：

数据集组成 ：
- 50 个真实任务：源自实际的产品需求
- 449 个人工验证的测试用例：平均每个任务 9.1 个测试点，用于评估功能正确性
- 多模态支持：70% 的任务附带 Figma 设计链接，92% 附带参考图
代码库规模：基于约 5GB 大小的真实 iOS 生产代码库（Swift/Objective-C）
任务复杂度：平均每个任务涉及修改 4.2 个文件，远超之前的基准测试

整个基准的规则是：

70% 任务包含 Figma
92% 包含参考图片
平均 PRD 长度 450 字

每个任务包含：

一个统一 diff 补丁（patch）输出
综合测试套件（平均 9.1 个测试案例）
任务难度分级：从简单 UI 调整到复杂跨模块改造

对于任务两个关键指标：

任务成功率：所有测试通过的任务比例

测试通过率：所有测试案例通过的比率

而对于 LLM，论文评估了 22 种 不同的“智能体-模型”配置，涵盖了四个主流框架：

商业智能体：Cursor、Codex (由 DeepSeek/OpenAI 等模型驱动)、Claude Code
开源智能体：OpenCode

评估维度包括：任务完成率、任务复杂度影响、成本效果对比、多次运行稳定性、Prompt 设计影响等。

而根据论文可以得出结论：当前 AI 在生产级的软件工程力存在巨大局限性：

成功率极低 ：表现最好配置的成功率仅为 12% ，大多数任务以“实现不完整”告终，但测试通过率最高可到 28%，说明部分任务可以部分正确生成，但没能完全部署成功
智能体架构十分重要 ：同一个底层模型，在 Cursor 框架下的成功率为 12%，但在 OpenCode 下仅为 2%，智能体的工具调用、上下文管理等设计与模型本身同等重要
商业模型占优：商业闭源智能体在处理大型代码库时的稳定性和正确性显著优于开源方案
复杂度陷阱：任务涉及 1-2 个文件时成功率为 18%，但当涉及 7 个以上文件时，成功率骤降至 2% ，显示出模型在跨文件长程推理方面的短板
“防御性编程”提示词更有效：研究发现，使用基于“防御性编程”（原则的简洁提示词，比复杂的提示词能让成功率提升 7.4%

对于失败，论文还针对失败类型归类：

缺失关键功能标志位或 Feature Flag 是主要的失败原因
其次是 数据模型缺失；
再者是 incomplete patch（文件覆盖不足）等问题

这些失败的类似，在一定程度上反映了智能体对真实工程流程、跨文件依赖、与视觉设计的理解严重不足，也就是这些问题是“工程级问题”，而不是“语言问题”：

所以哪怕换成 Android / Flutter，这类跨文件工程理解问题仍然存在。

基于这些数据，论文认为当前 LLM Agent 尽管在单一代码生成上有突破，但在端到端工程上下文（包含设计、代码库理解、工程流程）仍远未达到企业生产标准。

另外，论文也有一个有趣的结论数据，主要统计了各 Agent + Model 的每任务成本（美元）和平均耗时（分钟），例如：

Cursor + Opus 4.5 ： $3.50 / 15 min
Codex + GLM 4.6 ： $1.30 / 13.3 min
OpenCode + GLM 4.6 ： $0.13 / 32.5 min
OpenCode + Opus 4.5 ： $9.33 / 8.2 min

对此可以看出来：

Codex + GLM 4.6 是性价比最高
OpenCode 极便宜但成功率低
OpenCode + Opus 4.5 是最贵但效果很差（2%）

最后，下图是论文的最终结果对比，例如在 Success 和 Pass 上：

Cursor + Opus 4.5 → 12% / 28.1%
Codex + GLM 4.6 → 12% / 19.6%
OpenCode + GLM 4.6 → 8%

这么看，OpenCode 的实际数据表现是真的一般。

这个在同一个模型，在不同 agent 上的成功率也有所体现，OpenCode 再一次被鞭尸：

所以，可以看出来，目前的 AI 智能体离独立完成中大型移动开发还有很大距离，主要瓶颈在于多模态理解、大规模代码导航和跨文件逻辑一致性等。

另外，SWE-Bench Mobile 采用了托管基准挑战（Hosted Benchmark）模式 ，不公开测试集答案，以防止数据泄露到未来的模型训练中。

最后，论文只针对原生 iOS 开发进行测试，没有测试 Android 原生、Flutter、RN 等其他情况，按照一般直觉，这些框架的 AI 表现应该会好于 iOS 原生，当然这也只是我的个人直觉，真实数据还是得有企业做过 Benchmark 才知道。

不过至少从目前看，在移动端开发领域写代码上，至少比前端安全性高一些？你怎么看？

05-主题|事件响应者链@iOS-应用场景与进阶实践

掘金 iOS

没有故事的Zhang同学

2026年3月2日 14:16

本文在 01 总纲、02 hitTest、03 响应者链、04 UIResponder 基础上，总结工程中的应用场景与进阶用法：UIControl 的 target=nil 与响应者链、手势识别器与响应者的优先级、扩大点击区域与事件穿透、以及 SwiftUI 与 UIKit 的对比。文末附参考文献。

一、UIControl 与 target=nil 的响应者链

1.1 机制

对 UIControl（如 UIButton、UISlider）使用 addTarget(_:action:for:) 时，若将 target 设为 nil，系统不会在添加时绑定具体对象，而是在事件触发时从第一响应者开始，沿 next 查找第一个能响应该 action 的响应者并调用，即 action 沿响应者链寻找 target [1]。编辑菜单（复制/粘贴/剪切）也使用同一机制在链上查找实现 copy(_:)、paste(_:)、cut(_:) 等的对象。

1.2 Action 方法签名

Action 方法通常为以下形式之一 [2]：

@IBAction func doSomething()
@IBAction func doSomething(sender: UIButton)
@IBAction func doSomething(sender: UIButton, forEvent event: UIEvent)

1.3 使用注意

Cell 内按钮：按钮在 UITableViewCell/UICollectionViewCell 内时，链的路径是 Cell → 其他 view，不一定会经过 TableView 的 ViewController。若希望由 VC 处理，用 nil target 可能找不到 VC，此时更稳妥的做法是显式指定 target（如 VC）或通过 delegate/callback 把事件交给 VC [3]。Delegate、Block、闭包、函数封装、遍历传递等「传递方式」的对比与选型见 06-响应者链传递方式与编程模式详解。
非相邻 VC：通过 present 的 VC 与当前 VC 不一定在一条「相邻」的 next 链上，nil target 不一定能跨 present 边界找到目标，建议用显式 target 或业务层路由。

二、UIGestureRecognizer 与响应者链

2.1 优先级关系

手势识别器在触摸到达视图的 touchesBegan 等之前参与识别。若手势识别成功，可消费触摸，视图的 touches 方法可能不再被调用；若手势识别失败，触摸会交给视图并沿响应者链继续传递 [4]。

控件（如 UIButton）可通过 gestureRecognizerShouldBegin(_:) 等让父视图的手势不干扰自己的点击，从而保证按钮的 target-action 优先。

2.2 泳道图：手势、响应者与控件的优先级

flowchart TB
    subgraph 触摸发生
        T1[手指按下]
    end
    subgraph 系统
        S1[hit-test 得到 view]
        S2[手势识别器优先]
    end
    subgraph 手势层
        G1[识别成功?]
        G2[消费事件]
        G3[识别失败]
    end
    subgraph 响应者层
        R1[视图 touches / UIControl]
        R2[沿 next 传递]
    end
    T1 --> S1
    S1 --> S2
    S2 --> G1
    G1 -->|是| G2
    G1 -->|否| G3
    G3 --> R1
    R1 --> R2

2.3 小结

层级	说明
手势识别	先于视图的 touches 参与识别，成功则可消费事件
视图 touches	手势未消费时，由 hit-test view 及其 next 链处理
UIControl	通过内部逻辑与 gesture 的配合，保证点击等行为优先

三、扩大点击区域与事件穿透

3.1 扩大点击区域

对视觉较小的按钮或图标，可通过重写 point(inside:with:) 扩大可点击范围（如四周各扩展 20pt），提升可点性 [5]。

override func point(inside point: CGPoint, with event: UIEvent?) -> Bool {
    let margin: CGFloat = 20
    return bounds.insetBy(dx: -margin, dy: -margin).contains(point)
}

3.2 事件「穿透」到下层

若希望某视图不响应触摸、让触摸落到下层视图，可重写 hitTest(_:with:)，在满足条件时返回 nil，则当前视图及其子视图不参与命中，系统会继续用其兄弟或父视图参与 hit-test [6]。

override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
    let hit = super.hitTest(point, with: event)
    // 若希望本视图不拦截，可返回 nil；否则返回 hit
    return shouldPassThrough ? nil : hit
}

商用场景示例：视频播放页上的礼物动画、点赞动效浮层使用 PassThroughView 或重写 hitTest 返回 nil，使点击落到下层进度条、暂停按钮；或活动弹窗关闭后遮罩不拦截，点击空白处关闭。

3.3 手势与按钮共存的完整代码（商用：列表 Cell 内按钮由 VC 处理）

// Cell 内「加购」按钮希望由 ListViewController 处理，用 delegate 传递，避免 nil target 链不到 VC
protocol ProductCellDelegate: AnyObject {
    func productCell(_ cell: ProductCell, didTapAddCart productId: String)
}

class ProductCell: UITableViewCell {
    weak var delegate: ProductCellDelegate?
    private var productId: String = ""
    @objc private func addCartTapped() {
        delegate?.productCell(self, didTapAddCart: productId)
    }
}

class ListViewController: UIViewController, ProductCellDelegate {
    func tableView(_ tableView: UITableView, cellForRowAt indexPath: IndexPath) -> UITableViewCell {
        let cell = tableView.dequeueReusableCell(withIdentifier: "ProductCell", for: indexPath) as! ProductCell
        cell.delegate = self
        cell.configure(productId: items[indexPath.row].id)
        return cell
    }
    func productCell(_ cell: ProductCell, didTapAddCart productId: String) {
        // 加购、埋点、弹 toast 等
        cartService.add(productId: productId)
    }
}

3.4 应用场景分类（思维导图）

mindmap
  root((应用场景))
    列表与 Cell
      Cell 内按钮 delegate
      扩大热区 小图标
    浮层与遮罩
      穿透 hitTest 返回 nil
      手势与按钮共存
    编辑与输入
      编辑菜单 copy paste
      自定义 inputView
    手势与链
      手势优先 再响应者链
      gestureRecognizerShouldBegin

四、SwiftUI 与 UIKit 的对比（简要）

SwiftUI 没有 UIKit 式的「响应者链」[7][8]：

使用 Gesture 修饰符在视图上声明手势，由系统做 hit-test 与手势竞争，不会把事件沿「next」链向上冒泡。
可点击区域由 frame 与 contentShape 决定；.allowsHitTesting(false) 相当于从 hit-test 中排除。
多手势的优先级通过 highPriorityGesture、simultaneousGesture 等显式组合，而非依赖「链」传递。

在 UIKit 与 SwiftUI 混用时，需注意：SwiftUI 宿主视图内的交互由 SwiftUI 管理；嵌入的 UIKit 视图仍走 UIKit 的 hit-test 与响应者链。

五、应用场景小结

场景	涉及机制	建议
按钮/控件由上层 VC 统一处理	target-action + nil target → 响应者链	Cell 内或复杂层级下优先显式 target 或 delegate
编辑菜单（复制/粘贴）	链上查找 canPerformAction / target	在合适响应者上实现 copy/paste/cut 等方法
扩大按钮可点区域	point(inside:with:)	重写并扩大 bounds 的「有效」区域
浮层不拦截触摸	hitTest(_:with:) 返回 nil	指定条件下返回 nil 实现穿透
手势与按钮共存	手势识别 vs 响应者	用 gestureRecognizerShouldBegin 等保护控件
自定义键盘/输入条	First Responder + inputView	成为第一响应者并设置 inputView / inputAccessoryView
事件/回调传递方式选型	Delegate / Block / 闭包 / 函数封装 / 遍历	见 06-响应者链传递方式与编程模式详解

5.1 商用场景速查

场景	做法
电商列表加购/收藏	Cell 内小按钮用 delegate 交给 VC，或扩大热区 + target-action
视频/直播浮层不挡点击	浮层 view 重写 hitTest 在命中自己时返回 nil
活动弹窗遮罩点击关闭	遮罩用 PassThroughView 或 hitTest 返回 nil，按钮在遮罩上方单独处理
设置页开关/列表点击	系统 UITableView 的 didSelect + 响应者链；Cell 内控件用 delegate 更稳
安全输入/自定义键盘	自定义 UITextField 的 inputView，canBecomeFirstResponder = true

参考文献

[1] Using responders and the responder chain to handle events - Controls and the responder chain
[2] UIControl | Apple Developer Documentation
[3] UIControl Target Action event not flowing up the responder chain (Stack Overflow)
[4] Using responders and the responder chain - Gesture recognizers
[5] How to implement point(inside:with:) (Stack Overflow)
[6] Hacking Hit Tests (Khanlou)
[7] SwiftUI Gesture System Internals (DEV)
[8] SwiftUI Hit-Testing & Event Propagation Internals (DEV)

02-主题|事件响应者链@iOS-hitTest与事件传递详解

掘金 iOS

没有故事的Zhang同学

2026年3月2日 14:13

本文专门讲解 iOS 中事件传递的「确定目标」阶段：hitTest(_:with:) 与 point(inside:with:) 的原理、算法、子视图遍历顺序，以及可响应条件、自定义命中区域和常见图示。与「响应者链」的传递阶段配合理解，可参见 03-响应者链与 nextResponder 详解。

一、为什么需要 Hit-Testing

触摸发生时，系统需要确定「触摸点落在哪个视图上」，以便将事件交给该视图并进入响应者链。Hit-testing 即在这一阶段，从窗口根视图开始，沿视图层级向下查找最底层且包含该点的视图，该视图将作为该触摸事件的第一响应者（hit-test view）[1]。

二、核心 API

方法	所属	作用
`hitTest(_:with:)`	UIView	在视图树中查找包含指定点的最底层子视图；返回 nil 表示当前视图及其子视图均不接收该点
`point(inside:with:)`	UIView	判断给定点是否在当前视图的 bounds 内（可被重写以扩展或缩小命中区域）

系统从 UIWindow 开始，对根视图调用 hitTest(_:with:)，传入触摸点（已转换为该视图坐标系）。视图内部会先调用 point(inside:with:) 判断点是否在自己范围内，再递归对子视图调用 hitTest(_:with:)。

三、hitTest 算法与伪代码

3.1 可响应前提

视图要参与 hit-test，通常需同时满足（否则当前分支会被剪掉，返回 nil）[[2]][[3]]：

isUserInteractionEnabled == true
isHidden == false
alpha > 0.01

不满足时，hitTest(_:with:) 直接返回 nil，该视图及其子视图都不会成为命中目标。

3.2 系统 hitTest 逻辑（伪代码）

以下为对系统行为的等价描述，便于理解顺序与剪枝逻辑；实际实现以 Apple 源码为准。

函数 hitTest(point, event) -> UIView?:
    若 当前视图 不满足可响应条件（userInteractionEnabled / hidden / alpha）:
        返回 nil

    若 pointInside(point, event) 为 false:
        返回 nil   // 点不在当前视图内，整棵子树不再查找

    // 按子视图「从后往前」顺序遍历（逆序：最后加入的、Z 轴更靠前的先测）
    对 每个 subview 从 subviews.last 到 subviews.first:
        candidate = subview.hitTest( 将 point 转换到 subview 坐标系, event )
        若 candidate != nil:
            返回 candidate   // 找到第一个有返回值的子视图即停止

    若没有子视图命中:
        返回 self   // 点在自己范围内且没有更底层子视图命中，则自己就是 hit-test view

要点：

先判 pointInside：点不在当前视图内则直接返回 nil，整棵子树被剪枝。
子视图逆序：按 subviews 从后往前遍历，即** Z 轴靠前的子视图优先**，与视觉上的「最上层」一致。
第一个非 nil 即返回：找到第一个返回非 nil 的子视图就停止，该子视图即为 hit-test view。

3.3 point(inside:with:) 默认行为

默认实现等价于：判断点是否落在视图的 bounds 内（通常不考虑 subview 的超出部分；且若父视图 clipsToBounds == true，超出父视图 bounds 的子视图区域不会参与父视图的 hit-test，因为点不在父视图 bounds 内会先被剪枝）[[1]]。

函数 pointInside(point, event) -> Bool:
    返回 CGRectContainsPoint(self.bounds, 将 point 转换到当前视图的 bounds 坐标系)

可重写以扩大或缩小可点击区域（如圆形按钮、不规则形状、透明区域穿透等）。

四、事件传递流程（自上而下）

4.1 流程图

flowchart TB
    A[触摸发生] --> B[UIWindow 收到事件]
    B --> C[对根 view 调用 hitTest:withEvent:]
    C --> D{pointInside 为 true?}
    D -->|否| E[返回 nil，该分支结束]
    D -->|是| F[按逆序遍历子视图]
    F --> G[对子视图递归 hitTest]
    G --> H{有子视图返回非 nil?}
    H -->|是| I[返回该子视图 作为 hit-test view]
    H -->|否| J[返回 self]
    I --> K[该 view 成为触摸的 first responder]
    J --> K

4.2 泳道图：Hit-Test 各角色协作

flowchart TB
    subgraph 用户
        U1[手指触摸屏幕]
    end
    subgraph 系统_UIApplication
        S1[事件入队]
        S2[派发至 keyWindow]
    end
    subgraph 系统_UIWindow
        W1[hitTest 根 view]
        W2[得到 hit-test view]
    end
    subgraph 视图层级
        V1[pointInside 判断]
        V2[逆序遍历子视图]
        V3[递归 hitTest]
        V4[返回最终 view]
    end
    U1 --> S1
    S1 --> S2
    S2 --> W1
    W1 --> V1
    V1 --> V2
    V2 --> V3
    V3 --> V4
    V4 --> W2

4.3 Hit-Test 知识结构（思维导图）

mindmap
  root((Hit-Test))
    入口
      UIWindow 根视图
      hitTest:withEvent:
    条件
      userInteractionEnabled
      hidden / alpha
      pointInside
    遍历
      子视图逆序
      Z 轴优先
    结果
      hit-test view
      first responder
    自定义
      扩大热区
      穿透
      不规则区域

五、子视图顺序与 Z 轴

子视图在 subviews 数组中的索引越大，在 hit-test 时越先被遍历，因此后加入的、索引更大的子视图会优先被命中，与它们在屏幕上的「盖在上面」一致。若两个子视图重叠，则上面那一层会先被 hitTest 到并成为 hit-test view。

flowchart LR
    subgraph 视图层级
        V[父视图]
        V --> A[子视图 A index 0]
        V --> B[子视图 B index 1]
        V --> C[子视图 C index 2]
    end
    subgraph hitTest 顺序
        C --> B
        B --> A
    end

六、clipsToBounds 与命中

pointInside 只判断点是否在当前视图的 bounds 内。
若父视图设置了 clipsToBounds = true，子视图超出父视图 bounds 的部分会被裁剪掉显示，但 hit-test 仍按 bounds 判断：若触摸点落在父视图 bounds 外（即使落在子视图的 frame 内），父视图的 pointInside 会返回 false，整棵子树不会参与命中 [[1]]。
因此：子视图若超出父视图 bounds 且父视图 clipsToBounds，超出部分在默认实现下无法被 hit-test 命中，除非在父视图层重写 point(inside:with:) 或 hitTest(_:with:) 做特殊处理。

七、自定义 hitTest / pointInside 的常见用法

需求	做法
扩大点击区域	重写 `point(inside:with:)`，对中心区域做扩展（如上下左右各扩展 44pt）
透明区域不响应	重写 `point(inside:with:)`，根据像素透明度返回 false
让触摸「穿透」到下层	重写 `hitTest(_:with:)`，在特定条件下返回 nil，使当前视图不参与命中
指定子视图优先	重写 `hitTest(_:with:)`，自定义遍历顺序或强制返回某子视图

示例（扩大点击区域）：

override func point(inside point: CGPoint, with event: UIEvent?) -> Bool {
    let inset: CGFloat = -20
    return bounds.insetBy(dx: inset, dy: inset).contains(point)
}

商用场景示例：商品列表 Cell 内「加购」「收藏」等小图标，视觉约 24pt，为提升点击率将热区扩大到 44pt，重写该图标的容器 view 或子类的 point(inside:with:) 即可。

穿透示例（浮层不拦截、点击落到下层）：

/// 用于半透明遮罩：触摸不消费，交给下层视图（如背后的列表、按钮）
class PassThroughView: UIView {
    override func hitTest(_ point: CGPoint, with event: UIEvent?) -> UIView? {
        let hit = super.hitTest(point, with: event)
        return hit == self ? nil : hit  // 若命中自己则返回 nil，让下层接收
    }
}

商用场景示例：活动弹窗关闭后残留半透明遮罩，希望点击遮罩空白处能穿透到下层（如关闭按钮、跳过）；或直播/视频上的礼物动画层不拦截点击，让下层进度条、点赞可点。

Swift 完整示例：可复用的「扩大热区」UIView 子类（适用于任意按钮/图标）：

/// 将子视图的可点击区域向外扩展，不改变视觉 frame
final class ExpandHitAreaView: UIView {
    var hitAreaInset: UIEdgeInsets = .zero  // 负值表示扩大，如 (-10,-10,-10,-10)
    override func point(inside point: CGPoint, with event: UIEvent?) -> Bool {
        bounds.inset(by: hitAreaInset).contains(point)
    }
}
// 使用：将按钮包在 ExpandHitAreaView 内，设置 hitAreaInset = UIEdgeInsets(top: -10, left: -10, bottom: -10, right: -10)

八、与响应者链的衔接

hit-test 得到的是触摸事件的第一响应者（某个 UIView）。触摸事件会先发给该视图（及其上的手势识别器）；若视图未处理或未实现 touchesBegan 等，事件会沿 nextResponder 向上传递。因此：

阶段一（本文）：hit-test，自顶向下，确定「谁被点中」。
阶段二：响应者链，自底向上，确定「谁处理」。详见 03-响应者链与 nextResponder 详解。

参考文献

[1] Using responders and the responder chain to handle events - Determine which responder contained a touch event
[2] Event handling for iOS - hitTest:withEvent: and pointInside:withEvent:
[3] HitTest and UIResponder in iOS (Medium)

尝试给Lookin 支持 MCP

掘金 iOS

FeliksLv

2026年3月1日 22:33

不知道大家在 Vibe Coding 的时候，是否经常遇到这样的情况，让 AI 修改一个复杂页面，改完之后发现布局乱了，只能通过文字描述让 AI 去改，还经常改不对。

在日常开发中，我们经常会使用 Lookin 来查看布局，我想能否给 Lookin 支持 MCP 查看布局+刷新。这样是不是就不用我们自己给 AI 描述问题了。

于是我开始了这个集成工作，用本文记录下整个过程。先放下最终效果：

Lookin MCP 支持的所有方法

#	方法名	描述	参数
1	get_status	获取 Lookin 服务器状态和连接状态，返回是否有 iOS 应用连接以及是否有层级数据	无
2	list_apps	列出所有连接的 iOS 应用及其基本信息	无
3	get_hierarchy	获取已连接 iOS 应用的完整视图层级，返回所有视图及其属性、frame 和关系	flat: bool (可选) - 是否返回扁平数组 maxDepth: int (可选) - 最大遍历深度
4	get_view	通过 oid 获取指定视图的详细信息，包括 frame、bounds、类继承链等	oid: int (必需) - 视图对象 ID
5	get_screenshot	获取指定视图的截图，返回 base64 编码的 PNG 图片	oid: int (必需) - 视图对象 ID
6	search_views	按类名、文字内容或 oid 搜索视图	query: string (必需) - 搜索关键词 type: enum (可选) - 搜索类型: "class"/"text"/"oid"
7	list_viewcontrollers	列出应用中所有的 ViewController，包括类名、内存地址和关联的视图 oid	无
8	get_app_info	获取已连接 iOS 应用的详细信息，包括应用名、Bundle ID、设备名、OS 版本、屏幕尺寸	无
9	reload_hierarchy	重新加载视图层级数据，用于 UI 变化后刷新数据	无
10	get_view_attributes	获取视图的完整属性详情，包括所有属性组（Layout、AutoLayout、UILabel、UIScrollView 等）、事件处理器（手势、target-action）和 AutoLayout 约束	oid: int (必需) - 视图对象 ID

第一版-双进程

MCP 协议要求 Server 通过 stdio（标准输入/输出）与 Client 通信，这对于 GUI 应用来说是个问题：

macOS GUI 应用没有 stdin/stdout
GUI 应用不适合作为子进程被其他应用启动
Lookin 需要保持独立运行以维护与 iOS 设备的连接

所以第一版采用双进程架构：一个独立的命令行工具 lookin-mcp 处理 MCP 协议，通过 HTTP 与 Lookin 主应用通信。

sequenceDiagram
    participant AI as AI 工具
    participant MCP as lookin-mcp
    participant HTTP as LKMCPServer
    participant iOS as iOS App
    
    Note over AI,MCP: stdio (JSON-RPC)
    Note over MCP,HTTP: HTTP (REST)
    Note over HTTP,iOS: Peertalk/Bonjour
    
    AI->>MCP: tools/call (get_hierarchy)
    MCP->>HTTP: GET /hierarchy
    HTTP->>iOS: 获取视图数据
    iOS-->>HTTP: LookinHierarchyInfo
    HTTP-->>MCP: JSON Response
    MCP-->>AI: Tool Result

组件	角色	通信方式
`lookin-mcp`	MCP Server	stdio (JSON-RPC)
`LKMCPServer`	HTTP Server	HTTP REST API
Lookin.app	主应用	内嵌 HTTP Server

实现细节

1. 手写 MCP 协议

MCP 协议基于 JSON-RPC 2.0，需要实现请求/响应的解析和序列化：

struct JSONRPCRequest: Codable {
    let jsonrpc: String
    let id: RequestId?
    let method: String
    let params: AnyCodable?
}

struct JSONRPCResponse: Codable {
    let jsonrpc: String
    let id: RequestId?
    let result: AnyCodable?
    let error: JSONRPCError?
}

2. HTTP Server (LKMCPServer)

在 Lookin 主应用中内嵌一个轻量级 HTTP Server，监听 127.0.0.1:47199：

@implementation LKMCPServer

- (void)start {
    self.server = [[GCDWebServer alloc] init];
    
    // GET /status - 检查连接状态
    [self.server addHandlerForMethod:@"GET" path:@"/status" 
        requestClass:[GCDWebServerRequest class]
        processBlock:^GCDWebServerResponse *(GCDWebServerRequest *request) {
            return [self handleStatusRequest];
        }];
    
    // GET /hierarchy - 获取视图层级
    [self.server addHandlerForMethod:@"GET" path:@"/hierarchy" ...];
    
    // POST /reload - 刷新数据
    [self.server addHandlerForMethod:@"POST" path:@"/reload" ...];
    
    [self.server startWithPort:47199 bonjourName:nil];
}

@end

3. MCP Tools 定义

第一版实现了 8 个 Tools：

Tool	描述	HTTP 映射
`status`	检查连接状态	GET /status
`get_hierarchy`	获取视图层级	GET /hierarchy
`get_view`	获取视图详情	GET /view/:oid
`search`	搜索视图	GET /search?q=&type=
`get_screenshot`	获取视图截图	GET /screenshot/:oid
`get_app_info`	获取应用信息	GET /app-info
`list_view_controllers`	列出 VC	GET /viewcontrollers
`reload`	刷新层级数据	POST /reload

4. 构建和部署

需要在 Xcode Build Phase 中添加脚本，将 lookin-mcp 复制到 app bundle：

# Scripts/build_mcp.sh
cd "${SRCROOT}/LookinMCP"
swift build -c release

mkdir -p "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Contents/Helpers"
cp ".build/release/lookin-mcp" "${BUILT_PRODUCTS_DIR}/${PRODUCT_NAME}.app/Contents/Helpers/"

通信流程

启动流程：

sequenceDiagram
    participant User as 用户
    participant Lookin as Lookin.app
    participant Pref as LKPreferenceManager
    participant HTTP as LKMCPServer
    
    User->>Lookin: 启动应用
    Lookin->>Pref: 读取 enableMCPServer
    alt MCP Server 已启用
        Pref-->>Lookin: YES
        Lookin->>HTTP: start()
        HTTP-->>Lookin: 监听 127.0.0.1:47199
    else MCP Server 已禁用
        Pref-->>Lookin: NO
        Note over HTTP: 不启动
    end

查询流程：

sequenceDiagram
    participant AI as AI 工具
    participant MCP as lookin-mcp
    participant HTTP as LKMCPServer
    participant DS as DataSource
    
    AI->>MCP: {"method": "tools/call", "params": {"name": "get_hierarchy"}}
    MCP->>HTTP: GET http://127.0.0.1:47199/hierarchy
    HTTP->>DS: flatItems
    DS-->>HTTP: [LookinDisplayItem]
    HTTP-->>MCP: {"views": [...], "total": 150}
    MCP-->>AI: {"content": [{"type": "text", "text": "..."}]}

使用方式

以OpenCode为例，修改 ～/.config/opencode/opencode.json：

{
  "mcp": {
    "lookin": {
        "type": "local",
        "command": "/Applications/Lookin.app/Contents/Helpers/lookin-mcp"
    }
  }
}

运行试了一下，可以拿到对应节点的视图信息。

第一版的问题

虽然能用，但有几个不太满意的地方：

双进程架构复杂 - 需要维护两套代码，调试也麻烦
手写协议不可靠 - MCP 协议还在演进，手写实现容易出 bug
部署麻烦 - 需要在 Build Phase 中复制二进制文件
配置繁琐 - 用户需要手动修改 JSON 配置文件

第二版

MCP 是有 Swift 版本官方 SDK 的：

github.com/modelcontex…

既然有官方 SDK，为什么还要自己手写协议呢？而且第一版的双进程架构也有点复杂。于是我决定重构，目标是：

使用官方 Swift SDK 替换手写的 MCP 协议实现
将 MCP Server 内嵌到 Lookin 主应用，去掉独立进程
使用 HTTP Transport，简化用户配置

新架构

graph TB
    subgraph "AI 工具"
        AI[OpenCode / Claude / Cursor ...]
    end
    
    subgraph "Lookin.app"
        HTTP[NIO HTTP Server<br/>:47199/mcp]
        MCP[MCP Server<br/>官方 Swift SDK]
        DS[LKStaticHierarchyDataSource]
        Apps[LKAppsManager]
    end
    
    subgraph "iOS App"
        LookinServer[LookinServer SDK]
    end
    
    AI <-->|HTTP<br/>MCP Protocol| HTTP
    HTTP --> MCP
    MCP --> DS
    MCP --> Apps
    Apps <-->|USB/WiFi| LookinServer

对比一下两个版本：

对比项	第一版	第二版
协议实现	手写 JSON-RPC	官方 Swift SDK
进程模型	双进程 (stdio + HTTP)	单进程 (内嵌 HTTP)
通信方式	stdio → HTTP → 数据源	HTTP → 数据源
配置方式	修改配置文件	一行命令
依赖管理	复制二进制到 app bundle	SPM 本地 Package

SDK 选型

官方 SDK 版本 0.11.0 支持多种 Transport：

StdioServerTransport: 传统的 stdio 方式
StreamableHTTPServerTransport: 有状态的 HTTP 流式传输
StatelessHTTPServerTransport: 无状态 HTTP，适合简单场景

我选择了 StatelessHTTPServerTransport，因为 Lookin 的场景不需要维护会话状态，每次请求都是独立的查询。

实现细节

1. LookinMCP Package 结构

重构后的 Package 变得更简洁：

LookinMCP/
├── Package.swift                    # SPM 配置，依赖官方 SDK
└── Sources/LookinMCP/
    ├── LookinMCPDataSource.swift    # 数据源协议 + 模型定义
    ├── LookinMCPServer.swift        # HTTP Server + MCP Server
    └── LookinMCPToolHandler.swift   # 9 个 Tools 的注册和处理

Package.swift 配置：

// swift-tools-version: 6.1
import PackageDescription

let package = Package(
    name: "LookinMCP",
    platforms: [.macOS(.v13)],
    products: [
        .library(name: "LookinMCP", targets: ["LookinMCP"]),
    ],
    dependencies: [
        .package(url: "https://github.com/modelcontextprotocol/swift-sdk.git", from: "0.11.0"),
    ],
    targets: [
        .target(
            name: "LookinMCP",
            dependencies: [
                .product(name: "MCP", package: "swift-sdk"),
            ]
        ),
    ]
)

2. HTTP Server 实现

SDK 提供了 StatelessHTTPServerTransport，但需要自己搭建 HTTP Server。参考 SDK 示例，使用 swift-nio：

public func start() async throws {
    let bootstrap = ServerBootstrap(group: eventLoopGroup)
        .serverChannelOption(.backlog, value: 256)
        .childChannelInitializer { channel in
            channel.pipeline.configureHTTPServerPipeline().flatMap {
                channel.pipeline.addHandler(HTTPHandler(transport: self.transport))
            }
        }
    
    let channel = try await bootstrap.bind(host: host, port: port).get()
    // Server started on http://127.0.0.1:47199/mcp
}

3. Tool 注册

使用 SDK 的 withMethodHandler API 注册 Tools：

await server.withMethodHandler(ListTools.self) { _ in
    ListToolsResult(tools: [
        Tool(name: "status", description: "Check Lookin connection status"),
        Tool(name: "get_hierarchy", description: "Get view hierarchy", inputSchema: ...),
        // ... 更多 tools
    ])
}

await server.withMethodHandler(CallTool.self) { params in
    switch params.name {
    case "status":
        let status = await dataSource.getStatus()
        return CallToolResult(content: [.text(status.toJSON())])
    case "get_hierarchy":
        // ...
    }
}

4. 主应用集成

在 AppDelegate.m 中启动 MCP Server：

if ([LKPreferenceManager mainManager].enableMCPServer) {
    [[MCPServerManager shared] start];
}

MCPServerManager 是一个 Swift 类，提供 @objc 接口供 Obj-C 调用：

@objc(MCPServerManager)
@MainActor
final class MCPServerManager: NSObject {
    @objc static let shared = MCPServerManager()
    
    @objc func start() {
        Task {
            let server = try await LookinMCPServer(dataSource: dataProvider, port: 47199)
            try await server.start()
        }
    }
}

使用方式

对于 OpenCode：

// .config/opencode/opencode.json
{
    // ...
  "mcp": {
    "lookin": {
      "type": "remote",
      "url": "http://127.0.0.1:47199/mcp",
      "enabled": true
    }
  }
}

对于 Claude Code：

claude mcp add --transport http lookin http://127.0.0.1:47199/mcp

然后就可以直接使用了：

现在可以愉快地让 AI 帮我看布局、找问题了！

代码放在 fork 的仓库里：github.com/FeliksLv01/…

01-研究系统框架@Web@iOS | JavaScriptCore 框架：从使用到原理解析

掘金 iOS

没有故事的Zhang同学

2026年3月1日 20:10

JavaScriptCore 框架：从使用到原理解析

JavaScript 越来越多地出现在我们客户端开发的视野中，从 React Native 到 JSPatch，JavaScript 与客户端相结合的技术开始变得魅力无穷。本文主要讲解 iOS 中的 JavaScriptCore 框架，正是它为 iOS 提供了执行 JavaScript 代码的能力。未来的技术日新月异，JavaScript 与 iOS 正在碰撞出新的激情。

JavaScriptCore 是 JavaScript 的虚拟机，为 JavaScript 的执行提供底层资源。

📋 目录

一、JavaScript

在讨论JavaScriptCore之前，我们首先必须对JavaScript有所了解。

1. JavaScript干啥的？

说的高大上一点：一门基于原型、函数先行的高级编程语言，通过解释执行，是动态类型的直译语言。是一门多范式的语言，它支持面向对象编程，命令式编程，以及函数式编程。
说的通俗一点：主要用于网页，为其提供动态交互的能力。可嵌入动态文本于HTML页面，对浏览器事件作出响应，读写HTML元素，控制cookies等。
再通俗一点：抢月饼，button.click()。（PS：请谨慎使用while循环）

2. JavaScript起源与历史

1990年底，欧洲核能研究组织（CERN）科学家Tim Berners-Lee，在互联网的基础上，发明了万维网（World Wide Web），从此可以在网上浏览网页文件。
1994年12月，Netscape 发布了一款面向普通用户的新一代的浏览器Navigator 1.0版，市场份额一举超过90%。
1995年，Netscape公司雇佣了程序员Brendan Eich开发这种嵌入网页的脚本语言。最初名字叫做Mocha，1995年9月改为LiveScript。
1995年12月，Netscape公司与Sun公司达成协议，后者允许将这种语言叫做JavaScript。

3. JavaScript与ECMAScript

“JavaScript”是Sun公司的注册商标，用来特制网景（现在的Mozilla）对于这门语言的实现。网景将这门语言作为标准提交给了ECMA——欧洲计算机制造协会。由于商标上的冲突，这门语言的标准版本改了一个丑陋的名字“ECMAScript”。同样由于商标的冲突，微软对这门语言的实现版本取了一个广为人知的名字“Jscript”。
ECMAScript作为JavaScript的标准，一般认为后者是前者的实现。

4. Java和JavaScript

《雷锋和雷峰塔》

Java 和 JavaScript 是两门不同的编程语言一般认为，当时 Netscape 之所以将 LiveScript 命名为 JavaScript，是因为 Java 是当时最流行的编程语言，带有 “Java” 的名字有助于这门新生语言的传播。

二、 JavaScriptCore

1. 浏览器演进

演进完整图

upload.wikimedia.org/wikipedia/c…

WebKit分支

现在使用WebKit的主要两个浏览器Sfari和Chromium（Chorme的开源项目）。WebKit起源于KDE的开源项目Konqueror的分支，由苹果公司用于Sfari浏览器。其一条分支发展成为Chorme的内核，2013年Google在此基础上开发了新的Blink内核。

2. WebKit排版引擎

webkit是sfari、chrome等浏览器的排版引擎，各部分架构图如下

webkit Embedding API是browser UI与webpage进行交互的api接口；
platformAPI提供与底层驱动的交互，如网络，字体渲染，影音文件解码，渲染引擎等；
WebCore它实现了对文档的模型化，包括了CSS, DOM, Render等的实现；
JSCore是专门处理JavaScript脚本的引擎；

3. JavaScript引擎

JavaScript引擎是专门处理JavaScript脚本的虚拟机，一般会附带在网页浏览器之中。第一个JavaScript引擎由布兰登·艾克在网景公司开发，用于Netscape Navigator网页浏览器中。JavaScriptCore就是一个JavaScript引擎。
下图是当前主要的还在开发中的JavaScript引擎

4. JavaScriptCore组成

JavaScriptCore主要由以下模块组成：

Lexer 词法分析器，将脚本源码分解成一系列的Token
Parser 语法分析器，处理Token并生成相应的语法树
LLInt 低级解释器，执行Parser生成的二进制代码
Baseline JIT 基线JIT（just in time 实施编译）
DFG 低延迟优化的JIT
FTL 高通量优化的JIT

关于更多JavaScriptCore的实现细节，参考 trac.webkit.org/wiki/JavaSc…

5. JavaScriptCore 框架与历史

JavaScriptCore 是一个 C++ 实现的开源项目（WebKit 的一部分）。历史上，JSC 长期作为 Safari / WebKit 的内置 JS 引擎；自 iOS 7.0 / OS X 10.9 起，Apple 将 JavaScriptCore 以系统框架 JavaScriptCore.framework 的形式开放给开发者，使其可在 Objective-C 或基于 C 的程序中执行 JavaScript 代码，并向 JS 环境中插入自定义对象，而无需依赖 UIWebView。这为 Hybrid 应用、热更新、脚本引擎等场景提供了统一的底层能力。

在 JavaScriptCore.h 中，我们可以看到：

#ifndef JavaScriptCore_h
#define JavaScriptCore_h

#include <JavaScriptCore/JavaScript.h>
#include <JavaScriptCore/JSStringRefCF.h>

#if defined(__OBJC__) && JSC_OBJC_API_ENABLED

#import "JSContext.h"
#import "JSValue.h"
#import "JSManagedValue.h"
#import "JSVirtualMachine.h"
#import "JSExport.h"

#endif

#endif /* JavaScriptCore_h */

这里已经很清晰地列出了JavaScriptCore的主要几个类：

JSContext
JSValue
JSManagedValue
JSVirtualMachine
JSExport

接下来我们会依次讲解这几个类的用法。

6. Hello World！

这段代码展示了如何在 Objective-C 中执行一段 JavaScript 代码，并且获取返回值并转换成 OC 数据打印：

// 创建虚拟机
JSVirtualMachine *vm = [[JSVirtualMachine alloc] init];

//创建上下文
JSContext *context = [[JSContext alloc] initWithVirtualMachine:vm];

//执行JavaScript代码并获取返回值
JSValue *value = [context evaluateScript:@"1+2*3"];

// 转换成 OC 数据并打印
NSLog(@"value = %d", [value toInt32]);
// Output: value = 7

Swift 等价写法：

import JavaScriptCore

let vm = JSVirtualMachine()!
let context = JSContext(virtualMachine: vm)!
let value = context.evaluateScript("1 + 2 * 3")!
print("value =", value.toInt32())  // value = 7

三、 JSVirtualMachine

一个JSVirtualMachine的实例就是一个完整独立的JavaScript的执行环境，为JavaScript的执行提供底层资源。

这个类主要用来做两件事情：

实现并发的 JavaScript 执行
JavaScript 和 Objective-C 桥接对象的内存管理

看下头文件 JSVirtualMachine.h 里有什么：

NS_CLASS_AVAILABLE(10_9, 7_0)
@interface JSVirtualMachine : NSObject

/* 创建一个新的完全独立的虚拟机 */
(instancetype)init;

/* 对桥接对象进行内存管理 */
- (void)addManagedReference:(id)object withOwner:(id)owner;

/* 取消对桥接对象的内存管理 */
- (void)removeManagedReference:(id)object withOwner:(id)owner;

@end

每一个JavaScript上下文（JSContext对象）都归属于一个虚拟机（JSVirtualMachine）。每个虚拟机可以包含多个不同的上下文，并允许在这些不同的上下文之间传值（JSValue对象）。

然而，每个虚拟机都是完整且独立的，有其独立的堆空间和垃圾回收器（garbage collector ），GC无法处理别的虚拟机堆中的对象，因此你不能把一个虚拟机中创建的值传给另一个虚拟机。

线程和JavaScript的并发执行

JavaScriptCore API都是线程安全的。你可以在任意线程创建JSValue或者执行JS代码，然而，所有其他想要使用该虚拟机的线程都要等待。

如果想并发执行JS，需要使用多个不同的虚拟机来实现。
可以在子线程中执行JS代码。

通过下面这个 demo 来理解这个并发机制：

JSContext *context = [[CustomJSContext alloc] init];
JSContext *context1 = [[CustomJSContext alloc] init];
JSContext *context2 = [[CustomJSContext alloc] initWithVirtualMachine:[context virtualMachine]];
NSLog(@"start");
dispatch_async(queue, ^{
    while (true) {
        sleep(1);
        [context evaluateScript:@"log('tick')"];
    }
});
dispatch_async(queue1, ^{
    while (true) {
        sleep(1);
        [context1 evaluateScript:@"log('tick_1')"];
    }
});
dispatch_async(queue2, ^{
    while (true) {
        sleep(1);
        [context2 evaluateScript:@"log('tick_2')"];
    }
});
[context evaluateScript:@"sleep(5)"];
NSLog(@"end");

context和context2属于同一个虚拟机。

context1属于另一个虚拟机。

三个线程分别异步执行每秒1次的js log，首先会休眠1秒。

在context上执行一个休眠5秒的JS函数。

首先执行的应该是休眠5秒的JS函数，在此期间，context所处的虚拟机上的其他调用都会处于等待状态，因此tick和tick_2在前5秒都不会有执行。

而context1所处的虚拟机仍然可以正常执行tick_1。

休眠5秒结束后，tick和tick_2才会开始执行（不保证先后顺序）。

实际运行输出的 log 是：

start
tick_1
tick_1
tick_1
tick_1
end
tick
tick_2

四、 JSContext

一个JSContext对象代表一个JavaScript执行环境。在native代码中，使用JSContext去执行JS代码，访问JS中定义或者计算的值，并使JavaScript可以访问native的对象、方法、函数。

1. JSContext执行JS代码

调用evaluateScript函数可以执行一段top-level 的JS代码，并可向global对象添加函数和对象定义
其返回值是JavaScript代码中最后一个生成的值

API Reference

NS_CLASS_AVAILABLE(10_9, 7_0)
@interface JSContext : NSObject

/* 创建一个JSContext，同时会创建一个新的JSVirtualMachine */
(instancetype)init;

/* 在指定虚拟机上创建一个JSContext */
(instancetype)initWithVirtualMachine:
        (JSVirtualMachine*)virtualMachine;

/* 执行一段JS代码，返回最后生成的一个值 */
(JSValue *)evaluateScript:(NSString *)script;

/* 执行一段JS代码，并将sourceURL认作其源码URL（仅作标记用） */
- (JSValue *)evaluateScript:(NSString *)script withSourceURL:(NSURL*)sourceURL     NS_AVAILABLE(10_10, 8_0);

/* 获取当前执行的JavaScript代码的context */
+ (JSContext *)currentContext;

/* 获取当前执行的JavaScript function*/
+ (JSValue *)currentCallee NS_AVAILABLE(10_10, 8_0);

/* 获取当前执行的JavaScript代码的this */
+ (JSValue *)currentThis;

/* Returns the arguments to the current native callback from JavaScript code.*/
+ (NSArray *)currentArguments;

/* 获取当前context的全局对象。WebKit中的context返回的便是WindowProxy对象*/
@property (readonly, strong) JSValue *globalObject;

@property (strong) JSValue *exception;
@property (copy) void(^exceptionHandler)(JSContext *context, JSValue
    *exception);

@property (readonly, strong) JSVirtualMachine *virtualMachine;

@property (copy) NSString *name NS_AVAILABLE(10_10, 8_0);


@end

2. JSContext访问JS对象

一个JSContext对象对应了一个全局对象（global object）。例如web浏览器中中的JSContext，其全局对象就是window对象。在其他环境中，全局对象也承担了类似的角色，用来区分不同的JavaScript context的作用域。全局变量是全局对象的属性，可以通过JSValue对象或者context下标的方式来访问。

示例代码：

JSValue *value = [context evaluateScript:@"var a = 1+2*3;"];

NSLog(@"a = %@", [context objectForKeyedSubscript:@"a"]);
NSLog(@"a = %@", [context.globalObject objectForKeyedSubscript:@"a"]);
NSLog(@"a = %@", context[@"a"]);
// Output: a = 7, a = 7, a = 7

这里列出了三种访问JavaScript对象的方法

通过context的实例方法objectForKeyedSubscript
通过context.globalObject的objectForKeyedSubscript实例方法
通过下标方式

设置属性也是对应的。

API Reference

/* 为 JSContext 提供下标访问元素的方式 */
@interface JSContext (SubscriptSupport)

/* 首先将key转为JSValue对象，然后使用这个值在JavaScript context的全局对象中查找这个名字的属性并返回 */
(JSValue *)objectForKeyedSubscript:(id)key;

/* 首先将key转为JSValue对象，然后用这个值在JavaScript context的全局对象中设置这个属性。
可使用这个方法将native中的对象或者方法桥接给JavaScript调用 */
(void)setObject:(id)object forKeyedSubscript:(NSObject <NSCopying>*)key;

@end



/* 例如：以下代码在JavaScript中创建了一个实现是Objective-C block的function */
context[@"makeNSColor"] = ^(NSDictionary *rgb){
    float r = [rgb[@"red"] floatValue];
    float g = [rgb[@"green"] floatValue];
    float b = [rgb[@"blue"] floatValue];
    return [NSColor colorWithRed:(r / 255.f) green:(g / 255.f) blue:(b / 255.f)         alpha:1.0];
};
JSValue *value = [context evaluateScript:@"makeNSColor({red:12, green:23, blue:67})"];

五、 JSValue

一个JSValue实例就是一个JavaScript值的引用。使用JSValue类在JavaScript和native代码之间转换一些基本类型的数据（比如数值和字符串）。你也可以使用这个类去创建包装了自定义类的native对象的JavaScript对象，或者创建由native方法或者block实现的JavaScript函数。

每个JSValue实例都来源于一个代表JavaScript执行环境的JSContext对象，这个执行环境就包含了这个JSValue对应的值。每个JSValue对象都持有其JSContext对象的强引用，只要有任何一个与特定JSContext关联的JSValue被持有（retain），这个JSContext就会一直存活。通过调用JSValue的实例方法返回的其他的JSValue对象都属于与最始的JSValue相同的JSContext。

每个JSValue都通过其JSContext间接关联了一个特定的代表执行资源基础的JSVirtualMachine对象。你只能将一个JSValue对象传给由相同虚拟机管理（host）的JSValue或者JSContext的实例方法。如果尝试把一个虚拟机的JSValue传给另一个虚拟机，将会触发一个Objective-C异常。

1. JSValue类型转换

JSValue提供了一系列的方法将native与JavaScript的数据类型进行相互转换：

2. NSDictionary与JS对象

NSDictionary 对象以及其包含的 keys 与 JavaScript 中的对应名称的属性相互转换。key 所对应的值也会递归地进行拷贝和转换。

[context evaluateScript:@"var color = {red:230, green:90, blue:100}"];

//js->native 给你看我的颜色
JSValue *colorValue = context[@"color"];
NSLog(@"r=%@, g=%@, b=%@", colorValue[@"red"], colorValue[@"green"], colorValue[@"blue"]);
NSDictionary *colorDic = [colorValue toDictionary];
NSLog(@"r=%@, g=%@, b=%@", colorDic[@"red"], colorDic[@"green"], colorDic[@"blue"]);

//native->js 给你点颜色看看
context[@"color"] = @{@"red":@(0), @"green":@(0), @"blue":@(0)};
[context evaluateScript:@"log('r:'+color.red+'g:'+color.green+' b:'+color.blue)"];
// Output:
// r=230, g=90, b=100
// r=230, g=90, b=100
// r:0 g:0 b:0

可见，JS中的对象可以直接转换成Objective-C中的NSDictionary，NSDictionary传入JavaScript也可以直接当作对象被使用。

3. NSArray与JS数组

NSArray 对象与 JavaScript 中的 array 相互转换。其子元素也会递归地进行拷贝和转换。

[context evaluateScript:@"var friends = ['Alice','Jenny','XiaoMing']"];

//js->native 你说哪个是真爱？
JSValue *friendsValue = context[@"friends"];
NSLog(@"%@, %@, %@", friendsValue[0], friendsValue[1], friendsValue[2]);
NSArray *friendsArray = [friendsValue toArray];
NSLog(@"%@, %@, %@", friendsArray[0], friendsArray[1], friendsArray[2]);

//native->js 我觉得 XiaoMing 不错，给你再推荐个 Jimmy
context[@"girlFriends"] = @[friendsArray[2], @"Jimmy"];
[context evaluateScript:@"log('girlFriends :'+girlFriends[0]+' '+girlFriends[1])"];
// Output: Alice, Jenny, XiaoMing / girlFriends : XiaoMing Jimmy

4. Block/函数和JS function

Objective-C中的block转换成JavaScript中的function对象。参数以及返回类型使用相同的规则转换。

将一个代表native的block或者方法的JavaScript function进行转换将会得到那个block或方法。

其他的JavaScript函数将会被转换为一个空的dictionary。因为JavaScript函数也是一个对象。

5. OC对象和JS对象

对于所有其他 native 的对象类型，JavaScriptCore 都会创建一个拥有 constructor 原型链的 wrapper 对象，用来反映 native 类型的继承关系。默认情况下，native 对象的属性和方法并不会导出给其对应的 JavaScript wrapper 对象。通过 JSExport 协议可选择性地导出属性和方法。下面第六节对 JSExport 与原生对象导出做详细讲解。

六、JSExport 与原生对象导出

JSExport 是 JavaScriptCore 框架中的协议，用于将 Objective-C/Swift 的类（属性与方法）选择性导出给 JavaScript，使 JS 代码可以像调用普通对象一样调用原生对象 [1][2]。

6.1 作用与机制

遵循 JSExport 的协议中声明的属性和方法，会在将 native 对象注入到 JSContext（如 context[@"bridge"] = nativeObject）时，自动暴露为 JS 侧的属性和函数。
若类未实现 JSExport 或未在协议中声明，则对应属性/方法不会出现在 JS 中；这样可控制「桥接面」，避免暴露内部实现 [1][2]。

6.2 使用示例（概念）

@protocol MyPointExport <JSExport>
@property (nonatomic, assign) double x;
@property (nonatomic, assign) double y;
- (NSString *)description;
@end

@interface MyPoint : NSObject <MyPointExport>
@property (nonatomic, assign) double x;
@property (nonatomic, assign) double y;
@end

将 MyPoint 实例赋给 context[@"point"] 后，在 JS 中可访问 point.x、point.y 并调用 point.description()。
注意：若在 Block 或导出方法中再次使用 JSValue 或 JSContext，需注意线程与内存管理（见第七节 JSManagedValue）[1][2]。

Swift 中的等价写法（通过 JSContext 注入遵循 JSExport 的类）：

import JavaScriptCore

@objc protocol PointExport: JSExport {
    var x: Double { get set }
    var y: Double { get set }
    func description() -> String
}

class Point: NSObject, PointExport {
    @objc var x: Double
    @objc var y: Double
    init(x: Double, y: Double) { self.x = x; self.y = y }
    func description() -> String { "Point(\(x), \(y))" }
}

// 注入到 context
let context = JSContext()!
context.setObject(Point(x: 1, y: 2), forKeyedSubscript: "point" as NSString)
context.evaluateScript("point.x; point.description()")

6.3 与 Block 注入的对比

方式	适用场景
context[@"fn"] = ^(id arg){ ... }	单次或简单逻辑，直接暴露为 JS 函数
JSExport 协议 + 原生对象	需要暴露多个方法/属性、保持对象身份与状态的「桥接对象」

七、JSManagedValue 与内存管理

7.1 为何需要 JSManagedValue

JSValue 对 JSContext 有强引用；JSContext 又挂在 JSVirtualMachine 上。
若在 堆上的 OC 对象（如某 ViewController 的 property）中直接强引用 JSValue，而该 JSValue 通过某种方式（例如被注入到 context 的全局对象）又引用回该 OC 对象，会形成 OC ↔ JS 的循环引用，导致 Context 与 OC 对象均无法释放 [1][2]。

7.2 JSManagedValue 的职责

JSManagedValue 是 JSValue 的包装类，用于在「被 OC 堆对象持有」的场景下，以条件保留的方式引用 JS 值，并可与 JSVirtualMachine 的 addManagedReference:withOwner: / removeManagedReference:withOwner: 配合，让虚拟机在合适的时机断开或保留对 native 对象的引用，从而打破循环、避免 JSContext 无法释放 [1][2]。

7.3 使用要点（概念）

当需要把 JSValue（或从 JS 传回的函数/对象）存为 OC 对象的成员变量时，应使用 JSManagedValue 包装，并以 owner 注册到 JSVirtualMachine；在 owner 析构或不再需要时调用 removeManagedReference:withOwner: [1][2]。
仅临时在栈上使用 JSValue（如 evaluateScript 的返回值在方法内使用后不再持有）时，一般无需 JSManagedValue。

八、关键概念图示与流程

8.1 VM、Context、Value 关系

flowchart TB
  subgraph VM1[JSVirtualMachine 1]
    C1[JSContext 1]
    C2[JSContext 2]
  end
  subgraph VM2[JSVirtualMachine 2]
    C3[JSContext 3]
  end
  C1 --> V1[JSValue]
  C2 --> V2[JSValue]
  C1 -.->|可传值| C2
  C1 -.->|不可跨 VM| C3

同一 JSVirtualMachine 下多个 JSContext 可共享、传递 JSValue；不同 VM 之间不能传递 JSValue [3]。

8.2 JavaScriptCore 引擎执行层级（概念）

源码经 Lexer → Parser 得到语法树并生成字节码后，由下至上的执行/编译层级可概括为：

flowchart LR
  A[源码] --> B[Lexer]
  B --> C[Parser / AST]
  C --> D[字节码]
  D --> E[LLInt 解释器]
  E --> F[Baseline JIT]
  F --> G[DFG JIT]
  G --> H[FTL JIT]

LLInt：低级解释器，低延迟启动。
Baseline JIT：首次 JIT，兼顾分析与回退。
DFG：基于数据流的优化 JIT。
FTL：更高优化层（历史上曾用 LLVM/B3 后端）[4][5]。

更多实现细节见 WebKit JavaScriptCore Wiki。

九、应用场景与最佳实践

9.1 典型应用场景

场景	说明
Hybrid 应用	在 App 内执行 JS 脚本、调用原生能力（如弹窗、定位、支付），JavaScriptCore 提供 OC/Swift 与 JS 的双向桥接 [1][2]
React Native / 类 RN 方案	早期 RN 等方案在 iOS 上依赖 JSC 执行 JS bundle；JSC 提供 VM、Context、Value 等能力 [3]
JSPatch 等热修复	通过下发 JS 脚本并在 JSC 中执行，动态调用原生类与方法，实现热更新（需注意安全与审核政策）[3]
WKWebView 与 Web 页面	WKWebView 内部使用系统 WebKit，其 JS 引擎与 Safari 一致；独立使用 JSC 时无需 WebView 即可执行 JS [1][2]
规则引擎 / 脚本配置	将业务规则或配置写成 JS，由原生在 JSC 中执行并取结果，便于迭代与 A/B 测试

9.2 最佳实践要点

线程：同一 VM 下多线程会串行等待；需并发执行 JS 时使用多个 JSVirtualMachine [3]。
异常：设置 context.exceptionHandler，在 JS 抛错时记录或上报，避免静默失败 [3]。
内存：在 OC 堆对象中持有 JS 值时使用 JSManagedValue + add/removeManagedReference，避免循环引用 [1][2]。
安全：执行来自网络或不可信来源的 JS 时，需做沙箱与权限控制；避免将敏感 API 无限制暴露给 JS [3]。

十、伪代码与算法说明

10.1 执行脚本并取返回值（概念）

function evaluateScript(script: String) -> JSValue:
  parse script -> AST
  generate bytecode from AST
  execute bytecode (via LLInt or JIT tier)
  return last expression value as JSValue

10.2 将 Native 对象注入 Context（概念）

function setObject(object: Any, forKey key: String):
  if object is Block or conforms to JSExport:
    create JS wrapper (function or object with exported properties/methods)
  else:
    create generic wrapper preserving native type hierarchy
  set wrapper on context.globalObject[key]

10.3 JS 调用 Native Block 时（概念）

在 JavaScript 侧，调用通过 context[@"key"] 注入的 Block，与调用普通函数一致：

// 假设 Native 已注入：context["makeColor"] = ^(NSDictionary *rgb) { ... }
var color = makeColor({ red: 12, green: 23, blue: 67 });

底层流程（伪代码）：

当 JS 调用 context 中注册的 Block 时：
  1. JSC 将 JS 参数按类型转换为 OC 对象（NSNumber/NSString/NSDictionary/NSArray 等）
  2. 调用 Block，传入转换后的参数
  3. 将 Block 返回值按类型转换为 JSValue 并返回给 JS

参考文献

[1] Apple. JavaScriptCore Framework. iOS / macOS Developer Documentation.
[2] 掘金 / 博客. iOS 与 JS 交互开发知识总结、JavaScriptCore 初探 等.
[3] 本文原稿与常见 JSC 教程（JSVirtualMachine、JSContext、JSValue、并发与内存）.
[4] WebKit. Introducing the WebKit FTL JIT. webkit.org/blog/3362/i…
[5] WebKit. JavaScriptCore - Deep Dive. docs.webkit.org/Deep%20Dive…
[6] trac.webkit.org. JavaScriptCore. trac.webkit.org/wiki/JavaSc…
[7] 美团技术团队. 深入理解 JSCore. blog.csdn.net/MeituanTech…

SwiftUI路由管理架构揭秘：从混乱到优雅的蜕变

掘金 iOS

StarkCoder

2026年2月28日 19:26

引言

想象一下：当你打开一个 App，点击不同标签页，切换页面时，所有导航状态都能完美保持；当你从详情页返回时，TabBar 能智能地重新出现；当你需要传递数据时，类型安全的导航能让你告别字符串硬编码的烦恼。这一切，都离不开一个优秀的路由管理架构。

在现代 iOS 应用开发中，路由管理常常被视为"基础设施"而被忽视，但其重要性却不亚于任何核心功能。一个设计良好的路由系统，不仅能让代码结构更清晰，还能显著提升用户体验。今天，我将带大家深入剖析我项目中的路由管理架构，分享从设计到实现的全过程，希望能为你的项目带来启发。

路由架构概览

我项目的路由管理基于 SwiftUI 的 NavigationStack 和 NavigationPath，采用了集中式的路由管理方案。核心组件包括：

Router 类：全局导航路由器，管理所有 Tab 的导航路径
MainTab 枚举：定义应用的标签页结构
MainContainerView：主容器视图，负责整合标签页和导航逻辑
App 启动注入：在应用启动时将 Router 注入到环境中

路由的启动注入

在 EviApp.swift 中，我们通过 @StateObject 创建 Router 实例，并通过 environmentObject 将其注入到应用环境中：

import SwiftUI

@main
struct EviApp: App {
    // 把 AppDelegate 接进来，系统会照常调用 didFinishLaunchingWithOptions 等
    @UIApplicationDelegateAdaptor(AppDelegate.self) var appDelegate
    
    // 全局弹框管理器
    @StateObject private var overlay = GlobalOverlayManager.shared
    // 全局导航路由器
    @StateObject private var router = Router()
    
    var body: some Scene {
        WindowGroup {
            MainContainerView()
                .environmentObject(overlay)
                .environmentObject(router)
        }
    }
}

这样，在应用的任何视图中，都可以通过 @EnvironmentObject 来访问 Router 实例，实现全局路由管理。

核心组件分析

1. Router 类：路由管理的核心

import SwiftUI

/// 全局导航路由器，管理所有Tab的导航路径
class Router: ObservableObject {
    
    // 当前选中的Tab
    @Published var selectedTab: MainTab = .home
    
    // 为每个tab单独存储NavigationPath
    @Published var homePath = NavigationPath()
    @Published var hotPath = NavigationPath()
    @Published var creationPath = NavigationPath()
    @Published var stylePath = NavigationPath()
    @Published var profilePath = NavigationPath()
    
    // MARK: - 获取导航路径
    
    /// 获取指定tab的导航路径
    func getNavigationPath(for tab: MainTab) -> NavigationPath {
        switch tab {
        case .home: return homePath
        case .hot: return hotPath
        case .creation: return creationPath
        case .style: return stylePath
        case .profile: return profilePath
        }
    }
    
    /// 获取指定tab的导航路径绑定
    func getNavigationPathBinding(for tab: MainTab) -> Binding<NavigationPath> {
        switch tab {
        case .home: return binding(for: \.homePath)
        case .hot: return binding(for: \.hotPath)
        case .creation: return binding(for: \.creationPath)
        case .style: return binding(for: \.stylePath)
        case .profile: return binding(for: \.profilePath)
        }
    }
    
    // MARK: - 清空导航路径
    
    /// 清空指定tab的导航路径
    func clearPath(for tab: MainTab) {
        switch tab {
        case .home: clear(\.homePath)
        case .hot: clear(\.hotPath)
        case .creation: clear(\.creationPath)
        case .style: clear(\.stylePath)
        case .profile: clear(\.profilePath)
        }
    }
    
    /// 清空所有导航路径
    func clearAllPaths() {
        clear(\.homePath)
        clear(\.hotPath)
        clear(\.creationPath)
        clear(\.stylePath)
        clear(\.profilePath)
    }
    
    // MARK: - 当前Tab操作
    
    /// 获取当前选中Tab的导航路径
    func getCurrentNavigationPath() -> NavigationPath {
        return getNavigationPath(for: selectedTab)
    }
    
    /// 获取当前选中Tab的导航路径绑定
    func getCurrentNavigationPathBinding() -> Binding<NavigationPath> {
        return getNavigationPathBinding(for: selectedTab)
    }
    
    /// 清空当前选中Tab的导航路径
    func clearCurrentPath() {
        clearPath(for: selectedTab)
    }
    
    // MARK: - 私有辅助方法
    
    /// 创建导航路径的绑定
    private func binding(for keyPath: ReferenceWritableKeyPath<Router, NavigationPath>) -> Binding<NavigationPath> {
        Binding {
            self[keyPath: keyPath]
        } set: {
            self[keyPath: keyPath] = $0
        }
    }
    
    /// 清空指定的导航路径
    private func clear(_ keyPath: ReferenceWritableKeyPath<Router, NavigationPath>) {
        self[keyPath: keyPath].removeLast(self[keyPath: keyPath].count)
    }
}

设计亮点：

集中管理：所有路由逻辑集中在一个类中，便于统一管理
Tab 隔离：为每个标签页维护独立的导航路径，确保切换标签时不会影响其他标签的导航状态
响应式设计：使用 @Published 修饰符，实现路由状态的自动更新
便捷方法：提供了丰富的方法来操作导航路径，如获取路径、清空路径等

2. MainTab 枚举：标签页定义

import SwiftUI

/// 主标签栏枚举
enum MainTab {
    case home
    case hot
    case creation
    case style
    case profile
}

extension MainTab {
    
    /// 根据选中状态返回对应的图标名称
    func iconName(isSelected: Bool) -> String {
        switch self {
        case .home:
            return isSelected ? "tabbar_home_sel" : "tabbar_home_nor"
        case .hot:
            return isSelected ? "tabbar_hot_sel" : "tabbar_hot_nor"
        case .creation:
            return "tabbar_add"
        case .style:
            return isSelected ? "tabbar_style_sel" : "tabbar_style_nor"
        case .profile:
            return isSelected ? "tabbar_me_sel" : "tabbar_me_nor"
        }
    }
}

设计亮点：

类型安全：使用枚举定义标签页，避免了字符串硬编码
扩展功能：通过扩展为枚举添加了获取图标名称的功能，使代码更整洁

3. MainContainerView：路由的实际应用

import SwiftUI

/// 主容器视图，包含悬浮TabBar
struct MainContainerView: View {
    
    // 获取指定tab的导航路径
    private func getNavigationPath(for tab: MainTab) -> NavigationPath {
        return router.getNavigationPath(for: tab)
    }
    
    /// 创建带有NavigationStack的标签页视图
    private func tabView(_ tab: MainTab) -> some View {
        NavigationStack(path: router.getNavigationPathBinding(for: tab)) {
            switch tab {
            case .home:
                HomeView()
            case .hot:
                HotHomeView()
            case .creation:
                CreationHomeView()
            case .style:
                StyleHomeView()
            case .profile:
                ProfileHomeView()
            }
        }
        .tag(tab)
    }
    
    @StateObject private var appConfigManager = AppConfigManager.shared
    
    @EnvironmentObject private var overlay: GlobalOverlayManager
    @EnvironmentObject private var router: Router
    
    var body: some View {
        if appConfigManager.appConfig != nil {
            ZStack {
                
                // 真正负责页面生命周期的容器
                TabView(selection: $router.selectedTab) {
                    tabView(.home)
                    tabView(.hot)
                    tabView(.creation)
                    tabView(.style)
                    tabView(.profile)
                }
                
                // 你的悬浮TabBar，根据当前选中标签的导航路径长度控制显示
                if isTabBarVisible {
                    VStack {
                        Spacer()
                        FloatingTabBar(selectedTab: $router.selectedTab)
                            .padding(.horizontal, 16)
                            .padding(.bottom, 20)
                    }
                }
                
                // 全局弹框显示
                if let current = overlay.current {
                    
                    // 遮罩
                    Color.black.opacity(0.4)
                        .ignoresSafeArea()
                        .onTapGesture {
                            overlay.dismiss()
                        }
                    
                    switch current {
                    case .login:
                        LoginOverlayView(onClose: {
                            overlay.dismiss()
                        })
                        .transition(.flipFromBottom)
                    }
                }
                
            }
            .animation(.easeInOut(duration: 0.25), value: overlay.current)
        } else {
            // 显示空View
            EmptyView()
                .background(ThemeManager.Background.global)
        }
    }
    
    var isTabBarVisible: Bool {
        return getNavigationPath(for: router.selectedTab).count == 0
    }
}

设计亮点：

NavigationStack 集成：为每个标签页创建独立的 NavigationStack
TabBar 智能显示：根据当前导航路径长度控制 TabBar 的显示/隐藏
环境对象注入：使用 @EnvironmentObject 注入 Router，实现全局访问
动画效果：添加了平滑的过渡动画，提升用户体验

路由管理的实现细节

1. 路径管理机制

路由系统的核心是 NavigationPath 的管理。NavigationPath 是 SwiftUI 4.0+ 引入的类型，它是一个类型擦除的容器，可以存储任意类型的导航目的地。

在我们的实现中：

每个标签页都有自己的 NavigationPath 实例
通过 getNavigationPathBinding 方法获取路径的绑定，用于 NavigationStack
提供了 clearPath 和 clearAllPaths 方法来清空导航路径

2. 标签页切换逻辑

当用户切换标签页时：

router.selectedTab 的值会更新
TabView 会根据新的 selectedTab 显示对应的标签页
由于每个标签页有独立的 NavigationPath，切换标签不会影响其他标签的导航状态

3. 导航路径的实际使用

在具体的视图中，可以通过以下方式使用路由：

// 在视图中注入 Router
@EnvironmentObject private var router: Router

// 使用全局路由管理进行导航
let currentPath = router.getCurrentNavigationPathBinding()
// 向当前路径添加新页面
currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(material))

// 清空当前标签页的导航路径
router.clearCurrentPath()

4. 导航目的地定义

项目使用 AppNavigationDestination 枚举来定义导航目的地：

import Foundation
import SwiftUI

/// 导航目标枚举
enum AppNavigationDestination: Hashable {
    case accountLogin
    case materialDetail(MaterialListDTOElement)
}

这种方式的优势：

类型安全：使用枚举定义导航目的地，避免了字符串硬编码
参数传递：可以在导航时传递相关数据，如 materialDetail 中的 MaterialListDTOElement
可扩展性：可以轻松添加新的导航目的地

5. NavigationStack 中处理导航目的地

在使用 NavigationStack 时，需要处理导航目的地的显示逻辑。通常在根视图中添加 navigationDestination 修饰符：

NavigationStack(path: router.getNavigationPathBinding(for: tab)) {
    HomeView()
        .navigationDestination(for: AppNavigationDestination.self) { destination in
            switch destination {
            case .accountLogin:
                AccountLoginView()
            case .materialDetail(let material):
                MaterialDetailView(material: material)
            }
        }
}

这样，当我们通过 currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(material)) 导航时，NavigationStack 会自动显示对应的目标视图。

6. 完整导航流程示例

下面是一个完整的导航流程示例，展示从触发导航到显示目标页面的全过程：

// 1. 在视图中注入 Router
@EnvironmentObject private var router: Router

// 2. 定义导航触发事件
Button("查看素材详情") {
    // 3. 获取当前路径绑定
    let currentPath = router.getCurrentNavigationPathBinding()
    // 4. 向路径添加导航目的地
    currentPath.wrappedValue.append(AppNavigationDestination.materialDetail(selectedMaterial))
}

// 5. 在根视图中处理导航目的地
NavigationStack(path: router.getNavigationPathBinding(for: .home)) {
    HomeView()
        .navigationDestination(for: AppNavigationDestination.self) { destination in
            switch destination {
            case .materialDetail(let material):
                MaterialDetailView(material: material)
            default:
                EmptyView()
            }
        }
}

// 6. 从详情页返回
Button("返回") {
    // 清空当前路径，返回根视图
    router.clearCurrentPath()
}

7. 导航路径与 TabBar 显示的关联

在 MainContainerView 中，通过 isTabBarVisible 计算属性控制 TabBar 的显示：

var isTabBarVisible: Bool {
    return getNavigationPath(for: router.selectedTab).count == 0
}

当导航路径为空时（即处于标签页的根视图），显示 TabBar；当导航路径不为空时（即进入了子页面），隐藏 TabBar，为用户提供更大的内容显示区域。

优势与最佳实践

优势

清晰的职责分离：路由逻辑与 UI 逻辑分离，使代码更易于维护
类型安全：使用枚举和类型化的导航路径，减少运行时错误
状态管理：集中管理路由状态，避免状态分散
灵活性：可以轻松添加新的标签页和导航目的地
用户体验：标签页切换时保持各自的导航状态，提升用户体验

最佳实践

统一的路由入口：所有导航操作都通过 Router 进行，避免直接操作 NavigationPath
合理的路径清理：在适当的时机清理导航路径，避免内存占用过高
导航目的地的类型定义：为导航目的地创建明确的类型，提高代码可读性
错误处理：添加适当的错误处理，确保导航操作的稳定性
测试：为路由逻辑编写单元测试，确保其正确性

代码优化建议

导航目的地类型化：

// 建议为每个标签页创建导航目的地枚举
enum HomeDestination {
    case detail(id: String)
    case search
}

// 然后在导航时使用
router.homePath.append(HomeDestination.detail(id: "123"))

添加导航日志：

// 添加导航日志，便于调试和分析用户行为
func appendToPath(_ value: some Hashable, for tab: MainTab) {
    let path = getNavigationPathBinding(for: tab)
    path.wrappedValue.append(value)
    print("Navigate to \(value) in tab \(tab)")
}

导航路径持久化：

// 可以考虑在应用进入后台时保存导航状态，在应用启动时恢复
func saveNavigationState() {
    // 保存导航状态到 UserDefaults 或其他存储
}

func restoreNavigationState() {
    // 从存储中恢复导航状态
}

添加路由拦截器：

// 可以添加路由拦截器，用于处理登录验证等场景
func appendToPath(_ value: some Hashable, for tab: MainTab) {
    if needsAuthentication(for: value) {
        // 显示登录界面
        overlay.present(.login)
    } else {
        let path = getNavigationPathBinding(for: tab)
        path.wrappedValue.append(value)
    }
}

总结

通过以上分析，我们可以看到，一个良好的路由管理架构对于 iOS 应用的重要性。我项目中的路由架构采用了集中式管理、Tab 隔离、响应式设计等原则，通过 Router 类、MainTab 枚举和 MainContainerView 的配合，实现了清晰、灵活、用户友好的导航体验。

这种路由架构不仅适用于当前项目，也可以作为其他 SwiftUI 项目的参考。通过不断优化和扩展，可以构建更加完善的路由系统，为用户提供更加流畅的应用体验。

希望这篇文章能够帮助大家更好地理解和实现 iOS 项目中的路由管理架构。如果你有任何问题或建议，欢迎在评论区留言讨论！

Flutter调试组件：打印任意组件尺寸位置信息 NRenderBox

掘金 iOS

SoaringHeart

2026年2月28日 22:20

一、需求来源

当页面元素特别多，比较杂，又必须获取某个组件尺寸位置时，一个个加 GlobalKey 有太麻烦，这是使用一个封装好的组件就特别有用了。然后就有了 NRenderBox 组件，可以打印出子组件的位置及尺寸。

二、使用

NRenderBox(
  child: Container(
    padding: EdgeInsets.symmetric(horizontal: 8, vertical: 4),
    decoration: BoxDecoration(
      color: Colors.transparent,
      border: Border.all(color: Colors.blue),
      borderRadius: BorderRadius.all(Radius.circular(0)),
    ),
    child: Column(
      mainAxisSize: MainAxisSize.min,
      children: [
        NNetworkImage(
          width: 50,
          height: 60,
          url: AppRes.image.urls.random ?? '',
        ),
        Text("选项"),
      ],
    ),
  ),
)

flutter: NRenderBox rect: Rect.fromLTRB(88.5, 322.0, 157.5, 413.0)

三、NRenderBox源码

import 'package:flutter/material.dart';

/// 点击打印尺寸
class NRenderBox extends StatefulWidget {
  const NRenderBox({
    super.key,
    required this.child,
  });

  final Widget child;

  @override
  State<NRenderBox> createState() => _NRenderBoxState();
}

class _NRenderBoxState extends State<NRenderBox> {
  final renderKey = GlobalKey();

  RenderBox? get renderBox {
    final ctx = renderKey.currentContext;
    if (ctx == null) {
      return null;
    }
    final box = ctx.findRenderObject() as RenderBox?;
    return box;
  }

  Offset? get renderPosition {
    return renderBox?.localToGlobal(Offset.zero);
  }

  @override
  Widget build(BuildContext context) {
    return GestureDetector(
      key: renderKey,
      onTap: () {
        if (renderBox == null) {
          return;
        }
        final position = renderPosition;
        final size = renderBox!.size;
        final rect = Rect.fromLTWH(position!.dx, position.dy, size.width, size.height);
        debugPrint("$widget rect: $rect");
      },
      child: widget.child,
    );
  }
}

github

苹果谷歌商店：如何监控并维护用户评分评论

掘金 iOS

CocoaKier

2026年2月28日 18:59

前阵子，我无意中发现我们的应用在 App Store 上悄然出现了几条差评，但团队里似乎没人注意到。这让我意识到一个严重的问题：如果我们不能及时听到用户的声音，怎么能及时发现应用的不足，留住用户呢？ 更令人担忧的是，潜在用户在下载前往往会浏览评论区，一条未被回应的负面评价，可能就足以让他们转身离开，影响新增转化。

如果能在用户留下评论（尤其是差评）的第一时间收到通知，我们就能快速响应、修复问题、安抚情绪，甚至将一次不满转化为一次忠诚度的提升。更重要的是，积极、真诚地回复用户评论，不仅能展现团队的专业与负责，还能向所有观望者传递一个信号：我们在乎每一位用户。

本篇文章将从实操角度出发，为不熟悉苹果和谷歌开发者后台的开发或运营同学，讲解如何监控苹果谷歌商店的评分评论，以及如何回复用户评论，为大家提供一些帮助。

一、苹果

苹果开发者后台 appstoreconnect.apple.com/，需要 客户支持 权限。

1、如何监控评分和评论

苹果后台目前不支持收到新的评分评论后邮件通知开发者。只支持“开发者回复”（当顾客编辑你已回复的评论时，你将收到电子邮件），如需开启“开发者回复”邮件通知，按下面步骤操作：

登录 App Store Connect。
点击右上角的用户头像，进入 “用户和访问”。
选择你的账户，在左侧菜单点击 “通知”。

Tips：“收到评分评论后邮件通知开发者”，这个功能在旧版 iTunes Connect 中曾经存在，但在新版 App Store Connect 中已被移除。猜测苹果可能不想开发者过度关注单条评分评论。

如果目前想要监控苹果商店的评分评论，有几个方案可参考：
1、使用官方的 App Store Connect App，每天刷一刷，自己主动去看。App内可以设置“接收用户评分”通知，但不确定现在还是否有效。
2、苹果官方提供了App Store Connect API，可以自己开发程序拉取用户评分，再进一步做监控。
3、滴答清单定个周期性提醒，每天上班打开商店详情瞅一眼，现在苹果上线了Web版AppStore了，瞅一眼也很方便。
4、借助第三方平台。

2、查看和回复用户评论

（1）通过网页端查看

登录苹果开发者后台，appstoreconnect.apple.com/

评分评论入口：分发 - 评分和评论图片.png

点击“回复”可以回复用户评论
图片.png

（2）通过官方App "App Store Connect" 查看

iOS端下载地址：apps.apple.com/cn/app/app-…
（如果你搜不到可能是你手机系统版本太低了。没有安卓端。）

图片.png App Store Connect App核心功能：
-- 销售与趋势监控（查看 App 的下载量、销售额）
-- 版本状态管理（跟踪审核状态，回复审核）
-- 用户评论处理（查看和回复评论）

App Store Connect内查看评分及评论入口：
图片.png

3、重置总评分

发布新版本到 App Store 时（必须更包），你可以重置 App 总评分。重置后，你的 App Store 产品页面将显示说明，提示顾客 App 的总评分最近已重置。此说明将一直显示，直到有足够多的顾客对新版本进行了评分且页面出现新的总评分。

请注意，重置总评分并不会重置顾客评论，App Store 仍将继续显示历史的顾客评论。

图片.png

二、Google

Google开发者后台 play.google.com/console/dev…，需要 用户反馈 权限。
“用户反馈”权限

1、如何监控评分和评论

Google官方支持收到新的评论后邮件提醒开发者，并支持按应用、评分星级设置不同的提醒开关。注意：邮件提醒默认是关闭的，需要手动开启。请按下列步骤操作。

Google开发者后台 - 设置 - 个人邮件通知（这个只会改你个人的通知设置，不会改整个团队的）图片.png

按需将邮件提醒开关打开，修改后记得保存。
图片.png

如果你的账号拥有开发者账号下多个App的权限，默认是所有应用都给你发邮件，点击下图位置，可以选择哪些应用接收邮件。图片.png

收到新的评论后，Google会给你推邮件，模板样式如下，包含了应用名称、评分星级、评论内容，不用打开Google后台就能看到评论内容，很方便。
注意：如果你接收了多个应用的邮件，请留意邮件标题里App的名字。

图片.png

2、查看和回复用户评论

（1）网页端

Google后台 - 应用 - 监控与改进 - 评分与评价。

Google后台的评论，Google会默认帮你翻译成你的语言，很贴心。如果你想看原始评论，点击“显示原评论”查看。你也可以在这里回复用户的评论。
图片.png

（2）官方 Google Play Console App

Google也像苹果一样，提供了官方的供开发者维护自己App的应用，Google Play Console App。你可以通过它在移动端方便的看评分和回复评论。

iOS端：apps.apple.com/cn/app/goog…
安卓端：play.google.com/store/apps/…

Google Play Console App

Google Play Console App 核心功能：

查看数据指标：监控安装量、卸载量、更新量以及应用的崩溃率（ANR/Crash）。
回复用户评论：及时查看并回复用户的评价，这对于维护 App 评分至关重要。
订单管理：查看应用内购买和订阅的订单详情，甚至可以进行简单的退款操作。
发布状态监控：跟踪应用版本的审核进度和发布状态。

3、Google不支持重置评分评论

Google不像苹果那样可以主动重置评分。虽然你不能手动重置，但 Google Play 的评分系统是动态权重的，更加偏重于近期（Recent）的用户评分权重会更高。

这意味着：
（1）如果你的应用过去因为有 Bug 而评分很低，只要你在新版本中修复了问题，随着新用户和老用户在近期的好评增多，你的平均分会逐渐回升。
（2）时间是最好的解药：只要新版本的体验确实提升了，评分曲线会自动向好的方向修正。

三、结束语

其实维护应用商店的评论，并不需要多么复杂的流程或高深的技巧，但你做了和没做，用户感受是不一样的，每个人都希望被尊重，用真诚打动你的用户吧！

希望这篇文章能给你一点帮助。如果你有更好的监控方法，欢迎留言交流。

参考文档
【苹果官方文档】查看评分和评论

iOS设备崩溃日志获取与查看

掘金 iOS

iOS日常

2026年2月28日 17:14

1）如何从 iPhone 获取崩溃日志

路径：设置 → 隐私与安全性 → 分析与改进 → 分析数据
这里的崩溃日志通常是 .ips 文件。

.ips 原始内容示例（节选）：

{"app_name":"hello","timestamp":"2026-02-28 15:05:24.00 +0800","app_version":"1.0","bundleID":"com.example.hello","bug_type":"309","os_version":"iPhone OS 26.3 (23D127)","incident_id":"2B7A2F77-7F64-42DA-A184-AA496AD61AAC"}
{
  "modelCode" : "iPhone18,3",
  "captureTime" : "2026-02-28 15:05:24.5689 +0800",
  "procName" : "hello",
  "bundleInfo" : {"CFBundleShortVersionString":"1.0","CFBundleVersion":"1","CFBundleIdentifier":"com.example.hello"}
}

2）如何将 `.ips` 转成可查看的崩溃日志

把 .ips 文件复制到 Mac（如桌面），直接双击。
系统会用 控制台（Console） 打开，并自动转成可读格式（Translated Report）。

转换后示例（节选）：

-------------------------------------
Translated Report (Full Report Below)
-------------------------------------
Incident Identifier: 2B7A2F77-7F64-42DA-A184-AA496AD61AAC
Process: hello [1056]
Identifier: com.example.hello
Version: 1.0 (1)
OS Version: iPhone OS 26.3 (23D127)

Exception Type: EXC_BREAKPOINT (SIGTRAP)
Triggered by Thread: 0

Thread 0 Crashed:
0   libswiftCore.dylib   _assertionFailure(...)
1   hello.debug.dylib    ViewController.click(_:)

说明：这是一个 Demo 在真机调试运行时产生的崩溃日志，符号信息完整，不需要额外 dSYM 符号化也能直接看到具体崩溃代码位置（如 ViewController.click(_:)）。

Xcode 垃圾清理

掘金 iOS

iOS日常

2026年2月27日 17:42

一、可清理目录总览

场景	目录	是否可删	影响	建议
模拟器数据	`~/Library/Developer/CoreSimulator`	可删	模拟器数据会被清空	不用模拟器时可重点清理（如 `devices`）
真机调试符号	`~/Library/Developer/Xcode/iOS DeviceSupport`	可删（建议选择性）	删掉后下次连接对应 iOS 版本会自动重建	删除不用的设备版本，常用版本保留
打包归档	`~/Library/Developer/Xcode/Archives`	可删	会失去历史归档（.xcarchive）	先保留线上版本再清理
构建缓存	`~/Library/Developer/Xcode/DerivedData`	可删	下次打开/编译变慢，需要重新索引与构建	优先清理（最直接释放缓存空间）

二、分项说明

1) 模拟器（CoreSimulator）

路径：~/Library/Developer/CoreSimulator
说明：包含模拟器设备数据。
结论：可以删除；如果基本不用模拟器，可删除 devices 目录内容来释放较大空间。

2) 真机（DeviceSupport）

路径：~/Library/Developer/Xcode/iOS DeviceSupport
说明：真机调试时生成的设备符号文件。
结论：建议选择性删除不用的设备版本；常用设备版本保留，避免频繁重建影响调试效率。

3) 打包（Archives）

路径：~/Library/Developer/Xcode/Archives
说明：Xcode 打包归档历史。
结论：可以删除，但要先确认是否需要保留线上版本的归档记录。

4) 项目缓存（DerivedData）

路径：~/Library/Developer/Xcode/DerivedData
说明：构建缓存与索引。
结论：建议优先清理；能快速释放缓存空间。代价是后续首次编译和索引会变慢。

三、实操建议（个人整理）

优先清理：DerivedData（快速释放缓存空间）。
选择性清理：iOS DeviceSupport（删除不用的设备/系统版本，常用的保留）。
按需清理：CoreSimulator（尤其不用模拟器时）。
补充清理：过期 Archives（先保留可回滚版本）。
清理前先确认：
- 是否有线上紧急回滚需要的归档；
- 哪些真机系统版本仍在日常调试；
- 是否有正在使用的模拟器环境数据需要保留。

四、快速命令（可选）

先看大小再删，避免误操作。

# 查看各目录体积
sudo du -sh ~/Library/Developer/CoreSimulator \
  ~/Library/Developer/Xcode/iOS\ DeviceSupport \
  ~/Library/Developer/Xcode/Archives \
  ~/Library/Developer/Xcode/DerivedData

# 删除 DeviceSupport
rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

# 删除 Archives
rm -rf ~/Library/Developer/Xcode/Archives/*

# 删除 DerivedData（谨慎）
rm -rf ~/Library/Developer/Xcode/DerivedData/*

五、一句话总结

Xcode 清理的核心是：优先清理 DerivedData 释放缓存；DeviceSupport 只删不用的设备版本，常用版本保留；再按需处理模拟器与旧归档。

不越狱能抓到 HTTPS 吗？在未越狱 iPhone 上抓取 HTTPS

掘金 iOS

开心就好2025

2026年2月27日 15:49

这个问题在 iOS 调试中反复出现。

很多人听到“HTTPS”“证书校验”“SSL Pinning”，第一反应就是，是不是必须越狱？

这篇文章在不越狱设备上分别测试三种情况：

普通 HTTPS
启用证书校验的 App
启用双向认证的 App

环境：

iPhone（未越狱）
一台 Windows + 一台 Mac
代理工具（Charles / Proxyman）
设备本机抓包工具 SniffMaster

一、代理抓包：不越狱的第一条路径

先测试最基础的方式：代理抓包。

操作步骤

启动 Charles（或 Proxyman）
确认代理端口正在监听
iPhone 与电脑连接同一 Wi-Fi
在 iPhone 的 Wi-Fi 设置中填写代理地址与端口
在手机上安装并信任证书
用 Safari 打开一个 HTTPS 网站

如果 Safari 能完整显示请求和响应，说明：

代理路径没问题
HTTPS 解密生效
不需要越狱

二、普通 App 的 HTTPS 测试

在同样的代理环境下，打开一个普通测试 App。

结果：

请求可以出现在 Charles 中
HTTPS 内容可正常解密
请求体与响应体完整

这一步可以确认在未启用额外安全校验的情况下，不越狱完全可以抓到 HTTPS。

三、遇到证书校验（SSL Pinning）

接下来测试一个启用了证书校验的 App。

操作保持不变，只替换测试 App。

现象：

App 提示网络错误
Charles 中只出现握手失败或无请求记录

代理路径仍然有效，Safari 仍然可以抓到数据。

说明：

阻断发生在 App 内部
系统信任代理证书不代表 App 会信任

在这里继续重复安装证书不会改变结果。

四、是否必须越狱才能继续？

不越狱依然有两种路径可以尝试。

路径一：分析握手层

可以通过底层抓包确认：

是否存在 TLS ClientHello
是否建立 TCP 连接

如果 TLS 握手存在，说明流量确实发出，只是代理无法接管。

路径二：设备本机抓包

这里切换抓包方式。

使用 SniffMaster 进行设备本机 HTTPS 抓包

SniffMaster 支持通过 USB 在电脑上直接抓取 iOS 设备流量。

操作步骤

用 USB 将 iPhone 连接电脑
保持设备解锁并点击“信任此电脑”
启动 SniffMaster
在设备列表中选择对应 iPhone
按提示安装驱动与描述文件
进入 HTTPS 暴力抓包模式
点击开始
触发 App 请求

没有配置 Wi-Fi 代理，也没有安装代理证书。暴力抓包

五、证书校验 App 的抓包结果

在设备抓包模式下测试同一个启用证书校验的 App。

结果：

请求可以看到
HTTPS 内容显示正常
未出现握手失败

区别来自抓包场景。

代理模式依赖替换证书，设备直接抓包不依赖中间人证书。

六、当请求体为空时的判断

如果抓到的 HTTPS 中：

URL 可见
Header 可见
Body 为空

这与越狱无关，而与签名有关。

若测试的是 App Store 下载的应用，需要：

获取 IPA
使用 iOS 开发证书重签
重新安装
再次抓包

完成后，请求体与响应体可完整显示。

七、双向认证（mTLS）的测试

在双向认证场景中：

代理抓包会在握手阶段失败
设备级抓包仍可观察到 TLS 会话

关键点是抓包工具是否依赖代理替换证书

参考链接：www.sniffmaster.net/tutorial/zh…

iOS相机权限获取

掘金 iOS

傅里叶

2026年2月27日 11:25

语言：Flutter
问题：获取相机弹窗的权限不出来，iOS系统设置里面对应app也没有相机选项。是宏没有打开
解决方法：打开宏

Podfile

# post_install do |installer|
#   installer.pods_project.targets.each do |target|
#     flutter_additional_ios_build_settings(target)
#     # 为所有 Pod 目标启用 dSYM 生成
#     target.build_configurations.each do |config|
#       if config.name == 'Release'
#         config.build_settings['DEBUG_INFORMATION_FORMAT'] = 'dwarf-with-dsym'
#       end
#     end
#   end
# end

post_install do |installer|
  installer.pods_project.targets.each do |target|
    flutter_additional_ios_build_settings(target)

    target.build_configurations.each do |config|

      if config.name == 'Release'
        config.build_settings['DEBUG_INFORMATION_FORMAT'] = 'dwarf-with-dsym'
      end

      # ⭐ permission_handler 必须的宏配置
      config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= [
        '$(inherited)',

        'PERMISSION_CAMERA=1',

      ]

    end
  end
end

这段 Podfile 的 post_install 配置是正确的

一、post_install 是什么 🔧

post_install do |installer|

意思是：

CocoaPods 安装完成后执行这段脚本。

也就是在执行：

pod install

之后运行。

用途：

修改 iOS 编译参数
给插件加配置
修复 Flutter / iOS 插件问题

Flutter 权限插件基本都用这个。

二、installer.pods_project.targets.each do |target|

installer.pods_project.targets.each do |target|

意思是：

遍历所有 Pod 插件。

例如：

permission_handler
mobile_scanner
ffmpeg_kit
camera
etc

这段代码会对 所有插件生效。

相当于：

给所有插件统一设置编译参数。

三、flutter_additional_ios_build_settings(target)

flutter_additional_ios_build_settings(target)

意思：

Flutter 自动生成的 iOS配置。

它会自动设置：

Swift版本
架构支持
Bitcode
iOS版本兼容性

这是 Flutter 官方必须的一行。

不能删。

四、target.build_configurations.each do |config|

target.build_configurations.each do |config|

意思：

遍历 Debug / Release 编译模式。

iOS有三种模式：

Debug（开发）
Profile（性能分析）
Release（发布）

这段代码：

对每个模式分别设置参数。

五、DEBUG_INFORMATION_FORMAT = dwarf-with-dsym

if config.name == 'Release'
  config.build_settings['DEBUG_INFORMATION_FORMAT'] = 'dwarf-with-dsym'
end

意思：

Release版本生成 dSYM 文件。

作用：

崩溃日志解析
Crashlytics
TestFlight 崩溃分析

否则：

崩溃日志看不懂

这是一个好习惯配置 👍

和权限无关。

六、最重要的一段（权限宏）⭐

config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= [  '$(inherited)',  'PERMISSION_CAMERA=1',]

这是关键。

意思：

给 iOS 编译器设置宏定义。

等价于：

#define PERMISSION_CAMERA 1

告诉 permission_handler：

编译相机权限代码。

七、$(inherited) 是什么

'$(inherited)',

意思：

保留系统原来的设置。

如果不写：

可能破坏 Flutter 默认配置。

必须保留。

相当于：

在原来的基础上增加权限宏。

八、PERMISSION_CAMERA=1 是什么 ⭐

'PERMISSION_CAMERA=1',

意思：

打开相机权限模块。

permission_handler 内部代码类似：

#if PERMISSION_CAMERA
// 相机权限代码
#endif

如果没有：

#if PERMISSION_CAMERA

条件不成立。

相机代码不会编译进去。

结果就是：

request() 不弹窗
denied
设置里没有权限

之前就是这个问题。

九、整体逻辑总结（核心理解）

配置现在等价于：

安装所有插件
Flutter配置生效
Release版本生成崩溃符号
开启相机权限模块

流程：

pod install
   ↓
执行 post_install
   ↓
给所有插件加 PERMISSION_CAMERA=1
   ↓
Xcode 编译
   ↓
permission_handler 包含相机权限代码
   ↓
request() 正常弹窗

十、建议升级为完整权限配置（推荐）🔥

建议改成：

config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] ||= [  '$(inherited)',  'PERMISSION_CAMERA=1',  'PERMISSION_PHOTOS=1',  'PERMISSION_MICROPHONE=1',]

原因：

以后大概率会用：

相册
麦克风
视频

否则未来又会踩坑。

十一、最关键结论

现在这段：

'PERMISSION_CAMERA=1',

就是让：

Permission.camera.request();

真正生效的原因。

没有它：

iOS 会表现为：

不弹窗
denied
设置没有权限

flutter存储知识点总结

掘金 iOS

zhangkai

2026年2月26日 16:36

一、数据存储

1、本地持久化存储SharedPreferences

SharedPreferences为轻量级存储，存储少量简单数据，键值对形式，不适合大量、复杂数据的存储。

import 'package:shared_preferences/shared_preferences.dart'; 
// 存储数据 
Future<void> saveData() async { 
// 获取 SharedPreferences 实例 
final prefs = await SharedPreferences.getInstance(); 
// 存储不同类型的数据 await prefs.setString('user_token', 'abc123456'); // 字符串
await prefs.setInt('user_age', 25); // 整数 a
wait prefs.setBool('is_login', true); // 布尔值 
await prefs.setDouble('height', 1.75); // 浮点数 
await prefs.setStringList('hobbies', ['读书', '运动']); // 字符串列表 } 

// 读取数据 Future<void> readData() async { 
final prefs = await SharedPreferences.getInstance(); 
// 读取数据（第二个参数是默认值，避免 null） 
String? token = prefs.getString('user_token') ?? ''; 
int age = prefs.getInt('user_age') ?? 0;
bool isLogin = prefs.getBool('is_login') ?? false; 
print('token: $token, age: $age, isLogin: $isLogin'); 
} 
// 删除数据 
Future<void> removeData() async { 
final prefs = await SharedPreferences.getInstance(); await prefs.remove('user_token'); 
// 删除单个键 
// await prefs.clear(); 
// 清空所有数据 }

2、Provider存储

Provider 是运行时的内存状态管理工具非本地持久化存储，Provider 存储的数据只在 App 运行时有效，重启后丢失。它的核心价值是让数据在多个 Widget 之间共享、响应式更新，是 “内存级” 的数据存储与共享方案。适用于需要跨组件共享、实时响应更新的运行时数据。 Provider的原理是基于 Flutter 原生的 InheritedWidget 实现的，而 InheritedWidget 的核心特性就是通过 Context 向上查找共享数据。

从 Provider 中读取 / 监听数据：必须依赖 context（因为要确定查找的上下文范围）；
从 Provider 中修改数据：通常也需要 context，但有替代方案（无需 Context）；
初始化 / 注入 Provider：不需要 context（在根节点创建时）。

2.1 定义数据模型

import 'package:flutter/foundation.dart';

class ContractDataModel extends ChangeNotifier {
  // ========== 核心数据字段 (仅保留3个示例) ==========

  // 1. 房源类型名称 (来自第一步)
  String _goodsTypeName = '';

  // 2. 租客姓名 (来自第二步)
  String _customerName = '';

  // 3. 租金单价 (来自第三步)
  String _unitPrice = '';

  // ========== Getters ==========
  String get goodsTypeName => _goodsTypeName;
  String get customerName => _customerName;
  String get unitPrice => _unitPrice;

  // ========== 统一更新方法 ==========
  /// 更新核心数据
  /// 只要传入的值不为 null 就更新，允许空字符串覆盖原有数据
  void updateCoreInfo({
    String? goodsTypeName,
    String? customerName,
    String? unitPrice,
  }) {
    if (goodsTypeName != null) _goodsTypeName = goodsTypeName;
    if (customerName != null) _customerName = customerName;
    if (unitPrice != null) _unitPrice = unitPrice;

    // 通知监听者重建 UI
    notifyListeners();
  }

  // ========== 验证数据是否完整 (示例) ==========
  bool validateCoreInfo() {
    if (_goodsTypeName.isEmpty) return false;
    if (_customerName.isEmpty) return false;
    if (_unitPrice.isEmpty) return false;
    return true;
  }

  // ========== 获取所有数据的 Map ==========
  Map<String, dynamic> toMap() {
    return {
      'goodsTypeName': _goodsTypeName,
      'customerName': _customerName,
      'unitPrice': _unitPrice,
    };
  }

  // ========== 清空所有数据 ==========
  void clear() {
    _goodsTypeName = '';
    _customerName = '';
    _unitPrice = '';

    notifyListeners();
  }
}

2.2 更新provider中的数据

final contractModel = Provider.of<ContractDataModel>(context, listen: false);
contractModel.updatePersonInfo(
  customerCertificateId: _customerCertificateId,
  customerName: _customerName,
);

2.3 获取provider,提取内部的数据

late _contractDataModel = Provider.of<ContractDataModel>(context, listen: false);
if(_contractDataModel.signClientType == '1'){//企业
  _customerCertificateType = 'Z';
}else{
  _customerCertificateType = '';
}

tips: 使用late的作用是什么？ late 是用来修饰延迟初始化变量的关键字。

late用来声明变量时无法立即赋值的问题，Provider依赖context，而 context 通常在 Widget 的 build 方法、initState的位置才能获取，声明无法获取从而报错。
允许变量非空但延迟复制。（Dart空安全核心）Dart 开启空安全后，未用 ? 标记的变量必须声明时赋值或用 late 修饰。

二、Provider 流程页面剖析

应该这样理解：

✅ Provider 是在 CreateReserveStepPage 中创建的（第52行）

✅ 三个 Step Widget 各自有自己独立的 context

✅ 但它们都是 ChangeNotifierProvider 的子孙节点

✅ 所以它们都能通过各自的 context 向上查找，找到同一个 Provider 实例

或者说：

✅ 三个 Widget 的 context 都能访问到在 CreateReserveStepPage 中创建的 Provider，因为它们都在 Provider 的子树中。

如下：

class CreateReserveStepPage extends StatefulWidget {
final Map params;
const CreateReserveStepPage({Key key,this.params}) : super(key: key);
@override
_CreateReserveStepPage createState() => _CreateReserveStepPage();
}

class _CreateReserveStepPage extends State<CreateReserveStepPage> {
final BrnMetaHorizontalStepsManager _stepsManager = BrnMetaHorizontalStepsManager();
int _currentIndex = 0;
bool _isCompleted = false;
Timer _timer;
int _elapsed = 0;
Map<String, dynamic> _contractParams = {};
final List<String> _stepTitles = ['合同信息', '租客/入住人信息', '账单/补充信息'];
// 验证回调函数
Function _validateContractWidget;
Function _validatePersonWidget;
Function _validateBillWidget;
// 保存数据回调函数
Function _savePersonWidget;
Function _saveBillWidget;
// 添加ScrollController
final ScrollController _scrollController = ScrollController();
void initState() {
  super.initState();
}

@override
void dispose() {
  _scrollController.dispose();
  super.dispose();
}

@override
Widget build(BuildContext context) {
  return ChangeNotifierProvider(
    create: (_) => ContractDataModel(),
    builder: (providerContext, child) {
      return Scaffold(
        appBar: BrnAppBar(
          title: '创建签约',
          leading: IconButton(
            icon: Icon(Icons.arrow_back_ios_new, color: Colors.black),
            onPressed: () => BoostUtil.finish(),
          ),
        ),
        body: Column(
          children: [
            _stepsManager.buildSteps(
              steps: _stepTitles.map((title) => BrunoStep(stepContentText: title)).toList(),
              currentIndex: _currentIndex,
              isCompleted: _isCompleted,
            ),
            const SizedBox(height: 24),
            Expanded(
              child: SingleChildScrollView(
                controller: _scrollController,
                child: _buildStepContent(_currentIndex),
              ),
            ),
            Container(
              padding: const EdgeInsets.symmetric(horizontal: 20, vertical: 16),
              decoration: BoxDecoration(
                color: Colors.white,
                border: Border(top: BorderSide(color: Color(0xFFF0F0F0), width: 1)),
              ),
              child: _buildBottomButtons(providerContext),
            ),
          ],
        ),
      );
    },
  );
}

Widget _buildStepContent(int index) {
  switch (index) {
    case 0:
      return ReservationStepContractWidget(
        params: this.widget.params,
        onDataChanged: _handleContractDataChanged,
        onValidateCallback: (validateFunc) {
          _validateContractWidget = validateFunc;
        },
      );
    case 1:
      return ReservationStepPersonWidget(
        onDataChanged: _handlePersonDataChanged,
        onValidateCallback: (validateFunc) {
          _validatePersonWidget = validateFunc;
        },
        onSaveCallback: (saveFunc) {
          _savePersonWidget = saveFunc;
        },
      );
    case 2:
      return ReservationStepBillWidget(
        onDataChanged: _handleBillDataChanged,
        onValidateCallback: (validateFunc) {
          _validateBillWidget = validateFunc;
        },
        onSaveCallback: (saveFunc) {
          _saveBillWidget = saveFunc;
        },
      );
    default:
      return SizedBox();
  }
}

网络知识点 - TCP/IP 四层模型知识大扫盲

掘金 iOS

齐生1

2026年2月26日 11:46

一、计网基础概念

第一章先总体回顾一下

1.1 OSI 七层模型与 TCP/IP 四层模型

OSI 模型	TCP/IP	核心职责	常见协议	iOS 关联
7.应用层	4. 应用层	提供应用服务接口，定义数据格式与交互语义	HTTP, HTTPS, DNS, WebSocket	NSURL、URLSession
6.表示层	（并入应用层）	加密、压缩、格式转化	SSL/TLS, JSON, JPEG, UTF-8
5.会话层	（并入应用层）	会话管理、状态保持	TLS 握手、RPC、Session
4.传输层	3. 传输层	端到端通信、可靠传输	TCP、UDP、QUIC	Socket
3.网络层	2. 网络层	路由寻址、分片	IP、路由、ICMP、ARP
2.数据链路层	1. 网络接口层	MAC寻址、帧封装	MAC、Wi-Fi、Ethernet
1.物理层	（并入网络接口层）	比特流传输	光线、电缆、无线信号

网络通信是一条从 应用层 → 内核网络栈 → 网络接口 → 传输介质 → 对端主机 的完整路径。

1.2 数据封装与解封装

数据在网络中是如何传递的？

以 TCP 为例：

你的 App 数据：{"name":"张三"}
      │
      ▼ ④ 应用层：加 HTTP 头（方法、路径、Host、…）
┌──────────────────────────────────────┐
│ HTTP Header │ JSON: {"name":"张三"}   │ ← 消息（Message）
└──────────────────────────────────────┘
      │
      ▼ ③ 传输层：加 TCP 头（源端口、目的端口、序列号、…）
┌────────────────────────────────────┐
│ TCP Header │ HTTP Header │ JSON    │ ← 段（Segment）
└────────────────────────────────────┘
      │
      ▼ ② 网络层：加 IP 头（源IP、目的IP、TTL、协议号=6）
┌──────────────────────────────────────────────┐
│ IP Header │ TCP Header │ HTTP Header │ JSON  │ ← 包（Packet）
└──────────────────────────────────────────────┘
      │
      ▼ ① 网络接口层：加 MAC 头（源MAC、目的MAC） + 尾部校验（FCS）
┌────────────────────────────────────────────────────────────────┐
│ MAC Header │ IP Header │ TCP Header │ HTTP Header │ JSON │ FCS │ ← 帧（Frame）
└────────────────────────────────────────────────────────────────┘

以 UDP 为例：

你的 App 数据：{"query":"example.com"}
      │
      ▼ ④ 应用层：加上应用层协议头（例如 DNS / 自定义协议）
┌──────────────────────────────────────────────┐
│ DNS Header │ JSON: {"query":"example.com"}   │ ← 消息（Message）
└──────────────────────────────────────────────┘
      │
      ▼ ③ 传输层：加 UDP 头（源端口、目的端口、长度、校验和）
┌──────────────────────────────────────────────┐
│ UDP Header │ DNS Header │ JSON               │ ← 数据报（Datagram）
└──────────────────────────────────────────────┘
      │
      ▼ ② 网络层：加 IP 头（源IP、目的IP、TTL、协议号=17）
┌────────────────────────────────────────────────────────┐
│ IP Header │ UDP Header │ DNS Header │ JSON             │ ← 包（Packet）
└────────────────────────────────────────────────────────┘
      │
      ▼ ① 网络接口层：加 MAC 头（源MAC、目的MAC） + 尾部校验（FCS）
┌────────────────────────────────────────────────────────────────────────────┐
│ MAC Header │ IP Header │ UDP Header │ DNS Header │       JSON       │  FCS │ ← 帧（Frame）
└────────────────────────────────────────────────────────────────────────────┘

接下来按照数据封装的顺序，依次回顾一下各个层级的知识。

二、应用层（应用层 + 表示层 + 会话层）

App 层逻辑，包括 DNS、HTTP、HTTPS、WebSocket、缓存、认证体系。

2.1 DNS 域名解析

作用： 将域名 https://some.com 解析为 IP 地址，是一切请求的起点。

从输入网址 -> 页面返回，过程是怎样的？

解析顺序： 浏览器缓存 → OS 缓存 → hosts → 本地 DNS → 根服务器 → 顶级域服务器 → 权威服务器；
返回 IP 后进行 TCP（三次握手）→ TLS 握手 → HTTP 请求。

┌──────────────────────────────────────┐
│   访问 https://api.example.com/path   │
└──────────────────────────────────────┘
① 用户输入网址
   └──> 浏览器解析 URL
         协议 = https、主机 = api.example.com、端口 = 443、路径 = /path

② DNS 解析域名（api.example.com → IP）
   │
   ├─ 1) 查 [本机缓存]（浏览器 DNS 缓存 → OS DNS 缓存 → hosts 文件）
   │
   ├─ 2) 未命中 → 请求 [本地 DNS 服务器]（路由器 / 运营商）
   │
   └─ 3) 仍未命中 → [本地 DNS 服务器] 发起 [迭代查询]（由它代跑，浏览器只等结果）
         │
         ├─ 问 [根 DNS]（.）
         │  └─ 回答："去问 .com 的服务器"
         ├─ 问 [顶级域 DNS]（.com）
         │  └─ 回答："去问 example.com 的权威服务器"
         └─ 问 [权威 DNS]（example.com）
            └─ 回答："api.example.com = 203.0.113.8" ✓
               └─ 本地 DNS 缓存结果（根据 TTL），返回给浏览器            

③ 建立 TCP 连接（三次握手）

④ TLS 握手（HTTPS 特有，在 TCP 之上建立加密信道）

⑤ 发送 HTTP 请求（数据从上到下逐层封装）
   └──> [1.2 数据封装与解封装] 知识点

⑥ 服务器处理请求并返回响应
   │
   ├─ 1) 解封帧（拆 MAC -> ... -> 拿到 HTTP 请求）
   │
   ├─ 2) 业务处理（路由匹配 -> 鉴权 -> 查库 -> 生成结果）
   │
   └─ 3) 构建 HTTP 响应，逐层封装，发回客户端

⑦ 浏览器接收响应

⑧ 连接关闭（四次挥手，或保持复用）
   ├─ HTTP/1.1 Keep-Alive → 连接放入连接池，后续请求复用
   ├─ HTTP/2 → 同一连接上继续多路复用
   └─ 不再需要时 → 四次挥手断开：

DNS 劫持
- 现象：
  - App -> 运营商 DNS 服务器（可能被劫持）-> 返回错误的 IP
- 解决方案：HTTPDNS（绕过运营商，App 直连 DNS 服务）
  - App -> 通过 HTTP 直接请求 HTTPDNS 服务器（绕过运营商）-> 返回正确的 IP

2.2 HTTP 协议

HTTP(80)、HTTPS(443)

HTTP 是一种基于 “请求-响应” 的无状态的应用层协议，每次请求都是独立的。

最初就是为浏览器与 Web 服务器设计的。

2.2.1 HTTP 基本信息

HTTP 请求 = 请求行 + 请求头 + 空行 + 请求体

POST /api/users HTTP/1.1                ← 请求行：方法、路径、版本
Host: api.example.com                   ← 请求头：多行参数
...
...
                                        ← 空行：分隔头和体
{"name":"张三","email":"z@example.com"}  ← 请求体

HTTP 响应 = 状态行 + 响应头 + 空行 + 响应体

HTTP/1.1 201 Created                     ← 状态行：版本、状态码、描述
Content-Type: application/json           ← 响应头
...
...
                                         ← 空行
{"id":456,"name":"张三","created":true}   ← 响应体

2.2.2 HTTP 常见的请求方法

方法	语义	幂等？	安全？	有请求体？	典型场景
GET	获取资源	✅	✅	通常没有	获取用户列表、详情页
POST	创建资源/提交数据	❌	❌	✅	注册、下单、上传
DELETE	删除资源	✅	❌	通常没有	删除订单
HEAD	同 GET 但只要头部	✅	✅	没有	检查资源是否更新

幂等： 执行 1 次和执行 N 次效果相同。
- GET 请求 10 次，拿到的是同一份数据，幂等✅；
- DELETE 删 10 次，资源还是被删了（第 2 次返回 404），幂等✅；
- 但 POST 创建订单 10 次，可能创建 10 哥订单，不幂等❌；
安全： 不会修改服务器资源。
- GET、HEAD 不会修改服务器资源，只读，安全✅；
- POST/DELETE 有写操作，不安全❌；

思考： 实际项目中，为什么大部分是 POST 而非 GET？大部分场景不是只需要 “读” 吗？

为安全、加密、签名、防重放、复杂度等。

请求体加密
- 很多项目会对请求参数做 AES 等对称加密，将整个参数序列化后加密放在 request body 中传输。GET 请求没有 body，参数只能拼在 URL query string 里，无法做 body 级别的加密。
签名机制与 HTTP 方法绑定
```
NSString *source = [NSString stringWithFormat:@"POST&%@&%@", pathEncoding, paramEncoding];
NSString *hash = [self HmacSha1:kAppKey data:source];
```
- 常见的 API 签名方案会把 HTTP 方法作为签名原文的一部分，客户端和服务端按同一规则生成签名并校验。一旦签名协议绑定了 POST，改用 GET 会导致签名不一致、请求被拒绝。
公共参数太多，URL 长度受限
- 每个请求通常会自动携带大量公参（设备信息、版本号、签名、时间戳、MD5、...），GET 的请求参数在 URL 里：
  - URL 容易超长，超出中间代理/CDN 的长度限制；
  - 参数结构复杂时，编码笨重；
敏感信息不易暴露在 URL 中
- GET 请求的参数在 URL 里，会被以下环节明文记录：
  - 服务端 access log
  - CDN 日志
  - 浏览器/WebView历史记录
  - 网络抓包/运营商等
- 而用户凭证（uid/sid/token）、设备指纹、签名等都是敏感数据。
防重放机制的需要
- 为了防止请求被截获后重放，通常每个请求都会带上 nonce（随机数）和 millisecond（时间戳），并参与签名计算，GET 请求的缓存机制反而会造成干扰。
- POST 天然不会被缓存，与防重放设计更契合。
统一方案降低复杂度
- 如果 GET 和 POST 混用，就需要【签名逻辑、加密方案、服务端解析逻辑、网关/中间件的安全策略】等都需要区分两套，维护成本升高。

2.2.3 HTTP 常见的状态码

|状态码 | 说明 |
| --- |  -- |
|`1xx`（上传前试探）|`100`: 服务器说"继续发吧"，用于大文件上传前的试探<br>`101`: 协议升级，WebSocket 握手就用这个|
|`2xx`（成功）|`200`: 最常见的 OK|
|`3xx`（重定向）|`301`: 永久重定向|
|`4xx`（客户端错误）|`400`: 请求格式错误<br>`401`: 没登录或Token过期<br>`403`: 登录了但没权限<404>资源不存在|
|`5xx`（服务端错误）|`500`: 服务器崩了|

2.3 HTTP 缓存机制

HTTP 缓存分为两阶段机制： 强缓存（freshness）→ 协商缓存（validation）

“先看时间（强缓存），再问服务器（协商缓存）。”

首次请求
- 服务器返回资源 + 缓存控制信息（如 Cache-Control, ETag, Last-Modified）。
强缓存阶段（freshness）
- 客户端检查本地缓存是否仍在有效期（由 Cache-Control: max-age 或 Expires 判断）。
- 若未过期 → 直接使用本地副本，不访问服务器。
协商缓存阶段（validation）
- 若 强缓存过期或被标记需验证，则 客户端带验证头请求服务器：
  - If-None-Match: <etag>
  - 或 If-Modified-Since: <time>
- 服务器判断资源是否变化：
  - 未变化 → 304 Not Modified（仅返回头部，客户端复用旧内容）；
  - 已变化 → 200 OK（新资源内容）。

常见 Header:

分类	Header	作用
强缓存	`Cache-Control: max-age=3600`	指定可直接使用的秒数
	Expires:	老式写法，被 `Cache-Control` 覆盖
协商缓存	`ETag` / `If-None-Match`	内容标签验证
	Last-Modified / `If-Modified-Since`	修改时间验证
其他	`Vary`	声明缓存与哪些请求头有关
	`private` / `public`	是否允许代理缓存

常见配置：

场景	Header 示例
静态资源	Cache-Control: public, max-age=31536000, immutable
动态接口	Cache-Control: no-cache + ETag
敏感数据	Cache-Control: no-store

2.4 Cookie、Session、Token —— 认证三兄弟

HTTP 是无状态协议 ———— 服务器不记得你是谁。每次请求都是独立的，但是有很多场景需要 “记住用户”（登录态、用户身份等），于是就有了他们仨。

名称	存储位置	主要作用	特点
Cookie	浏览器 / 客户端	存放少量数据，携带 `Session ID`	每次请求自动携带到服务器
Session	服务端	保存用户状态（如登录态）	有状态，需要共享。依赖 Cookie 或 URL 中的 `Session ID`
Token	客户端	身份凭证（常为加密签名）	服务端无状态验证，跨端通用

Web 用 Session，App 常用 Token 鉴权。

Cookie
- 本质： HTTP 头中由服务器通过 Set-Cookie 下发的 键值对。客户端保存后，在后续请求 自动携带 Cookie 头。
- 示例：
  - Set-Cookie: session_id=abc123; HttpOnly; Secure; Max-Age=3600
  - Cookie: session_id=abc123
Session（服务端状态）
- 流程：
  1. 用户登录 -> 服务端验证成功，生成唯一 Session ID;
  2. 服务端保存登录信息（uid、权限等）到内存或 redis；
  3. 将 Session ID 下发给客户端（通常通过 Cookie）；
  4. 后续请求客户端自动携带 Session ID, 服务器查表恢复状态。
- 特点：
  - 状态保存在服务器（有状态）；
  - 适合小规模 / 单机服务；
  - 分布式时需要共享 Session (如 Redis 集中存储)。
Token（无状态身份验证）
- 原理： 服务端不保存状态，只验证 Token 的合法性。
- 常见类型：
  - JWT（JSON Web Token）：Header.Payload.Signature 三段式 Base64 编码。
- 验证流程：
  1. 登录成功后生成 Token（带用户信息 + 过期时间 + 签名）。
  2. 客户端保存（如 iOS Keychain）.
  3. 每次请求带头部: Authorization: Bearer <token>
  4. 服务端验签（是否过期、签名是否匹配）。
- 特点：
  - 无需服务器保存状态；
  - 一旦签发，撤销复杂（需要黑名单机制）；
  - Token 通常短期有效，需要配合 Refresh Token 使用。

Session 与 Token 对比

项目	Session	Token
状态保存	服务端	客户端（无状态）
可扩展性	弱（需共享 Session）	强（验证即可）
安全性	依赖 Cookie 保护	依赖签名/加密
登出控制	服务端可立即失效	需黑名单或等待过期
常见场景	Web 登录态	移动端 / API 鉴权

2.5 HTTPS 与 TLS

TLS 是 SSL 的后继协议，SSL 已被淘汰。

HTTPS = HTTP + TLS。TLS 在 TCP 之上、HTTP 之下，提供三大安全保障：

保障	含义	实现方式
加密（Encryption）	防窃听	对称加密（AES）
认证（Authentication）	防伪造	数字证书 + CA 体系
完整性（Integrity）	防篡改	MAC（消息认证码）

即 HTTPS = HTTP + 加密 + 认证 + 完整性

TLS 握手流程：

客户端发送 随机数与算法列表；
服务端返回 证书与随机数；
客户端 验证证书，生成 会话密钥；
使用 非对称算法 安全交换 对称密钥，后续双方使用 对称密钥加密通信。

TLS 1.3 优化了流程：

握手仅需 1-RTT（一次往返），更快；
默认强加密算法（如 AES-GCM、ChaCha20）；
支持 0-RTT 快速重连。

iOS 强制使用 TLS1.2+（ATS），支持证书 Pinning。

类型	用途	特点
非对称加密（RSA、ECDHE）	握手阶段，用于密钥协商	安全但慢
对称加密（AES、ChaCha20）	传输阶段，用同一密钥加解密数据	快速

2.6 WebSocket 协议

HTTP 是"你问我答"（请求-响应）模式。客户端不问，服务器不答。但很多场景需要服务器 主动推送.

在 WebSocket 之前，人们用各种"土办法"模拟：

方案	原理	缺点
轮询（Polling）	客户端定时发 HTTP 请求（如每 3 秒一次）	浪费带宽和电量，延迟高
长轮询（Long Polling）	客户端发请求，服务器有数据时才响应，否则挂起直到超时	服务器资源开销大
SSE（Server-Sent Events）	服务器单向推送	只能服务器→客户端，不支持双向

而 WebSocket 才是真正的解决方案：全双工、持久连接、双方可以随时发数据。

iOS 实践： 使用 URLSessionWebSocketTask。

WebSocket 握手

本质： 就握手本质就是一个 HTTP 请求，只不过请求目的不是获取数据，而是 请求协议升级。
步骤：
1. 客户端发送一个特殊的 HTTP 请求 GET /chat HTTP/1.1 ← 还是普通的 HTTP 请求 Host: server.example.com Upgrade: websocket ← "我想升级为 WebSocket 协议" Connection: Upgrade ← "这是一个升级请求" Sec-WebSocket-Key: dGhlIHNhbXBsZQ== ← 随机 Base64 值（防伪造） Sec-WebSocket-Version: 13 ← WebSocket 协议版本 Origin: example.com ← 来源（可选，用于安全校验）
2. 服务器同意升级 HTTP/1.1 101 Switching Protocols ← 101 = "我同意切换协议了" Upgrade: websocket Connection: Upgrade Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGz... ← 基于 Key 计算的值（验证对方确实懂 WebSocket）
3. 协议升级完成
  - 从此刻起，这条 TCP 连接不再说 HTTP 了，双方改说 WebSocket 的帧协议（Frame Protocol），双向随时发数据，没有请求-响应的限制。

握手前（HTTP）：                  握手后（WebSocket）：
┌──────────────┐               ┌──────────────┐
│   HTTP/1.1    │  ── 升级 ──→  │   WebSocket   │
│   文本协议     │               │   二进制帧协议  │
│   请求-响应    │               │   全双工       │
│   头部几百字节  │               │   帧头 2~14字节 │
└──────────────┘               └──────────────┘
       ↑                              ↑
  还是跑在 TCP 之上              还是同一条 TCP 连接
  (如果 wss:// 则还有 TLS)     （连接没断，只是协议变了）

Sec-WebSocket-Key / Sec-WebSocket-Accept 是做什么的？
- 简单的 防伪造机制, 不是加密，验证对方是否是 WebSocket 服务器。

WebSocket vs HTTP 对比

维度	HTTP	WebSocket
通信模式	请求-响应（半双工）	全双工
连接	短连接或 Keep-Alive	持久连接
头部开销	每次请求带完整头部（几百字节）	握手后每帧只有 2~14 字节头部
服务器推送	不支持（只能客户端发起）	支持
URL 协议	http:// / https://	ws:// / wss://
适用场景	API 调用、资源获取	实时通信、推送、游戏

iOS 一般使用原生的 URLSessionWebSocketTask（iOS 13+)。

为什么有些项目使用自定义协议（例如[包长度｜protobuf序列化数据]），不使用 WebSocket？

	WebSocket	自定义协议
建连开销	TCP 握手 + HTTP 升级握手（多一个 RTT）	TCP 握手后直接发数据
帧头开销	2~14字节（opcode/mask/长度）	4字节（只写长度就够了）
心跳	固定的 ping/pong	自定义 Protobuf 心跳（可带业务数据）
压缩	整个连接统一压缩策略	不同消息可选不同的压缩策略
传输层	只能 TCP	可以 TCP / KCP 等随时切换
浏览器兼容	✅这是它存在的意义	❌但是 App 不需要

2.5 HTTP 版本演进（HTTP/1.0 -> HTTP/1.1 → HTTP/2 → HTTP/3）

HTTP/1.0
- 引入请求头、状态码。
- 问题：
  - 最初版本，每次请求都需要重新建立连接。
HTTP/1.0 -> HTTP/1.1（）
- 问题： HTTP/1.0 每次请求都要新建 TCP 连接，用完就断开，资源浪费；
- 改进：
  - 持久连接（Keep-Alive）: 默认不断开，复用同一个 TCP 连接发送多个请求；
  - 管道化（Pipelining）: 连续发送 多个请求，不用等待上一个响应回来。
- 仍有问题：
  - 对头阻塞（HTTP 层）： HTTP/1.1 规定响应必须按照请求顺序返回，如果第 1 个请求慢了，后续全阻塞。
HTTP/1.1 -> HTTP/2（大幅性能提升，显著减少延迟与连接数量）
- 改进：
  - 二进制分帧： 不再是文本协议，把数据拆成带有 Stream ID 标记的帧（Frame）传输；
  - 多路复用： 一个 TCP 连接上 并行传输 多个请求和响应的帧，互不阻塞；
    - ‼️每个帧都标记了 Stream ID，接收方根据 ID 把帧重新组装成各自的响应。帧可以交错发送，谁先好就先发谁—— HTTP 层的队头阻塞 解决了。
  - 头部压缩（HPACK）： HPACK 用静态表+动态表+哈夫曼编码大幅压缩头部；
  - 服务器推送（Server Push）: 服务器主动推送资源；
- 仍有问题：
  - ‼️多路复用虽然解决了 HTTP 层的队头阻塞，但底层 TCP 的对头阻塞还在——TCP 丢一个包，整个连接上所有 Stream 都得等重传。
    - ‼️因为底层用的还是 一条 TCP 连接，TCP 的特性 保证字节流严格有序到达，所有 Stream 共享一条字节流，空洞就等，等到补齐为止。

HTTP/2 -> HTTP/3（基于 QUIC，连更低的头部延迟与更快的握手）

改进：

特性	HTTP/2 (TCP)	HTTP/3 (QUIC/UDP)
传输层	TCP	UDP（自己实现可靠传输）
队头阻塞	TCP 层有	完全消除（各 Stream 独立）
握手延迟	TCP 握手 + TLS 握手	QUIC 内置 TLS，1-RTT
重连	全新握手（WiFi→蜂窝）	0-RTT 恢复（快速重连）
连接迁移	基于四元组，换 IP 就断	Connection ID 标识，换 IP 不断

‼️解决 TCP 层对头阻塞
- 不用 TCP 了，在 UDP 上自己造一个传输层，让每个 Stream 都有独立的序号和重传机制，每个 Stream 有自己独立的字节流，互不干扰。
对 iOS 端的意义： 用户在 WiFi 和蜂窝之间可以做到无感切换

传统 TCP（HTTP/2）：
用户走出公司（WiFi）→ 走上街（蜂窝） → IP 地址变了 → TCP 连接断了 → 重新握手
QUIC（HTTP/3）：
用户走出公司（WiFi）→ 走上街（蜂窝） → IP 变了但 Connection ID 没变 → 连接无缝切

三、传输层：TCP、UDP、QUIC、KCP

3.1 TCP

TCP 是一个 面向连接、可靠、有序、全双工 的传输协议。在建立连接前，双方需要达成 3 个共识：

确认通信能力： 双向通信，双方都能收能发。
交换初始序列号（ISN）： 每个字节都有序号，双方要各自告知自己的起始序号。
防止历史连接的干扰： 网络中的旧报文不能让新连接误认为是有效的。

三次握手就是为了解决这三件事。

3.1.1 TCP 三次握手

过程:
- 第 1 次: C -> 连接请求 (SYN) -> S
- 第 2 次: S -> 收到请求后，发送连接请求的确认请求 (SYN+ACK) -> C
- 第 3 次: C -> 收到请求后，发送确认请求的确认请求 (ACK) -> S

常见问题：

1. 为什么不是 2/4 次握手，而是 3 次握手？

2 次握手，双端状态可能不一致，存在 “半开连接” 和 “旧连接干扰” 问题。
3 次握手 的作用：
1. 确认双向通信可达：
  - 3 次握手保证 C、S 双方相互得知对方的收发能力正常；
  - 如果只有 2 次握手，S 无法得知 C 的接收能力是否正常。
2. 防止旧连接干扰：
  - 3 次握手通过新的 ISN 和确认机制，可以识别出过期连接并丢弃。
  - 如果只有 2 次握手，S 可能错误建立 “脏连接”，造成状态混乱。
3. 建立可靠传输基础：
  - 3 次握手双方交换初始序列号，建立有序的、基于字节流的协议。

2. 如果第 3 次握手丢失，服务端、客户端分别如何处理？

第 3 次握手丢失会造成短暂的 “半开连接”，但 TCP 的 重传与超时机制 最终会恢复一致性。

客户端
- 进入 ESTABLISHED，认为连接成功，继续等待 S 响应或者发送数据。
服务端
- 仍在 SYN_RECEIVED，等待 ACK，定时器到期后会重传 SYN+ACK。
- C 收到重传的 SYN+ACK 后，会再次发送 ACK；
- 若多次重传仍无回应，S 会放弃连接，并释放 半连接资源；
- C 尝试发数据，若 S 未进入 ESTABLISHED，可能收到 RST 响应。

3. 为什么 ISN（初始序列号）不固定？

防止旧连接干扰：
- 网络中可能残留旧包，若新连接的 ISN 与旧连接相同，旧报可能被误认为是当前连接的数据。
增强安全性：
- 防止攻击者通过预测序列号来伪造 TCP 报文（TCP 盲注入攻击、会话劫持）；
- RFC 要求 ISN 必须 随时间变化且不可预测，现代操作系统（Linux/iOS/macOS）也都采用 “时间戳+随机扰动” 动态生成方式。

4. 3 次握手的过程中是否携带数据?

标准的 TCP 行为 是不会在握手阶段携带数据的：

前 2 次握手 不携带数据，是因为 连接尚未建立，接收方未分配接收缓冲区，若携带数据，可能造成安全与资源浪费问题（攻击者伪造 SYN 报文携带大量数据）。
第 3 次握手 理论上可以携带数据，因为 C 已经进入 ESTABLISHED 状态了。但是大多实现出于简化和安全考虑，也不在 ACK 中携带数据。
- 实现简化：
  - S 的 接收缓冲区和应用层 socket 可能还没准备好，处理逻辑复杂。
- 安全问题：
  - 防止 DoS 攻击和数据误处理（若 ACK 丢失或重传，可能导致同一份数据被重复处理，S 在连接未确认时读渠道未认证的数据，会产生安全隐患（伪造、注入等风险））。

特殊情况： TCP Fast Open (TFO) 允许在 SYN 报文中携带应用数据并提前发出，实现 “0- RTT 建连”，但需要 S 支持。

5. “半开连接” 是怎么产生的？

概念： 半开连接(Half-Open Connection) 是指连接的两端状态不同步：一方认为连接已建立或仍存在，另一方实际上未建立或已断开。

后果： 半连接堆积（如 SYN Flood 攻击）。

检测手段： 内核（SYN Cookies、防火墙限速）、应用层（心跳检测、超时挥手）。

握手阶段丢包： 第 3 次握手丢失，S 进入 SYN_RECEIVED，客户端已进入 ESTABLISHED。
- 服务端 会将半开连接存放在 半连接队列 中。
已连接后异常断线： C 退出 App，S仍认为连接存在，处于 ESTABLISHED，等待数据。
- 需要依赖 KeepAlive 心跳 检测。
关闭阶段异常： 某端未正确完成四次挥手（如 FIN/ACK 丢失）。
- 双方状态不一致（FIN_WAIT / CLOSE_WAIT）。

扩展一下

1. 全双工 vs 半双工

全双工： 指通信双方可以同时进行发送和接收数据。

半双工： 双方都可以发送数据，但 不能同时，只能 “你说完我再说”。

模式	含义	能否同时发送/接收	TCP 中体现
单工	单向通信	否	几乎不用
半双工	双向但不同时	否	早期物理层通信
全双工	双向同时	是	TCP 是全双工协议
半关闭	一方发送关闭，但可接收	仅一方向关闭	TCP 四次挥手中的状态

2. 全连接队列 vs 半连接队列

服务端 TCP 内核实现层面的关键概念，

全连接队列： 存放 3 次握手已完成，但还未被应用层 accept() 接收的连接。

半连接队列： 存放已收到客户端 SYN，但 3 次握手尚未完成 的连接。

握手过程：

步骤	状态	队列
C -> 发送 SYN	S 进入 `SYN_RECIEVED`	加入半连接队列
S -> 发送 SYN+ACK，等待 ACK	C 进入 `ESTABLISHED`	半连接队列中等待确认
C -> 回 ACK 包	S 进入 `ESTABLISHED`	从半连接队列移入全连接队列

特点：

如果第 3 次握手迟迟不到，连接会在队列中等待一段时间，知道超市或超过最大重传次数，就删除这个 半连接。
若 全连接队列 已🈵，新握手完成的连接会被 丢弃/拒绝。
应用层调用 accept() 是，才会将连接从 全连接队列 中取出。

3.1.2 TCP 四次挥手

过程：
- 第 1 次： C -> FIN -> S，客户端主动发送 FIN 关闭发送通道，服务端收到 FIN 后 关闭接收通道。
- 第 2 次： S -> ACK -> C，服务器仍可继续 发送剩余数据。
- 第 3 次： S -> FIN -> C，服务端发送完所有数据后，主动发送 FIN 关闭发送通道，客户端收到 FIN 后 关闭接收通道。
- 第 4 次： C -> ACK -> S，服务端收到 ACK 后 立即关闭连接，客户等待 2MSL 后 彻底关闭连接，确保最后的 ACK 能被对方收到并防止旧包干扰。

常见问题：

1. 为什么是 “4 次挥手”，而不是 “3 次”？

因为 TCP 是 全双工协议，双方的发送和接收通道是 独立的，每个方向都必须 单独关闭，因此有了 “4 次” 挥手。
- 当一方（主动方）发出 FIN，只表示 “不再发送数据”，但是 “还能接收数据”；
- 另一方（被动方）可能还没有发完数据，所以不能立即 FIN；
- 另一方（被动方）必须等到自己也准备关闭时，再单独发出 FIN；
- 因此需要一次 FIN 一次 ACK，再一次 FIN 一次 ACK，总共四次，确保双方都能 安全、完整地 关闭。

2. TIME_WAIT 是什么？

主动关闭连接的一方，在发送最后一个 ACK 后会先进入 TIME_WAIT 状态，等待一段时间（2MSL）再彻底关闭连接（进入 CLOSED）。
- MSL（Max Segment Lifetime）: 网络中一个 TCP 报文可能存在的最长时间。
为什么不直接进入 CLOSED 呢？
1. 保证 “最后一个 ACK” 可靠传输
  - 如果 C 立即关闭，S 没收到 ACK，会重发 FIN；
  - 若 C 已关闭，就无法回应，导致服务端一直处于 LAST_ACK 状态。
2. 防止旧连接的干扰
  - 如果立即关闭，并重新使用相同四元组（IP、PORT、协议），网络中延迟处理的旧包可能被当作新连接的数据；
  - TIME_WAIT 期间确保旧包在网络中全部消失后才关闭。

3. 为什么 TIME_WAIT 要持续 2 x MSL?

一段 MSL 是为了 确保本连接最后发送的 ACK 能到达对方；
另一段 MSL 是为了 确保旧连接中的报文在网络中彻底消失。

4. TIME_WAIT 常见问题

问题	原因	对策
TIME_WAIT 太多，占用端口	客户端大量主动关闭连接	1. 调整 tcp_tw_reuse、tcp_tw_recycle（Linux 旧版）；2. 使用长连接；3. 服务端主动关闭
TIME_WAIT 导致端口耗尽	并发短连接太多	增大临时端口范围；采用连接池或 HTTP keep-alive
服务端出现大量 CLOSE_WAIT	服务端未调用 close()正常关闭	检查应用层逻辑，确保及时释放

5. TIME_WAIT 与 CLOSE_WAIT 区别

状态	所在端	触发条件	表示意义
TIME_WAIT	主动关闭方	发完最后 ACK 等待 2MSL	等待旧包消失，保证连接彻底关闭
CLOSE_WAIT	被动关闭方	收到对方 FIN，尚未发送自己的 FIN	应用层未 close()，导致资源占用

6. RST 什么时候出现？

对 已关闭的连接 发送数据；
向 未建立的连接 发送请求；
半连接超时被清理；
异常关闭；

3.1.3 TCP vs UDP

一句口诀：

TCP 是一种面向连接、可靠的、一对一的、面向字节流的、首部 20-60 字节的、传输层通信协议。
UDP 是一种无连接的、不可靠的、任意连接个数的、面向报文的、首部 8 字节的、传输层通信协议。

维度	TCP	UDP
连接性	面向连接（三次握手）	无连接的（不需要事先建立连接）
可靠性	可靠（数据包校验、包重排、丢弃重复数据包、ACK 机制、超时重传机制、拥塞控制、流量控制）	不可靠（可能丢包、乱序）
通信模式	一对一	一对任意数量（单播、多播、广播）
数据传输单元	面向字节流（无边界，可能粘包/拆包）	面向报文（有边界，保留报文长度）
首部开销	较大，20～60 字节	很小，固定 8 字节
传输效率	相对较低（需建立连接、确认、控制机制）	极高（无控制开销，延迟低）
适用场景	要求数据准确完整的场景，如 FTP、HTTP、SMTP、SSH	要求实时性高、速度快的场景，如音视频、通话、直播、DNS 查询、游戏等

TCP 特性详解
1. 核心特性：
  - 面向连接： 三握四挥
  - 可靠传输： 一系列复杂机制确保数据 准确、有序、不重复 地送达
  - 全双工通信： 连接建立后，双方可同时进行数据收发。
2. 可靠性保障机制： 0. 三次握手、四次挥手
  1. 序列号与确认应答（ACK）： 每个字节都有唯一序列号，接收方通过返回 ACK 确认收到。
  2. 超时重传（RTO）： 发送数据后启动计时器，若在 RTO（超时重传时间）内未收到 ACK，则重发数据。RTO 动态计算，通常略大于 RTT（往返时延）。
  3. 数据包排序： 利用序列号对数据包排序。
  4. 丢弃数据包： 根据序列号识别并丢弃重复包。
  5. 校验和： 校验数据在传输中是否出错，出错则丢弃等待重传。
  6. 流量控制： 通过接收方通告的窗口大小，动态调整发送速率，防止接收方缓冲区溢出。
  7. 拥塞控制： 通过拥塞窗口和四种算法（慢开始、拥塞避免、快重传、快恢复）感知并应对网络拥塞，降低整体丢包率。
    - RTT 往返时延：
      - 由链路的传播时间、末端系统出的处理时间、路由缓存中的排队和处理时间组成。
      - 最后一个因素会 随着网络拥塞程度而变化，所以 RTT 一定程度上也反映网络拥塞程度。
3. 面向字节流与粘包问题：
  - 字节流： TCP 将数据视为无结构的字节流，不保留消息边界。发送方多次写入数据可能被合并（粘包）或拆分（拆包）发送。
  - 粘包解决方案：
    - 先传包大小，再传包内容；
    - 固定包长度；
    - 设置结束标志；
4. 核心机制：
  - 滑动窗口：
    - 是 实现流量控制的核心数据结构，它标识了在无需等待确认的情况下，发送方 能连续发送的数据范围，极大 提高传输效率。
  - 流量控制：
    - 目的是 保护接收方，防止接收方被淹没，控制对象为端到端(rwnd)，接收方通过 ACK 包中的 “窗口大小” 字段，告知发送方自己 剩余的缓冲区容量，从而 控制发送方的发送速率。
  - 拥塞控制：
    - 目的是 保护网络，防止网络过载，控制对象为全网(cwnd)，通过感知网络拥塞程度（如丢包、RTT增长），动态调整 “拥塞窗口” 的大小，控制 向网络注入数据的全局速率。
5. TCP 缓冲区
  - 发送缓冲区： 存储 已发送未确认、以及待发送 的数据，每个字节都有序列号，在收到 ACK 确认的数据才会从缓冲区移除。
  - 接收缓冲区： 存储 已接收但未被应用层读取，以及乱序到达 的数据，其剩余空间大小通过窗口通告给发送方，确保接收缓冲区不溢出。

UDP 特性详解
1. 核心特性
  - 无连接： 直接发送数据，无需建立连接，开销小。
  - 不可靠传输： 不提供 ACK、重传、排序 等保障机制，数据可能 丢失、重复、乱序。
  - 面向报文： 对应用层交下来的报文，既不合并也不拆分，一次发送一个完整的报文，保留消息边界。
2. 优缺点
  - 优点：
    - 速度快、延迟低： 无连接、无控制开销。
    - 头部开销小： 仅 8 字节。
    - 支持多播/广播： 可以高效向多个目标发送数据。
    - 无阻塞控制： 在网络拥塞时仍能保持发送速率，适合实时应用。
  - 缺点：
    - 不保证可靠性： 需要由 应用层 自行处理 丢包、重复、乱序 等问题。
    - 易导致网络拥塞： 缺乏拥塞控制，若大量发送可能加剧网络拥塞。
3. UDP 报文结构
  - 头部（8 字节）：源端口(2)、目的端口(2)、长度(2)、校验和(2)。
4. 不可靠性的应用层解决方案
  1. 增加序列号
  2. 引入ACK与重传机制
  3. 实现流量控制
5. UDP缓冲区
  - 发送缓冲区： 发送时，将数据放入缓冲区后立即发送，并从缓冲区清除不停留；
  - 接收缓冲区： 接收时，将数据放入缓冲区供应用读取。

单独讲一下拥塞控制与流量控制

拥塞控制：
- 本质： 拥塞控制的本质是发送方通过一个 拥塞窗口 变量，来动态探测并适应网络传输能力，尽可能高效利用可用带宽。
  - 拥塞窗口（cwnd）：
    - 发送方根据自己 对网络拥塞程度的评估 而维护的一个窗口值，它代表了 “在当前网络情况下，我能安全发送多少数据，而不造成拥塞”。
  - 发送窗口的最终大小：
    - 发送方在任一时刻，实际能发送的数据了 = min(cwnd，rwnd)。
  - 慢启动门限（ssthresh）：
    - 一个状态切换的阈值。当 cwnd < ssthresh，使用慢开始算法；当 cwnd >= ssthresh，使用拥塞避免算法。
- 影响： 网络拥塞时 TCP 继续发包可能会导致数据包丢失或时延，这时 TCP 就会重传，导致网络更加拥塞。
- 拥塞前兆：
  - 数据包延迟显著增加；
  - 丢包率上升；
  - 网络吞吐量下降；
    1. 超时重传（RTO 超时）： 严重拥塞信号。
      - 网络非常拥堵，必须 “急刹车”，然后从最低速重新开始指数增长。
    2. 收到 3 个重复的 ACK： 轻度拥塞信号。
      - 网络只是轻度丢包，数据还在流动，可以适度减速。
- 拥塞控制：
```
初始状态
    ↓
慢启动（指数增长）
    ↓ (cwnd >= ssthresh)
拥塞避免（线性增长）
    ↓
[网络事件发生]
    ├─ 超时重传 ──→ 慢启动重启（cwnd=1）
    └─ 3个重复ACK ──→ 快重传 + 快恢复 ──→ 拥塞避免
```

流量控制：

本质： 本质是控制供需平衡，解决收发双方的速率匹配问题，防止发送方发送速率超过接收方的处理能力，导致接收方缓冲区溢出和数据丢失。
核心机制：滑动窗口

发送缓冲区（发送方维护）
┌───────────────────────────────────────────────────┐
│ 已发送且已确认 │  已发送未确认 │  可发送未发送 │ 不可发送 │
│  (可清除)     │  (等待ACK)   │  (在窗口内)  │(超出窗口)│
├───────────────────────────────────────────────────┤
◄── 已确认部分 ──►◄─────────── 发送窗口 ────────────►

接收缓冲区（接收方维护）
┌──────────────────────────────────────┐
│ 已接收已确认  │ 可接收未接收   │ 不可接收 │
│ (待应用读取)  │  (在窗口内)   │(超出窗口)│
├──────────────────────────────────────┤
◄── 已使用部分 ─►◄─────── 接收窗口 ───────►

四、网络层：IP

4.1 作用

逻辑寻址 + 路由转发

核心协议：IP、ICMP、ARP、NAT、路由协议（RIP/OSPF/BGP）。

4.2 IP 基础

版本	地址长度	示例
IPv4	32 位	192.168.1.1
IPv6	128 位	2001:db8::1

IP 报文由 【头部 + 数据】 组成，头部含源 IP、目标 IP、TTL、协议号。
若包太大，网络层负责分片与重组。
- 负责寻址与分片；
- TTL 防死循环；
- 协议号区分上层（6=TCP，17=UDP）。

4.3 ICMP

Internet Control Message Protocol，用于诊断和错误报告。
常见命令：ping（测试连通性）、traceroute（路由追踪）。

4.4 路由机制

静态路由：手动配置；
动态路由：路由器间自动交换信息（RIP、OSPF、BGP）。
默认网关：未知目标的转发出口。

五、网络接口层（链路层、物理层）：WiFi、蜂窝

5.1 职责

封装帧、寻址、差错检测（FCS）、介质访问控制。
负责同一局域网内的 节点到节点通信。

5.2 MAC 地址与 ARP

每个网卡唯一的 48 位地址（00-1C-42-7A-xx-xx）。
ARP（地址解析协议）：根据 IP 查 MAC 地址。
- 逆向为 RARP。

5.3 常见协议

类型	协议	作用
有线	Ethernet	主流局域网协议
无线	Wi-Fi（IEEE 802.11）	无线局域网标准
点对点	PPP	拨号链路协议

六、三方库：AFNetworking

6.1 AFNetworking

AFNetworking 本质上就是对苹果 NSURLSession 的面向对象封装，把 delegate 回调模式变成更易用的 Block 模式，同时加了一套序列化体系。

整体结构：

AFNetworking 4.0
│
├── 核心层
│   ├── AFURLSessionManager        会话管理器（核心中的核心）
│   └── AFHTTPSessionManager       HTTP 便捷管理器
│
├── 序列化层
│   ├── AFHTTPRequestSerializer    请求序列化（拼参数、设 Header）
│   │   ├── AFJSONRequestSerializer
│   │   └── AFPropertyListRequestSerializer
│   ├── AFHTTPResponseSerializer   响应序列化（解析数据）
│   │   ├── AFJSONResponseSerializer
│   │   ├── AFXMLParserResponseSerializer
│   │   └── AFImageResponseSerializer
│   └── AFSecurityPolicy           SSL 证书校验策略
│
├── 辅助层
│   └── AFNetworkReachabilityManager  网络状态检测
│
└── UIKit 扩展 (可选)
    ├── UIImageView+AFNetworking
    ├── UIButton+AFNetworking
    └── AFNetworkActivityIndicatorManager

AFURLSessionManager（一切的基础）
- 持有：
  - NSURLSession *session ← 苹果原生会话
  - NSOperationQueue *operationQue
  - AFSecurityPolicy *securityPolicy
  - AFNetworkReachabilityManager *reachabilityManager
  - NSMutableDictionary *mutableTaskDelegatesKeyedByTaskIdentifier (每个 Task 对应一个 delegate, 管理回调)
- 做了什么？
  - 实现 NSURLSessionDelegate 全家桶
  - 把 delegate 回调 →转化成→ Block 回调
  - 给每个 NSURLSessionTask 配一个 AFURLSessionManagerTaskDelegate，这个内部 delegate 负责收集数据、计算进度、最终回调。
  - 管理 Task 的生命周期 (创建/取消/暂停/恢复)
  - SSL 证书校验 (通过 AFSecurityPolicy)
- 关键方法：
  - 数据任务（用于普通 HTTP 请求，请求与响应体都在内存中）： dataTaskWithRequest:completionHandler:
  - 上传任务（用于 “上传本地文件” 到服务器，底层基于 http(s)）： uploadTaskWithRequest:fromFile:progress:completionHandler:
  - 下载任务（用于 “下载文件” 到本地磁盘）： downloadTaskWithRequest:destination:progress:completionHandler:
AFHTTPSessionManger（继承自 AFURLSessionManager, HTTP的便捷入口）
- 新增：
- 提供 RESTful 风格方法：
- 内部流程：

序列化体系

这是 AFNetworking 最核心的设计模式 —— 请求/响应序列化器可替换：

请求序列化器 (怎么把参数变成 HTTP 请求)
────────────────────────────────────────

AFHTTPRequestSerializer (默认)
  · Content-Type: application/x-www-form-urlencoded
  · 参数编码: key1=value1&key2=value2
  · 设置通用 Header: User-Agent / Accept-Language

AFJSONRequestSerializer
  · Content-Type: application/json
  · 参数编码: JSON 格式 {"key1":"value1"}
  
  响应序列化器 (怎么把响应数据变成对象)
────────────────────────────────────────
AFHTTPResponseSerializer (默认)
  · 不做任何解析, 直接返回 NSData

AFJSONResponseSerializer
  · 验证 Content-Type 是否为 JSON
  · NSJSONSerialization 解析 → NSDictionary / NSArray

AFImageResponseSerializer
  · 验证 Content-Type 是否为图片
  · 解析 → UIImage

6.1.1 一个请求在 AF 内部的完整流程

manager.POST(url, parameters, headers, success, failure):   业务调用
    │
    ▼
① AFHTTPRequestSerializer.request:          请求序列化
    │
    ▼
    返回 NSMutableURLRequest
    │
    ▼
② AFURLSessionManager.dataTask:           创建 Task，绑定 delegate，注册回调。
    │
    ▼
③ task.resume()  ← 请求发出去了
    │
    ▼
④ NSURLSession delegate 回调 (AF 接管):        接收数据，回调 AFURLSessionManagerTaskDelegate
    │
    ▼
⑤ AFURLSessionManagerTaskDelegate:        汇总数据
    │
    ▼
⑥ AFJSONResponseSerializer.response:     响应序列化
    │
    ▼
    返回 NSDictionary
    │
    ▼
⑦ dispatch_group:           回到主线程

6.1.2 `AFNetworking` 使用优化

AFHTTPSessionManager: 可以注入 Cronet 以支持 QUIC / HTTP2‘
AFHTTPRequestSerializer: 可以增加 AES128 加密等；
AFJSONResponseSerializer 可以增加对应的 AES128 加密、加 GZip/Brotli 解压逻辑等。

6.1.3 `AFNetworking` vs 直接使用 `NSURLSession`

裸 `NSURLSession`	AF 封装后
要自己实现 4 个 delegate 协议	Block 回调，几行代码搞定
要自己拼 URL、编码参数	manager.POST(url, params) 一行搞定
要自己管理 Task 生命周期	AF 自动管理
要自己解析 JSON	responseSerializer 自动解析
要自己做 SSL 校验	AFSecurityPolicy 配置即可
要自己检测网络状态	AFNetworkReachabilityManager 现成的

6.1.4 `AFNetworking` vs Protobuf

AF 序列化: 把参数 → 变成 HTTP 协议能理解的格式
Protobuf: 把数据 → 变成一种紧凑的二进制编码格式

AF 序列化把字典变成 HTTP 能传的文本（HTTP 协议规范），Protobuf 把对象变成 Socket 能传的二进制。前者为了兼容 HTTP 标准，后者为了追求极致的小和快。

	AF 序列化	Protobuf
格式	文本 (JSON / 表单)	二进制
可读性	人能直接看	看不懂，需要 `.proto` 文件才能解
体积	大	小（1/3~1/5）
解析速度	慢	快（10~100x）
Schema	无，运行时动态解析	有，编译时生成代码（GPBMessage 子类）
用在哪	HTTP 请求/响应	TCP 长连接的数据包
为什么选它	HTTP 标准就是 JSON/表单	长连接要求低延迟、省流量

七、总结

落实到 App 开发中，常见链路可能是这样的：

整体链路关系：

┌─────────────────────── 应用层 ───────────────────────────┐
│                                                         │
│  业务协议:      HTTP API / Protobuf / RTC                │
│  安全:          AES 加密 / HMAC-SHA1 签名   / 防重放       │
│  域名管理:            业务统一管理                         │
│  域名解析:           HTTPDNS / 系统 DNS                   │
│                                                         │
├─────────────────────── 传输层 ───────────────────────────┤
│  TCP (GCDAsyncSocket)                                   │
│  UDP + KCP (GCDAsyncUdpSocket + KCP)                    │
│  QUIC (Cronet)                                          │
│                                                         │
├─────────────────────── 网络层 ───────────────────────────┤
│  IP (v4/v6)                                             │
│                                                         │
├─────────────────────── 接口层 ───────────────────────────┤
│  WiFi / 蜂窝 / 断网检测                                   │
└─────────────────────────────────────────────────────────┘

HTTP 链路：

┌─────────────────────── 应用层 ───────────────────────────┐
│                                                         │
│  ① 业务入口                                              │
│     ObjC:  xxxxHTTP.facebookLogin(...)                  │
│     Swift: xxxxAPI(params).observable.subscribe(...)    │
│                          │                              │
│                          ▼                              │
│  ② 调度中心                                              │
│     ObjC:  业务统一错误码处理等                             │
│     Swift: MoyaProvider  (插件链处理)                     │
│                          │                               │
│                          ▼                               │
│  ③ 请求模型 (两侧做同样的事, 语言不同)                       │
│       · 填充公共参数: uid, sid, device_id, version...     │
│       · 生成防重放:   nonce (UUID) + millisecond (时间戳)  │
│       · 计算签名:     token (HMAC-SHA1)                   │
│                      sign  (HMAC-SHA1)                   │
│       · 合并业务参数                                       │
│                          │                               │
│                          ▼                               │
│  ④ 序列化 & 加密                                          │
│     ObjC:  HTTPAESRequestSerialization                   │
│     Swift: MoyaAESHandler.prepare                        │
│       · 按路径判断是否需要 AES128 加密请求体                  │
│       · 设置请求头 X-ENCRYPTED-VERSION                     │
│                          │                               │
│                          ▼                               │
│  ⑤ HTTP 库                                               │
│     ObjC:  AFNetworking  →  AFHTTPSessionManager         │
│     Swift: Alamofire     →  Session                      │
│                          │                               │
│                          ▼                               │
│  ⑥ NSURLSession (两侧共用)                                │
│     · SessionConfiguration 注入 Cronet                    │
│     · Cronet 尝试 QUIC → 降级 HTTP/2 → 降级 HTTP/1.1       │
│                                                          │
├─────────────────────── 传输层 ───────────────────────────┤
│                                                         │
│          QUIC (Cronet, UDP) 或 TCP (系统)                │
│                          │                              │
│                          ▼                              │
│                       TLS 握手                           │
│                                                         │
├─────────────────────── 网络层 ───────────────────────────┤
│                                                          │
│  IP 路由                                                  │
│                                                          │
├─────────────────────── 接口层 ───────────────────────────┤
│                                                          │
│  WiFi / 蜂窝                                             │
│                                                          │
└──────────────────────────────────────────────────────────┘

TCP 链路：

┌─────────────────────── 应用层 ───────────────────────────┐
│                                                         │
│  ① 建连 (App启动 / 登录成功触发)                           │
│                          │                               │
│                          ▼                               │
│  ② 认证 (连接建立后)                                      │
│       · 构建请求: sid + deviceId + version                │
│                          │                               │
│                          ▼                               │
│  ③ 封包：Protobuf 等                                      │
│                          │                               │
│                          ▼                               │
│  ④ Socket 发送                                            │
│                          │                               │
│                          ▼                               │
├─────────────────────── 传输层 ────────────────────────────┤
│                                                          │
│  TCP (GCDAsyncSocket)  /  KCP + UDP (GCDAsyncUdpSocket)  │
│                                                          │
├─────────────────────── 网络层 ────────────────────────────┤
│                                                          │
│  IP 路由                                                  │
│                                                          │
├─────────────────────── 接口层 ───────────────────────────┤
│                                                          │
│  WiFi / 蜂窝                                             │
│                                                          │
└──────────────────────────────────────────────────────────┘

保护机制：

┌─────────────────────── 应用层 ───────────────────────────┐
│                                                         │
│  心跳保活                                                │
│     →  NSTimer 定时发送心跳包                             │
│                                                         │
│  守护进程 (ConnectorDaemon)                             │
│    ├── TCP 守护: 连续 n 次失败 → 切备用域名                │
│    └── KCP 守护: n 秒内 n 次超时 → 切回 TCP               │
│                                                        │
│  重连策略                                                │
│    TCP 断开      → 0.5s 自动重连                          │
│    bind 失败     → 1s 重试 bind                          │
│    域名故障      → 切备用域名                              │
│    KCP 故障      → 切回 TCP 连同一域名                     │
│    前后台切换    → 发探测包验证, 失败则重连                   │
│                                                          │
└──────────────────────────────────────────────────────────┘

百款出海社交 App 一夜下架！2026，匿名社交的生死劫怎么破？

掘金 iOS

iOS研究院

2026年2月25日 20:15

2026年2月24日，出海社交领域迎来标志性的“黑色星期二”，百余款社交类App在无任何预警、无邮件通知、无申诉通道的情况下，被App Store集体下架。即便部分应用近期刚完成版本更新、运营状态平稳，也未能幸免。此次事件引发行业震动，苹果的清理行动究竟是偶然误伤还是定向整治？下架风暴的背后暗藏哪些监管逻辑？出海社交开发者如何突破困境、实现可持续发展？本文将深入拆解事件本质，梳理监管趋势，提供合规生存路径。

定向整治而非偶然误伤，四大市场同步发力

此次App Store下架行动并非随机操作，而是覆盖美国、澳大利亚、巴西、新加坡四大核心市场的定向清理，各市场虽审查重点略有差异，但整治核心高度统一，均聚焦于高风险社交场景。

美国作为全球最核心的应用市场，下架应用表面涵盖AI音乐、职场社交、旅游、育儿等多个品类，但核心筛选标准清晰——凡是包含“Live Chat”“Video Chat”“Meet New Friends”等关键词、以陌生人实时互动为核心功能的社交应用，均成为清理重点。

新加坡与澳大利亚的清理逻辑高度一致，对匿名社交类应用实施“零容忍”政策，大量主打“匿名聊天”“视频聊天”的产品被集中移除，其中不乏Aloha Live - Anonymous Chat、Xonder: Anonymous Chat & Vent等直接以“匿名”为核心卖点的应用，凸显两地对不可追溯社交模式的严格监管态度。

巴西市场的清理范围进一步扩大，除纯社交应用外，春辉乐玩、玩伴Vibe等具备旅游属性的轻度社交产品也被纳入下架名单。这一举措背后，是巴西市场将用户数据安全与未成年人保护纳入核心审查维度，审查标准提升至历史新高。

中国开发者高频踩雷：四类高危产品触发监管红线

梳理此次被下架的中国开发者相关产品，可发现其普遍存在明确的“高危特征”，均精准触碰了全球监管红线，具体可分为四大类：

1. 匿名树洞类产品

以默言、nimi-i人专属匿名聊天为代表，这类产品精准定位职场人、社恐群体的表达需求，主打“匿名对话”“无社交压力”等核心卖点，部分产品甚至取消点赞、推荐、动态广场等功能，极致强化匿名属性。但在监管层面，匿名意味着用户行为不可追溯，此类模式被明确界定为“高风险交互模式”，极易成为不良信息传播的载体，从而触发监管处罚。

2. 速配交友类产品

连连婚恋、LivMe-Meet new friend等产品均以“陌生人速配”为核心模式，前者面向职场人群提供免费婚恋交友服务，后者主打全球范围内的随机匹配聊天。此类产品的核心痛点的在于，多数中小开发团队难以承担7×24小时实时内容审核的成本，缺乏完善的审核机制，导致诈骗、色情等违法违规信息极易滋生，成为监管重点整治对象。

3. AI情感伴侣类产品

Joiy、ItsMee等产品将AI技术与情感社交深度结合，推出AI聊天、情绪匹配、专属AI聊天机器人等功能，看似是产品创新，实则触碰监管敏感点。AI技术本身并非违规核心，但当AI被用于模拟人类进行情感交流，且存在触达未成年人的可能时，监管容忍度降至零。此次下架也明确释放信号：情感类AI社交已成为全球监管的下一重点领域。

4. 马甲工具/社区类产品

部分产品以工具、垂直社区为外壳，暗藏社交属性，例如摄影社区CNU-顶尖视觉精选，虽以摄影内容分享为核心，但包含UGC内容发布、用户私信互动等社交功能，最终也被纳入清理范围。这一现象表明，只要涉及用户互动与内容传播，无论产品外在形态如何，均需遵守社交应用监管规范，不存在“法外之地”。

双重监管合围：苹果新规与全球法律形成监管合力

此次下架风暴的爆发，并非苹果单独行动，而是苹果平台规则升级与全球各国监管政策收紧形成的合力，推动出海社交行业正式进入“强合规时代”。

苹果平台规则升级：匿名社交被明确禁止

2026年2月6日，苹果悄然更新《App Store审核指南》，在1.2章节“用户生成内容”中，明确将“随机或匿名聊天”与色情内容、人身威胁、欺凌等列为App Store禁入类型，并保留“未经通知即可移除应用”的权利。

此前广泛应用于陌生人社交的Chatroulette式随机匹配模式，曾是行业核心创新点，如今已被定义为高风险功能。苹果的监管逻辑清晰：匿名+随机社交模式需要极致的内容审核能力，而多数中小开发团队难以承担相应成本，为规避平台风险，采取“一刀切”的清理策略。

全球各国监管收紧：未成年人保护成核心红线

如果说苹果新规是“平台层面的管控”，全球各国的法律政策则是“市场层面的约束”，且均以未成年人保护为核心，进一步压缩不合规产品的生存空间：

——巴西、澳大利亚、新加坡：自2月24日起，下载18+应用需通过苹果年龄验证；巴西额外规定，包含“开箱抽奖”等类赌博机制的应用，直接评级为18+，直接切断此类社交+游戏类产品的未成年人用户市场。

——美国：犹他州《应用商店责任法案》已于2025年5月生效，要求应用商店强制验证用户年龄，未成年人账号需关联家长账号，开发者违规将面临家长最高1000美元/次的索赔，苹果为规避“连坐”风险，进一步提高应用审核标准。

——欧洲：欧盟近期认定TikTok的“成瘾性设计”（如无限滚动、自动播放）违反《数字服务法案》，拟处以全球年收入6%的罚款；西班牙更推进“禁止16岁以下未成年人使用社交媒体”的政策，进一步强化对未成年人的保护。

综上，此次下架风暴是全球监管层对社交产品的一次“全面清算”，过去“先野蛮生长、后合规整改”的出海模式已彻底失效。

2026年出海社交合规生存指南：三大路径实现突围

面对全球监管收紧的大环境，出海社交开发者若想实现可持续发展，核心在于放弃侥幸心理、坚守合规底线，以下三条路径可作为破局关键：

路径一：放弃匿名模式，搭建实名/强认证体系

若产品商业模式依赖“用户匿名、无需对言行负责”的核心逻辑，需尽快完成转型。未来社交产品的核心底线是“可追溯”，即便采用昵称体系，也需搭建完善的持久账户体系，通过手机号验证、身份信息核验等强认证方式，确保用户行为可追溯、可管控，从源头降低不良信息传播风险。

路径二：将合规融入产品功能，适配全球监管要求

苹果推出的“申报年龄范围API”不应被视为运营负担，而应作为核心功能进行适配。开发者可针对不同年龄段用户设计差异化内容与功能：对未成年人开启严格的内容过滤、使用时间管理机制；对成年人提供合规范围内的社交服务。这种“分龄管理”模式，不仅能满足全球监管要求，更能提升产品公信力，成为打入欧美主流市场的核心优势。

路径三：严控AI功能风险，建立完善的内容过滤机制

随着AI技术在社交领域的广泛应用，AI陪聊、AI生成头像、AI匹配等功能成为产品创新方向，但需严格把控风险。开发者在引入AI功能前，需明确三大核心问题：AI训练数据是否合法合规？是否存在生成涉黄、涉政等敏感内容的可能？是否会诱导未成年人做出危险行为？无论采用何种大模型，均需建立严格的输出过滤机制，即便牺牲部分产品趣味性，也要确保内容绝对安全——海外市场中，单一违规内容（如AI生成的疑似儿童违规图片），即可导致应用永久下架，开发者甚至需承担刑事责任。

结语：合规是出海社交的唯一生路

2026年2月24日的下架风暴，只是全球社交领域监管收紧的一个开端。随着全球数字治理体系的不断完善，过去依赖技术红利、模式创新就能快速出海的时代已一去不复返，合规能力将成为出海社交开发者的核心竞争力。

对于在此次风暴中下架的产品，行业深感遗憾；而对于仍在坚守的开发者，需重新审视产品逻辑，主动拥抱监管、搭建完善的合规体系。唯有坚守合规底线，才能在全球出海赛道中长久立足——2026年，合规才是出海社交的唯一生存通行证。

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

WKWebView 中 iframe 无法监听原生 JSBridge 回调的完整分析

掘金 iOS

Neon1204

2026年2月25日 15:09

WKWebView 中 iframe 无法监听原生 JSBridge 回调的完整分析

一、问题标题

WKWebView 场景下，Web 项目通过 iframe 加载三方页面，为什么无法在纯 Web 层监听到 recharge / newTppClose 等原生 JSBridge 回调？

二、问题描述

在 iOS App 中，使用 WKWebView 加载前端 Web 项目。Web 项目内部通过 iframe 嵌入三方页面（跨域）。

三方页面在某些业务节点（如充值、关闭页面）会调用以下接口：

window.JSBridgeService.recharge(arg)
window.JSBridgeService.newTppClose(arg)

在 原有方案 中：

iOS 原生通过 WKUserScript 向 WebView 注入 JSBridgeService
三方页面调用后，iOS 原生可以正常收到回调
原生再通过注入 JS 或其他桥接方式通知 Web 项目

现在的目标是：

去掉 iOS 原生中转，直接让 Web 项目与三方 iframe 通信，在 Web 层监听到 recharge / newTppClose 消息。

但实际情况是：

Web 项目中无论通过 addEventListener、postMessage、函数重写等方式
都无法监听到这两个回调

三、定位问题：为什么 Web 一定监听不到？

3.1 原生注入的 JSBridge 本质是什么？

iOS 原生注入的代码如下（简化）：

window.JSBridgeService = {
  recharge: (arg) => {
    recharge.postMessage(JSON.stringify(arg || {}))
  },
  newTppClose: (arg) => {
    newTppClose.postMessage(JSON.stringify(arg || {}))
  }
}

这里有一个非常关键的认知点：

recharge / newTppClose 并不是 JavaScript 世界里的函数或事件，而是 WKWebView 提供的 Native Message Handler 代理对象。

3.2 JSBridge 调用链路分析

实际调用链路如下：

┌─────────────┐
│ 三方 iframe │
└──────┬──────┘
       │ 调用
       ▼
window.JSBridgeService.recharge()
       │
       ▼
┌──────────────────────────┐
│ WKWebView messageHandler │  ← JS Runtime 到此为止
└──────────┬───────────────┘
           │
           ▼
      iOS 原生代码

重点：

这个调用 不会进入 DOM Event Loop
不会触发任何 JS Event
不支持冒泡、捕获、监听

因此，在 Web 层以下方式全部无效：

window.addEventListener('recharge', ...)
window.onrecharge = ...
Object.defineProperty(...)
Proxy(...)

3.3 为什么 `window.postMessage` 方案行不通？

很多人会下意识把这个问题类比为 postMessage，但两者完全不是一个层级的东西：

对比项	window.postMessage	WKWebView messageHandlers
标准	Web 标准	iOS 私有实现
是否可监听	✅	❌
是否可冒泡	✅	❌
JS 可代理	✅	❌
跨 iframe	✅	❌

结论：

WKWebView 的 messageHandler 是一个「JS → Native 的单向黑洞通道」，JS 只能调用，不能监听。

四、解决方案分析

4.1 为什么原来的「原生中转方案」一定可行？

原有架构实际上是：

iframe
  ↓
JSBridgeService.recharge()
  ↓
WKWebView
  ↓
iOS 原生（协议翻译）
  ↓
注入 JS / dispatchEvent
  ↓
Web 项目监听

iOS 原生在其中承担了一个关键角色：

协议翻译器（Native → Web Event）

示例：

window.dispatchEvent(
  new CustomEvent('tpp:recharge', { detail: payload })
)

4.2 纯 Web 场景下有哪些可行方案？

✅ 方案一（推荐 & 唯一标准）：三方 iframe 支持 postMessage

三方页面：

window.parent.postMessage({
  type: 'recharge',
  payload: {}
}, '*')

主页面：

window.addEventListener('message', (e) => {
  if (e.data?.type === 'recharge') {
    // 业务处理
  }
})

这是唯一的纯 Web 正解。

❌ 方案二：跨域 iframe 注入 / Hook（不可行）

iframe 跨域
浏览器同源策略限制
CSP 限制

👉 无法实现

⚠️ 方案三：三方通过 URL / hash / storage 通知

例如：

修改 location.hash
写入 localStorage

Web 监听：

window.addEventListener('hashchange', ...)

该方案依赖三方实现，稳定性与可维护性较差。

五、最终结论（工程视角）

recharge / newTppClose 不是 JS 事件
它们是 WKWebView Native Message Handler
JS 世界 无法监听、劫持或转发
不经过原生或三方改造，纯 Web 无解

如果三方页面只支持 JSBridge 调用： 👉 必须保留一个桥接层（原生或 SDK）

六、相关知识点总结

WKWebView messageHandlers 工作机制
JS Runtime 与 Native Runtime 的边界
iframe 跨域通信模型
window.postMessage 原理
Hybrid 架构中「协议翻译层」的重要性

这类问题本质不是技术实现问题，而是平台能力边界问题。理解边界，比写代码更重要。

iOS Swift：蓝牙 BLE 连接外设CoreBluetooth

掘金 iOS

tangbin583085

2026年2月24日 17:59

在 iOS 与智能硬件（手环、传感器、控制模块等）交互中，BLE（Bluetooth Low Energy）是最常用的通信方式。本文将基于 CoreBluetooth + Swift，给出一套工程可用的连接外设代码，并总结开发中最常遇到的注意事项。

适用场景：BLE 设备连接、读写特征、订阅通知、接收回包、断线重连。

一、准备工作

1）Info.plist 权限配置（必须）

iOS 13+ 起必须给出蓝牙使用说明，否则扫描/连接会失败或系统拒绝。

<key>NSBluetoothAlwaysUsageDescription</key>
<string>需要使用蓝牙连接外设进行数据通讯</string>

如果你还需要后台持续蓝牙通信：需要 capability + plist 配置（后文注意事项会讲）。

2）导入框架

import CoreBluetooth

二、BLE 连接的标准流程

初始化 CBCentralManager
蓝牙开启后开始扫描
找到目标外设并连接
发现 Service
发现 Characteristic
找到写特征（Write）与通知特征（Notify）
开启通知并开始收发数据

三、代码：BluetoothManager（可直接用）

下面给出一个轻量但工程化的 BLE 管理器，支持：

按名称/服务 UUID 过滤
扫描超时
连接成功后自动发现服务/特征
自动开启 Notify
写入数据（支持写入响应/无响应）
断开回调（可扩展重连）
简单的写入节流（避免写太快导致丢包） ``

你只需要把 UUID 替换成你设备的即可。

import Foundation
import CoreBluetooth

final class BluetoothManager: NSObject {
    
    static let shared = BluetoothManager()
    
    // MARK: - Public callbacks (按需扩展)
    var onStateChanged: ((CBManagerState) -> Void)?
    var onDiscovered: ((CBPeripheral, NSNumber) -> Void)?
    var onConnected: ((CBPeripheral) -> Void)?
    var onDisconnected: ((CBPeripheral, Error?) -> Void)?
    var onReceiveData: ((Data, CBCharacteristic) -> Void)?
    
    // MARK: - CoreBluetooth
    private var central: CBCentralManager!
    private(set) var peripheral: CBPeripheral?
    
    private var writeChar: CBCharacteristic?
    private var notifyChar: CBCharacteristic?
    
    // MARK: - Config (替换为你的设备 UUID)
    /// 推荐：用 Service UUID 过滤扫描，效率更高、结果更准
    private let targetServiceUUID = CBUUID(string: "FFF0")
    private let writeCharUUID      = CBUUID(string: "FFF1")
    private let notifyCharUUID     = CBUUID(string: "FFF2")
    
    /// 可选：按名称过滤（如果设备名称稳定）
    private let targetNamePrefix = "MyBLE"
    
    // MARK: - Scan control
    private var scanTimer: Timer?
    private let scanTimeout: TimeInterval = 10
    
    // MARK: - Write throttle
    private var writeQueue: [Data] = []
    private var isWriting = false
    
    private override init() {
        super.init()
        // queue 建议用串行队列，避免回调并发导致状态错乱
        let queue = DispatchQueue(label: "com.tangbin.ble.queue")
        central = CBCentralManager(delegate: self, queue: queue)
    }
    
    // MARK: - Public APIs
    
    /// 开始扫描
    func startScan() {
        guard central.state == .poweredOn else { return }
        stopScan()
        
        // 只扫目标 Service：更省电更精准（强烈推荐）
        central.scanForPeripherals(withServices: [targetServiceUUID], options: [
            CBCentralManagerScanOptionAllowDuplicatesKey: false
        ])
        
        startScanTimeoutTimer()
    }
    
    /// 停止扫描
    func stopScan() {
        if central.isScanning {
            central.stopScan()
        }
        scanTimer?.invalidate()
        scanTimer = nil
    }
    
    /// 连接外设
    func connect(_ p: CBPeripheral) {
        stopScan()
        peripheral = p
        peripheral?.delegate = self
        
        central.connect(p, options: [
            CBConnectPeripheralOptionNotifyOnDisconnectionKey: true
        ])
    }
    
    /// 主动断开
    func disconnect() {
        guard let p = peripheral else { return }
        central.cancelPeripheralConnection(p)
    }
    
    /// 发送数据（写入队列节流）
    func send(_ data: Data, withResponse: Bool = false) {
        guard let p = peripheral, let w = writeChar else { return }
        let type: CBCharacteristicWriteType = withResponse ? .withResponse : .withoutResponse
        
        // 如果写入无响应，也建议做节流，避免外设来不及处理
        writeQueue.append(data)
        pumpWriteQueue(peripheral: p, characteristic: w, type: type)
    }
    
    // MARK: - Private
    
    private func startScanTimeoutTimer() {
        scanTimer?.invalidate()
        scanTimer = Timer.scheduledTimer(withTimeInterval: scanTimeout, repeats: false) { [weak self] _ in
            self?.stopScan()
        }
        RunLoop.main.add(scanTimer!, forMode: .common)
    }
    
    private func pumpWriteQueue(peripheral p: CBPeripheral,
                                characteristic c: CBCharacteristic,
                                type: CBCharacteristicWriteType) {
        guard !isWriting else { return }
        guard !writeQueue.isEmpty else { return }
        
        isWriting = true
        let packet = writeQueue.removeFirst()
        
        // 注意：此处写入发生在 central 的队列上
        p.writeValue(packet, for: c, type: type)
        
        // withoutResponse 的情况下不会走 didWriteValueFor，所以用延迟释放
        if type == .withoutResponse {
            DispatchQueue.global().asyncAfter(deadline: .now() + 0.02) { [weak self] in
                self?.isWriting = false
                self?.pumpWriteQueue(peripheral: p, characteristic: c, type: type)
            }
        }
    }
}

// MARK: - CBCentralManagerDelegate
extension BluetoothManager: CBCentralManagerDelegate {
    
    func centralManagerDidUpdateState(_ central: CBCentralManager) {
        onStateChanged?(central.state)
        
        if central.state == .poweredOn {
            // 可按需自动扫描
            // startScan()
        } else {
            // 蓝牙关闭/不可用时要清空状态
            stopScan()
            peripheral = nil
            writeChar = nil
            notifyChar = nil
        }
    }
    
    func centralManager(_ central: CBCentralManager,
                        didDiscover peripheral: CBPeripheral,
                        advertisementData: [String : Any],
                        rssi RSSI: NSNumber) {
        
        // 如果还想按名称做二次过滤
        if let name = peripheral.name, name.hasPrefix(targetNamePrefix) {
            onDiscovered?(peripheral, RSSI)
            connect(peripheral)
            return
        }
        
        // 不按名称过滤也行：只要服务 UUID 已经过滤，通常就很准
        onDiscovered?(peripheral, RSSI)
        connect(peripheral)
    }
    
    func centralManager(_ central: CBCentralManager, didConnect peripheral: CBPeripheral) {
        onConnected?(peripheral)
        
        // 连接后发现服务
        peripheral.discoverServices([targetServiceUUID])
    }
    
    func centralManager(_ central: CBCentralManager,
                        didFailToConnect peripheral: CBPeripheral,
                        error: Error?) {
        onDisconnected?(peripheral, error)
    }
    
    func centralManager(_ central: CBCentralManager,
                        didDisconnectPeripheral peripheral: CBPeripheral,
                        error: Error?) {
        onDisconnected?(peripheral, error)
        
        // 可选：重连策略（示例：延迟重连）
        // DispatchQueue.global().asyncAfter(deadline: .now() + 1) {
        //     central.connect(peripheral, options: nil)
        // }
    }
}

// MARK: - CBPeripheralDelegate
extension BluetoothManager: CBPeripheralDelegate {
    
    func peripheral(_ peripheral: CBPeripheral, didDiscoverServices error: Error?) {
        guard error == nil else { return }
        guard let services = peripheral.services else { return }
        
        for s in services {
            if s.uuid == targetServiceUUID {
                peripheral.discoverCharacteristics([writeCharUUID, notifyCharUUID], for: s)
            }
        }
    }
    
    func peripheral(_ peripheral: CBPeripheral,
                    didDiscoverCharacteristicsFor service: CBService,
                    error: Error?) {
        guard error == nil else { return }
        guard let chars = service.characteristics else { return }
        
        for c in chars {
            if c.uuid == writeCharUUID { writeChar = c }
            if c.uuid == notifyCharUUID { notifyChar = c }
        }
        
        // 开启通知（Notify）
        if let n = notifyChar {
            peripheral.setNotifyValue(true, for: n)
        }
        
        // 可选：读取一次初始值
        // if let n = notifyChar { peripheral.readValue(for: n) }
    }
    
    func peripheral(_ peripheral: CBPeripheral,
                    didUpdateNotificationStateFor characteristic: CBCharacteristic,
                    error: Error?) {
        // 通知开关状态回调
    }
    
    func peripheral(_ peripheral: CBPeripheral,
                    didUpdateValueFor characteristic: CBCharacteristic,
                    error: Error?) {
        guard error == nil else { return }
        let data = characteristic.value ?? Data()
        onReceiveData?(data, characteristic)
    }
    
    func peripheral(_ peripheral: CBPeripheral,
                    didWriteValueFor characteristic: CBCharacteristic,
                    error: Error?) {
        // 只有 withResponse 才会进这个回调
        isWriting = false
        if let w = writeChar {
            pumpWriteQueue(peripheral: peripheral, characteristic: w, type: .withResponse)
        }
    }
}

四、调用示例（在 ViewController 里）

final class ViewController: UIViewController {
    
    override func viewDidLoad() {
        super.viewDidLoad()
        
        let ble = BluetoothManager.shared
        
        ble.onStateChanged = { state in
            print("BLE state:", state.rawValue)
            if state == .poweredOn {
                ble.startScan()
            }
        }
        
        ble.onConnected = { p in
            print("已连接:", p.name ?? "unknown")
        }
        
        ble.onReceiveData = { data, ch in
            let hex = data.map { String(format: "%02x", $0) }.joined()
            print("收到数据((ch.uuid)):", hex)
        }
    }
    
    func sendCommand() {
        // 举例：发送一段 hex 指令
        let hex = "aabbccdd"
        let data = Data(hexString: hex) // 见下方扩展
        BluetoothManager.shared.send(data, withResponse: false)
    }
}

也可以复用我之前写的 ParseDataTool（Swift版）来做 Hex/Data 转换。

五、附：Data 十六进制扩展（可选）

extension Data {
    init(hexString: String) {
        let clean = hexString.replacingOccurrences(of: " ", with: "")
        var data = Data()
        var idx = clean.startIndex
        while idx < clean.endIndex {
            let next = clean.index(idx, offsetBy: 2)
            let byteStr = clean[idx..<next]
            if let b = UInt8(byteStr, radix: 16) {
                data.append(b)
            }
            idx = next
        }
        self = data
    }
}

六、开发注意事项（非常关键）

1）强烈建议：扫描时指定 Service UUID

更快、更省电、更准确
避免扫描全部 nil 会扫到大量无关设备，影响体验

central.scanForPeripherals(withServices: [targetServiceUUID], options: nil)

2）不要用 `peripheral.name` 当唯一标识

name 可能为空、可能变化。更靠谱的是：

过滤 Service UUID
使用 peripheral.identifier（UUID）做缓存识别（重连）

3）写数据别太快，否则丢包/外设卡死

BLE 写入速度过快常见问题：

外设缓冲区溢出
回包延迟或丢失
iOS 侧 write 被吞

建议做写入节流（本文示例已经做了队列 + 20ms 间隔）

4）区分 `withResponse` / `withoutResponse`

.withResponse：可靠，有回调 didWriteValueFor
.withoutResponse：速度快，但无写入确认，建议配合队列节流

实战建议：

协议关键指令用 .withResponse
大数据（如 OTA）用 .withoutResponse + 节流 + 外设 ACK

5）Notify 要记得开启（很多人漏掉）

外设回包多数走 Notify（通知），不打开你永远收不到数据：

peripheral.setNotifyValue(true, for: notifyChar)

6）断线是常态：要做重连策略

断线原因很多：

超距
外设省电休眠
手机锁屏/系统资源回收

建议：

didDisconnectPeripheral 里做延迟重连
或 UI 提示用户手动重连
结合 peripheral.identifier 记住上次设备

7）后台蓝牙通信（可选）

如果你需要锁屏/后台持续通信：

Xcode → Signing & Capabilities → Background Modes → 勾选 Uses Bluetooth LE accessories
并合理控制扫描/连接行为（后台会更耗电）

8）MTU 与分包问题

BLE 默认有效载荷常见为 20 字节（不同设备协商后可能变大）
大数据（日志、图片、OTA）一定要做分包 + 协议确认

最后

本文给出了一套 Swift BLE 连接外设的我开发成熟项目过程中的代码，可直接运用在项目中，覆盖了：

初始化、扫描、连接
服务/特征发现
Notify 开启、收包回调
写入（带队列节流）
断开处理与重连扩展

如有写错的地方，敬请指正，相互学习进步，谢谢~

春节期间独立开发者从 0 到 1：呼吸训练 iOS App 的工程化落地

掘金 iOS

SameX

2026年2月24日 16:33

项目：呼吸视界（iOS 已上架）
技术栈：SwiftUI + SwiftData + StoreKit 2 + WidgetKit + ActivityKit

各位新年快乐，春节期间体验到了人挤人，车挤车，闲来无事撸了个一直想做的APP，分享点技术心得大家共勉。

1. 架构目标：把“训练体验”和“增长闭环”同时做出来

这个项目不是只做一个呼吸动画，而是做一条完整链路：

训练引擎：稳定跑节奏（吸气/停顿/呼气）
多感官反馈：视觉 + 音频 + 触觉一致
习惯闭环：课程进度、训练记录、分享卡片
增长入口：提醒、Widget、Live Activity、深链
商业化：订阅、恢复购买、权益门控

核心分层：

状态中枢：breathing-iOS/breathing/Domain/AppStore.swift
页面编排：breathing-iOS/breathing/UI/RootView.swift
能力引擎：breathing-iOS/breathing/Engines/*
数据模型：breathing-iOS/breathing/Data/*
外部触达：breathing-iOS/breathingWidget/* + BreathingLiveActivityManager

2. 单一状态中枢：AppStore 统一收口

AppStore 用 @MainActor + ObservableObject 统一管理业务状态，避免“每个页面自己存一份状态”。

@MainActor
final class AppStore: ObservableObject {
    @Published var activeMode: BreathingMode
    @Published var activeDuration: Int
    @Published var isPro: Bool
    @Published var settings: AppSettings
    @Published var soundEnabled: Bool
    @Published var soundscapeId: String

    let breathingEngine: BreathingEngine
    let hapticsEngine: HapticsEngine
    private let soundscapePlayer = SoundscapePlayer()
    private let liveActivityManager = BreathingLiveActivityManager()
}

同时把订阅商品 ID 固定在内部，避免散落字符串：

private enum ProProductID {
    static let monthly = "com.xun.breathing.pro.monthly"
    static let yearly = "com.xun.breathing.pro.yearly"
    static let all = [monthly, yearly]
}

收益：UI 层只绑定状态，不再承担复杂业务判断；后续加模式/加权益不会牵一发而动全身。

3. 训练引擎：状态机 + 双 Task 保证节奏稳定

BreathingEngine 的关键是“阶段推进”和“总时长倒计时”分离：

@MainActor
final class BreathingEngine: ObservableObject {
    @Published private(set) var phase: BreathPhase = .ready
    @Published private(set) var isPlaying: Bool = false
    @Published private(set) var timeRemaining: Int

    private var cycleTask: Task<Void, Never>?
    private var countdownTask: Task<Void, Never>?
    private var sessionId = UUID()
}

启动时并行两条异步任务：

func start() {
    guard !isPlaying else { return }
    isPlaying = true
    sessionId = UUID()
    timeRemaining = duration

    runCountdown(sessionId: sessionId)
    switch courseType {
    case .standard:
        runBreathingLoop(sessionId: sessionId)
    case .wimHof(let config):
        runWimHofSession(sessionId: sessionId, config: config)
    }
}

倒计时任务只做一件事：

private func runCountdown(sessionId: UUID) {
    countdownTask?.cancel()
    countdownTask = Task { [weak self] in
        guard let self else { return }
        while !Task.isCancelled {
            try? await Task.sleep(nanoseconds: 1_000_000_000)
            guard sessionId == self.sessionId, self.isPlaying else { return }
            self.timeRemaining = max(0, self.timeRemaining - 1)
            if self.timeRemaining <= 0 {
                self.completeSession()
                return
            }
        }
    }
}

收益：暂停/恢复/切模式时行为稳定，不会出现“相位跳变”或“倒计时错乱”。

4. 音景引擎：缓存 + 淡入淡出，解决听感跳变

音频引擎里最关键是三点：

bufferCache：避免每次重新解码 mp3
fadeIn/fadeOut：切换音景不突兀
updatePlayback：统一播放入口（按 isPlaying/isEnabled 决策）

func updatePlayback(isPlaying: Bool, isEnabled: Bool, soundscapeId: String) {
    guard isEnabled, isPlaying else {
        stop()
        return
    }
    play(soundscapeId)
}

private func loadBuffer(for soundscape: Soundscape) -> AVAudioPCMBuffer? {
    if let cached = bufferCache[soundscape.id] { return cached }
    guard let url = Bundle.main.url(forResource: soundscape.fileName, withExtension: "mp3") else { return nil }
    do {
        let file = try AVAudioFile(forReading: url)
        let frameCount = AVAudioFrameCount(file.length)
        guard let buffer = AVAudioPCMBuffer(pcmFormat: file.processingFormat, frameCapacity: frameCount) else { return nil }
        try file.read(into: buffer)
        bufferCache[soundscape.id] = buffer
        return buffer
    } catch {
        return nil
    }
}

停止时先淡出再停引擎：

fade(to: 0, duration: fadeOutDuration) { [weak self] in
    self?.stopNow(resetSession: resetSession)
}

5. 通知提醒：权限、频率、撤销一体化

提醒模块用 UNUserNotificationCenter，重点是“配置即覆盖”而不是“叠加创建”。

func configure(enabled: Bool, minutes: Int, frequency: ReminderFrequency) async -> Bool {
    if !enabled {
        cancel()
        return true
    }
    let allowed = await requestAuthorizationIfNeeded()
    guard allowed else {
        cancel()
        return false
    }
    schedule(minutes: minutes, frequency: frequency)
    return true
}

按周频次时生成固定 ID，方便后续精确取消：

let id = "\(weekdayPrefix)\(weekday)"
let request = UNNotificationRequest(identifier: id, content: content, trigger: trigger)
center.add(request, withCompletionHandler: nil)

6. Live Activity：状态去重，避免无效刷新

Live Activity 不是“每帧都更新”，而是先比对状态，只有变化才推送：

func update(state: BreathingLiveActivityAttributes.ContentState) {
    guard #available(iOS 16.1, *) else { return }
    guard let activity else { return }
    guard state != lastState else { return }
    lastState = state
    Task {
        let content = ActivityContent(state: state, staleDate: nil)
        await activity.update(content)
    }
}

收益：减少无意义更新，降低系统开销。

7. 数据闭环：训练记录 + 课程进度

7.1 会话记录模型（SwiftData）

@Model
final class SessionRecord {
    var id: UUID
    var timestamp: Date
    var modeId: String
    var courseId: String?
    var programId: String?
    var programDay: Int?
    var duration: Int
    var preCheckin: String?
    var postCheckin: String?
}

preCheckin/postCheckin 让“训练前后变化”可追踪，这是后续留存和转化分析的基础字段。

7.2 课程进度推进

static func nextDayIndex(program: BreathingProgram, record: ProgramProgressRecord?) -> Int? {
    let completed = Set(record?.completedDays ?? [])
    for index in program.plan.indices {
        if !completed.contains(index) {
            return index
        }
    }
    return nil
}

这个实现很朴素，但稳定，且便于后续做“断点继续”。

8. Widget 深链：缩短回流路径

Widget 直接绑定深链，用户从桌面可一跳进入训练：

private let quickURL = URL(string: "breathing://start?type=quick")!
private let emergencyURL = URL(string: "breathing://start?type=emergency")!

这比“打开 App -> 选模式 -> 开始”少至少 2 步，对高频场景（焦虑急救/会前调整）很关键。

9. 订阅链路：StoreKit 2 的最小闭环

关键流程：拉商品 -> 发起购买 -> 校验交易 -> finish -> 刷新权益。

func purchaseSelectedProduct() async {
    guard let product = selectedProduct else { return }
    let result = try await product.purchase()
    switch result {
    case .success(let verification):
        let transaction = try checkVerified(verification)
        await transaction.finish()
        await refreshSubscriptionStatus()
    case .pending, .userCancelled:
        break
    @unknown default:
        break
    }
}

恢复购买也单独兜底：

try await StoreKit.AppStore.sync()
await refreshSubscriptionStatus()

10. 工程复盘：最值得复用的 4 个点

状态收口：AppStore 统一管理跨页面状态。
节奏分治：阶段循环和倒计时分为两条 Task。
增长内建：提醒/Widget/Live Activity 不是后补功能，而是留存系统。
数据先行：从第一天就保留训练前后字段，后续分析成本最低。

后记：APP已经上架，某书上反响还不错，赚钱是次要的，主要产品有人用，技术有积累就很开心啦。体验链接：apps.apple.com/cn/app/%E5%… PS：要兑换码好说，哈哈~