框架中的崩溃分析工具

Question

我的团队正在开发一个供客户使用的iOS框架，当我们想要某种崩溃报告工具(比如Crashlytics、KSCrash等)时，我们遇到了一个瓶颈。在我们的框架中，当客户端在应用程序中使用我们的框架时，我们可以跟踪崩溃。

然而，问题是，如果(框架和客户端)同时使用相同的崩溃报告工具，这些第三方崩溃报告工具似乎无法工作。例如，如果我们的框架和客户端应用程序都依赖Crashlytics来报告崩溃，由于API受限，它将无法工作。大多数其他开放源码项目几乎一直使用sharedInstance来初始化类。所以，这也行不通。

我的问题是..。我确信有一些公司和软件使用某种崩溃报告工具来分析他们自己的框架上的崩溃，并分发给许多客户。这是怎么做的？有什么见解吗？

Answer 1

我曾经是苹果平台的Crashlytics SDK的维护者。我曾多次被一些非常受欢迎的框架供应商问过这个问题。而且，我在这些领域投入了大量的工作--报告工具互操作性和非主机应用程序报告。

我想更详细地谈谈为什么这件事如此困难。

问题1：崩溃本质上是每个进程

到目前为止，您注意到的问题与报告框架的API有关，但问题要深得多。一次坠机使整个过程崩溃。存在于iOS (macOS，tvOS)上的设施不能在每个库的基础上应用.(我相信有些是可以做到的，但我不确定这是否真的能给你买任何东西。)

这就是为什么互操作性，即使与苹果自己的ReportCrash，是如此具有挑战性的核心原因。进程内报告工具安装了它们的机器，然后当实际发生崩溃时，它们的设置将保持不变。这台机器的两本(即两本破碎机)没有道理。只有一个，因为所使用的资源只存在于每个进程的基础上。

通常，报告工具需要在最佳报告和最佳互操作性之间进行权衡。例如，如果我没记错的话，如果在同一个过程中同时使用Crashlytics和KSCrash，Crashlytics正确捕获C++异常信息的能力就会受到损害。

Problem 2：谁拥有这次崩溃？

忽略问题1，记者如何知道崩溃是一个库而不是应用程序？这是一个宽泛的话题，基本上可以归结为坠机责任这一核心问题。崩溃是一种效应，但大多数开发人员不会立即以这种方式考虑崩溃。当您想要修复崩溃时，您需要一个原因。确定库是原因并不容易。在你认为“它不应该给我提供包含我的库框架的崩溃吗？”之前，想象一下它是如何为UIKit或基金会工作的。

有许多方法来处理这个问题。然而，在没有过多偏离的情况下，我相信崩溃总是由主机应用程序拥有的，但也可能对第三方感兴趣。这就引出了一系列其他问题，包括验证库所有者的身份，以及处理对主机应用程序的隐私/安全问题。整件事。

不管您是如何处理这个问题的，我认为解决方案只能在服务器端使用报告服务完成。从理论上讲，他们可以抓住这份报告并进行分析。碰撞学的洞察力系统就是朝着这个方向迈出的一步。但是，它目前没有为库供应商提供查看这些报告的能力。其重点是将崩溃( effect)与众所周知的原因(或类原因)连接起来。

摘要

努力使你的库尽可能稳定是一个很好的目标。不幸的是，我只是不认为这可以用专门的过程中的报告。

实际上，您应该做的是帮助客户端开发人员更好地理解您的库正在做什么。因此，当它崩溃时，就可以更容易地进行调试并向您报告。

• 列出所有队列/线程的名称
• 包括一些伐木设备
• 积极检查有效的参数/输入
• 尽可能描述性和全面性地从APIs中返回错误。
• 不要在生产中断言(对主机应用程序来说，我的感觉正好相反)
• 永远不要抛出ObjC和/或C++异常
• 永远不要@catch/catch在您的代码中
• 查看NSProcessInfo APIs，它可以帮助更好地公开库在调试过程中所做的事情。

我希望这是有帮助的，尽管它并没有真正达到你想要的地方。