iOS 警告处理方法

一个好的程序猿，会重视他写的每一行代码，看到警告会去思考为什么，会去尽量的消除警告，消除警告是代码洁癖必不可少的一项。所以对于iOS开发者来说了解警告的类型，并开启必要的警告是必须的。下面是Build Setting里关于warning的配置选项与Podfile配置。

ios 警告:The iOS deployment target is set to x.x, but the range of supported deployment….消除

开启工程我们会看到这样的警告

/Users/linqiang/Documents/Project/ios-app/Pods/Pods.xcodeproj
The iOS Simulator deployment target ‘IPHONEOS_DEPLOYMENT_TARGET’
is set to 8.0, but the range of supported deployment target
versions is 9.0 to 14.5.99.

target ‘MJRefresh’ 在这里插入图片描述
他们是如何产生的呢？仔细看一下应该能理解其就是依赖的第三方库 在 pod 工程中 targets 中

给出的警告。比如我自己的xcode 是 xcode 12.5 可以从警告看出，版本支持为9.0~14.5，当低于此范围则会给出警告。

消除警告

在podfile 最下方加上以下代码

post_install do |installer|
  installer.pods_project.targets.each do |target|
    target.build_configurations.each do |config|
      if config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'].to_f < 9.0
        config.build_settings['IPHONEOS_DEPLOYMENT_TARGET'] = '8.0'
      end
    end
  end
end
复制代码

第三方库的时候他们的注释会出现很多警号

对于这样的警告太多，直接影响我们判断其他内容&警告⚠️，我们要想对待bug那样消除警告。

对于上面在注释中的警告的解决方法

Build settings ->all – Documentation Comments – NO

禁止所有的Warnings

Inhibit All Warnings表示是否禁止所有的Warnings，默认为NO。如果设置为YES，那你就不会得到任何警告提示了。

迂腐的Warnings

Pedantic Warnings这个主要跟C和C++的标准有关，Pedantic意思是迂腐的，也就是说那些没有严格按照ISO C和ISO C++标准的代码是否显示。默认为NO，也就是不提示。

将警告等于错误

Treat Warnings as Errors，一种很常见的做法和代码洁癖是将警告标识为错误，从而中断编译过程。这让开发者不得不去修复这些警告，从而保持代码干净整洁。这个选项默认是NO，设置为YES，就会将警告等于错误。有时候我们在开发时不想被一些简单的warning给打断，那么可以先设置Debug为NO，Release为YES，在build release时就可以发现这些warning了。

我们也可以在Other C Flags里加入-Werror标识将警告等于错误。

如果要将某一类警告等于错误可以这样写-Werror=…。示例如下：

Other C Flags

我们可以在Other C Flags中加入-Werror、-Wno-error=…、-Werror=…，来实现类似于Treat Warnings as Errors选项的效果及更强大的扩展。

其实我们也可以在Other C Flags加入特别的标识来达到Build Setting里设置对应警告选项BOOL值的效果。

Other C Flags里设置的优先级是大于某一个具体配置的。如在Apple LLVM 8.0 – Warning – All languages中的选项Unused Variable设置为YES，那么就表示这种类型的warning是会提示的。但是我在Other C Flags中加入-Wno-unused-variable，表示这种类型的warning是不提示的。
那么最后以Other C Flags中的设置为准，也就是不会提示这种类型的warning。

Other C Flags中具有以下几种标记类型：

将警告等于错误相关

这部分上面已经提到过，包括-Werror、-Wno-error=…、-Werror=…。

打开或关闭某些警告

-W…开启某些警告，如-Wunused-variable。-Wno-…关闭某些警告，如-Wno-unused-variable。

打开某一警告组

-Wall 并不是所有警告。这一个警告组开启的是编译器开发者对于“你所写的代码中有问题”这一命题有着很高的自信的那些警告。要是在这一组设定下你的代码出现了警告，那基本上就是你的代码真的存在严重问题了。但是同时，并不是说打开Wall就万事大吉了，因为Wall所针对的仅仅只是经典代码库中的为数不多的问题，因此有一些致命的警告并不能被其捕捉到。但是不论如何，因为Wall的警告提供的都是可信度和优先级很高的警告，所以为所有项目（至少是所有新项目）打开这组警告，应该成为一种良好的习惯。

-Wextra 如其所名，-Wextra组提供“额外的”警告。这个组和-Wall组几乎一样有用，但是有些情况下对于代码相对过于严苛。一个很常见的例子是，-Wextra中包含了-Wsign-compare，这个警告标识会开启比较时候对signed和unsigned的类型检查，当比较符两边一边是signed一边是unsigned时，产生警告。其实很多代码并没有特别在意这样的比较，而且绝大多数时候，比较signed和unsigned也是没有太大问题的（当然不排除会有致命错误出现的情况）。需要注意，-Wextra和-Wall是相互独立的两个警告组，虽然里面打开的警告标识有个别是重复的，但是两组并没有包含的关系。想要同时使用的话必须在Other C Flags中都加上。

-Weverything 这个是真正的所有警告。但是一般开发者不会选择使用这个标识，因为它包含了那些还正在开发中的可能尚存bug的警告提示。这个标识一般是编译器开发者用来调试时使用的，如果你想在自己的项目里开启的话，警告一定会爆棚导致你想开始撞墙。

关闭警告

全局关闭

在build setting里找到对应的警告选项设置为NO即可。或者在build setting中的Other C Flags里加入-Wno-…标识。

相应文件关闭

在Build Phases的Compile Source相应的文件中的Compiler Flags加入对应的编译标识即可，如-Wno-unused-variable。优先级如下：
Build Phases的Compile Source>Build Setting的Other C Flags>Build Setting中的某一中具体warning的开关
相对文件打开警告也类似。

在某几行关闭某个警告

#pragma clang diagnostic push

#pragma clang diagnostic ignored "-Wunused-variable"

int a;

#pragma clang diagnostic pop 
复制代码

这样如果之后a未被使用，也不会出现unused-variable类型的警告了。

参考

关于iOS里的警告