IOS开发

Kingfisher 是一款纯 Swift 图片下载和缓存库，支持 iOS、macOS、tvOS、watchOS 和 visionOS 全平台。当前最新版本为 8.8.0（2026年3月），已全面适配 Swift 6 严格并发模型。本文基于 v8.x 源码进行分析。 一、整体架构 Kingfisher 采用协议导向的模块化设计，核心由四大组件构成： graph TB subgraph "UI层" A["UIImageView.kf / KFImage"] end subgraph "管理层" B["KingfisherManager"] end subgraph "功能层" C["ImageDownloader"] D["ImageCache"] E["ImageProcessor"] end subgraph "存储层" F["MemoryStorage.Backend(NSCache)"] G["DiskStorage.Backend(FileManager)"] end A -->|"retrieveImage"| B B -->|"下载"| C B -->|"缓存"| D B -->|"处理"| E D --> F D --> G 源码目录结构： Sources/ ├── General/ # KingfisherManager, KingfisherOptionsInfo, Resource, Source ├── Networking/ # ImageDownloader, SessionDelegate, ImagePrefetcher ├── Cache/ # ImageCache, MemoryStorage, DiskStorage ├── Image/ # ImageProcessor, 图片格式处理, 滤镜 ├── Extensions/ # UIKit/AppKit 扩展 (ImageView+Kingfisher, UIButton+Kingfisher) ├── SwiftUI/ # KFImage, KFAnimatedImage, ImageBinder ├── Views/ # AnimatedImageView └── Utility/ # 辅助工具类 二、命名空间设计 — KingfisherWrapper Kingfisher 使用 kf 命名空间来避免对系统类型的污染，这是 Swift 社区广泛使用的一种模式。 ...

基础概念 KVC（Key-Value Coding，键值编码）是 Apple 提供的一种通过字符串 key 间接访问对象属性的机制，定义在 NSKeyValueCoding 协议中，NSObject 默认遵循该协议。 // 直接访问 person.name = @"Tom"; NSString *name = person.name; // KVC 访问 [person setValue:@"Tom" forKey:@"name"]; NSString *name = [person valueForKey:@"name"]; KVC 的核心价值在于：通过字符串动态访问属性，不需要在编译期知道属性名。这使得字典转模型、序列化/反序列化、Interface Builder 的 Runtime Attributes 等场景成为可能。 setValue:forKey: 的底层流程 当调用 [obj setValue:value forKey:@"name"] 时，Runtime 按照以下顺序查找： flowchart TD A["setValue:forKey:@'name'"] --> B{"查找 setter 方法"} B -->|"找到"| C["调用 setter"] B -->|"未找到"| D{"accessInstanceVariablesDirectly返回 YES?"} D -->|"YES"| E{"按顺序查找实例变量_name → _isName → name → isName"} D -->|"NO"| F["调用 setValue:forUndefinedKey:默认抛出 NSUndefinedKeyException"] E -->|"找到"| G["直接设置实例变量值"] E -->|"未找到"| F 第一步：查找 setter 方法 Runtime 按以下顺序查找 setter 方法： ...

什么是MVVM MVVM（Model-View-ViewModel）是一种通过数据绑定实现View和业务逻辑解耦的架构模式。它最初由Microsoft提出，用于WPF开发，后来被广泛应用于iOS开发。 MVVM的核心特点是： ViewModel不持有View的引用 通过数据绑定实现View和ViewModel的同步 View的状态完全由ViewModel驱动 MVVM的结构 flowchart TB subgraph View["View (ViewController)"] V1["绑定ViewModel的属性"] V2["将用户事件传递给ViewModel"] end subgraph ViewModel["ViewModel"] VM1["暴露可观察的属性"] VM2["展示逻辑 + 业务逻辑"] end subgraph Model["Model"] M1["数据模型"] M2["数据访问 (API/DB)"] end View <-->|"数据绑定 (Binding)"| ViewModel ViewModel -->|"获取/更新数据"| Model MVVM的数据流 MVVM的核心原则是：View不直接访问Model，所有交互都通过ViewModel进行。在iOS开发中，由于UIViewController的特殊地位，MVVM的数据流可以更细化为四个角色： flowchart LR subgraph View["View"] V["纯UI展示用户交互触发"] end subgraph ViewController["ViewController"] VC["数据绑定生命周期管理路由/导航"] end subgraph ViewModel["ViewModel"] VM["业务逻辑数据转换状态管理"] end subgraph Model["Model"] M["数据结构数据存储"] end VC -->|"持有"| V VC -->|"持有"| VM V -->|"1. 用户交互"| VC VC -->|"2. 转发事件"| VM VM -->|"3. 业务处理"| M M -->|"4. 数据变化"| VM VM -->|"5. 状态更新"| VC VC -->|"6. 更新UI"| V 各层职责与持有关系 组件 职责 持有关系 View 纯UI展示、触发用户交互事件 不持有其他层 ViewController 数据绑定、生命周期管理、持有View和ViewModel 持有View和ViewModel ViewModel 业务逻辑、数据转换、状态管理 持有Model/Service Model 数据结构、数据存储 不持有其他层 详细数据流说明 View → ViewController（用户交互） ...

背景 Hybrid 开发模式下，WebView 加载 H5 页面的体验一直是痛点。一个典型的 H5 页面加载流程涉及：初始化 WebView -> DNS 解析 -> 建立连接 -> 下载 HTML -> 解析 HTML -> 下载 CSS/JS/图片 -> 渲染页面。在弱网或首次加载场景下，白屏时间常常达到 2~5 秒，远不如 Native 体验。 离线包的核心思路是：将 H5 的静态资源（HTML、CSS、JS、图片、字体等）预先打包下发到客户端本地，WebView 加载时直接从本地读取资源，跳过网络请求环节，从而大幅缩短页面加载时间。 离线包加载 vs 在线加载 sequenceDiagram participant App participant WebView participant Local as 本地离线包 participant Server as 远程服务器 Note over App, Server: 在线加载流程 App->>WebView: loadURL WebView->>Server: DNS + TCP + TLS + HTTP请求 Server-->>WebView: HTML WebView->>Server: 请求 CSS/JS/图片 Server-->>WebView: 资源文件 WebView->>WebView: 渲染页面 Note over App, Server: 离线包加载流程 App->>WebView: loadURL（被拦截） WebView->>Local: 读取本地 HTML Local-->>WebView: HTML WebView->>Local: 读取本地 CSS/JS/图片 Local-->>WebView: 资源文件 WebView->>WebView: 渲染页面 对比项 在线加载 离线包加载 首屏时间 2~5秒（弱网更久） 0.5~1秒 网络依赖 强依赖 仅更新时需要网络 白屏问题 严重 基本消除 资源新鲜度 实时最新 有一定延迟 流量消耗 每次访问都消耗 仅增量更新消耗 整体架构 一个完整的离线包系统包含三大部分： ...

didFinishLaunchingWithOptions是main阶段的核心入口，在这里初始化大量SDK和服务会阻塞启动。本文介绍如何优化这个阶段的耗时。 问题分析 典型的问题代码： func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { // 所有初始化都在主线程同步执行 CrashReporter.setup() Analytics.setup() PushNotification.setup() NetworkManager.setup() DatabaseManager.setup() ImageCache.setup() AdSDK.setup() SocialSDK.setup() // ... 更多SDK return true } 这种写法的问题： 所有初始化都在主线程同步执行 无论是否需要，所有SDK都在启动时初始化 阻塞首帧渲染 优化方案 方案1：分级启动任务管理 将启动任务按优先级分类，只在启动时执行必要的任务： // 启动任务优先级 enum LaunchTaskPriority { case required // 必须在首帧前完成 case high // 首帧后立即执行 case normal // 首屏稳定后执行 case low // 空闲时执行 } // 启动任务管理器 class LaunchTaskManager { static let shared = LaunchTaskManager() private var tasks: [LaunchTaskPriority: [() -> Void]] = [:] func register(priority: LaunchTaskPriority, task: @escaping () -> Void) { if tasks[priority] == nil { tasks[priority] = [] } tasks[priority]?.append(task) } func executeRequiredTasks() { tasks[.required]?.forEach { $0() } } func executeHighPriorityTasks() { DispatchQueue.main.async { self.tasks[.high]?.forEach { $0() } } } func executeNormalTasks() { DispatchQueue.main.asyncAfter(deadline: .now() + 1.0) { self.tasks[.normal]?.forEach { $0() } } } func executeLowPriorityTasks() { // 监听RunLoop空闲时执行 CFRunLoopPerformBlock(CFRunLoopGetMain(), kCFRunLoopDefaultMode) { self.tasks[.low]?.forEach { $0() } } } } 使用示例 func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool { let manager = LaunchTaskManager.shared // 必须在首帧前完成 manager.register(priority: .required) { CrashReporter.setup() // 崩溃收集必须最先初始化 } // 首帧后立即执行 manager.register(priority: .high) { Analytics.setup() PushNotification.setup() } // 首屏稳定后执行 manager.register(priority: .normal) { AdSDK.setup() SocialSDK.setup() } // 空闲时执行 manager.register(priority: .low) { PreloadManager.preloadResources() } // 只执行必须的任务 manager.executeRequiredTasks() return true } 任务分级建议 优先级 适用场景 示例 required 崩溃收集、核心功能依赖 Crash SDK、必要的配置加载 high 用户可能很快用到 推送、统计、网络配置 normal 非首屏功能 广告SDK、社交分享 low 预加载、缓存 图片预加载、数据预热 方案2：并行初始化 将无依赖关系的初始化任务并行执行： ...

Swift 的类型推导、泛型约束求解、WMO / CMO 是编译性能的核心影响因素。理解它们能让源码层面的小改动带来显著的编译加速。本文聚焦"代码写法 + 编译开关"两方面的优化。 Swift 编译流程速览 相比 C/OC，Swift 编译多出大量工作： flowchart LR A[Parse] --> B[Sema类型检查] B --> C[SILGen生成 SIL] C --> D[SIL Optimization] D --> E[IRGenLLVM IR] E --> F[LLVM Optimization] F --> G[CodeGen] 其中 Sema（语义分析） 阶段负责类型推导，是 Swift 特有的性能热点。-debug-time-compilation 看到的 “Type checking” 时间基本都集中在这里。 类型推导与 “Too Complex” 错误 约束求解 Swift 的类型系统比大多数语言复杂： 函数重载 + 运算符重载 隐式字面量类型（Int、Double、Float80…） 泛型 + 协议 + 关联类型 闭包参数类型推导 SwiftUI 风格的 ViewBuilder / Result Builders 遇到表达式 let x = a + b * c - d，编译器需要给 + * - 每个运算符枚举所有可能的重载，在多个候选里做约束传播。当候选组合爆炸时，Sema 会放弃并抛出： ...

Swift 面试：编译流程、Runtime 与元数据源码解析 Swift 面试里问编译流程和 Runtime，通常不是想听一串名词，而是想看你能不能把 源码 -> AST -> SIL -> 优化 -> IRGen -> LLVM -> Runtime Metadata 串起来。 这篇文章按面试题展开，把答案落到 Swift 编译器源码里的 SILGen、SILOptimizer、IRGen、Metadata、Value Witness Table、Protocol Witness Table 和 HeapObject。 面试高频问题 Swift 源码从 .swift 到机器码经历哪些阶段？ AST、SIL、LLVM IR 分别负责什么？ 为什么 Swift 需要 SIL，而不是直接生成 LLVM IR？ SILGen 做什么？SILOptimizer 做什么？ IRGen 为什么要生成 Metadata 和 Witness Table？ Swift Runtime Metadata 保存了哪些信息？ Value Witness Table 是什么？ Protocol Witness Table 和 class vtable 有什么区别？ class、struct、enum 在 Runtime 表示上有什么差异？ HeapObject 和 Metadata 有什么关系？ 30 秒回答版 Swift 编译流程可以简化为： ...

objc4 runtime +load 调度：从 load_images 到 call_load_methods 这页解释 objc4 如何在 dyld 映射镜像后发现、排队并调用 Objective-C 的 +load。 重点是类与分类的顺序、父类优先、递归和重入处理，以及 runtimeLock 与 loadMethodLock 的边界。 入口：dyld callback 队列：loadable_classes / loadable_categories 调度：call_load_methods 测试：load*.m 目录 作用 实现原理 核心结构和关键函数 关键流程 带注释代码片段 测试体现的语义 作用 +load 是 Objective-C 运行时在类或分类被装入进程时主动调用的类方法。 它不依赖消息发送触发，也早于普通的 +initialize。objc4 的任务不是简单遍历所有方法并调用， 而是在 dyld 映射镜像、runtime 完成类注册和分类附着后，按照语言语义和装载依赖稳定地调用。 装载时机 dyld 通过 _dyld_objc_register_callbacks 注册 runtime 回调。镜像映射后先走 map_images，随后 load_images 处理该镜像中的非懒加载类和分类。 顺序语义 类 +load 必须父类优先；所有当前可调用的类 +load 先于分类 +load；分类必须等宿主类已经完成自己的 +load。 重入安全 +load 内部可能 dlopen 新镜像，再次进入 load_images。objc4 让内层调用只排队，真正调用由最外层 call_load_methods 收尾。 实现原理 objc4 将 +load 分成“发现”和“调用”两阶段。发现阶段需要持有 runtimeLock， 因为它要读取和实现类、解析分类、查找元类方法列表。调用阶段释放 runtimeLock， 只持有递归的 loadMethodLock，因为用户代码可能执行任意 Objective-C 行为并重新映射镜像。 ...

APM 的第一步不是写代码，而是定义指标。一个 App 的性能好坏不是一句话能说清的，必须把模糊的"快 / 稳 / 省"拆解为可量化、可对比、可报警的数字。本文把业界常用指标按"稳定性 / 流畅性 / 启动 / 资源 / 业务 / 网络"六大族分类，并补充 RUM 的 Session / View / Action / Resource / Error 口径，给出每个指标的定义、计算方式、典型目标值与常见陷阱。 一、指标设计原则 设计指标前先达成共识： 1.1 北极星分层 graph TB L0[用户体验北极星留存率 / NPS] L1[业务指标秒开率 / 转化率 / 关键路径完成率] L2[技术指标FPS / Crash率 / 启动时间] L3[原子指标单帧耗时 / 内存峰值 / 单请求耗时] L0 --> L1 --> L2 --> L3 好的指标体系应该：技术指标能解释业务指标，业务指标能解释北极星。否则就是"为了采集而采集"。 1.2 分位数思维 永远不要只看平均值。同一个启动指标： 设备 平均 P50 P90 P99 iPhone 15 800ms 750ms 900ms 1200ms iPhone SE 2 2000ms 1500ms 3500ms 8000ms 平均值把两者拉成 1400ms，但 iPhone SE 的 P99 用户"实际等了 8 秒"。APM 的所有耗时指标都必须同时提供 P50 / P90 / P99。 ...

前言 很多团队对"国际化"的理解停留在"把中文文案翻译成英文"，等真正把 App 推向多区域时就会发现远远不够：阿拉伯语用户看到的界面左右颠倒了，用户在纽约和东京看到的"今天"不是同一天，欧洲的小数点变成了逗号，日本用户抱怨价格里的¥符号指向人民币而不是日元，印度用户发现自己的 ₹1,23,456.78 被错误地按千分位显示成 ₹123,456.78，复数规则在俄语里比英语复杂得多，而这些问题单靠"翻译"都解决不了。 国际化（Internationalization，简称 i18n，取首末字母与中间 18 个字符）是架构层面的能力建设，让 App 能够适配不同语言、地区、文字方向、日历、时区、货币、单位制与文化习俗；而本地化（Localization，l10n）是针对某个具体地区的"适配落地"。两者的关系是：“国际化一次，本地化 N 次”。 本文从 NSLocale/Locale 的基础模型开始，把 iOS 国际化的完整工程面梳理清楚——文案本地化、复数/性别规则、RTL 布局、多时区、多币种、单位与数字格式、图片资源、字体、App 内切换语言、测试方法，最后给出研发规范与排查清单。 一、基础概念：Locale、Language 与 Region 1.1 Locale 不等于 Language 大多数工程师第一次接触国际化时会把"语言"和"地区"混为一谈，这在 iOS 下会直接导致格式错误。 Language（语言）：zh、en、ar、ja…决定 UI 文字内容。 Region（地区）：CN、US、SA、JP…决定格式（日期、数字、货币、时间制 12/24h、起始星期、度量单位）。 Locale（语言+地区）：两者合成一个完整的标识，如 zh_CN、en_US、ar_SA、en_IN。 一个美国人移居日本后，完全可能把 iPhone 语言设为英文，但地区设为日本。此时： 场景 期望 UI 文案 英文 日期格式 1月23日(月) 风格？No，应显示 January 23 (Mon)，因为语言决定月/星期的名字 数字分隔符 , 作千分位（与日本/美国一致） 货币符号 ¥（JPY） 温度单位 ℃（日本） 首日周 周日（日本区域） 对应的 Locale 是 en_JP——看似奇怪，但在现实中非常普遍。代码里要区分"用哪个语言去查字符串"和"用哪个 Locale 去格式化数据"： let preferredLanguage = Locale.preferredLanguages.first ?? "en" let currentLocale = Locale.current let formatter = DateFormatter() formatter.locale = currentLocale formatter.dateStyle = .long print(formatter.string(from: Date())) 不要传 Locale(identifier: "en") 去格式化数字，那会丢掉用户的区域偏好。 ...