崩溃率直降90%：基于crashpad的跨平台崩溃报告

crashpad通过接管崩溃处理流程生成minidump文件并上传服务器从而大幅降低崩溃率。其核心在于提高崩溃捕获可靠性、生成包含线程堆栈和寄存器信息的minidump文件、配置符号服务器解析地址为函数名、内置重试机制确保上传成功。接入步骤包括集成库、初始化设置存储路径与上传url、配置符号服务器、处理上传结果。在多线程环境下，crashpad暂停所有线程、收集各线程堆栈信息、生成综合minidump文件。自定义内容可通过annotation添加键值对、实现自定义exceptionhandler、或向minidump写入自定义stream。性能开销主要来自崩溃捕获、minidump生成与上传，可通过选择minidump类型、限制annotation大小、异步上传、设置采样率优化。无网络时可配置本地存储并在恢复后手动上传。相比breakpad，crashpad采用多进程架构、支持更多平台、功能更强且持续维护。调试集成问题可通过查看日志、使用调试器、检查minidump文件、配合符号服务器进行分析。

崩溃报告，简单来说，就是应用崩溃后，收集信息并上报，方便开发者定位和修复问题。Crashpad，则是Google开源的一个崩溃报告库，跨平台支持是它的一个亮点。用Crashpad，的确能大幅降低崩溃率，90%只是个说法，但效果确实显著。

使用Crashpad大幅降低崩溃率

Crashpad的核心在于它能接管崩溃处理流程，生成minidump文件，然后上传到服务器。这个过程的关键点在于：

1. 崩溃捕获的可靠性：传统的崩溃捕获机制在某些情况下可能会失效，而Crashpad通过自身的设计，提高了崩溃捕获的成功率。

2. Minidump文件的详细程度：Minidump文件包含了崩溃时的线程堆栈、寄存器信息、模块列表等，这些信息对于定位问题至关重要。Crashpad可以配置生成更详细的minidump，但也会增加文件大小。

3. 上传的成功率：即使生成了minidump，如果无法成功上传到服务器，也无法发挥作用。Crashpad内置了上传机制，并且可以配置重试策略，确保上传成功。

4. 符号文件（Symbol Files）：有了minidump，还需要符号文件才能将内存地址解析为函数名和行号。Crashpad需要配合符号服务器使用，确保能够获取到正确的符号文件。

具体来说，接入Crashpad的步骤大致如下：

• 集成Crashpad库：将Crashpad库添加到你的项目中，这通常涉及到修改构建脚本（例如CMakeLists.txt）。

• 初始化Crashpad：在应用程序启动时，初始化Crashpad，指定minidump的存储路径和上传服务器的URL。

• 配置符号服务器：配置符号服务器，确保Crashpad能够找到正确的符号文件。

• 处理上传结果：在服务器端，接收并处理上传的minidump文件，生成崩溃报告。

Crashpad如何处理多线程环境下的崩溃？

多线程环境下的崩溃往往更加复杂，因为崩溃可能发生在任何线程中，并且可能受到其他线程状态的影响。Crashpad在处理多线程崩溃时，会捕获所有线程的堆栈信息，这使得开发者可以了解崩溃发生时整个应用程序的状态。

更具体地说，Crashpad会：

• 暂停所有线程：当一个线程发生崩溃时，Crashpad会暂停所有其他线程，以防止它们修改崩溃线程的状态。

• 收集所有线程的堆栈信息：Crashpad会遍历所有线程，收集它们的堆栈信息，包括函数调用链、寄存器值等。

• 生成包含所有线程信息的minidump：Crashpad会将收集到的所有线程信息写入minidump文件。

这种方式确保了开发者能够获取到尽可能多的信息，从而更容易定位问题。但需要注意的是，暂停所有线程可能会导致应用程序短暂的无响应，因此需要权衡性能和可靠性。

如何自定义Crashpad的崩溃报告内容？

虽然Crashpad默认会收集很多有用的信息，但在某些情况下，你可能需要自定义崩溃报告的内容，例如添加一些应用程序特定的信息，或者过滤掉一些敏感数据。

Crashpad提供了自定义崩溃报告内容的能力，主要通过以下几种方式：

• Annotation：Annotation是一种键值对，你可以使用Crashpad提供的API，在应用程序中添加Annotation。当发生崩溃时，Crashpad会将这些Annotation添加到minidump文件中。

• 自定义ExceptionHandler：你可以实现自己的ExceptionHandler，并在其中添加自定义的崩溃处理逻辑。例如，你可以记录一些日志信息，或者执行一些清理操作。

• MinidumpStream：你可以向minidump文件中添加自定义的Stream，Stream是一种二进制数据块，你可以将任何你想添加的数据写入Stream中。

例如，假设你想在崩溃报告中添加应用程序的版本号，你可以这样做：

#include "client/crashpad_client.h"
#include "client/crash_report_database.h"

int main() {
  crashpad::CrashpadClient client;
  std::map annotations;
  annotations["version"] = "1.2.3";
  client.SetAnnotations(annotations);

  // ... 应用程序的其他代码 ...
}

这段代码会在崩溃报告中添加一个名为"version"，值为"1.2.3"的Annotation。

Crashpad的性能开销如何？

任何崩溃报告机制都会带来一定的性能开销，Crashpad也不例外。主要的性能开销来自于以下几个方面：

• 崩溃捕获：Crashpad需要接管崩溃处理流程，这会带来一定的开销。

• Minidump生成：生成minidump文件需要读取内存、线程堆栈等信息，这会消耗CPU和内存资源。

• Minidump上传：上传minidump文件需要网络带宽，并且可能会影响应用程序的响应速度。

  

  Musico

  Musico 是一个AI驱动的软件引擎，可以生成音乐。 它可以对手势、动作、代码或其他声音做出反应。

  下载

为了降低性能开销，可以采取以下措施：

• 选择合适的Minidump类型：Crashpad支持多种Minidump类型，例如Mini、MiniPlus、Full等。Mini类型的Minidump文件最小，性能开销也最小，但包含的信息也最少。Full类型的Minidump文件最大，性能开销也最大，但包含的信息也最多。

• 限制Annotation的数量和大小：Annotation会增加Minidump文件的大小，因此需要限制Annotation的数量和大小。

• 异步上传Minidump：可以将Minidump上传操作放在后台线程中执行，以避免阻塞主线程。

• 采样率：可以设置采样率，只对一部分崩溃生成崩溃报告。

总的来说，Crashpad的性能开销是可以接受的，尤其是在考虑到它所带来的好处（例如大幅降低崩溃率）之后。

如何在没有网络的环境下使用Crashpad？

有些应用程序可能需要在没有网络的环境下运行，例如嵌入式设备。在这种情况下，Crashpad仍然可以发挥作用，但需要进行一些额外的配置。

Crashpad的核心功能是生成minidump文件，即使没有网络，Crashpad仍然可以生成minidump文件并将其存储在本地。当网络恢复时，你可以手动上传这些minidump文件到服务器。

具体来说，你需要：

• 配置本地存储路径：在初始化Crashpad时，指定一个本地存储路径，用于存储minidump文件。

• 实现手动上传机制：当网络恢复时，你需要实现一个手动上传机制，将本地存储的minidump文件上传到服务器。

例如，你可以创建一个后台线程，定期检查本地存储路径，如果发现有新的minidump文件，就尝试上传。

#include "client/crashpad_client.h"
#include "client/crash_report_database.h"
#include 
#include 
#include 

void UploadMinidumps() {
  while (true) {
    // 检查本地存储路径
    std::filesystem::path minidump_path("/path/to/minidumps");
    for (const auto& entry : std::filesystem::directory_iterator(minidump_path)) {
      if (entry.is_regular_file() && entry.path().extension() == ".dmp") {
        // 上传minidump文件
        UploadFile(entry.path().string(), "https://your.upload.server");
        // 删除已上传的文件
        std::filesystem::remove(entry.path());
      }
    }
    // 等待一段时间
    std::this_thread::sleep_for(std::chrono::minutes(5));
  }
}

int main() {
  crashpad::CrashpadClient client;
  std::map annotations;
  annotations["version"] = "1.2.3";
  client.SetAnnotations(annotations);

  // 启动上传线程
  std::thread upload_thread(UploadMinidumps);
  upload_thread.detach();

  // ... 应用程序的其他代码 ...
}

这段代码会创建一个后台线程，每隔5分钟检查一次本地存储路径，如果发现有新的minidump文件，就尝试上传。

需要注意的是，你需要自己实现UploadFile函数，该函数负责将minidump文件上传到服务器。

Crashpad与Breakpad的区别是什么？

Crashpad和Breakpad都是Google开源的崩溃报告库，它们有很多相似之处，但也有一些重要的区别。

• 架构：Crashpad采用了多进程架构，而Breakpad采用了单进程架构。这意味着Crashpad的崩溃处理过程是在一个独立的进程中进行的，而Breakpad的崩溃处理过程是在应用程序的进程中进行的。多进程架构使得Crashpad更加稳定可靠，因为即使崩溃处理进程崩溃了，也不会影响应用程序的运行。

• 跨平台支持：Crashpad对跨平台的支持更好，它可以支持Windows、macOS、Linux、Android等多个平台。Breakpad对跨平台的支持相对较弱。

• 功能：Crashpad提供了更多的功能，例如自定义崩溃报告内容、异步上传Minidump等。

• 维护：Crashpad目前仍在积极维护中，而Breakpad已经停止维护。

总的来说，Crashpad是Breakpad的替代品，它具有更好的架构、更广泛的跨平台支持、更多的功能和更积极的维护。如果你正在寻找一个崩溃报告库，Crashpad是一个更好的选择。

如何调试Crashpad集成？

在集成Crashpad的过程中，可能会遇到各种各样的问题，例如崩溃报告无法生成、崩溃报告无法上传、符号文件无法找到等。为了解决这些问题，你需要掌握一些调试技巧。

• 查看日志：Crashpad会生成日志，你可以通过查看日志来了解Crashpad的运行状态。日志中包含了Crashpad的各种信息，例如崩溃捕获、Minidump生成、Minidump上传等。

• 使用调试器：你可以使用调试器来调试Crashpad的代码，例如GDB、LLDB、Visual Studio Debugger等。通过调试器，你可以单步执行Crashpad的代码，查看变量的值，从而了解Crashpad的运行过程。

• 检查Minidump文件：你可以使用Minidump分析工具来检查Minidump文件，例如WinDbg、GDB、LLDB等。通过Minidump分析工具，你可以查看崩溃时的线程堆栈、寄存器信息、模块列表等，从而了解崩溃的原因。

• 使用符号服务器：你可以使用符号服务器来查找符号文件，例如Microsoft Symbol Server、Mozilla Symbol Server等。通过符号服务器，你可以将内存地址解析为函数名和行号，从而更容易定位问题。

例如，你可以使用WinDbg来分析Minidump文件：

windbg -z crash.dmp

然后，你可以使用!analyze -v命令来分析崩溃原因：

0:000> !analyze -v
*******************************************************************************
*                                                                             *
*                        Exception Analysis                                   *
*                                                                             *
*******************************************************************************

... (省略大量输出) ...

MODULE_NAME:  test

IMAGE_NAME:  test.exe

FAILURE_BUCKET_ID:  NULL_POINTER_READ

... (省略大量输出) ...

这段代码会使用WinDbg打开crash.dmp文件，并使用!analyze -v命令来分析崩溃原因。分析结果会告诉你崩溃的模块名、异常类型等信息。