IOS开发

在 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 仓库。抖音改造为： ...

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开发中，经常会接触到三种重要的编程范式：面向对象编程（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同样支持面向对象编程，但提供了更现代的语法和更强的类型安全。 ...

什么是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就成为状态变化的唯一入口，所有状态转换都在一处完成。 ...

基础概念 Block 是 Apple 在 C 语言基础上扩展的语法特性（也称为 Closure / 闭包），它允许将一段代码和其执行时需要的上下文环境封装为一个可传递的对象。Block 在 Objective-C 和 C/C++ 中均可使用，是 GCD、动画 API、回调等场景的核心机制。 // Block 的声明与调用 void (^myBlock)(NSString *) = ^(NSString *name) { NSLog(@"Hello, %@", name); }; myBlock(@"World"); 一个核心问题是：Block 是函数指针还是对象？ 答案是——Block 本质上是一个 OC 对象。它的底层是一个包含 isa 指针的 C 结构体，满足 OC 对象的基本条件；同时它也包含一个函数指针（FuncPtr），指向 Block 实际执行的代码。因此可以说，Block 是一个用对象形式包装了函数指针和捕获变量的特殊 OC 对象。 底层数据结构 通过 clang -rewrite-objc 可以将 Block 语法转换为 C++ 代码，观察其底层结构。这个转换虽然不完全等同于最终编译产物，但准确反映了 Block 的数据布局和调用机制。 编译器转换示例 对以下源码： int main() { int a = 10; void (^block)(void) = ^{ NSLog(@"%d", a); }; block(); return 0; } Clang 会将其转换为如下结构： ...

Alamofire 是 Swift 社区最广泛使用的 HTTP 网络库，由 Alamofire Software Foundation 维护，在 GitHub 已收获 42k+ star。它在 URLSession 之上构建了一整套链式 API、拦截器、认证、证书校验、重试与响应序列化等能力。本文基于最新版本 v5.11.2（2026 年 4 月发布）源码进行分析，覆盖 Swift 6 严格并发、async/await、WebSocket、OfflineRetrier 等最新特性。 一、整体架构 Alamofire 采用中央调度 + 状态机 + 协议导向的设计，核心角色分工清晰： graph TB subgraph "入口层" AF["AF(Session.default)"] end subgraph "调度层" S["Session统一调度器"] SD["SessionDelegateURLSession 桥接"] end subgraph "请求层" R["Request (基类)状态机 + 生命周期"] DR["DataRequest"] DLR["DownloadRequest"] UR["UploadRequest"] DSR["DataStreamRequest"] WSR["WebSocketRequest"] end subgraph "拦截层" RA["RequestAdapter请求改写"] RR["RequestRetrier失败重试"] RI["RequestInterceptor= Adapter + Retrier"] end subgraph "服务层" RS["ResponseSerializer响应序列化"] STE["ServerTrustEvaluating证书/公钥校验"] EM["EventMonitor事件监控"] MP["MultipartFormData表单编码"] end subgraph "系统层" US["URLSession / URLSessionTask"] end AF --> S S --> SD S -->|创建| R R --> DR & DLR & UR & DSR & WSR S -.使用.-> RI RI -.= .-> RA & RR R -.序列化.-> RS SD -.校验.-> STE S -.通知.-> EM UR -.构建.-> MP SD <-->|delegate| US R -->|执行| US 源码目录（Source/，总计约 17000 行纯 Swift 代码）： ...

当 iOS 工程的规模突破 CocoaPods / Xcode 原生构建体系的舒适区，Bazel 就成为下一代构建系统的首选。字节跳动的头条、抖音、Airbnb、Uber、Lyft、Pinterest、Square、Bilibili 等都已把 iOS 工程迁到 Bazel。本文介绍 Bazel 的核心原理、在 iOS 上的生态（rules_apple / rules_swift / rules_xcodeproj）以及大厂落地实践。 为什么是 Bazel CocoaPods + Xcode 在超大工程上的固有瓶颈： 粗粒度依赖：以 Pod / Target 为单位，增量编译颗粒粗 隐式依赖：Build Phases 隐含顺序，难以沙箱化 难以远程缓存：编译环境非 hermetic，hash 易变 难以远程执行：Xcode Build System 绑定本地 macOS Bazel 针对这些问题从设计之初就提供了： 能力 Bazel Xcode/CocoaPods 依赖粒度 文件级 Target 级 依赖显式化 必须声明 部分隐式 Sandbox 默认开启 无 远程缓存 原生 需第三方（ccache/Rugby） 远程执行 原生 不支持 跨语言 一流（Swift/OC/C++/Go/Rust/JS） 主要 Apple 平台 多平台 天生 iOS/macOS 为主 Bazel 核心概念 Workspace 与 Package WORKSPACE # 仓库根，声明外部依赖 foo/ ├── BUILD.bazel # package，本目录的构建声明 ├── main.swift └── util/ └── BUILD.bazel # 子 package Workspace：整个 Bazel 仓库，一个 WORKSPACE 文件一个仓 Package：任何包含 BUILD.bazel 的目录 Target：BUILD 文件里的一个 rule 调用，比如 swift_library(name = "foo") Label：Target 的全局 ID，形如 //foo/util:util Rule Rule 是构建函数，输入 sources + deps，输出 artifacts： ...

什么是MVC MVC（Model-View-Controller）是Apple官方推荐的iOS应用架构模式，也是最基础、最常见的架构。它将应用分为三个核心组件： Model（模型）：负责数据和业务逻辑 View（视图）：负责界面展示 Controller（控制器）：负责协调Model和View MVC的结构（Apple MVC） graph TD V[ViewUIView] -->|用户事件| C[ControllerUIViewController] C -->|更新UI| V C <-->|读写数据| M[Model数据层] 在Apple的MVC中，View和Model之间不能直接通信，所有交互都必须通过Controller中转。 Model（模型层） Model负责： 数据的存储和管理 业务逻辑处理 网络请求和数据持久化 数据验证 // Model示例 struct User { let id: Int let name: String let email: String var isValidEmail: Bool { let emailRegex = "[A-Z0-9a-z._%+-]+@[A-Za-z0-9.-]+\\.[A-Za-z]{2,64}" let emailPredicate = NSPredicate(format: "SELF MATCHES %@", emailRegex) return emailPredicate.evaluate(with: email) } } class UserService { func fetchUser(id: Int, completion: @escaping (Result<User, Error>) -> Void) { // 网络请求逻辑 } } View（视图层） View负责： ...

Instruments 是 Xcode 内置的性能分析套件，基于 DTrace/Apple Trace 基础设施构建，可以对 iOS、iPadOS、macOS、watchOS、tvOS、visionOS 的应用与系统进行 CPU、内存、图形、能耗、网络、I/O 等各个维度的观测。 Xcode 26（WWDC25）对 Instruments 做了近年来最大规模的升级，重点包括： Power Profiler：全新的能耗分析工具，支持 Tethered 与 Passive 两种录制模式。 下一代 SwiftUI instrument：基于 Cause & Effect Graph 可视化状态变更到视图更新的因果链。 Processor Trace：基于 Apple Silicon 硬件特性的"全量指令级"采集（Xcode 16.3 引入，26 完善）。 CPU Counters 重做：引入 Bottleneck Analysis 方法论与 CPU Bottlenecks 模板。 Foundation Models instrument：为 FoundationModels 框架提供 Prompt / Asset Loading / Inference 分阶段观测。 Animation Hitches 重做：修正多显示器场景下的统计，数据量显著减少，处理更快。 UI 重设计：主菜单精简、Settings 页面重写、Track 次级菜单、Launch/Attach 环境变量配置。 一、Instruments 基础 1.1 启动 Instruments 的几种方式 方式 使用场景 Xcode Product → Profile（⌘I） 日常开发，自动以 Release 模式编译并附加符号 Xcode Debug Navigator 中的图表 粗略观测 CPU / Memory / Disk / Network / Energy 直接打开 Instruments.app 对已安装的 App、系统进程或已录制的 .trace 文件进行分析 命令行 xcrun xctrace record CI / 自动化性能回归 设备端 Developer Settings 的 Power Profiler 离线、无 Mac 场景采集能耗数据 Xcode 26 中，Product → Profile 会按默认 scheme 的 Profile 构建配置（通常是 Release + -O），这与 Debug 模式的数据差异很大，做性能评估时必须用 Profile 构建。 ...

启动类型概览 iOS应用启动分为三种类型： 启动类型 描述 特点 冷启动（Cold Launch） App完全不在内存中，需要从头开始加载 耗时最长，需要完整执行所有启动流程 热启动（Warm Launch） App在后台被挂起（Suspended），重新进入前台 最快，只需恢复App状态，不需要重新创建进程 预热启动（Pre-warm Launch） 系统预测用户可能启动App，提前在后台执行部分启动流程 iOS 15+引入，介于冷启动和热启动之间 graph LR subgraph "冷启动（耗时最长）" A1[创建进程] --> A2[加载dylib] A2 --> A3[Rebase/Bind] A3 --> A4[+load] A4 --> A5[main] A5 --> A6[首帧渲染] end subgraph "预热启动（iOS 15+）" B1[系统提前完成（后台）:创建进程 → 加载dylib → Rebase/Bind] --> B2[用户点击后执行:+load → main → 首帧渲染] end subgraph "热启动（最快）" C1[唤醒进程] --> C2[WillEnterForeground] C2 --> C3[DidBecomeActive] C3 --> C4[恢复UI] end 一、冷启动（Cold Launch） 冷启动是最完整的启动流程，也是启动优化的主要关注点。 冷启动流程概览 flowchart TD Start([App 冷启动流程]) --> PreMain subgraph PreMain["Pre-main 阶段"] direction TB A[加载可执行文件] --> B[加载动态库（包括 Swift Runtime）] B --> C[Rebase & Bind] C --> D[ObjC Runtime 初始化（类注册、Category 附加）] D --> D2[Swift Runtime 元数据注册（类型元数据、协议遵循表）] D2 --> D3[调用 +load 方法] D3 --> E[执行 Initializers（C++静态构造函数、__attribute__）] end PreMain --> MainPhase subgraph MainPhase["main 阶段"] direction TB F[main函数] --> G[UIApplicationMain] G --> H[AppDelegate回调] H --> I[首帧渲染（创建Window、RootViewController、首屏UI）] end MainPhase --> End([启动完成]) Pre-main 阶段 Pre-main阶段是指从用户点击App图标到main函数执行之前的过程，这个阶段主要由dyld（动态链接器）负责。 ...