我们苹果后台有大量的崩溃上报，崩溃信息如下：
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: RUNNINGBOARD 0xdead10cc
我们也接到不少用户反馈存在崩溃问题，现象就是App退到后台一段时间后，有概率崩溃，有的用户反馈崩溃的很频繁，我们自测又没有问题，毫无规律。由于我们是TestFlight分发的应用，所以崩溃了会特别明显，因为会弹一个"XX应用已崩溃，是否上报"的系统弹框。如果是AppStore分发的应用，即使存在这个问题，可能也容易察觉，因为你切到别的应用，再切回来发现应用重启了，你也没法分辨是系统正常的杀掉应用了，还是应用崩溃了。
苹果后台崩溃日志的堆栈虽然各不相同，但都涉及到数据库操作，所以我们猜测，这类崩溃和后台操作数据库有关。
崩溃的原因：
异常码 0xdead10cc，意味着应用程序因为在后台操作系统资源（而非App沙盒内资源）而被 iOS 系统终止。
我们的应用包含一个ShareExtensionApp，为了方便主App和ShareExtensionApp共享数据，我们把数据库默认存放应用的共享容器（containerURLForSecurityApplicationGroupIdentifier）中，这就是问题的关键所在。
我们打印并观察一下，主App沙盒路径和共享容器路径区别：
沙盒目录（NSDocumentDirectory）：
/var/mobile/Containers/Data/Application/A4B74E98-9B7D-4DA0-BA15-DFE03AA580E1/Documents/test.db
共享目录（containerURLForSecurityApplicationGroupIdentifier）：
/private/var/mobile/Containers/Shared/AppGroup/806B3545-5ECE-46FF-91E0-C138449A684E/test.db
可以看到，共享目录是"private"开头的私有系统目录，并不是主App的沙盒子目录。
iOS文件的锁机制对在共享区域的文件有更严格的要求。当iOS准备挂起一个应用的时候，系统会检查这个应用是否正在使用一些可能被其他进程使用的文件（即存在对非沙盒文件的锁），如果有，iOS就会直接终止这个应用。
我们的应用退到后台后，在被挂起前，如果仍在进行数据库操作，访问系统private目录下的文件，系统就杀死了我们的应用，触发0xdead10cc状态码。
如何重现崩溃：
偶现的bug最让人头疼的就是如何复现，即使有方案修复，也不确定是否真的修复了。所以，重现崩溃至关重要，没法复现，那就创造条件让它复现！
既然我们怀疑是退到后台后，进行数据库操作导致的崩溃。那我们开发就可以通过写临时代码的方式做暴力测试，退到后台后疯狂访问和修复数据，看会不会崩溃。
经过我们的测试，复现了崩溃，且崩溃错误类型和苹果后台的一致，验证了我们的猜想。
需要注意的是，Debug模式下，错误码是3735883980，网上查了下资料，该值就对应Release模式下的0xdead10cc错误码。
Exception Type: EXC_CRASH (SIGKILL)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Termination Reason: RUNNINGBOARD 3735883980
解决方案：
起初，我们想的方案是，应用退到后台前，暂停数据库操作，回到前台后恢复操作。但这似乎并不容易，你需要保留现场和状态，如何恢复是一个考验。
我们最终采用的方案是，把主App的数据库文件挪到App沙盒目录中存放，然后在合适的时机同步一份到ShareExtensionApp的共享目录。这样，就不存在退到后台仍然访问private目录加锁的问题了。
如何同步：删除共享目录的.db文件，拷贝App沙盒目录的.db文件到共享目录。
同步时机：这个结合自己的业务场景制定即可，比如 App启动时、App回到前台时。尽量避免App处于后台时做同步操作。
总之，iOS系统对于private目录下的文件会更敏感，文件的操作尽量在自己的沙盒目录下进行（比如先把文件从private目录拷贝到沙盒目录），减少对private目录文件的访问和修改，避免各种异常情况发生。
参考文献：
如何避免应用崩溃
0xdead10cc问题调研
Crash in iOS 15 EXC_CRASH (SIGKILL) without reason on TestFlight