阅读 513

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.

image.png

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

image.png

给出的警告。比如我自己的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
复制代码

image.png

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

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

image.png

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

Build settings ->all - Documentation Comments - NO

禁止所有的Warnings

image.png

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

迂腐的Warnings

image.png

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

将警告等于错误

image.png

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

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

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

image.png

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里的警告

文章分类
iOS
文章标签