iOS 中常见的宏

__has_include

• 描述
  此宏传入一个你想引入文件的名称作为参数，如果该文件能够被引入则返回1，否则返回0。
• 用法

#if __has_include(<AFNetworking/AFNetworking.h>)
#import <AFNetworking/AFNetworking.h>
#else
#import "AFNetworking.h"
#endif

__func__，__FUNCTION__ ，__PRETTY_FUNCTION__

• 描述
  GCC实现了如下的函数宏
  __func__ C99的标准，但是GCC只输出函数名称。
  __FUNCTION__ 同 __func__，
  __PRETTY_FUNCTION__ 非标准宏。这个宏比 __FUNCTION__ 功能更强:
  （1）若用 g++ 编译 C++ 程序, __FUNCTION__ 只能输出类的成员函数名,不会输出类名；而 __PRETTY_FUNCTION__ 则会以 <return-type> <class-name>::<member-function-name>(<parameters-list>)的格式输出成员函数的详悉信息(注: 只会输出 parameters-list 的形参类型，而不会输出形参名)。
  （2） 若用 gcc 编译 C 程序，__PRETTY_FUNCTION__ 跟 __FUNCTION__ 的功能相同.

__VA_ARGS__

• 描述
  C99 编译器标准允许定义可变参数宏(variadic macros)，这样就使用拥有可以变化的参数表的宏。

#define FYFLog(format, ...) NSLog(format, __VA_ARGS__)

缺省号代表一个可以变化的参数表。使用保留名 '__VA_ARGS__' 把参数传递给宏。当宏的调用展开时，实际的参数就传递给 NSLog() 了。

"##"

• 描述
  （1）在标准 C 里，你不能省略可变参数，但是你却可以给它传递一个空的参数。GNU CPP 在这种情况下可以让你完全的忽略可变参数。在上面的例子中，编译器仍然会有问题（ complain ），因为宏展开后，里面的字符串后面会有个多余的逗号。
  为了解决这个问题， CPP 使用一个特殊的‘ ## ’操作。书写格式为：

#define FYFLog(format, ...) NSLog(format, ##__VA_ARGS__)

这里，如果可变参数被忽略或为空，‘ ## ’操作将使预处理器（ preprocessor ）去除掉它前面的那个逗号。如果你在宏调用时，确实提供了一些可变参数， GNU CPP 也会工作正常，它会把这些可变参数放到逗号的后面。
（2）##还可以起到连接的作用

#define FYFName(Item) Item##Name
NSString *numName;
NSLog(@"%@", FYFName(num));

这里将会输出 numName 的数据.

__LINE__

• 描述：在源代码中插入当前源代码行号
• 用法：

#ifdef DEBUG
#define FYFLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
#else
#define FYFLog(...)
#endif

__FILE__

• 描述：在源文件中插入当前源文件名
• 用法：

NSLog(@"__FILE__ %s", __FILE__);

__DATE__

• 描述：在源文件中插入当前的编译日期

__TIME__

• 描述 在源文件中插入当前编译时间

__STDC__

• 描述：当要求程序严格遵循ANSI C标准时该标识被赋值为1

__cplusplus

• 描述：当编写 C++ 程序时该标识符被定义

NS_ASSUME_NONNULL_BEGIN 与 NS_ASSUME_NONNULL_END

• 描述：

在swift中，可以使用 ! 和 ? 来表示一个对象是 optional，还是 non-optional，如 view? 和 view! 。而在 Objective-C 中则没有这一区分，view 即可表示这个对象是 optional，也可表示是non-optioanl。这样就会造成一个问题：在 Swift 与 Objective-C 混编时，Swift 编译器并不知道一个 Objective-C 对象到底是 optional 还是 non-optional，因此这种情况下编译器会隐式地将 Objective-C 的对象当成是non-optional。

为了解决这个问题，苹果在 Xcode 6.3 引入了一个 Objective-C 的新特性：nullability annotations。这一新特性的核心是两个新的类型注释：__nullable 和 __nonnull。从字面上我们可以猜到，__nullable 表示对象可以是 NULL 或 nil，而 __nonnull 表示对象不应该为空。当我们不遵循这一规则时，编译器就会给出警告。

事实上，在任何可以使用 const 关键字的地方都可以使用 __nullable 和 __nonnull，不过这两个关键字仅限于使用在指针类型上。而在方法的声明中，我们还可以使用不带下划线的 nullable 和 nonnull。

** Nonnull 区域设置 (Audited Regions) **
如果需要每个属性或每个方法都去指定 nonnull 和 nullable，是一件非常繁琐的事。苹果为了减轻我们的工作量，专门提供了两个宏：NS_ASSUME_NONNULL_BEGIN 和 NS_ASSUME_NONNULL_END。在这两个宏之间的代码，所有简单指针对象都被假定为 nonnull，因此我们只需要去指定那些 nullable 的指针。
不过，为了安全起见，苹果还制定了几条规则：

• typedef 定义的类型的 nullability 特性通常依赖于上下文，即使是在 Audited Regions 中，也不能假定它为 nonnull。
• 复杂的指针类型（如 id *）必须显示去指定是 nonnull 还是 nullable。例如，指定一个指向 nullable 对象的 nonnull 指针，可以使用 __nullable id * __nonnull。
• 我们经常使用的 NSError ** 通常是被假定为一个指向 nullable NSError 对象的 nullable 指针。

__IPHONE_OS_VERSION_MAX_ALLOWED 与 __IPHONE_OS_VERSION_MIN_REQUIRED

• 描述：
  这两个宏定义（预编译宏），
  __IPHONE_OS_VERSION_MAX_ALLOWED 满足要求的系统最高版本（可以理解为当前设备的系统版本）
  __IPHONE_OS_VERSION_MIN_REQUIRED 满足要求的系统最低版本（也就是iOS Deployment Target选择的版本）

• 用法：

#if __IPHONE_OS_VERSION_MAX_ALLOWED >= __IPHONE_7_0
// 系统版本在iOS7.0及以上则编译此部分代码
#else
// 如果低于iOS7.0则编译此部分代码
#endif

NS_EXTENSION_UNAVAILABLE_IOS

• 描述：
  标记 iOS 插件不能使用这些 API，后面有一个参数，可以作为提示（比如提示应该用什么 API 替换）。
• 用法：

// 示例 1：
NS_EXTENSION_UNAVAILABLE_IOS("Use view controller based solutions where appropriate instead.")
@interface AFNetworkActivityIndicatorManager : NSObject
@end
// 示例 2：
+ (UIApplication *)sharedApplication NS_EXTENSION_UNAVAILABLE_IOS("Use view controller based solutions where appropriate instead.");

参考：

一九八网络科技V客学院
Nullability and Objective-C