Instruments — 是什么，Time Profiler 和 Allocations 的功能

什么是 Instruments？

Instruments — 是一个性能分析和跟踪系统，是 Xcode 的一部分，基于 Sun Microsystems 开发的 DTrace 技术构建。Instruments 将数十种性能分析工具（模板）整合在统一界面中：只需选择模板，通过 Xcode 运行应用程序，然后开始收集数据。

Instruments 的架构基于客户端-服务器模型：设备上的代理收集数据并通过 USB 连接将其传输到 Mac。这最大程度地减少了分析工具对应用程序性能的影响——Instruments 主要在主机端运行。根据 WWDC 2022 的数据，在 1 毫秒采样频率下，Time Profiler 的开销小于 3%。

Instruments 支持自定义模板——开发者可以在一个分析会话中组合多个工具。例如，同时运行 Time Profiler + Allocations + Leaks，并查看 CPU 峰值与内存分配之间的关联。这提供了每个组件单独分析所无法获得的整体性能视图。

默认可用的模板

Xcode 附带 16 个预装的 Instruments 模板：Time Profiler、Allocations、Leaks、Energy Log、Network、Core Animation、Metal System Trace、File Activity、System Trace 等。每个模板都针对特定任务进行了优化，并预先配置了正确的触发器和过滤器设置。

Time Profiler：CPU 性能分析

Time Profiler — 是最常用的 Instruments 模板。它基于调用堆栈采样工作：每 1-10 毫秒，系统记录应用程序所有线程的调用堆栈。会话停止后，Instruments 汇总样本并显示哪些方法和函数占用了最多时间。结果以 Call Tree（按 Self Weight 排序的调用树）的形式呈现。

Time Profiler 的关键指标——Self Weight（直接在方法中花费的时间，不包括子方法调用）。正是 Self Weight 显示了哪些函数真正给处理器带来负载。Weight（包含子方法的总时间）可能具有欺骗性：高 Weight 的方法可能只是调用了另一个慢速方法，而它本身很快。

import UIKit

class ImageGalleryViewController: UIViewController {
    // Time Profiler 将显示 cellForItemAt 具有 Self Weight = 40%
    // 在其中 decodeImage 占用 35% — 这是一个瓶颈

    func collectionView(
        _ collectionView: UICollectionView,
        cellForItemAt indexPath: IndexPath
    ) -> UICollectionViewCell {
        let cell = collectionView.dequeueReusableCell(
            withReuseIdentifier: "ImageCell",
            for: indexPath
        ) as! ImageCell
        // ❌ decodeImage — 瓶颈 (Self Weight = 35%)
        cell.imageView.image = UIImage(contentsOfFile: imagePath)
        return cell
    }
}

在分析 Time Profiler 时，请注意在 com.apple.main-thread 中执行的方法。如果主线程上的 Self Weight 超过每帧 16 毫秒的阈值——UI 将出现卡顿。解决这些问题的方法——通过 Grand Central Dispatch (GCD) 将图像解码、布局计算和数据处理从主线程转移到后台。

如何阅读 Time Profiler 中的 Call Tree

Call Tree — 是所有方法调用的层次结构视图，按 Self Weight 排序。Call Tree 中最重的方法——第一行。展开该行，您可以看到此方法调用了哪些子方法以及它们花费了多少时间。寻找那些 Self Weight（自身时间）显著超过 Weight（总时间）的方法——这是同步阻塞和等待的标志。

Allocations：实时内存跟踪

Allocations — 是用于监控应用程序所有内存分配的工具。它显示在每个时刻创建了哪些对象、数量以及总大小。与 Android Studio 中的 Memory Profiler 不同，Allocations 支持 Heapshot——活动对象的快照，并可比较两个快照。

Allocations 的界面由两个主要部分组成：All Allocations（按所有对象类型的汇总统计）和 Call Trees（按创建对象的方法细分的调用树）。要查找泄漏，请使用 Heapshot Analysis：在执行场景之前拍摄快照，执行场景，之后拍摄快照——然后比较哪些新对象留在了内存中。

根据 Apple Developer Documentation，通过 Allocations 检测到的最常见泄漏模式——滚动集合时过度创建 UIView 和 CALayer。如果每次滚动时活动 UIView 的数量都在增加，而集合在重用单元格——那么某个地方在创建额外的视图而没有释放旧的视图。Allocations 会显示这些视图被创建的精确调用堆栈。

Heapshot Analysis：比较内存快照

Heapshot — 是 Allocations 中活动对象的快照。在执行场景之前拍摄 Heapshot，执行场景，然后拍摄第二个 Heapshot。快照之间的差异将显示哪些对象已被创建但未释放。理想的结果——仅临时对象（Autorelease pool）的增长。要进行精确分析，请在单个会话中使用 Allocations + Leaks 的组合。Allocations 显示哪些对象未被释放，而 Leaks 显示原因（哪个强引用在持有它们）。每次怀疑泄漏时都运行双重会话。

Leaks：自动查找内存泄漏

Leaks — 是用于检测 iOS 和 macOS 应用程序内存泄漏的专业工具。与仅显示分配的 Allocations 不同，Leaks 主动扫描堆以查找 retain cycles——两个或多个对象通过强引用互相持有的情况。

Leaks 与 Cycles & Roots（对象持有关系图的可视化工具）协同工作。当检测到泄漏时，Leaks 显示循环中的所有对象、它们的 retain count 以及引用传递的精确字段。开发者只需查看图表并理解哪个引用需要替换为 weak。

该工具会自动在时间线上用红色标记突出显示泄漏。Leaks 实时工作：一旦系统检测到泄漏，它会立即通知开发者。这允许现场修复问题，无需等待转储和事后分析。

根据 WWDC 2022 的数据，Leaks 能够检测甚至复杂的多层 retain cycles——例如，当三个或更多对象形成强引用的封闭链时。对于此类循环的诊断，Cycles & Roots 图表是不可或缺的：它直观地显示对象如何相互闭合。

如何阅读 Cycles & Roots 图表

图表的每个节点是一个对象，每个箭头——一个强引用。循环——箭头的闭合轮廓。节点的颜色表示状态：红色——泄漏的对象，绿色——根（GC Root），灰色——中间对象。要修复泄漏，找到可以在不违反逻辑的情况下改为 weak 的箭头——然后在代码中替换引用类型。

Energy Log：能耗分析

Energy Log — 是用于测量应用程序能耗的 Instruments 模板。它从设备的硬件传感器收集数据：CPU 负载、Wi-Fi 和蜂窝网络状态、GPS 使用情况、显示屏和蓝牙。Energy Log 显示应用程序中哪些操作导致最大的电池消耗，并将它们叠加在时间尺度上的能耗图表上。

该工具根据能耗级别对操作进行分类：低（处理器正常工作）、中（Wi-Fi 传输）、高（GPS、移动网络、GPU）。如果 Energy Log 长时间显示高级别的红色指示器——应用程序正在后台消耗电池，并将被用户删除。

Energy Log 检测到的典型问题：没有时间限制的 WakeLock（应用程序在完成任务后保持处理器活动）、后台高精度位置更新（每几秒请求一次坐标）、网络会话异常（频繁重新连接到服务器）。Energy Log 建议记录每个此类事件，并添加条件以关闭高能耗操作。

要测试能耗，请使用电池供电的真实设备——在模拟器上，能耗指标不正确。将 Energy Log 与 UI 测试一起运行，以在 CI 中自动检查电池消耗。

如何运行和解释 Instruments 结果

从 Xcode 运行 Instruments 有两种方式：通过 Product → Profile (⌘I) 菜单，或通过 Launchpad 将 Instruments 作为独立应用程序打开。第一种方式更方便：Xcode 会自动以分析模式构建应用程序，并在连接的设备上使用所选模板运行它。会话停止后，Instruments 将跟踪保存到扩展名为 .trace 的文件中。

结果的解释取决于模板。对于 Time Profiler，查看按 Self Weight 排序的 Call Tree——最顶部的方法是您的主要瓶颈。对于 Allocations——查看循环场景后的 # Living：如果对象数量增加，请查找泄漏。对于 Leaks——查看红色标记和 Cycles & Roots 图表。比较优化前后的结果——这是确认更改有效性的唯一方法。

// CI 中 Instruments 的命令行
// 将 Instruments 集成到 CI/CD 流水线中
import XCTest

class PerformanceTests: XCTestCase {
    func testScrollPerformance() {
        // 测量集合滚动时间
        measure(metrics: [XCTCPUMetric(), XCTMemoryMetric()]) {
            app.scrollToBottom()
        }
    }
}

在 CI 中，可以通过 xcodebuild -showBuildSettings 和 xcrun xctrace 从命令行运行 Instruments。这样可以自动化每次提交的分析，避免回归。对于分析，请使用基线比较：如果指标相对于前一次提交恶化了 5%——管道应停止。

使用 Instruments 的主要错误：在模拟器而非设备上分析（CPU 和 GPU 数据不正确）、没有场景的数据收集（结果是随机的）、忽略 Call Tree（只看图表，不看具体方法）。纠正这些错误可以获得 80% 的分析质量。