请谨慎使用 @weakify 和 @strongify

482 查看

前言

相信大部分见过 @weakify 和 @strongify 的开发者都会喜欢上这两个宏。但是很多人只知道它的强大威力,却没有意识到在特定环境下的危险性。

本文将通过代码测试的方式告诉读者,如何正确地使用这两个的宏。

@weakify 和 @strongify

本文意在说明其危险性,所以不会全面的讲解这两个宏。
如果您对其该兴趣,请参考其它作者的文章或者自行查看源码。

这两个宏的定义如下:

EXTScope.h#L45-L47

EXTScope.h#L83-L88

其中 rac_keywordify 的定义如下:
EXTScope.h#L114-L118

测试

下面是官方提供了一个示例代码。
示例代码中定义了一个 block,该 block 用于判断入参 obj 是否和 foofar 其中的任何一个对象相等并返回 YESNO

测试代码一

为了方便测试,这里重写了 rac_keywordify 的定义。

相信眼尖的读者一眼就能看出与上面代码的不同。
block缺少返回值

下面是 Xcode 的截图。Xcode 产生一个 Control reaches end of non-void block 的❗️错误提示。

111711809-056de1723d47ea04
错误提示.png

测试代码二

为了方便测试,这里重写了 rac_keywordify 的定义。

这份代码除了将 #define rac_keywordify autoreleasepool { } 修改为 #define rac_keywordify try { } @catch(...) {}以外,与上面的代码并没有不同。
理想的情况当然时,Xcode 依然有❗️错误提示。但是,现实往往是残酷的,Xcode 只提供了一个未使用变量的⚠️。

121711809-ff83f1f00fe772bd
无错误提示.png

由上图可知,Xcode 丢失了错误提示的能力

问题分析

在 Release 模式下,rac_keywordify 被定义为 #define rac_keywordify try { } @catch(...) {},经预处理器处理后,会转换为下面的代码

@try { } @catch(...) {}被添加到了等式的前面。
在这种情况下,Xcode 本身的错误提示能力能被抑制了,就如同源码的注释中提到的那样。

很多人都研究过这部分代码,但是大部分的人都得出类似于这样的结论。

这段宏定义中的代码开头都少了个@,使得weakify、strongify前面必须加上@,当然也只有这作用。 然后这里为什么要判断DEBUG呢?我也不知道,我觉得这里没必要这样判断。

判断DEBUG的作用在于,正常的开发模式都是在DEBUG模式下面进行的。这样可以保留 Xcode 提示错误的能力

结论

请读者回想一下,你是否可以快速的判断出自己是否在 DEBUG模式下开发?如果回答是NO,请谨慎使用 @weakify@strongify

修改开发模式

点击项目名称,在弹出框中,点击 Edit Scheme...

131711809-4762003d6617e1ec
Paste_Image.png

在模态视图中,点击 Build Configuration 单选框

141711809-af6c3c497d3d5fc4
Paste_Image.png