（Unity 2019.2）iOS构建在应用程序被用户杀死5秒后崩溃 描述

应用程序在用户终止后2~5秒出现崩溃（即强制终止应用程序）。这只发生在基于多个unity版本的iOS版本上（请参阅下面的详细信息）。 大多数碰撞报告不是通过Crashlytics发送的。控制台上几乎没有崩溃，即使我们每天都不断地重复这个错误。 Android版本不会出现相同的错误

复制步骤

开局

等待加载场景即将完成或游戏场景完全加载

终止应用程序

等待2~5秒，然后查看碰撞报告窗口

• 繁殖率：80%
• 用于测试的设备：iPhone SE、iPhone 7、iPhone 8、iPad Mini 4
• 还观察到：iPhone XS、iPhone XR上的崩溃

补充资料

• 这是一个具体的问题。我们在Android上有相同的构建，可以正常工作
• 在大多数情况下，Crashlytics不会捕获崩溃报告（请参阅下面的一些崩溃）
• 只有在加载的最后步骤（外部SDK正在初始化）才会发生崩溃
• 在TestFlight上，几乎所有版本的崩溃计数都是0，包括用户报告崩溃的版本
• 使用调试按钮调用Unity的Application.Quit（）方法不会导致应用程序崩溃，即使关闭需要一段时间
• 崩溃似乎对操作系统版本和iOS设备是不变的

技术资料

• 统一版本：2019.2.17f1。也与2019.2.0f1和2019.3.10f1一起复制
• 外部插件是
• 事故报告

探索 以下是迄今为止未成功的所有解决方案尝试的列表：

• 删除GameAnalytics插件
• 删除IronSource插件
• 删除UnityAP插件
• 关于后处理iOS
• 将最低操作系统版本设置为9.0
• 注释所有应用程序暂停/退出实现（包括插件）
• 启用位码

解决方案 说明：一般的问题是当应用程序完成时，iOS上的任何代码块都会阻塞主线程（有关更多信息，请参阅）。在我们的例子中，这是因为玩家杀死应用程序时正在进行的请求。当应用程序终止时（使用

Dispose（）

方法），我们在服务器上保存播放器进程时，请求阻塞了主线程，导致崩溃。解决方案是删除此特定保存。我们测试了一个包含此修复的构建，到目前为止，在加载游戏场景后，我们没有20次尝试杀死游戏时发生崩溃。我们以前没有考虑过这一点，因为这段代码从2019年8月就存在了，从那以后就再也没有被触及过。这个问题直到2020年2月才开始出现

更多信息：由于这段有问题的代码自2019年8月起就在项目中，并且问题仅在2020年2月才开始出现，因此有可能与iOS版本有关。我们还没有调查变更日志，但到目前为止出现崩溃的最旧iOS版本是2019年10月28日发布的iOS 13.2

另一种可能是后端代码的某些更改导致请求挂起。当我们使用BestHTTP时，默认情况下，当应用程序终止时，所有请求都会中止。我们尚未调查

Dispose

与

OnDisable/OnApplicationQuit

的执行顺序是否可能是问题所在。此外，默认情况下，BestHTTP在应用程序退出期间中止的请求仍会调用回调。在我们的例子中，该保存播放器的回调是

null

，因此这可能不是问题所在

相关碰撞：我们在装载现场仍面临一些碰撞。就我们所见，当有请求时，它们就会发生。这些问题的再现率远远低于游戏场景中的问题

提示：我们很难在Crashlytics上检索日志，因为大多数日志都没有被发送。以下是如何从iOS设备本身检索日志的逐步步骤：

打开iPhone/iPad设备上的设置应用程序

转到隐私（在iOS 13上显示在电池下方）

滚动至底部，打开分析和改进

开放分析数据

查找所需应用程序的日志