IOS

什么是MVI MVI（Model-View-Intent）是一种单向数据流架构模式。“Model-View-Intent"这一命名最早出现在Andre Medeiros（Staltz）创建的JavaScript框架Cycle.js中。2016年，Hannes Dorfmann在其博客系列中将MVI系统化引入Android开发，他在文中明确提到同时受到了Cycle.js和Redux（以及更早的Elm架构）的启发——MVI的命名和响应式理念来自Cycle.js，而Reducer纯函数和单一状态源的机制则与Redux一脉相承。随着Swift社区对函数式编程和响应式编程的接受度提高，MVI也逐渐被引入iOS开发。 MVI的核心思想： 单向数据流：数据沿固定方向流动（View -> Intent -> Reducer -> State -> View），没有捷径或后门 不可变状态：整个界面由单一不可变的State描述，每次更新都产生全新的State对象 可预测性：给定相同的当前State和Intent，Reducer总是产生相同的新State MVI的核心概念 Model（状态） 在MVI中，Model不是传统意义上的领域数据模型，而是界面状态模型（State）。它用一个不可变的值类型来描述UI在某一时刻的完整快照，包括数据内容、加载状态、错误信息等。 struct UserListState: Equatable { var users: [User] var isLoading: Bool var error: String? var searchQuery: String static let initial = UserListState( users: [], isLoading: false, error: nil, searchQuery: "" ) } 这里使用var属性配合struct值类型，利用Swift的值语义在Reducer中通过拷贝实现不可变效果，这是Swift中最常用的做法（详见后文"状态的不可变性"一节）。 Intent（意图） Intent代表所有触发状态变化的事件。它不仅包括用户的UI操作，还包括副作用的结果回调（如网络请求完成、数据库查询结果）、系统事件（如生命周期回调、推送通知）等。所有这些事件统一通过Intent进入Reducer驱动状态变化。 enum UserListAction { // 用户意图 case loadUsers case refreshUsers case deleteUser(id: Int) case searchQueryChanged(String) // 副作用结果（也是Intent的一种） case usersLoaded([User]) case loadFailed(String) } 将用户操作和副作用结果统一为同一类型，是MVI的关键设计。这样Reducer就成为状态变化的唯一入口，所有状态转换都在一处完成。 ...

在iOS开发中，经常会接触到三种重要的编程范式：面向对象编程（OOP）、面向协议编程（POP）和面向切面编程（AOP）。 OOP - 面向对象编程 基本概念 面向对象编程（Object-Oriented Programming）是一种以对象为核心的编程范式。它将数据和操作数据的方法封装在一起，形成对象。 OOP的四大核心特性： 特性 说明 iOS中的体现 封装 隐藏内部实现细节，只暴露必要的接口 @interface/@implementation分离，private属性 继承 子类继承父类的属性和方法 UIViewController继承自UIResponder 多态 同一接口可以有不同的实现 子类重写父类方法 抽象 提取共同特征形成抽象类型 抽象基类、协议 Objective-C中的OOP Objective-C是一门典型的面向对象语言，它在C语言的基础上添加了面向对象的特性。 // 基类定义 @interface Animal : NSObject @property (nonatomic, copy) NSString *name; - (void)speak; - (void)eat:(NSString *)food; @end @implementation Animal - (void)speak { NSLog(@"Animal speaks"); } - (void)eat:(NSString *)food { NSLog(@"%@ is eating %@", self.name, food); } @end // 子类继承 @interface Dog : Animal @property (nonatomic, copy) NSString *breed; @end @implementation Dog // 重写父类方法 - 多态 - (void)speak { NSLog(@"%@ barks: Woof!", self.name); } // 子类特有方法 - (void)fetch { NSLog(@"%@ is fetching", self.name); } @end Swift中的OOP Swift同样支持面向对象编程，但提供了更现代的语法和更强的类型安全。 ...

Initializers是指在main函数之前执行的初始化代码，包括C++静态构造函数和__attribute__((constructor))标记的函数。这些代码会在Pre-main阶段同步执行，阻塞启动。 问题分析 以下代码会在main之前执行： 1. C++静态构造函数 __attribute__((constructor)) static void MyInitializer() { // 耗时初始化 initializeHeavyResource(); } 2. 全局静态变量的构造函数 // 全局静态变量 static std::vector<std::string> globalCache = loadFromDisk(); // 构造函数在main前调用 3. 非基本类型的全局变量 // 非POD类型的全局变量会触发构造函数 static std::string globalString = "Hello"; static MyClass globalObject; 优化方案 方案1：延迟初始化 将全局变量改为懒加载模式： // 优化前：全局变量在main前初始化 static std::vector<std::string> globalCache = loadFromDisk(); // 优化后（纯C++方案，适用于 .cpp 文件）： #include <mutex> static std::vector<std::string>* getGlobalCache() { static std::vector<std::string>* cache = nullptr; static std::once_flag onceFlag; std::call_once(onceFlag, [&] { cache = new std::vector<std::string>(); *cache = loadFromDisk(); }); return cache; } // 优化后（ObjC++方案，适用于 .mm 文件）： static std::vector<std::string>* getGlobalCache() { static std::vector<std::string>* cache = nullptr; static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ cache = new std::vector<std::string>(); *cache = loadFromDisk(); }); return cache; } 方案2：使用Swift懒加载 Swift的懒加载特性可以避免在启动时初始化： ...

在 iOS 生态中，CocoaPods 依然是大多数中大型工程的依赖管理工具。当 Pod 数量达到几百个子组件上千个时，pod install 的耗时会变成研发流程里的硬性卡点。抖音在其 seer-optimize 项目中系统化地优化了 CocoaPods 的整个生命周期，全量 Pod Install 耗时减少 50%、增量减少 65%。本文系统介绍这些优化背后的原理。 关于 CocoaPods 整体架构的深度介绍可以参考 CocoaPods源码导读-架构总览。 Pod Install 耗时构成 Installer#install! 的六个阶段： flowchart LR A[prepare] --> B[resolve_dependencies] B --> C[download_dependencies] C --> D[validate_targets] D --> E[generate_pods_project] E --> F[integrate_user_project] 抖音公开的典型耗时分布： 阶段 典型耗时 说明 prepare < 0.01s 初始化 resolve_dependencies 数秒到数分钟 依赖决议，瓶颈 download_dependencies 数秒到数分钟 依赖下载，IO 密集 validate_targets 0.1s 校验 generate_pods_project 数秒到数十秒 生成 xcodeproj integrate_user_project 0.01s 集成主工程 resolve_dependencies 优化 Source 仓库更新 默认 CocoaPods 在 pod install --repo-update 时会更新所有 source 仓库。抖音改造为： ...

Codable 是 Swift 4 引入的序列化方案，官方定位是替代 Objective-C 时代的 NSCoding、以及各种第三方字典转模型框架（MJExtension、YYModel、JSONModel 等）。与运行时反射方案不同，Codable 通过"编译器自动合成 + 标准库协议抽象 + 具体格式实现"三层解耦，在编译期就把类型与序列化逻辑绑定好，兼具类型安全、性能和扩展性。 本文基于以下 Swift 源码展开分析： 协议定义：swift/stdlib/public/core/Codable.swift 编译器合成：swift/lib/Sema/DerivedConformanceCodable.cpp、DerivedConformanceCodingKey.cpp Foundation 实现：swift-corelibs-foundation/Sources/Foundation/JSONEncoder.swift、JSONDecoder.swift、PropertyListEncoder.swift 整体架构 在开始深入之前，先建立整体印象。Codable 可以拆成三层角色： 用户类型层：业务中的 struct / class / enum，声明遵循 Codable 标准库与编译器层：标准库定义 Encodable / Decodable / Encoder / Decoder 等协议，编译器为符合条件的类型合成 encode(to:) 和 init(from:) 格式实现层：Foundation 或第三方提供具体 Encoder / Decoder，负责把容器操作落到 JSON、Plist、BSON 等格式上 flowchart LR subgraph L1[用户类型层] A[struct / class / enum声明遵循 Codable] end subgraph L2[标准库与编译器层] B[Encodable / Decodable协议要求] C["编译器合成encode(to:) / init(from:)"] D[Encoder / Decoder容器协议] B --> C C --> D end subgraph L3[格式实现层] E[JSONEncoder / JSONDecoderPropertyListEncoder / 第三方实现] F[Data / 字符串 / 其他格式] E --> F end A -->|conforms to| B D -->|由具体类型实现| E 核心思想是：标准库只定义"如何描述一个可编码类型"和"编码器需要提供什么能力"，具体的格式（JSON、Plist、BSON…）由 Foundation 或第三方实现。用户类型只需要遵循协议，剩下的由编译器在 SIL 层自动生成。 ...

本文对比目前 iOS APM 领域主流的七大方案，从接入形态、原理、能力深度、适用场景四个维度深入剖析。每个方案都包含核心技术原理与关键源码解读，帮助读者做"自研还是三方、自研该参考哪个"的选型决策。 一、全景对比 quadrantChart title "iOS APM 方案对比" x-axis "低侵入" --> "高侵入" y-axis "浅能力" --> "深能力" quadrant-1 "专业级" quadrant-2 "旗舰级" quadrant-3 "入门级" quadrant-4 "高性价比" MetricKit: [0.05, 0.45] Firebase: [0.15, 0.4] "Xcode Organizer": [0.02, 0.35] Sentry: [0.3, 0.65] Bugly: [0.25, 0.5] "Matrix (微信)": [0.6, 0.88] "Slardar (字节)": [0.65, 0.95] "Hertz (美团)": [0.5, 0.8] "Alita (阿里 mPaaS)": [0.55, 0.85] 二、MetricKit + Xcode Organizer（Apple 官方） 2.1 定位 Apple 自 iOS 13 推出的官方性能监控框架，完全系统侧实现，SDK 零开销，是所有方案的基线。 ...

Apple 从 Xcode 15 开始在 Swift 上引入 Explicit Modules，Xcode 16 在 C/C++/Objective-C 上全面铺开，Xcode 17 进一步默认启用并与细粒度依赖追踪结合。这是近五年 Apple 构建系统最重要的一次变革，直接影响到大部分项目的编译模型。 模块（Module）基础 为什么需要模块 C 家族语言的 #include 机制有两个致命问题： 文本替换：头文件是纯文本替换，每个源文件都要重新解析一遍所有包含的头文件 宏污染：先引入的头文件宏会影响后续头文件的行为，没有隔离 Clang 在 2012 年引入 Clang Modules，用一个预编译的二进制模块（.pcm）替代文本包含，同一 module 在一次构建里只解析一次。Swift 的 .swiftmodule 从设计之初就是模块化的。 flowchart LR A["源文件"] -->|"include 头文件"| B["Foundation.h 文本"]; B --> C["每次都重新解析"]; D["源文件"] -->|"@import Foundation"| E["Foundation.pcm 预编译"]; E --> F["一次解析，多次复用"]; 模块的组成 类型 载体 描述 Clang Module .pcm C/OC 模块的序列化 AST Swift Module .swiftmodule Swift 模块的接口 + SIL Swift Interface .swiftinterface 可被不同 Swift 版本解析的文本接口 Module Map module.modulemap 描述哪些头文件构成某个 module Implicit Modules 的问题 原理 在 Xcode 16 之前，Clang Modules 以 隐式 方式工作： ...

IGListKit 是 Instagram（Meta）开源的一款数据驱动的 UICollectionView 框架，旨在构建快速、灵活的列表。它的核心思想是将每个数据对象映射为独立的 Section Controller，通过高效的 O(n) Diff 算法自动计算数据变化并应用最小化更新，避免手动调用 performBatchUpdates 或 reloadData。本文基于 v5.2.0 源码（2026年2月发布）进行分析。 一、整体架构 IGListKit 采用分层架构，核心由三大模块构成： graph TB subgraph "使用层" A["UIViewController"] end subgraph "适配层" B["IGListAdapter"] C["IGListAdapterDataSource"] end subgraph "控制层" D["IGListSectionController"] E["IGListBindingSectionController"] end subgraph "更新层" F["IGListAdapterUpdater"] G["IGListUpdateCoalescer"] H["IGListUpdateTransaction"] end subgraph "Diff层 (IGListDiffKit)" I["IGListDiffPaul Heckel算法"] J["IGListDiffable协议"] end subgraph "视图层" K["UICollectionView"] end A --> B B --> C B --> D D --> E B --> F F --> G F --> H H --> I I --> J B --> K 源码目录结构： ...

什么是MVP MVP（Model-View-Presenter）是一种将展示逻辑与视图分离的架构模式，起源于上世纪90年代。MVP通过引入Presenter层来解决MVC中Controller职责过重（Massive ViewController）的问题。MVP的核心思想是让View变得"被动"（Passive View），所有的展示逻辑都由Presenter处理，View只负责UI的展示和事件的转发。 MVP的结构 graph LR subgraph View["View (ViewController)"] V1["- 只负责UI展示- 将事件转发给Presenter- 持有Presenter强引用"] end subgraph Presenter["Presenter"] P1["- 持有View的弱引用（通过协议）- 持有Model的引用- 处理所有业务逻辑- 决定何时更新View"] end subgraph Model["Model"] M1["数据和业务逻辑"] end View -->|"用户事件"| Presenter Presenter -.->|"weak引用调用协议方法更新UI"| View Presenter <-->|"获取/更新数据"| Model MVP的三个组件 Model（模型层） 与MVC中的Model相同，负责数据和业务逻辑。 // Model struct User { let id: Int let name: String let email: String let avatarURL: URL? } // Service protocol UserServiceProtocol { func fetchUser(id: Int, completion: @escaping (Result<User, Error>) -> Void) func updateUser(_ user: User, completion: @escaping (Result<Void, Error>) -> Void) } class UserService: UserServiceProtocol { func fetchUser(id: Int, completion: @escaping (Result<User, Error>) -> Void) { // 网络请求实现 } func updateUser(_ user: User, completion: @escaping (Result<Void, Error>) -> Void) { // 更新用户实现 } } View（视图层） 在MVP中，View是"被动的"（Passive View），它： ...

前言 iOS 上的 WebView 目前以 WKWebView 为事实标准。它对外表现得像一个 UIView 子类，但内部其实对接着整个 WebKit 引擎——一个由多个独立进程协作的庞大系统。日常开发中遇到的那些困扰：为什么 Web 页白屏不会把 App 带崩？为什么 Cookie 和 App 自身的 NSHTTPCookieStorage 总是对不上？为什么 JS 调用 Native 永远是异步？为什么 NSURLProtocol 拦不到 WKWebView 的请求？这些问题单看 API 都得不到答案，必须下潜到 WebKit 源码里才能看清楚。 好在 WebKit 是 Apple 官方开源的项目，仓库在 github.com/WebKit/WebKit。本文基于其 Source/ 目录下的公开源码，按"源码地图 → 多进程架构 → 各进程职责 → 全链路串联 → 工程启示"的顺序，把 WKWebView 从创建到渲染一帧的底层机制梳理清楚。 一、先看源码地图 阅读源码前，先在脑子里建立目录结构。以 WebKit/WebKit 仓库的 Source/ 目录为例： Source/ ├── JavaScriptCore/ # JS 引擎（解释器、JIT 编译器、GC） ├── WebCore/ # 渲染引擎核心（DOM、CSSOM、Layout、Paint） ├── WebKit/ # 多进程框架 + Cocoa 层 API │ ├── UIProcess/ # 主进程侧（App 进程） │ │ ├── API/Cocoa/ # WKWebView.mm、WKProcessPool.mm 等 │ │ ├── API/ios/ # WKWebViewIOS.mm │ │ ├── ios/ # WKContentView.mm、WebPageProxyIOS.mm │ │ └── ... │ ├── WebProcess/ # 渲染进程侧（WebContent） │ ├── NetworkProcess/ # 独立网络进程 │ ├── GPUProcess/ # 独立 GPU 进程 │ └── Shared/ # 跨进程共享的数据结构、IPC 消息定义 └── WTF/ # 基础容器、线程、字符串工具库 日常 iOS 开发能看到的 WKWebView，对应的实现就在 Source/WebKit/UIProcess/API/Cocoa/WKWebView.mm。它是一个 Objective-C++ 文件，内部只是持有一个 C++ 的 WebPageProxy 对象，几乎所有实际工作都转发给它。为什么要这样设计？原因就藏在下一节要讲的多进程架构里。 ...