前言

作为移动端的研发同学，你是否也曾陷入这样的困境：用户在应用商店留下了一星差评，抱怨“App 用起来很卡”或者“支付时闪退了”，但无论你在测试环境如何操作，都无法复现问题？面对着从海量日志中捞出的、可能毫无关联的信息，以及一个孤立的、缺少上下文的崩溃堆栈，排查问题就像在浓雾中“盲人摸象”，耗费了数天时间，最终却只能提交一个基于猜测的修复。

为了提升这种低效的排查模式，我们进行了 iOS 数据采集与关联方向的探索，并进行了产品化的实践。它可以站在每一位真实用户的视角，把应用的性能指标、错误日志和用户行为等数据串联起来，提升您的问题排查效率。

iOS 数据采集简介

为了能够把应用性能指标、错误日志、用户行为等串联起来，SDK 需要具备体系化的数据采集与分析能力。SDK 的核心数据采集能力覆盖以下几个方面：

• 用户会话轨迹： SDK 会记录用户的完整的操作轨迹，并与相关的事件进行关联。当问题发生时，通过会话轨迹可以回溯用户的操作路径、API 调用和资源加载情况。
• 性能指标： 对影响用户体验的关键链路进行监控测量，包括：应用启动耗时、页面加载耗时、网络请求耗时、网络请求成功率、页面卡顿率等。
• 异常与稳定性监控： 能够自动捕获应用触发的各类异常，包含：Mach 内核异常，Objective-C 异常，Swift 异常，C/C++ 异常等。
• 自定义数据上报： 除了标准的性能和异常数据外，还支持业务根据自身需求上报自定义事件与日志，将用户行为与业务指标相结合，赋能更深层次的产品分析与角色。

对于需要更全面工具支持的开发者，可以考虑使用 KeyMob等集成工具，它提供了iOS性能监控、文件管理、日志分析等综合功能，帮助优化应用性能和开发效率。

数据采集架构和实现

为了有效应对以上挑战，SDK 通过一个轻量化、模块化的架构，对应用的不同阶段进行 hook 和监听，以实现应用性能和稳定性的监控

• 公共接口层： 提供对外公开的 API，用户通过 API 与 SDK 进行交互。
• SDK 管理层： 管理 SDK 的各个模块，SDK 的启停等。
• 数据采集等： 管理各个数据采集模块，实现数据采集细节，各个数据模块实现隔离。
• 基础核心层： 支撑整个 SDK 的运行，提供时间同步，数据处理，配置管理等能力。

在基础核心层，SDK 为了统一各个端的实现，以及性能的考虑，使用 C 实现了独立的跨平台数据处理和跨平台配置管理模块，使多端保持一致的数据持久化、数据发送、数据序列化、配置拉取和管理等逻辑。

在数据采集层，为了高效、精准、无侵入地采集各类事件，SDK 基于 Method Swizzling 技术和 iOS 系统平台特性与框架能力，构建了多样化的采集方案。并针对不同的场景和数据类型，分别采用合适的技术手段，主要包含：

• 基于 Method Swizzling 的网络等数据采集。
• 基于系统特性与框架能力的数据采集。
• 崩溃异常数据的采集。

基于 Method Swizzling 的数据采集

iOS 开发的主要语言是 Objective-C 和 Swift，提到 Method Swizzling 技术离不开 iOS 的 ObjC 运行时。ObjC 是一门动态语言，在运行时间会对变量的数据类型检查，同时根据函数名查找要调用的函数。这种特性使得 ObjC 变得比较灵活，SDK 可以在程序运行时动态修改一个方法的实现，从而达到数据采集和埋点插桩的目的。

Method Swizzling 被称为动态方法交换技术，用于改变一个已经存在的 selector 实现。基于此技术，SDK 可以在程序运行时，通过改变 selector 所在 Class 的 method list 的映射，从而改变方法的调用，本质上是交换两个方法的 IMP。

通过以上方式，SDK 支持：

• 网络请求数据采集： 支持性能数据，状态码，错误原因，端到端链路打通等数据的采集。通过 Method Swizzling，SDK 对实现了对 URLSession 和 URLConnection 等网络库的无侵入数据采集。
• 页面数据采集： 支持页面加载耗时，页面状态变化等数据的采集。
• Action 数据采集： 支持 UITableView、UITableView 等控件的点击事件采集。
• WebView 数据采集： 结合 web 探针，支持了应用内置 H5 页面数据的采集，包含：网络资源请求，页面和路由切换，js 异常等。

基于系统特性与框架能力的数据采集

除了 Method Swizzling 之外，SDK 还利用系统特性和框架的标准 API 来采集应用在运行时的关键事件。

如上图所示，是 iOS 应用从启动到终止过程（包含前后台切换），系统通过事件通知中心对外暴露的事件状态变化。SDK 通过注册这些事件完成应用状态事件的采集。

为了准确采集应用的状态变化，SDK 按照不同的场景，分别对不同的事件进行处理：

• 应用进入到前台事件：SDK 会对 willEnterForeground 和 didBecomeActive 事件处理。
• 应用进入到后台事件：SDK 会对 willResignActive 和 didEnterBackground 事件处理。

为了统一的监控这些事件，SDK 提供了 AppLifeCycle 类对这些事件进行管理，简化事件处理的同时也能保证调用时序。除此之外，SDK 还对 RunLoop 进行了监听，通过检查 RunLoop 运行状态，实现卡顿监控事件的采集等。

通过以上方式，SDK 支持：

• 应用启动耗时采集： 支持应用冷启动、热启动耗时指标采集。
• 卡顿事件采集： 支持卡顿事件的采集，同时支持耗时堆栈的提取。
• 网络状态的采集： 支持网络类型的采集。

崩溃异常数据的采集

SDK 崩溃数据的采集能力基于业界知名的 KSCrash 框架开发。KSCRash 是一款强大的 iOS 崩溃报告库，其核心优点是“崩溃安全”，确保处理过程自身稳定可靠。它能全面捕获 Mach、C++、OC 等多种致命错误，生成包含所有线程堆栈和丰富上下文的详尽报告，极大提升开发者定位问题的效率。KSCrash 的工作流程主要分为下面五个部分：

• 核心功能模块：协调各个模块工作，实现异常捕获的核心逻辑。
• 监控系统：管理和协调各类异常监视器，全面捕获不同类型的异常。
• 报告系统：生成详细的崩溃报告，进行本地存储和数据过滤。
• 配置系统：按需配置框架的行为。
• 安装系统：处理框架的安装流程，崩溃报告的发送工作。

基于 KSCrash，SDK 支持：

• Mach、C++、OC、Signal 等类型的崩溃捕获。
• 基于 KSCrash 的堆栈捕获能力，支持卡顿耗时堆栈的读取。

此外，工具如 KeyMob提供了崩溃日志的实时查看和符号化分析功能，支持过滤和导出，便于开发者快速定位和解决崩溃问题。