slo*_*low 4 crash frameworks crash-reports crashlytics
我的团队正在开发供客户端使用的iOS框架，当我们想要在框架中使用某种崩溃报告工具（例如Crashlytics，KSCrash等）时遇到瓶颈，以便我们可以跟踪崩溃当客户在其应用程序中使用我们的框架时。
但是，问题在于，如果第三方崩溃报告工具（框架和客户端）都使用相同的崩溃报告工具，则它们似乎无法正常工作。例如，如果我们的框架和客户端应用程序均依赖Crashlytics报告崩溃，则由于API受限制，它将无法正常工作。大多数其他开放源代码项目几乎所有时间都用于sharedInstance初始化类。因此，这也不起作用。
我的问题是...我敢肯定，那里有公司和软件正在使用某种崩溃报告工具来分析在分发给许多客户的自己的框架上的崩溃。怎么做？有什么见解吗？
我曾经是Apple平台的Crashlytics SDK的维护者。过去，一些知名的框架供应商曾多次询问我这个问题。而且，我在这些领域投入了大量工作-报告工具的互操作性和非主机应用程序报告。
我想更详细地说明为什么这么难。
问题1：崩溃本质上是每个进程
到目前为止，您已经注意到的问题与报告框架的API有关，但是问题更加严重。崩溃会破坏整个过程。iOS上存在的功能（macOS，tvOS）不能在每个库的基础上应用。（我相信每个线程都可以，但是我不确定实际上是否可以买到任何东西。）
这就是为什么即使使用Apple自己的ReportCrash，互操作性仍然如此具有挑战性的核心原因。进程内报告工具会设置其设备，然后期望它们的设置在实际发生崩溃时保持不变。这种机器的两个副本（即两个Crashlytics）没有意义。只能有一个，因为所使用的资源仅基于每个进程存在。
通常，报告工具需要在可能的最佳报告和最佳的互操作性之间进行权衡。例如，如果我没有记错的话，就是如果您在同一过程中同时使用Crashlytics和KSCrash，则会损害Crashlytics正确捕获有关C ++异常信息的能力。
问题2：谁是坠机事故的所有者？
忽略问题1，记者应该如何知道崩溃是库还是应用程序？这是一个广泛的话题，基本上可以归结为崩溃责任的核心问题。崩溃是一种后果，但是大多数开发人员不会立即想到这种崩溃。当您要解决崩溃问题时，您需要一个原因。确定库是原因并不容易。在您认为“它不应该让我崩溃了我的库框架吗？”之前，请想象一下这是如何对UIKit或Foundation起作用的。
有很多方法可以解决此问题。但是，我认为如果没有过多讨论，我相信崩溃始终是由主机应用程序拥有的，但是第三方也可能对此感到兴趣。这带来了其他所有问题，包括对库所有者进行身份验证以及处理主机应用程序的隐私/安全隐患。这是一整件事。
无论您如何处理，我都认为该解决方案只能通过报告服务在服务器端完成。从理论上讲，他们可以获取报告并进行分析。Crashlytics的Insights系统是朝这个方向迈出的一步。但是，它当前不向图书馆供应商提供查看这些报告的功能。它的重点更多是将崩溃（一种影响）与一个众所周知的原因（或原因类别）联系起来。
摘要
试图使您的库尽可能稳定是一个很好的目标。不幸的是，我只是认为无法通过专用的过程中报告来完成。
您实际上应该做的是帮助您的客户开发人员更好地了解您的库在做什么。因此，当它崩溃时，可以更轻松地进行调试并将其报告给您。
NSProcessInfoAPI，这些API可以帮助更好地展示调试过程中您的库在做什么我希望这会有所帮助，即使它并不能真正将您带到想要的地方。