PayU 如何对移动 SDK 进行主动错误监控——：-www.deekpay.com

背景

PayU 为在线企业提供支付网关解决方案，服务超过 500,000 家商户，支持超过 150 种支付方式。它是电子商务商户首选的支付合作伙伴，包括所有主流电子商务公司以及大部分航空公司。

PayU 拥有众多移动 SDK，在商户应用中支付功能中发挥着至关重要的作用。我们的主要目标是让商户在 PayU 平台上的集成尽可能简单、无缝，且所需努力最小。

下面我们来谈谈我们如何构建 PayU 崩溃报告器 SDK 并将其整合到所有 SDK 产品中，以采取早期修复策略。

问题陈述

PayU 通过公共仓库（如 Maven Central、Cocoa Pods）分发 SDK，企业将其集成到自己的应用中。当我们的代码库中发生崩溃时，崩溃信息会被记录在商户的崩溃工具仪表板上，然后稍后传达给我们。我们无法实时监控崩溃。由于从商户仪表板中获取所需的调试信息并不总是容易，因此调试时间较长。有时由于缺少 SDK 版本信息和相应的映射文件，我们难以解析堆栈跟踪。

探索

我们尝试使用市场上多种产品（如 Crashlytics、ACRA、BugSnag）来解决这个问题，但没有任何一个产品能够即插即用。

以下是我们无法解决问题的原因：

在单个应用中同时存在多个此类解决方案在技术上是不可能的，因为所有这些解决方案都需要在应用程序级别配置一个唯一的 ID。这些产品不支持库模块，仅限于应用程序级别的项目使用。

我们发现了一个开源解决方案 Sentry，它能够解决上述问题。Sentry 拥有一个 SDK 产品，能够实现我们监控 SDK 崩溃的主要目标，但它也带来了一些挑战：

体积庞大：Sentry SDK 的大小约为 1000KB，因为它提供了许多我们并不感兴趣的其他功能，如健康监控、NDK 崩溃报告等。

数据控制：我们希望对数据有更严格的控制，因为 Sentry SDK 捕获了很多对我们来说并不重要的数据点。这也导致了有效载荷大小的膨胀。

最终方法

我们开发了自己的 PayU 崩溃报告器 SDK（基于 Sentry），以解决上述问题。PayU 崩溃报告器 SDK 注册了一个全局异常处理器来解析堆栈跟踪，并仅报告在 PayU SDK 中发生的崩溃。高频事件随后会被纳入我们的冲刺周期或作为热修复来解决，从而创建更加稳定的 SDK。

PayU 崩溃报告器 SDK 流程

PayU 崩溃报告器 SDK 仪表板

体积：大约 40 KB，仅为 Sentry SDK 大小的 1/25。我们通过移除所有不必要的功能来减少体积。

数据控制：仅报告必要字段，如库版本、交易 ID、商户应用中所有模块的详细信息以及堆栈跟踪，以简化调试。

稳定性：PayU 崩溃报告器完全使用 Kotlin 编写，采用现代实践（如协程）来减轻网络调用，提高稳定性。

可扩展性：PayU 崩溃报告器 SDK 被设计为可被我们所有 SDK 产品用于崩溃监控。

不断进步

随着 PayU 崩溃报告器 SDK 集成到所有 SDK 中，我们能够为超过 150 家商户提供平稳且稳定的体验。

近期的一个例子是，我国一家拥有数百万日活跃用户的顶级电子商务公司，在我们的 SDK 在设备内存较低时发生崩溃，导致客户体验不佳。我们在应用的早期发布阶段就利用 PayU 崩溃报告器 SDK 发现并修复了这个问题。

除此之外，在运行时，PayU 崩溃报告器 SDK 观察到的频繁发生的崩溃（如未处理的异常、数字格式异常、非法参数异常、空指针异常等）也立即在相应 SDK 的后续版本中得到了修复。

一切入门所需

您可以查看 PayU 提供的各种支付 SDK，以实现无缝支付体验——适用于 Android 和 iOS。

对于任何集成相关的支持，请联系您的关键账户经理或发送邮件至 [email protected]。