Impact 是一个适用于 Apple 平台的崩溃检测和记录库。 它不是一个完整的崩溃报告系统。 但是，它可以成为一个崩溃报告系统的核心。 它的设计目标是：
- 提高对崩溃报告系统的理解
- 支持所有 Apple 平台
- 可靠性
- 准确性
- 简洁性
- 趣味性
当前功能集
- Mach 异常
- UNIX 信号
- NSExceptions (包括来自 AppKit 的)
- 基于帧指针的堆栈展开
- 对 x86_64 和 arm64 的部分紧凑展开支持
- 对 x86_64 和 arm64 的部分 DWARF CFI 支持
Impact 使用基于文本的日志格式。 虽然格式本身是稳定的，但内容仍然是不稳定的。 它的设计目标是简单，同时仍然使调试和解析在崩溃时失效的情况下成为可能。
进程内崩溃报告非常糟糕。 可用于崩溃事件检测的机制，UNIX 信号和 Mach 异常，是复杂的、有漏洞的，并且不能捕获所有类型的故障。 最重要的是，崩溃报告器需要运行的环境非常恶劣。 这真是一件棘手的事情。
Apple 长期以来一直拥有设备端的所有组件，可以生成世界一流的崩溃报告系统。 虽然他们已经解决了报告方面的问题，但开发者体验（分析、演示、调查工具）仍有很多不足之处。 这使得第三方报告服务对于绝大多数应用开发者来说仍然至关重要。 Apple 的系统也不适用于 App Store 之外的 macOS 应用，这令人失望。
我真诚地希望 Apple 能够解决这些限制，以便我们可以一劳永逸地停止这种愚蠢的行为。
但是，目前，进程内报告是大多数开发者必需的组件。 许多权衡和设计决策会极大地影响报告系统的质量。 了解这些权衡，并明确影响这些权衡的选择是该项目的目标之一。
此外，崩溃报告是一个有趣且引人入胜的问题。 它往往被非常普遍地使用，但却被理解得很差。 我认为 Apple 开发社区可以从对该领域的更深入理解中受益匪浅。
您必须记住，Impact 只捕获有关崩溃事件的信息。 它没有任何工具可以将这些事件传输回您，或者将它们翻译成人类可读的版本。 一个完整的报告系统需要更多的工作。 以下是一些选项：
- Impact 本身，完全控制您如何生成和使用报告
- 与 Wells 集成以进行报告传输和管理
- 使用 Meter 和 ImpactMeterAdapter 进行 MetricKit 崩溃报告，并进行优雅的回退
我曾在 Crashlytics 工作多年。 在那里工作期间，我曾短暂地使用过 PLCrashReporter，然后从头开始构建了一个完全自定义的系统。 我在那里花费了大量时间分析和理解进程内崩溃报告的失效模式。 这项工作塑造了 Crashlytics SDK 的大部分设计，尽管自我离开后情况可能发生了变化。
Impact 的确与 Crashlytics 有许多相同的设计理念。 有时很难不去沿用之前的解决方案。 但主要是因为我相信这些核心设计理念是最好的方法。
如果能看到贡献那就太好了。 如果您想做一些事情，最安全的做法是首先打开一个 issue 或 PR。 这样，我们就可以在您花费太多时间工作之前讨论这些更改。
绝对没有任何经验/知识要求。 只要有兴趣就足够了，我很乐意提供帮助。
我们很乐意听取您的意见！ 通过 issue 或 pull request 与我们联系。
请注意，此项目已发布 贡献者行为准则。 通过参与此项目，您同意遵守其条款。