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