Framework 中的崩溃分析工具
Crash analyzing tool in Framework
我的团队正在开发一个 iOS 框架供客户使用，当我们想要在其中使用某种崩溃报告工具（例如 Crashlytics、KSCrash 等）时，我们遇到了瓶颈我们的框架，这样当客户在他们的应用程序中使用我们的框架时，我们可以追踪崩溃。
但是，问题是如果两者（框架和客户端）都使用相同的崩溃报告工具，那么这些第 3 方崩溃报告工具似乎不起作用。例如，如果我们的框架和客户端应用程序都依赖于 Crashlytics 来报告崩溃，它就不会工作，因为受限 API。大多数其他开源项目几乎所有时间都使用 sharedInstance 来初始化 class。所以，这也行不通。
我的问题是...我敢肯定有些公司和软件使用某种崩溃报告工具来分析他们自己分发给许多客户的框架的崩溃。这是怎么做到的？有什么见解吗？
我是 Apple 平台的 Crashlytics SDK 的前维护者。过去一些非常受欢迎的框架供应商曾多次问过我这个问题。而且，我在这些领域投入了大量工作 - 报告工具互操作性和非主机应用程序报告。
我想更详细地说明为什么这如此困难。
问题 1：崩溃本质上是每个进程的
到目前为止您注意到的问题与报告框架的 API 相关，但问题更深层次。崩溃会导致整个过程中断。 iOS（macOS、tvOS）上存在的设施不能在每个库的基础上应用。 （我相信有些可以按线程进行，但我不确定这是否真的能给你带来任何好处。）
这就是互操作性如此具有挑战性的核心原因，即使是使用 Apple 自己的 ReportCrash。进程内报告工具设置它们的机器，然后期望它们的设置在实际发生崩溃时保持不变。该机器的两个副本（即两个 Crashlytics）没有意义。只能有一个，因为正在使用的资源仅存在于每个进程的基础上。
通常，报告工具需要在最佳报告和最佳互操作性之间做出权衡。例如，如果我没记错的话，如果您在同一进程中同时使用 Crashlytics 和 KSCrash，Crashlytics 正确捕获有关 C++ 异常信息的能力就会受到损害。
问题 2：崩溃的原因是谁？
忽略问题 1，记者如何知道崩溃是图书馆还是应用程序？这是一个广泛的话题，基本上可以归结为碰撞责任的核心问题。崩溃是一种影响，但大多数开发人员不会立即以这种方式想到崩溃。当你想修复崩溃时，你需要一个原因。确定图书馆是原因并不容易。在你思考 "shouldn't it just give me the crashes with my library's frames in it?" 之前，想象一下它是如何在 UIKit 或 Foundation 上工作的。
有很多方法可以解决这个问题。然而，在这里不离题太多，我相信崩溃总是由主机应用程序拥有，但第三方可能也感兴趣。这带来了一大堆其他问题，包括验证库所有者和处理 privacy/security 对主机应用程序的影响。整整一件事。
无论您如何解决这个问题，我认为解决方案只能在服务器端使用报告服务来完成。理论上，他们可以获取报告并进行分析。 Crashlytics' Insights系统是朝这个方向迈出的一步。但是，它目前不向图书馆供应商提供查看这些报告的能力。它的重点更多是将崩溃（影响）与众所周知的原因（或class原因）联系起来。
总结
努力使您的库尽可能稳定是一个极好的目标。不幸的是，我只是认为它不能通过专门的进程内报告来完成。
您实际上应该做的是帮助您的客户端开发人员更好地了解您的库在做什么。因此，当它确实崩溃时，可以更轻松地调试并向您报告。
- 说出你所有的 queues/threads
- 包括某种日志记录工具
- 积极检查有效 parameters/input
- 使从 API 传回的错误尽可能具有描述性和全面性
- 永远不要在生产中断言（我对主机应用程序的看法恰恰相反）
- 从不抛出 ObjC and/or C++ 异常
- 永远，永远不要在你的代码中@catch/catch
- 查看
NSProcessInfo API，这有助于更好地揭示您的库在调试期间正在做什么
我希望这对您有所帮助，尽管它并不能真正将您带到您想要的地方。
我的团队正在开发一个 iOS 框架供客户使用，当我们想要在其中使用某种崩溃报告工具（例如 Crashlytics、KSCrash 等）时，我们遇到了瓶颈我们的框架，这样当客户在他们的应用程序中使用我们的框架时，我们可以追踪崩溃。
但是，问题是如果两者（框架和客户端）都使用相同的崩溃报告工具，那么这些第 3 方崩溃报告工具似乎不起作用。例如，如果我们的框架和客户端应用程序都依赖于 Crashlytics 来报告崩溃，它就不会工作，因为受限 API。大多数其他开源项目几乎所有时间都使用 sharedInstance 来初始化 class。所以，这也行不通。
我的问题是...我敢肯定有些公司和软件使用某种崩溃报告工具来分析他们自己分发给许多客户的框架的崩溃。这是怎么做到的？有什么见解吗？
我是 Apple 平台的 Crashlytics SDK 的前维护者。过去一些非常受欢迎的框架供应商曾多次问过我这个问题。而且，我在这些领域投入了大量工作 - 报告工具互操作性和非主机应用程序报告。
我想更详细地说明为什么这如此困难。
问题 1：崩溃本质上是每个进程的
到目前为止您注意到的问题与报告框架的 API 相关，但问题更深层次。崩溃会导致整个过程中断。 iOS（macOS、tvOS）上存在的设施不能在每个库的基础上应用。 （我相信有些可以按线程进行，但我不确定这是否真的能给你带来任何好处。）
这就是互操作性如此具有挑战性的核心原因，即使是使用 Apple 自己的 ReportCrash。进程内报告工具设置它们的机器，然后期望它们的设置在实际发生崩溃时保持不变。该机器的两个副本（即两个 Crashlytics）没有意义。只能有一个，因为正在使用的资源仅存在于每个进程的基础上。
通常，报告工具需要在最佳报告和最佳互操作性之间做出权衡。例如，如果我没记错的话，如果您在同一进程中同时使用 Crashlytics 和 KSCrash，Crashlytics 正确捕获有关 C++ 异常信息的能力就会受到损害。
问题 2：崩溃的原因是谁？
忽略问题 1，记者如何知道崩溃是图书馆还是应用程序？这是一个广泛的话题，基本上可以归结为碰撞责任的核心问题。崩溃是一种影响，但大多数开发人员不会立即以这种方式想到崩溃。当你想修复崩溃时，你需要一个原因。确定图书馆是原因并不容易。在你思考 "shouldn't it just give me the crashes with my library's frames in it?" 之前，想象一下它是如何在 UIKit 或 Foundation 上工作的。
有很多方法可以解决这个问题。然而，在这里不离题太多，我相信崩溃总是由主机应用程序拥有，但第三方可能也感兴趣。这带来了一大堆其他问题，包括验证库所有者和处理 privacy/security 对主机应用程序的影响。整整一件事。
无论您如何解决这个问题，我认为解决方案只能在服务器端使用报告服务来完成。理论上，他们可以获取报告并进行分析。 Crashlytics' Insights系统是朝这个方向迈出的一步。但是，它目前不向图书馆供应商提供查看这些报告的能力。它的重点更多是将崩溃（影响）与众所周知的原因（或class原因）联系起来。
总结
努力使您的库尽可能稳定是一个极好的目标。不幸的是，我只是认为它不能通过专门的进程内报告来完成。
您实际上应该做的是帮助您的客户端开发人员更好地了解您的库在做什么。因此，当它确实崩溃时，可以更轻松地调试并向您报告。
- 说出你所有的 queues/threads
- 包括某种日志记录工具
- 积极检查有效 parameters/input
- 使从 API 传回的错误尽可能具有描述性和全面性
- 永远不要在生产中断言（我对主机应用程序的看法恰恰相反）
- 从不抛出 ObjC and/or C++ 异常
- 永远，永远不要在你的代码中@catch/catch
- 查看
NSProcessInfoAPI，这有助于更好地揭示您的库在调试期间正在做什么
我希望这对您有所帮助，尽管它并不能真正将您带到您想要的地方。