iOS 进阶

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

前言 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 对象，几乎所有实际工作都转发给它。为什么要这样设计？原因就藏在下一节要讲的多进程架构里。 ...

背景 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秒 网络依赖 强依赖 仅更新时需要网络 白屏问题 严重 基本消除 资源新鲜度 实时最新 有一定延迟 流量消耗 每次访问都消耗 仅增量更新消耗 整体架构 一个完整的离线包系统包含三大部分： ...

前言 很多团队对"国际化"的理解停留在"把中文文案翻译成英文"，等真正把 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") 去格式化数字，那会丢掉用户的区域偏好。 ...

前言 打开 iPhone 的"设置 → 辅助功能 → 旁白（VoiceOver）"，再用三指在屏幕上滑动，iPhone 就会逐个读出当前界面上的每个控件："登录按钮，双击以激活"、"用户名，文本框，已填写 ancheng"、"价格，¥99"。这背后支撑 VoiceOver、开关控制（Switch Control）、语音控制（Voice Control）、全键盘访问（Full Keyboard Access）、Xcode UITest、AI Agent 识屏 等一系列能力的，是一棵并行于 UIView 视图树的 无障碍树（Accessibility Tree，AX Tree）。 对大多数 iOS 工程师来说，无障碍树是"黑盒"：设了 isAccessibilityElement = true、填了 accessibilityLabel，然后就不管了。但一旦遇到以下问题，就不得不深入理解它的工作机制： 为什么 UITest 里用 XCUIElement 定位不到某个按钮？ 为什么打开 VoiceOver 后 App 明显变卡？ 为什么一个自绘的 CALayer 按钮在 VoiceOver 下无法被朗读？ 为什么 UILabel 嵌在 UIStackView 里焦点顺序是乱的？ SwiftUI 的 .accessibilityElement(children: .combine) 到底合并了什么？ Accessibility Inspector 里看到的树结构从哪儿来？ AI Agent（如 iOS 上的 Claude、ChatGPT Mac 客户端）是如何"看到"屏幕的？ 本文从操作系统层的 AX 架构讲起，逐层拆解：AX Server 守护进程、UIKit 中的 UIAccessibility 协议、UIAccessibilityElement 类、UIAccessibilityContainer 协议、焦点排序算法、SwiftUI 的 AX 实现、辅助技术的工作原理、性能优化、UITest 与 AI 识屏原理、调试工具与最佳实践。 ...

音视频开发是iOS中一个庞大且核心的技术领域，涵盖采集、编码、传输、解码、渲染等完整链路。本文从基础概念出发，深入iOS平台提供的音视频框架和底层原理。 音视频处理全链路 一个完整的音视频系统（如直播、视频通话、短视频）包含以下环节： flowchart LR A["采集Camera/Mic"] --> B["前处理美颜/降噪"] B --> C["编码H.264/AAC"] C --> D["封装FLV/MP4"] D --> E["传输RTMP/HLS"] E --> F["解封装解析容器"] F --> G["解码VideoToolbox"] G --> H["后处理滤镜/混音"] H --> I["渲染Metal/Speaker"] 环节 做什么 iOS中对应的技术 采集 从摄像头/麦克风获取原始数据 AVCaptureSession 前处理 美颜、滤镜、降噪、回声消除 CoreImage、vDSP 编码 将原始数据压缩为体积更小的格式 VideoToolbox、AudioToolbox 封装 将编码后的音视频数据打包到容器中 AVAssetWriter 传输 通过网络发送到服务器或其他端 URLSession、第三方推流SDK 解封装 从容器中分离出音频流和视频流 AVAssetReader 解码 将压缩数据还原为原始像素/采样数据 VideoToolbox、AudioToolbox 后处理 滤镜、水印、混音等 CoreImage、Metal 渲染 将画面显示到屏幕、声音输出到扬声器 AVSampleBufferDisplayLayer、Metal、AudioUnit 核心术语 在深入细节之前，先了解几个贯穿全文的核心概念： 什么是编解码器（Codec） Codec = Coder + Decoder，即编码器+解码器的合称。编码器负责将原始音视频数据压缩为更小的格式，解码器负责将压缩数据还原。 音视频中有两类完全不同的"格式"概念，初学者极易混淆： 编码格式（Codec）：定义数据怎么压缩 视频：H.264、H.265、VP9、AV1 音频：AAC、MP3、Opus、FLAC 封装格式（Container）：定义压缩后的数据怎么组织存储 MP4、MOV、FLV、MKV、TS 两者是独立的，可以自由组合: MP4容器 + H.264视频 + AAC音频 （最常见的组合） MOV容器 + H.265视频 + AAC音频 （iPhone录制默认） FLV容器 + H.264视频 + AAC音频 （直播推流常用） MKV容器 + AV1视频 + Opus音频 （新一代免费组合） 什么是H.264和H.265 H.264（也叫AVC，Advanced Video Coding）是目前使用最广泛的视频编码标准，由ITU-T和ISO/IEC联合制定，2003年发布。它定义了一套将视频帧压缩为比特流的算法规范——包括如何划分图像块、如何预测、如何变换量化等。几乎所有设备和平台都支持H.264硬件解码。 ...