xcode中diagnostics中各选项的用途

iOS开发小挖
295 阅读16分钟

image.png

Address Sanitizer （Scheme 的 Diagnostics中）

Sanitizer 消毒杀菌剂，食品防腐剂

它是一种用于检测内存错误的工具，最初由 Google 开发，并集成到了 LLVM 编译器中。Xcode 从版本 7 开始支持 Address Sanitizer，它能够帮助开发者识别并解决多种类型的内存错误。 当你运行应用时，如果遇到任何由 ASan 可以检测到的问题，它会立即暂停执行并在控制台输出详细的错误报告，包括问题发生的源代码位置、堆栈跟踪等信息。

Address Sanitizer 主要用于检测以下几类内存错误：

  1. Use-after-free（释放后使用） ：尝试访问已经被释放的内存。
  2. Out-of-bounds accesses（越界访问） ：数组或缓冲区的读写操作超出了分配给它们的边界。
  3. Double free（重复释放） ：多次释放同一块内存。
  4. Memory leaks（内存泄漏） ：虽然严格意义上不属于内存破坏问题，但 ASan 配合其他工具可以帮助识别未释放的内存，尤其是在调试过程中。

"Address Sanitizer 下的 detect use of stack after return" 指的是 Address Sanitizer（简称 ASan）的一项功能，用于检测当函数返回后对栈上分配的变量（即局部变量）的非法使用。这种错误通常被称为栈缓冲区溢出后的悬空指针使用或返回后使用栈上的数据。

什么是“使用返回后的栈”？

在C、C++等语言中，局部变量是在栈上分配的。一旦函数执行完毕并返回到调用者，该函数所使用的栈帧会被释放或者覆盖，这意味着任何指向这些局部变量的指针都变成了悬空指针（dangling pointer）。如果程序试图通过这样的指针访问已经失效的数据，就会导致未定义行为，可能会引起程序崩溃、数据损坏或其他难以调试的问题。

char* getLocalString() { 
    char buffer[10]; 
    strcpy(buffer, "Hello"); 
    return buffer; // 返回局部变量的地址，危险！ 
} 
void badUsage() { 
    char* str = getLocalString(); // 此时str指向已释放的栈内存 
    printf("%s\n", str); // 未定义行为：尝试访问已失效的栈内存 
}

thread sanitizer

Thread Sanitizer（简称 TSan） 是一个用于检测多线程程序中的数据竞争（data races）的工具。它由 Google 开发，并集成到了 LLVM 和 GCC 编译器中，因此可以在支持这些编译器的环境中使用，包括 Xcode。TSan 主要用于帮助开发者发现并解决并发编程中的同步问题，这些问题往往难以重现和调试。

1. 检测数据竞争

数据竞争是指两个或多个线程同时访问同一内存位置，且至少有一个线程在写入该位置，而这些访问没有适当的同步机制（如互斥锁、读写锁等）。这种情况下，程序的行为是未定义的，可能导致崩溃、数据损坏或其他不可预测的行为。TSan 能够有效地识别这类问题。

int global_var = 0;

void* threadFunc(void* arg) {
    global_var++; // 如果没有适当的同步，这里可能发生数据竞争
    return NULL;
}

int main() {
    pthread_t t1, t2;
    pthread_create(&t1, NULL, threadFunc, NULL);
    pthread_create(&t2, NULL, threadFunc, NULL);
    pthread_join(t1, NULL);
    pthread_join(t2, NULL);
    return 0;
}

在这个例子中，两个线程同时尝试增加 global_var 的值，但由于没有同步机制，可能会导致数据竞争。 当检测到数据竞争时，TSan 不仅会指出存在竞争的位置，还会提供详细的堆栈跟踪信息，包括发生竞争的具体代码行以及涉及的所有线程的信息。这有助于开发者快速定位并修复问题。

在 Xcode 中，当你选择启用 Address Sanitizer (ASan) 之后，Thread Sanitizer (TSan) 变为不可选状态的原因主要是因为这两个工具的运行机制和它们对程序执行的影响存在冲突。具体来说：

1. 内存布局的不同需求

  • Address Sanitizer (ASan) ：为了检测内存错误（如越界访问、使用已释放的内存等），ASan 需要重新组织程序的内存布局，并插入额外的检查代码来监控每个内存操作。这包括为每个内存块添加“阴影内存”以跟踪其状态。
  • Thread Sanitizer (TSan) ：TSan 则专注于检测多线程环境下的数据竞争问题。它通过重载内存访问函数并记录所有共享变量的读写操作来实现这一点。TSan 对内存布局的要求与 ASan 不同，因为它需要一种能够高效地跟踪并发访问的方式。

由于两者都需要修改程序的内存布局和行为，同时启用它们会导致冲突，使得无法正确地进行内存管理和错误检测。

2. 性能开销叠加

  • 启用 ASan 或 TSan 单独一个时，都会给程序带来显著的性能开销（通常会使程序变慢几倍）。如果同时启用两者，不仅会进一步加剧性能下降，还可能引入额外的复杂性，使得调试变得更加困难。

3. 相互干扰的可能性

  • ASan 和 TSan 在处理内存访问和同步问题的方式上有所不同。例如，ASan 可能会在内存访问前后插入检查点，而这些检查点本身可能会触发 TSan 的数据竞争检测逻辑，反之亦然。这种相互干扰可能导致误报或漏报，降低诊断结果的准确性。

Undefined Behavior Sanitizer (UBSan)

ta是一种用于检测 C、C++ 程序中未定义行为（undefined behavior）的工具。它作为 Clang 和 GCC 编译器的一部分，旨在帮助开发者识别那些在标准中没有明确规定行为的代码路径，这些未定义行为可能导致程序崩溃、数据损坏或安全漏洞。

什么是未定义行为？

在 C 和 C++ 中，某些操作被认为是“未定义行为”，这意味着它们的结果依赖于具体的编译器实现和运行时环境，并且可能在不同的平台上表现出不同的行为。一些常见的未定义行为包括：

  • 整数溢出（例如，超出 int 类型的最大值）
  • 使用已经释放的内存
  • 数组越界访问
  • 除以零
  • 访问未初始化的变量
  • 类型不匹配的指针转换
#include <iostream>

int main() {
    int a = INT_MAX;
    int b = a + 1; // 这里会发生整数溢出
    std::cout << "Result: " << b << std::endl;
    return 0;
}

main thread checker

在 Apple 的生态系统中（UIKit、AppKit、SwiftUI 等），所有与用户界面相关的操作都必须在主线程（Main Thread）上执行。这是因为 UI 框架不是线程安全的，如果在后台线程直接修改 UI，可能导致：

  • 界面卡顿或刷新异常
  • 崩溃（Crash）
  • 不可预测的行为（Undefined Behavior）

Main Thread Checker 就是为了帮你提前发现这些问题，在开发阶段就发出警告。

// ❌ 错误：在后台线程直接更新 UI
DispatchQueue.global().async {
    let data = fetchDataFromNetwork()
    
    // ⚠️ 警告！不能在非主线程更新 UI
    self.label.text = "Loaded: \(data)"
    self.imageView.image = UIImage(data: data)
}

thread performance checker

虽然你的 App 可能没有崩溃，但如果主线程被长时间占用，用户就会感受到“卡”、“不流畅”、“按钮无响应”等问题。Thread Performance Checker 就是为了帮你提前发现这类性能问题。

// ❌ 错误：在主线程执行耗时操作
@IBAction func loadButtonTapped(_ sender: UIButton) {
    let data = try! Data(contentsOf: largeFileURL) // 阻塞主线程读文件
    let parsed = parseHeavyData(data)             // 复杂解析也放主线程
    self.imageView.image = UIImage(data: data)
}

Thread Performance Checker 会在 Xcode 控制台输出警告：

Thread Performance Checker: A long-running operation is occurring on the main thread. File: LoadViewController.swift Line: 25

malloc scribble

它的名字“Scribble”就是“涂写”的意思，形象地描述了它对内存“乱写”的行为。

它是如何工作的？

1. 内存分配时（malloc）

  • 系统分配内存后，立即将其内容填充为 0x55（即二进制 01010101）

  • 这可以检测：

    • 读取未初始化的内存
    • 假设内存是“零初始化”的错误逻辑

2. 内存释放时（free）

  • 在调用 free() 或 CFRelease() 时，系统会将这块内存的所有字节写为 0xAA（即 10101010）

  • 然后这块内存不会立即归还给操作系统，而是标记为“已释放”

  • 如果程序后续仍然访问这块内存（use-after-free），就会读到 0xAA，导致：

    • 指针变为 0xAAAAAAAA → 解引用会崩溃
    • 整数变为 0xAAAAAAAA → 逻辑错误
    • 字符串变成乱码 → 显示异常

这样就能快速暴露“释放后使用” 的 bug。

例如，为初始化内存读取

int *ptr = (int *)malloc(sizeof(int)); // 忘记初始化 
printf("%d\n", *ptr); // ❌ 读取未初始化内存 → 输出 0x55555555

释放后使用

int *ptr = (int *)malloc(sizeof(int)); 
*ptr = 42; 
free(ptr); // 此时 ptr 指向的内存已被涂写为 0xAA 
printf("%d\n", *ptr); // ❌ 读取已释放内存 → 可能崩溃或输出奇怪值

zombie objects

可以说，这个大家肯定都非常熟悉了，它专门检测 Objective-C 对象释放后使用， 与 Scribble 互补 当一个 Objective-C 对象被释放后，不让它真正销毁，而是将其变成一个“僵尸对象”——它还能接收消息，但一旦收到任何方法调用，就会立即崩溃并打印详细的错误日志，从而帮助你定位问题。

// 假设 ViewController 持有一个按钮的引用
@property (nonatomic, weak) UIButton *button;

- (void)viewDidLoad {
    [super viewDidLoad];
    
    UIButton *tempButton = [[UIButton alloc] initWithFrame:CGRectZero];
    self.button = tempButton; // weak 引用
    
    // tempButton 离开作用域，被释放（假设没有其他强引用）
    // 此时 self.button 指向一个已释放的对象（悬空指针）
}

- (void)someLaterMethod {
    [self.button setTitle:@"Click Me" forState:UIControlStateNormal];
    // ❌ 崩溃！向已释放的对象发送消息
}

没有启用 Zombie 时：

  • 可能崩溃，错误信息是 EXC_BAD_ACCESS，难以定位是哪个对象出了问题。

启用 Zombie Objects 后：

  • 程序会立即崩溃，并输出类似日志：
 -[UIButton setTitle:forState:]: message sent to deallocated instance 0x10c012340

Malloc Guard Edges

在每次内存分配的前后（边缘）添加“警戒页”（guard pages），如果程序越界写入这些区域，就会立即触发崩溃（EXC_BAD_ACCESS），从而精确暴露内存越界错误。

典型检测场景

场景 1：C 数组越界
int *arr = (int *)malloc(4 * sizeof(int)); // 分配 4 个 int
arr[4] = 100; // ❌ 越界写入（索引 0~3 有效）→ 触发 guard page 崩溃
场景 2：字符串操作溢出
char *str = (char *)malloc(10);
strcpy(str, "Hello, World!"); // ❌ 源字符串太长 → 溢出 → 崩溃
场景 3：结构体拷贝越界
struct Data {
    int a, b;
} *data = malloc(sizeof(struct Data));

memcpy(data, largeBuffer, 100); // ❌ 拷贝太多字节 → 触发 guard

guard malloc

它的处理机制同malloc guard edges非常类似

Guard Malloc和Malloc Guard Edges都是苹果对标准内存分配器的增强调试方案，但保护粒度不同。Guard Malloc更彻底，每个内存块都单独隔离，像给每个公寓单元安排独立地基；而Malloc Guard Edges只在内存块边缘设置栅栏，像在小区外围建围墙。前者能精确定位野指针，后者只能捕捉溢出。

特性Guard Malloc (libgmalloc)Malloc Guard Edges
保护目标单个分配块的前后边界堆内存区域的整体边界
实现方式每个 malloc 块放在独立虚拟内存页，前后设置 GUARD PAGE在堆内存区域的起始和结束地址设置 GUARD PAGE
检测能力✅ 缓冲区溢出/下溢 (越界读写) ✅ 释放后使用 (Use-After-Free) ✅ 野指针访问 (指向已释放内存)✅ 大规模溢出/下溢 (跨越堆边界) ❌ 块内或释放后的小范围错误
内存开销⚠️ 极高 (每个分配至少消耗 1-3 个完整内存页)✅ 极低 (仅增加 2 个保护页)
性能影响⚠️ 非常严重 (频繁的页错误、TLB 刷新)✅ 轻微 (只在访问堆边界时触发)
适用场景精准定位小范围内存错误 (越界、UAF)检测严重溢出导致堆破坏的崩溃
设备限制❌ 仅限模拟器 (依赖虚拟内存机制)✅ 模拟器 & 真机 (ARM 支持 guard pages)
推荐程度针对性调试特定内存错误时使用轻量级全局防护，真机调试可用

malloc stack logging

它记录下程序中每一次内存分配 (malloc, calloc, realloc, valloc, block_copy) 和释放 (free) 操作的调用堆栈信息。这为深入分析内存问题（尤其是内存泄漏、异常内存增长）提供了关键线索。 主要用于内存泄露的检测

  • 优势：  比 Xcode 内置的简单 Leaks 检测提供更精确的泄露源头定位，尤其是对于未直接关联到 Objective-C 对象的纯 C/C++ 内存泄漏。

使用 leaks 命令行工具或 Instruments Allocations/Leaks 分析内存泄漏和驻留时必须启用！核心调试手段。

API Validation - API 验证

作用:  启用特定框架的额外运行时 API 参数和状态验证。

常见子项:

  • Core Data:  检测多线程访问冲突、对象上下文使用错误等。
  • SceneKit / SpriteKit / Metal / etc:  检测参数无效、状态机错误、资源使用问题。

原理:  框架内部在关键 API 调用时进行更严格的参数和状态检查。

开销:  中低（额外检查）。

平台:  Simulator & 真机。

何时用:  当你在开发中使用到相应框架（如 Core Data, Metal），且遇到与该框架相关的崩溃或异常行为时启用。有助于捕获框架层面的误用。

memory graph on resource exception

Memory Graph on Resource Exception 是 Xcode 提供的一个功能，它允许开发者在遇到资源异常（如内存警告或崩溃）时生成内存图（Memory Graph），以便于分析和调试内存相关的问题。这个功能特别有助于识别潜在的内存泄漏、循环引用以及其他与内存管理有关的问题。

shader validation

Shader Validation 是一个专门用于检测和报告 Metal 着色器代码中潜在问题的功能。它旨在帮助开发者在开发阶段就能发现并修正着色器代码中的错误，从而提高应用程序的稳定性和性能。特别是在使用 Metal 进行图形编程时，Shader Validation 提供了重要的保障。

Show Graphics Overlays (显示图形覆盖层)

  • 作用：  在 App 的界面上直接绘制实时的可视化图层，帮助你肉眼识别潜在的渲染性能问题。

  • 原理：  Xcode 在 App 运行时注入代码，在屏幕内容之上叠加半透明的彩色图层，直观展示：

    • 颜色混合 (Color Blended Layers - 红色/洋红色)：

      • 用 红色/洋红色高亮 标记发生 Alpha 通道混合 (Blending)  的区域。
      • 为什么重要？  过度混合（尤其是多层半透明视图叠加）是导致 GPU 填充率瓶颈和滚动卡顿的最主要原因之一。红色区域越多越深，性能开销越大。

    • 离屏渲染 (Color Offscreen-Rendered Yellow - 黄色)：

      • 用 黄色高亮 标记触发 离屏渲染 (Offscreen Rendering)  的图层。
      • 为什么重要？  离屏渲染（如使用 cornerRadius + masksToBounds、shadow、shouldRasterize）需要 GPU 额外开辟缓冲区，显著增加渲染时间和内存/功耗。黄色区域越亮越多，性能影响越大。

    • 光栅化 (Color Hits Green and Misses Red - 绿色/红色)：

      • 对启用了 shouldRasterize 的图层：

        • 绿色：  命中了缓存（复用之前光栅化的结果），性能好。
        • 红色：  未命中缓存（需要重新光栅化），性能差。

      • 为什么重要？  帮你判断 shouldRasterize 是否真的带来了性能优化，还是适得其反。

  • 如何使用：

    1. Xcode 中：Edit Scheme -> Diagnostics -> Logging 区域，勾选 Show Graphics Overlays。
    2. 运行 App (通常在 Simulator 上使用，真机也支持但可能影响性能)。
    3. 在 App 界面上直接观察出现的彩色覆盖层。

  • 优点：

    • 极其直观：  一眼就能定位哪些 UI 元素导致了混合或离屏渲染。
    • 实时反馈：  操作 App (如滚动列表) 时能动态看到高亮区域的变化。

  • 缺点/限制：

    • 只提供视觉提示，不给出具体数值或调用栈。
    • 在复杂 UI 上可能显得杂乱。
    • 真机上开启可能略微影响性能。

  • 何时使用：

    • 快速筛查 UI 滚动卡顿、动画掉帧 的视觉元凶。
    • 优化视图层级结构，减少不必要的透明度和图层特效。
    • 检查 shouldRasterize 的实际效果。

Log Graphics API Usage (记录图形 API 使用情况)

  • 作用：  在 Xcode 控制台 或 系统日志 中详细输出 App 使用的图形 API (Core Animation, Metal, OpenGL ES) 的调用信息和警告。

  • 原理：  启用底层图形框架（主要是 Core Animation）的详细日志记录和API 验证。它会报告：

    • Core Animation 提交 (Commit)：  记录每次图层树 (CALayer hierarchy) 提交给渲染服务器的操作。

    • 隐式动画触发：  报告哪些属性的变更触发了隐式动画（可能导致性能问题或意外效果）。

    • 昂贵的图层操作：  警告可能导致性能问题的操作，如：

      • 频繁修改视图/图层的 frame/bounds/position (导致重排布局和重绘)。
      • 设置 drawsAsynchronously。
      • 过度使用 cornerRadius + masksToBounds (触发离屏渲染)。
      • 视图层级过深或过于复杂。

    • API 误用警告：  检测并报告不符合最佳实践或可能出错的 API 调用。

    • Metal/OpenGL ES 调用 (部分)：  记录部分底层图形 API 的调用（不如 Instruments 的 GPU 帧捕获详细）。

  • 如何使用：

    1. Xcode 中：Edit Scheme -> Diagnostics -> Logging 区域，勾选 Log Graphics API Usage。
    2. 运行 App (Simulator 或 真机 均可)。
    3. 查看 Xcode 的 Debug Console (Command + Shift + C) 输出的日志信息。信息量通常很大。

  • 优点：

    • 提供文本化的详细信息，比覆盖层更深入。
    • 能捕获覆盖层无法显示的问题（如隐式动画、频繁修改布局）。
    • 在 真机上运行 也能获取日志，对解决真机特有图形问题至关重要。

  • 缺点/限制：

    • 日志信息非常冗长，需要耐心筛选关键信息。
    • 不如覆盖层直观，需要理解日志含义。
    • 对 Metal/OpenGL ES 的日志不如专门的 GPU 帧捕获工具（如 Instruments 的 Metal System Trace）详细。

  • 何时使用：

    • 当 Show Graphics Overlays 没发现问题，但 UI 性能依然不佳时，深入挖掘原因。
    • 调试 隐式动画 导致的性能问题或视觉异常。
    • 检测代码中是否存在昂贵的、频繁的图层属性修改。
    • 获取 真机环境 下的图形 API 使用情况和警告。
    • 作为使用更重量级的 Instruments Graphics Tools (如 Time Profiler, Core Animation, Metal System Trace) 之前的初步诊断手段。
avatar
文章
阅读
粉丝