使用 Clang 静态分析器尽早发现 Bug
这篇文章向你展示如何在 Xcode 上使用 LLVM 内置的静态分析器（static analyzer）帮助你找到 Bug 并且修复它。
快速使用
静态分析器是一个 Xcode 内置的工具，使用它可以在不运行源代码的状态下进行静态的代码分析，并且找出其中的 Bug，为 app 提供质量保证。
静态分析器工作的时候并不会动态地执行你的代码，它只是进行静态分析，因此它甚至会去分析代码中没有被常规的测试用例覆盖到的代码执行路径。
静态分析器只支持 C/C++/Objective-C 语言，因为静态分析器隶属于 Clang 体系中。不过即便如此，它对于 Objective-C 和 Swift 混编的工程也可以很好地支持。
下面是一个实际的使用案例，使用 Objective-C 和 Swift 混编的工程。通过点击 Xcode 的 Product 菜单栏中的 Analyze 选项就可以让分析器开始工作。
像编译一样，需要等待一段时间，然后被静态分析器捕获的问题就以蓝色的感叹号 在 Xcode 上方显示出来。也可以在 issue navigator 中查看蓝色的分析器捕获的问题。
以下是目前分析器支持捕获的错误类型：
其中包括了安全、逻辑、以及 API 方面的问题。分析器可以帮你找到以上的这些问题，并且解释原因以及指出代码的执行路径。
这里是 WWDC 案例工程中被分析器捕获的一个问题：
可以看到这个方法声明了返回类型为 nonnull，但是分析器发现这个方法可能返回为 nil，这并不符合返回值定义的预期。如果想要查看返回为 nil 的具体原因，我们可以通过点击左边 issue navigator 中的这个 issue，点击展开后的具体步骤，查看分析器分析到的导致问题产生的代码执行路径。
点击导致返回 nil 的最后一个步骤，可以看到：
自底向上查看，最后一个步骤是 position 这个变量初始化为 nil。通过点击倒数第二个步骤可以看到，regularPositionAtDate 这个方法没有被调用，因为方法的接收者是 nil。而我们知道，在 OC 中调用方法（也叫消息发送）的时候，如果方法的调用者（也被称为：消息的接收者）本身为 nil，方法调用的结果会返回 nil，所以这行代码的执行结果就是 position 依然为 nil。
那么为什么方法的接收者 object 变量是 nil 呢？继续向上查看我们发现是因为这个 switch 语句中的 default 分支没有做任何的处理，这样 object 对象就会保持初始化的状态，即为 nil。
找到了原因，为了修复这个问题，通过把第一个 case 中的处理作为 default，对 object 赋值为 self 即可，修复之后再次运行分析器，确保这个 bug 被成功修复。
如果这个 bug 没有被修复，这个 OC 的方法就很有可能返回 nil，而这个时候如果恰好是 Swift 在调用这个方法的话，就会马上产出一个运行时异常。
借助静态分析器，我们就能轻松地发现并修复这类隐藏较深的隐患！
Xcode 13 新增的检查项
在 Xcode 13 中，静态分析器也得以升级，现在它可以捕获更多的一些逻辑问题：
- 死循环
- 无用的冗余代码（例如多余的分支条件）
- 断言 Assert 的副作用
- C++ 中 move 和 forward 的滥用导致的潜在问题
一部分的改进来自于开源作者们对 Apple Clang 编译器的贡献。
下面举例：
NSAssert 中的副作用
使用 NSAssert 规避非预期的代码逻辑是很常见的好习惯，但是不规范地使用也会带来一些副作用，例如在 NSAssert 的判断条件中对变量或内存进行修改操作。
上图例子中，依旧是太阳系系统的案例，数组中是一个个的天体对象，遍历天体，计算有卫星的天体数量，由于这个计数变量 objectsWithMoonsCount 是在NSAssert中做的累加操作，但是在Release模式中，为了程序的执行效率，会把assert给禁用，这样这个累加的操作就不会在Release模式下被执行，这样就导致了业务错误。
这样的错误在 Xcode 13 的静态分析器中可以被捕获出来，不仅仅是 Objectie-C 的 NSAssert，也包括了 C 和 C++ 的 assert 函数：
当然这个代码也很好修复，我们只需要把累加操作外置到NSAssert函数的上面即可：
下面是一个很常见的死循环的案例，这种稍微复杂一些的逻辑，乍眼一看，似乎没有什么问题：
这段代码中，做了一个二维循环，但是在内层的循环中，没有对 column 做递增，而是做了 value 的递增，这个问题虽然会隐晦，但是新版本的静态检查器可不会错过它！
如图，它会捕获这个问题：
把 value 替换成 column 修复这个问题：
自定义分析器参数
Xcode 也为静态分析器提供了很多的自定义项，方便开发者根据自身工作流进行定制。在 BuildSetting 中通过搜索 analysis 关键字，可以筛选出跟分析器相关的设置项。
每一次编译都执行分析器
通过打开 Analyze During 'Build' 可以使得每一次编译操作都执行分析器：
设置静态分析器的运行模式
另一个选项，Mode of Analysis for 'Analyze' 可以配置分析器运行的模式，Xcode 提供了两种运行模式：Shallow(faster) 和 Deep，顾名思义，Shallow规避了去检查一些耗时复杂的检查操作，所以 Shallow 运行的更快，Deep 则进行深入的检查，能抛出更全面的错误。
专项检查配置
另外，静态分析器也提供了一些专项检查的配置，可以根据工程情况定制选择：
例如，如果项目有严格的安全检查，可以打开下图中选中的这些配置项目：
如果静态分析器抛出的某一类问题你并不需要关注，你想忽略掉这类问题，可以在下面这些选项中找到并关闭这类策略，从而使得静态分析器捕获到的问题对你的工程更有参考意义：
单个文件的分析
我们也可以对单个文件进行分析，选中你想要分析的文件，在 Product 菜单栏下选择 Analyze ’FileName‘ 即可进行对这个文件进行分析，并且不会分析import关联的所有文件。
这个操作非常方便，不需要编译就可以对我们修改的代码进行分析。
以上是 Session 10202 中的全部内容，以下是译者补充部分
静态分析
静态分析并不是一个新奇的东西，早在 Clang 出现之前，C 和 C++ 的代码就有了静态分析工具，例如：cppcheck。在过去的几十年中，静态分析器已经从基本的语法检查器发展到可以通过对代码的语义进行推理得以捕获更深层的 bug 的工具。
静态分析程运行的时候，并没有实际运行你的代码。不同于我们常见的黄色编译警告⚠️。
与编译警告有什么区别？
当我们第一次运行静态分析程序的时候，看到那些被 Checker 捕获出来的问题，会觉得跟编译器的黄色警告很类似，对吧？
因为编程器也在天天跟我讲说「这个变量你定义出来但是 Never used~」，那我第一个问题当然是：
那黄色和蓝色的 warning，有什么区别呢？反正又不影响程序运行？
编译的本质是把各种语言的代码转换到目标机器的指令集，我们经常会讨论编译器的效率、目标代码的执行效率、编译过程如何对机器码进行优化，等等这些关于速度和效率的问题。
静态分析唯一关注的事情就是寻找代码缺陷，它做的事情，就是用 CPU 的时间去换取代码逻辑的强壮，尽它最大的可能去分析找到代码中的各种 Bug，甚至于在一些问题的寻找上，它的算法的时间复杂度可能是指数级别的！就为了寻找确保一个不一定会出现的错误。
所以，点击「Analyze」按钮之前，你要提前心里有预期，它的速度真的不能跟编译器相提并论。
当然静态分析器也不能完全不顾执行效率，所以虽然它尽量地去追求了一些轻量级和执行效率，但是也是被限制在一定的资源范围内，去用合理的 CPU 资源，去换取更多的检查执行，从而尽可能的保证代码质量。
另外从范围角度来解答这个问题：LLVM 的编译流程涉及三部分：前端代码编译（Clang）、IR 中间代码生成优化、目标机器代码翻译优化（x86/arm64等）。静态分析器是编译器前端的一部分。
局限性与持续性
静态分析器的原理很好理解，它由一个入口引擎和很多很多的 Checker 来完成。
引擎负责读取配置参数进行启动，以及管理这些若干 Checker 来执行各自的捕获算法，就像自动化测试中自动执行测试用例一样。
所以也就像自动化测试一样，静态分析能捕获出来的问题，全部都是经过专门设计的。
因为 Checker 的执行逻辑是有限的，静态分析能做的事情当然也是有限的。作为一个代码健壮性的辅助工具，更多的逻辑错误和设计方案上的问题只能开发设计人员自己来负责。
虽然静态分析有自己本身的局限性，但是拿 Clang 静态分析器来说，在达到那个峰值之前，还有很长的一段路要走，以后每年随着 Xcode 的更新，也会有越来越多更实用的分析项提供给开发者们使用！
关于 Clang 静态分析器
Xcode 于 3.2 版本内置集成了 Clang 静态分析器。在此之前它是以命令行的形式提供给开发人员使用，下面有命令介绍和深入链接。
Clang 静态分析器的目标是提供一个工业级别的静态分析框架，用于分析 C、C++ 和 Objective-C 程序代码，它是免费可用的、可扩展的，并且拥有极高的代码质量。
Clang 静态分析器基于 Clang 和 LLVM 之上，LLVM 之父 Chris Lattner 对外介绍 LLVM 称之为「一系列接口清晰的可重用库」，Clang 就是这些库中的一个，所以它也具备很好的可重用性。
Clang 是 LLVM 体系中的编译器独立前端，为 C/C++/Objective-C 三种语言（Clang 就是 C Language 的意思），Clang 的 Static Analyzer，是 Clang 的子工具，编译 Clang 后可独立运行，目的就是为了对代码进行静态检查、捕获问题然后报告问题。
源码结构
下图是在 LLVM 中，它的模块位置：
/llvm/tools/clang/lib/StaticAnalyzer
我们可以看到，这个 Checkers 目录下就是一个又一个的检查器，每一个检查器负责一个独立的检查项目，很多的复用结构，共用逻辑部分下沉到 Core 模块中。
因为整个模块位于 Clang 和 LLVM 的上层，所以 Core 模块中大量依赖了 LLVM、Clang 中的库。
示例：下图是 Checkers 文件夹中，数组越界检查的类文件，可以看到他仅向外暴露一个检查函数，执行检查算法，捕获问题传递给调用者。
woboq 是一个在线的源码阅读工具，点击链接[3]可以可以看到 Checkers 路径下的所有 Checkers 文件源码，以及上一级的 Core & Frontend。
scan-build 和 scan-view
scan-build 负责对目标代码进行分析，并生成 html 样式的分析报告。
scan-view 负责在本地运行一个简易的 web server，用来让使用者方便的查看生成的报告。
编译 LLVM 编译后生成的 scan-build 和 view 两个命令的位置：
/build/tools/clang/tools/scam-build
/build/tools/clang/tools/scam-view
如果想了解更多关于这两个命令的使用细节，请查阅官方文档：scan-build: running the analyzer from the command line[4]Clang Static Analyzer[5]
参考资料
[1]博客地址: https://www.jianshu.com/u/9ef127e6fca4
[2]酷酷的哀殿: https://ai-chan.top/
[3]点击链接: https://code.woboq.org/llvm/clang/lib/StaticAnalyzer/Checkers/
[4]scan-build: running the analyzer from the command line: http://clang-analyzer.llvm.org/scan-build.html
[5]Clang Static Analyzer: http://clang-analyzer.llvm.org/