日志采集SDK选型：开源SDK对比、自研采集器设计要点、多平台统一方案

崩溃日志采集是整个归因链条的起点。采集SDK的能力直接决定了你能捕获多少崩溃现场信息、以及能否稳定可靠地上传。本章从开源方案对比入手，再深入自研采集器的设计要点，最后给出多平台统一架构方案。

2.1 主流开源SDK对比

目前工业界常用开源崩溃采集SDK可分为两类：原生C/C++级别（minidump/Breakpad系） 和 跨平台框架内嵌（Firebase/AppCenter/Sentry）。下表从关键维度对比四个代表性方案。

2.2 自研采集器设计要点

当开源SDK无法满足特定需求（如私有协议、信号安全栈深、高性能嵌入式、与内核事件联动），自研成为必须。核心模块设计如下：

• 信号处理器 / 异常钩子：注册 SIGSEGV/SIGABRT/SIGBUS/SIGFPE 及 Mach异常端口；必须在异步安全函数内完成最小化内存操作，避免死锁。
• 堆栈回溯：基于 libunwind / ucontext_t / _Unwind_Backtrace 获取调用链；记录每帧的PC、SP、FP。
• 符号化决策：真机环境可选延迟符号化（先保存地址到文件，上传后云端解析）或内置符号表（仅release裁剪版）。
• 日志收集：支持从内存环形缓冲区（ring buffer）取出近N条日志，不与信号处理互斥。
• 文件生成与本地缓存：将dump+meta信息序列化为压缩包（.dmp/.zip .crash），写入应用沙盒专用目录。
• 上传队列：基于SQLite或文件索引，实现失败重试、去重、限速；支持WIFI下后台静默上传。
• 用户/会话绑定：采集时注入用户ID、app版本、设备ID、启动时间等维度字段。

2.3 多平台统一方案

理想的生产级采集SDK应暴露同一套C风格API，各平台通过条件编译选择底层实现。架构设计如下所示：

2.4 关键技术点与配置示例

CMake 构建配置（多平台分支）

add_library(crash_core STATIC
    base/ringbuffer.cpp
    base/serializer.cpp
    upload/queue.cpp
)

if(WIN32)
    target_sources(crash_core PRIVATE platform/win/exception_seh.cpp)
    target_link_libraries(crash_core dbghelp)
elseif(APPLE)
    target_sources(crash_core PRIVATE platform/apple/mach_exception.cpp)
    target_link_libraries(crash_core "-framework CoreFoundation")
elseif(ANDROID)
    target_sources(crash_core PRIVATE platform/android/linker_listener.cpp)
endif()

target_include_directories(crash_core PUBLIC include)

初始化 API 示例（C语言）

// crash_init.h
typedef struct crash_config {
    const char* upload_url;
    const char* cache_dir;
    int         max_cache_mb;
    int         enable_backtrace;
} crash_config_t;

int crash_init(const crash_config_t* cfg);
void crash_set_user_id(const char* uid);
void crash_upload_now(void);

上传队列配置 JSON（示例）

{
    "upload_interval_sec": 60,
    "max_retries": 3,
    "retry_backoff_base_ms": 5000,
    "network_policy": "wifi_only",
    "enable_batch": true,
    "batch_size": 5
}

2.5 调试与部署注意事项

• 符号文件版本对齐：每次发版需将对应符号文件（.sym / .dSYM / .pdb / .map）上传到符号服务器。
• 重入死锁：所有回调函数必须可重入；使用 volatile sig_atomic_t 做状态保护。
• 测试用例：通过 raise(SIGSEGV) 和 abort() 验证捕获流程；使用 setrlimit 限制core dump体积。
• 上线灰度：先在大约1%~5%设备上开启采集，观察崩溃率上升还是下降（防止因采集器自身bug导致二次崩溃）。
• 日志脱敏：确保用户手机号、等敏感信息在写入dump前被擦除或掩码。