点赞评论，感觉有用的朋友可以关注笔者公众号 iOS 成长指北，持续更新
原书为 iOS Crash Dump Analysis Book，已得作者授权，欢迎 star
当近期的代码修改导致应用程序发生崩溃时，我们可以很容易的对崩溃进行分析然后找到相关代码并进行修改。但是通常，崩溃只是由于操作环境的变化而出现。那可能是最烦人的。例如，应用程序在办公室中正常运行，但在客户站点崩溃。我们没有时间去探究为什么崩溃，但需要快速解决或提出解决方法。当探索一个新项目时，会出现另一个常见的问题场景。 在这里，我们没有使用代码库的经验，但是在编译和运行应用程序后立即会遇到崩溃问题。
在本章中，我们将探讨由于操作环境的变化而导致崩溃的可能原因。无需深入分析手头问题的细节就可以解决许多问题。 实际上，有时我们只需在取得进展的同时进行回顾，便可以追溯到根本原因。
故障排除
资源缺失问题
有些时候，我们的应用程序由于资源缺失问题而在启动时崩溃。
我们应该尝试去编译运行项目中的所有的Xcode Target。有时候，某个特定的 Target，会成为该项目整体环境不可获取的一部分如果是这样，我们可以做一个注释，以便稍后解决这些问题。
二进制兼容问题
由于二进制兼容的问题，有些时候，我们的应用程序会在启动时发生崩溃。
如果我们刚刚更新了我们的Xcode，或者在编译好我们工程的同时拉代码进行了更新。我们可以使用 Option-Command-Shift-K 命令编译过程中产生的中间文件，目标文件及可执行文件，使得项目回到没有编译之前的状态，然后重新编译。
一般来说我们可以直接删除
~/Library/Developer/Xcode/DerivedData达到近似效果
只有模拟器有的问题
有些时候，我们的应用程序只在模拟器上发生崩溃。
这时候，我们应该尝试模拟器的 Hardware->Reset 功能对内容和功能进行重置。我们可以尝试使用 iPad 模拟器来替代 iPhone模拟器，反之亦然。示例项目通常用于解释特定技术，而不会去考虑产品化或着通用性。
特定设备的问题
有些时候，我们的应用程序只会在客户设备上发生崩溃。
我们可以检查 Wi-Fi 设置或尝试将 iPad 热点连接到 iPhone。在办公室/家庭环境中开发我们的应用程序时，有时我们会忽略诸如连接或延迟之类的网络问题。如果这就是问题所在，我们应该记录下来以便尝试并修复这些问题。
用户设备部署的问题
有些时候，我们的应用程序仅在客户设备上发生崩溃。
当我们将电脑与用户的设备相连时，我们可能正在进行 Debug 环境的部署。这意味着推送通知的 tokens 将是开发环境而不是生产环境的推送 tokens。这同时也意味着资源的访问授权（例如，对 Camera 相机功能的授权）不再有效，因为它们可能已经通过应用程序的 TestFlight 版本或先前的App Store版本（生产版本）获得了批准。
我们应该尝试通过 Command -< 选择左侧面板中的 Run，右侧面板中的 Info 选项，Build Configuration 设置 Release（不是 Debug）来切换部署配置。 我们还应手动检查 iPad/iPhone 设置中的任何资源访问授权。
特定语言环境的问题
有时候，客户设备的特定的语言环境会导致崩溃的发生
错误的语言环境中可能会缺失某些资源文件。此外，处理语言环境充斥着毫无征兆的特殊情况。我们应该尝试将区域设置暂时更改为已知的语言区域。 当你回归问题时不要忘记做好笔记。
不同地区的用户，NSCalendar 默认的 firstWeekday 的值是不一致的，这个基于当地的习惯。如果你的 APP 的受众更为广泛，请注意这一点
对于崩溃的思考
从上面的例子中得到的教训就是我们需要在更广泛的背景下去思考我们的代码。我们应该考虑应用程序的运行环境。 包括：
- 编译后的代码
- 代码模块之间的二进制不兼容性（不同的语言版本，编译器和工具链）
- 捆绑或下载到应用程序中的资源文件
- 构建配置（例如
Release或Debug） - 网络环境，可用性/延迟/速度
- 应用程序的允许使用的权限
- 应用程序被拒绝的权限（在移动设备管理安全环境中）
- 平台变种
- 方向
- 前后端不同的操作模式
- 硬件性能(旧的慢速硬件与更快的新设备)
- 硬件组件(GPU，内存，CPU，配件等)
- 地理位置相关问题
- 区域问题(语言环境等)
- 存在诊断设置
- 存在调试器或分析器
- 目标设备的操作系统版本
作为树立正确的思路以解决应用程序崩溃的第一步，我们有必要解决上述每个操作环境差异，并试着记下这种差异是否会导致我们知道或怀疑可能发生的崩溃。这告诉我们，崩溃更多是关于环境而不是源代码。另一个次要的见解是，我们越能够根据特定的环境差异生成一系列假设，我们就能更容易、更快地找到其他人看起来很神秘的崩溃的根本原因，而且我们几乎是神奇的想出了问题可能出在哪里的建议。
以下是民间传说中的一些奇怪的信息技术崩溃案例，以激发我们的欲望并让我们展开思考：
基于不同语言环境的崩溃
俄语语言环境在日期处理期间导致崩溃。
这是因为 1984-04-01 被用来当做哨兵日期。但是，在俄罗斯是没有这样的日期/时间，因为在俄罗斯当天是没有午夜的，即没有 1984-04-01 00:00:00。这是因为俄罗斯的夏令时开始于当天的 1 点钟。
这是在 WecudosPro iPad 应用程序开发期间在俄罗斯进行测试时看到的
地理位置引起的崩溃
一台计算机在每天的不同时间都会发生崩溃。
这个问题实际上是因为这台计算机被放置在一个有船只经过的河口旁边的窗户。在涨潮时，一艘军舰将驶过，其雷达将破坏电子设备从而导致计算机发生崩溃。
在 Kepner-Tregoe 正式的问题解决培训会上，这个民间传说故事被告知给在英国的 Sun Microsystems 客服中心的工程师们。
总线噪音崩溃
当计算机同时承受较大的网络负载和磁盘负载时，系统会发生崩溃。
这个奔溃是由于磁盘损坏造成的。每64字节的内存中都会出现一个零。它是计算机的缓存行大小。由于内存板接线错误，导致旁边的磁盘带状电缆在64字节边界处产生噪音。
这是在 Sun Volume Systems Group 计算机的早期原型中看到的。
感谢你阅读本文！ 🚀
