如何解决Crashlytics中记录“对象引用未设置为对象的实例”异常时，如何找出哪个对象引用为空？
我使用 Crashlytics 发布了一款游戏，可在 Android 和 iOS 上运行。
我有 "Object reference not set to an instance of an object" 异常的记录，这些异常告诉我在哪个方法中遇到了空引用，但不能确切地告诉我是哪个引用，或发生在哪一行。
代码在本地测试中运行成功，但在实际使用场景中，可能会出现空引用。
请注意，在 Unity 中，这可能意味着实际的 MonoBehaviour 对象已被销毁且不再可用，因此在各处添加空检查无济于事。我想知道到底是哪个对象被销毁了，这样我才能找出导致异常的事件顺序。
我想过每隔几行就添加一个带有更新值的 Crashlytics.SetCustomKey()，这样我至少可以猜测发生在哪一行，这样我就可以做出更好的猜测。
但是您有什么更好的建议吗？
编辑：这个问题已被标记为重复，所以我在描述为什么它不是提到的问题的重复。
我已经知道为什么会发生 NullReferenceException，如果它在我本地发生，我可以修复它。 这个问题是与上述重复项不同的问题。 这个问题是关于一个复杂的情况，当一系列事件导致一些对象被销毁，而他们不希望被销毁时。
我的问题更多地与更好地利用 Crashlytics 相关，而不是与 NullReferenceException 相关。
为了更好地描述这种情况，这是一个棋盘游戏。每一轮游戏都会在棋盘上创建一些棋子，当玩家触摸棋盘时，棋盘上会创建一些高亮对象，因此玩家可以选择可以移动棋子的位置。
举个可能的例子，当玩家重新开始游戏或在任何情况下离开游戏时，这些对象都会被销毁。
但另一项工作可能会在刷新后完成它的工作（可能是 AI 思维），然后期望船上有物体，但它们不再存在！
我真的不知道要分享什么代码，我想我需要分享项目的很大一部分。而且我认为这也无济于事。因为我不是在寻找问题的直接答案。但我通常会问如何更好地获取有关 Crashlytics 记录的 NullReferenceExceptions 的更多信息。
我也已经搜索过，但没有找到针对我的具体问题的解决方案。
所以考虑到描述的情况，我知道异常发生的方法。 当我在 Crashlytics 中有记录时，您认为我如何知道该异常发生在哪一行，或者哪个对象为空？ （除了我自己提到的解决方案）
编辑 2：我最初认为堆栈跟踪可能会分散人们对实际问题的注意力，但查看评论后，我认为它确实有帮助。
这是堆栈跟踪：
Non-fatal Exception: java.lang.Exception: NullReferenceException : Object reference not set to an instance of an object. at OfflineGameScreen.MoveSuggestionTouched(OfflineGameScreen) at OfflineGameScreen+<MakeNextMoveByBot>d__74.MoveNext(OfflineGameScreen+<MakeNextMoveByBot>d__74) at System.Threading.ContextCallback.Invoke(System.Threading.ContextCallback) at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext) at System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner.Run(System.Runtime.CompilerServices.AsyncMethodBuilderCore+MoveNextRunner) at System.Action.Invoke(System.Action) at System.Threading.SendOrPostCallback.Invoke(System.Threading.SendOrPostCallback) at UnityEngine.UnitySynchronizationContext+WorkRequest.Invoke(UnityEngine.UnitySynchronizationContext+WorkRequest) at UnityEngine.UnitySynchronizationContext.Exec(UnityEngine.UnitySynchronizationContext)
解决方法
当然不知道您的代码的详细信息，但是您可以在销毁时以及在引发错误之前记录对象的 InstanceID。这可能会导致您进入可能发生异常的逻辑鸿沟。
要小心 nullchecks，主要是在 Updates() 中，因为它们不是“免费的”，因为 unity 有自己的 == 操作符来处理典型的 {{ 1}}。