性能优化

卡顿是影响用户体验的关键问题之一。当应用无法在一帧的时间内（通常为16.67ms）完成渲染工作时，就会出现掉帧，用户会感知到界面不流畅。 本系列文章从渲染原理入手，系统性地介绍iOS卡顿的检测与优化方法。 卡顿监控是 APM 流畅性子系的核心能力，线上指标体系、检测采集、上报策略请参考 APM 系列：指标体系、数据采集、业界方案（微信 Matrix / 字节 Slardar 卡死监控）。 什么是卡顿 iOS设备的屏幕刷新率通常为60Hz（ProMotion设备可达120Hz），这意味着每秒需要渲染60帧画面。每一帧的渲染时间窗口约为16.67ms（1000ms / 60）。 当CPU或GPU无法在这个时间窗口内完成工作时，就会发生掉帧（Frame Drop），用户会感知到卡顿。 掉帧情况 用户感知 严重程度 偶尔掉1-2帧 几乎无感知 轻微 连续掉帧 明显卡顿 中等 长时间阻塞（>250ms） 界面冻结 严重 渲染流程概述 iOS的渲染流程涉及CPU和GPU的协作，通过Core Animation Pipeline完成： flowchart TB subgraph APP["App 进程（CPU 阶段）"] direction TB Layout["Layout（布局计算）layoutSubviews、约束计算"] Display["Display（绘制显示）drawRect:、文本绘制"] Prepare["Prepare（准备）图片解码、格式转换"] Commit["Commit（提交）打包图层树"] Layout --> Display --> Prepare --> Commit end subgraph RS["Render Server 进程（GPU 阶段）"] direction TB Decode["解码图层树"] Vertex["顶点着色器"] Raster["光栅化"] Fragment["片段着色器"] Buffer["帧缓冲区写入"] Decode --> Vertex --> Raster --> Fragment --> Buffer end APP -->|"IPC 传输"| RS RS --> VSync["VSync 信号到来"] VSync --> Screen["显示到屏幕"] CPU与GPU的职责 阶段 主要工作 常见瓶颈 CPU 布局计算、视图创建、文本计算、图片解码 复杂布局、大量文本、主线程阻塞 GPU 纹理渲染、图层混合、离屏渲染 离屏渲染、大量透明图层、超大图片 卡顿的常见原因 CPU瓶颈 主线程阻塞：耗时操作在主线程执行 复杂布局：大量约束计算、频繁布局 文本计算：复杂富文本、大量文本渲染 图片解码：大图片在主线程解码 对象创建：大量对象的创建和销毁 GPU瓶颈 离屏渲染：圆角、阴影、遮罩触发离屏渲染 图层混合：大量透明图层叠加 超大图片：纹理尺寸超过GPU限制 复杂特效：模糊、滤镜等GPU密集操作 文章导航 本系列包含以下文章，建议按顺序阅读： ...

App Thinning是Apple提供的包体积优化技术，让用户只下载适合其设备的内容。本文详细介绍App Thinning的三个组成部分及其原理。 整体架构 开发者上传： ┌─────────────────────────────────────────┐ │ Universal IPA │ │ ├── arm64 代码 │ │ ├── @1x/@2x/@3x 图片 │ │ ├── iPhone/iPad 资源 │ │ └── Metal GPU资源（OpenGL ES已弃用） │ └─────────────────────────────────────────┘ ↓ App Store处理 ↓ ┌───────────┐ ┌──────────┐ ┌──────────┐ │ iPhone 12 │ │ iPhone 8 │ │ iPad Pro │ │ 变体 │ │ 变体 │ │ 变体 │ │ @3x图片 │ │ @2x图片 │ │ @2x图片 │ │ arm64 │ │ arm64 │ │ arm64 │ │ A14 GPU │ │ A11 GPU │ │ M1 GPU │ └───────────┘ └──────────┘ └──────────┘ App Thinning包含三个部分： ...

在进行包体积优化之前，首先需要了解如何分析包体积。本文介绍常用的分析工具和Mach-O文件结构。 查看IPA构成 解压IPA文件分析各部分大小： # 解压IPA unzip -q YourApp.ipa -d ./ipa_content # 查看各文件大小 find ./ipa_content -type f -exec ls -lh {} \; | sort -k5 -h -r | head -20 LinkMap分析 LinkMap文件记录了链接器生成可执行文件的详细信息，可以精确分析二进制大小： # Build Settings中设置 Write Link Map File = YES Path to Link Map File = $(TARGET_TEMP_DIR)/$(PRODUCT_NAME)-LinkMap-$(CURRENT_VARIANT)-$(CURRENT_ARCH).txt LinkMap文件结构 # Path: /path/to/YourApp # Arch: arm64 # Object files: [ 0] linker synthesized [ 1] /path/to/ViewController.o [ 2] /path/to/Model.o # Sections: # Address Size Segment Section 0x100001000 0x00012345 __TEXT __text 0x100013345 0x00001234 __TEXT __stubs # Symbols: # Address Size File Name 0x100001000 0x00000100 [ 1] -[ViewController viewDidLoad] 0x100001100 0x00000050 [ 2] -[Model init] 解析脚本 可以使用脚本解析LinkMap统计各模块大小： ...

可执行文件通常占iOS应用包体积的30-50%，是优化的重点。本文介绍各种可执行文件优化手段及其原理。 编译器优化选项 优化级别原理 编译器优化级别控制了LLVM在编译时应用的优化Pass数量和类型。 什么是优化Pass？ Pass是指编译器对代码进行的一次特定优化处理过程。LLVM将优化工作分解为多个独立的Pass，每个Pass负责一种特定类型的优化： 源代码 → 前端解析 → IR（中间表示）→ Pass1 → Pass2 → Pass3 → ... → 优化后的代码 → 机器码 常见的优化Pass包括： Pass名称 作用 Dead Code Elimination 删除永远不会执行的代码 Constant Folding 编译时计算常量表达式，如3+5直接变成8 Function Inlining 将函数调用替换为函数体本身 Loop Unrolling 展开循环，减少循环控制开销 Common Subexpression Elimination 消除重复计算的表达式 不同的优化级别启用不同数量和类型的Pass： # Build Settings Optimization Level = -Os # 级别：-Os 优化大小（推荐用于Release） -O0（无优化） 不应用任何优化Pass，编译速度最快。代码按原样生成，保留所有变量和控制流，便于调试。适用于Debug构建。 -O1（基础优化） 应用不显著增加编译时间的基础优化，包括： 基本的死代码消除 简单的常量折叠 基本块合并 死代码消除： 死代码消除（Dead Code Elimination）是指编译器自动移除永远不会被执行或执行结果不会被使用的代码。注意：这里的死代码消除是编译阶段的优化，作用于函数内部；而后文提到的Dead Code Stripping是链接阶段的优化，用于移除未被引用的整个函数或类。 -O1 适合需要一定优化但对编译速度敏感的场景。 -O2（标准优化） 应用大多数优化Pass，是性能和体积的平衡点。包括： ...

资源文件通常占iOS应用包体积的40-60%，是优化的重要方向。本文介绍各种资源优化手段及其原理。 图片优化 Asset Catalog原理 Asset Catalog（.xcassets）编译后生成Assets.car文件，这是一个优化过的资源容器： 编译前： Images.xcassets/ ├── AppIcon.appiconset/ │ ├── icon-60@2x.png │ └── icon-60@3x.png ├── Logo.imageset/ │ ├── logo@2x.png │ └── logo@3x.png └── Contents.json 编译后： Assets.car ← 单一文件，包含所有资源 Assets.car的优化： 图片被重新编码，使用更高效的压缩 支持App Thinning，按设备分发 运行时高效加载（内存映射） 可以使用assetutil查看Assets.car内容： assetutil --info Assets.car 图片压缩原理 PNG压缩原理： PNG使用DEFLATE无损压缩，但可以通过以下方式减小体积： 原始PNG结构： ┌────────────────┐ │ PNG Header │ ├────────────────┤ │ IHDR (图像信息) │ ├────────────────┤ │ IDAT (图像数据) │ ← 压缩的像素数据 ├────────────────┤ │ 辅助chunks │ ← 可以移除 └────────────────┘ 优化方向： 1. 移除不必要的chunks（如tEXt、iTXt） 2. 优化DEFLATE压缩参数 3. 减少颜色数量（有损） 4. 使用更高效的滤波器 有损压缩原理（pngquant）： ...

包体积（IPA大小）是iOS应用的重要质量指标。App Store对蜂窝网络下载有200MB的提示阈值，超过这个大小会弹窗询问用户是否使用流量下载（iOS 13之前是强制要求Wi-Fi）。这个弹窗会增加用户的决策成本，影响下载转化率。因此，包体积优化对于用户获取和留存都有重要影响。 包格式介绍 iOS开发中常见的包格式有三种： 格式 扩展名 说明 .app 目录 应用程序包，是一个包含可执行文件和资源的目录结构 .xcarchive 目录 Xcode归档包，包含.app、dSYM符号文件、构建信息等 .ipa 文件 安装包，本质是ZIP压缩的.app，用于分发和安装 日常使用场景： 开发调试：Xcode直接将.app安装到模拟器或真机 测试分发：使用.ipa通过TestFlight、蒲公英、fir.im等平台分发给测试人员 App Store上架：通过Xcode或Transporter将.xcarchive导出并上传到App Store Connect（实际上传的是从xcarchive导出的IPA或直接上传xcarchive中的内容） .app（Application Bundle） .app是macOS/iOS应用的标准格式，实际上是一个目录（Finder中显示为单个文件）。包含： 可执行文件（Mach-O格式） Info.plist配置文件 资源文件（图片、音频、本地化文件等） Frameworks目录（动态库） PlugIns目录（App Extension） .xcarchive（Xcode Archive） .xcarchive是Xcode的归档格式，用于保存完整的构建产物。目录结构： YourApp.xcarchive/ ├── Products/ │ └── Applications/ │ └── YourApp.app # 应用程序包 ├── dSYMs/ │ └── YourApp.app.dSYM # 符号文件（用于崩溃解析） ├── Info.plist └── SCMBlueprint/ # 源码管理信息 主要用途： 保存dSYM符号文件，用于线上崩溃日志符号化 导出不同分发渠道的IPA（App Store、Ad Hoc、Enterprise） 上传到App Store Connect .ipa（iOS App Store Package） .ipa是iOS应用的安装包格式，本质是一个ZIP压缩文件。结构： ...