框架中的崩溃分析工具

我的团队正在开发一个供客户端使用的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系统是朝这个方向迈出的一步.但是,它当前不向图书馆供应商提供查看这些报告的功能.它的重点更多地是将崩溃(一种影响)与一个众所周知的原因(或原因类别)联系起来.

摘要

试图使您的库尽可能稳定是一个很好的目标.不幸的是,我只是认为无法通过专用的过程中报告来完成.

您实际上应该做的是帮助您的客户开发人员更好地了解您的库在做什么.因此,当它崩溃时,可以更轻松地进行调试并将其报告给您.

>命名所有队列/线程
>包括某种日志记录工具
>积极检查有效的参数/输入
>尽可能使您从API中传回的描述性和综合性错误
>永远不要断言生产(对于宿主应用程序,我感觉与此相反)
>永远不要抛出ObjC和/或C异常
>永远不要@ catch / catch代码
>检查NSProcessInfo API,这些API可以帮助更好地展示您的库在调试期间正在做什么

我希望这会有所帮助,即使它并不能真正将您带到想要的地方.

转载注明原文:框架中的崩溃分析工具 - 代码日志