如何通过运行时检查来加强代码？
在某些发生运行时类型检查的情况下，无法进行编译时类型检查。 就像从网络上读取数据（当时源代码不知道数据）一样，从用户那里获取输入不满足要求以及由于算术运算等导致的溢出问题。
Swift提供断言来意识到这些问题。
在深入研究Assertions之前，让我们看一下新引入的Swift编译模式和Swift优化级别。
- 调试构建：增量-Swift支持增量构建目标，即，在更改单个文件时，不重建目标中的每个Swift源文件。 依赖于已修改文件的每个文件都将被重建。
- 发布版本：整个模块-此选项一起优化目标中整个模块的所有文件，并提高性能。 它可以执行函数内联和函数专业化等优化。
Swift提供了四种不同的优化级别：
- -Onone ：基本上用于常规开发，即调试版本。 它执行最少的优化，并保留所有调试信息。 建议始终在此模式下使用增量编译。
- -O ：这用于生产代码。 编译器执行了激进的优化，可以极大地改变发出代码的类型和数量。 调试信息将被发出，但是会造成损失。
- -Ounchecked ：这是一种特殊的优化模式，适用于愿意为性能而牺牲安全性的特定库或应用程序。 编译器将删除所有溢出检查以及一些隐式类型检查。 通常不打算使用此方法，因为它可能导致未检测到的内存安全问题和整数溢出。 仅当您仔细检查了代码对于整数溢出和类型强制转换是安全的后，才应使用它。
- -Osize ：这是一种特殊的优化模式，在该模式下，编译器将代码大小优先于性能。 此模式适用于整个模块以及单文件编译，而整个模块模式可提供最佳的优化结果。
注意：可以在项目的构建设置中设置优化级别和编译模式。
每当我们需要根据预期的条件检查代码时，就可以使用断言，并且将引发异常。
标准Swift库带有五个断言函数：
- 断言（_：_：file：line 🙂
- assertionFailure（_：file：line 🙂
- 前提条件（_：_：file：line 🙂
- preconditionFailure（_：file：line 🙂
- fatalError（_：file：line 🙂
让我们详细研究每个功能：
- assert（）：此方法类似于传统的C样式断言，带有可选消息。 它仅应用于在测试过程中处于活动状态但不会影响运输代码性能的内部完整性检查。 如果
condition评估为false，则在打印message后以可调试状态停止程序执行。
示例：对于要入学的孩子，最低年龄要求为3岁，因此我们可以在此处检查此情况：
注意：“ **”优化器可能会假定从未调用此函数。
- https://swift.org/blog/whole-module-optimizations/
- https://swift.org/blog/osize/
- https://developer.apple.com/documentation/swift/swift_standard_library/debugging_and_reflection
采用断言是一个好习惯。 您应该注意使用正确的功能进行适当的构建。 一个小错误可能会导致生产应用程序崩溃，从而影响最终用户。
感谢您的阅读，我们期待您的反馈。
您可以在以下位置找到我：
Linkedin个人资料： Aaina Jain
推特： __aainajain