objective-c – 为什么[self class]响应methodSignatureForSelector：？

25-04-11 5

如果您对objective-c–为什么[selfclass]响应methodSignatureForSelector：？感兴趣，那么这篇文章一定是您不可错过的。我们将详细讲解objective-c–为

如果您对objective-c – 为什么[self class]响应methodSignatureForSelector：？感兴趣，那么这篇文章一定是您不可错过的。我们将详细讲解objective-c – 为什么[self class]响应methodSignatureForSelector：？的各种细节，此外还有关于Every Pixel Matters: Center-aware Feature Alignment for Domain Adaptive Object Detector、ios – rac_signalForSelector：需要空实现、ios – – [NSObject(NSObject)doesNotRecognizeSelector：]调用时崩溃 – [ViewController prepareForSegue：sender：]、iOS关于-[NSProxy methodSignatureForSelector:] called!App崩溃的问题的实用技巧。

本文目录一览：

objective-c – 为什么[self class]响应methodSignatureForSelector：？
Every Pixel Matters: Center-aware Feature Alignment for Domain Adaptive Object Detector
ios – rac_signalForSelector：需要空实现
ios – – [NSObject(NSObject)doesNotRecognizeSelector：]调用时崩溃 – [ViewController prepareForSegue：sender：]
iOS关于-[NSProxy methodSignatureForSelector:] called!App崩溃的问题

objective-c – 为什么[self class]响应methodSignatureForSelector：？

参见英文答案 > Are classes objects in Objective-C? 1个
methodSignatureForSelector：方法是一个实例方法 – 而不是第一类.那么为什么我这样做时我的应用程序不会崩溃：

return [[self class] methodSignatureForSelector:@selector(selector)];

它也适用于methodForSelector：方法.为什么？事实证明,类可以响应消息,例如alloc和for-messages.任何人都可以对这个问题有所了解吗？

解决方法

对象类的类称为 meta class.在大多数情况下,元类和普通类共享相同的根类NSObject.这就是为什么每个类都响应NSObject的实例方法.

Every Pixel Matters: Center-aware Feature Alignment for Domain Adaptive Object Detector

摘要

域适配目标检测旨在将目标检测器适配到未知的域，新的域可能会遇到各种各样的外观变化，包括外观，视角或者背景。现存的大多数方法在图像级或者实例级上采用图像对齐的方法。然而，在全局特征上的图像对齐可能会使得前景和背景像素同时发生缠绕。和现有的方法所不同的是，我们提出了一个域适配框架提前预测目标和中心度来对每个像素都负责。特别地，提出的方法通过给背景像素更多的关注来进行中心可知的对齐，因此比以前的适配方法效果更好。在大量适配设置的大量实验上证明了我们所提出方法的有效性，并且展示了比SOTA算法更佳的表现。

1、简介

作为图像分析和场景理解的关键组成部分，目标检测对许多高层的计算机视觉应用是必要的，例如实例分割、图像captioning和目标跟踪。尽管目标检测已经取得了显著的进步，将目标检测器适配到各种各样的目标外观、视角和背景是有意义的。例如，一个进行自动驾驶的目标检测器需要在不同天气条件下都工作良好，尽管训练数据在一些特殊天气条件下可能也是需要的。为了解决这些挑战，无监督域适配方法用来将在有标注的源域数据上训练的检测器适配到别的无标签的目标域上。采用一个基于对抗特征对齐的类似策略到分类网络上，对目标检测大量UDA方法用来减少源域和目标域之间的差距。然而这些对齐通常采用全局特征在图像级上进行，当域差距比较大的时候效果不明显。为了提升上述的全局对齐，现存的方法适配实例级分布，在一个区域建议内适配所有像素池化特征图像级分布。然而，因为像素分布在目标域中是未知的，从目标域中提取的区域建议可能包含许多背景像素。结果是，这可能明显融合对齐的过程，当将目标域区域建议的实例级特征适配到源域分布时可能会包含大多数前景像素。本文中，当通过两个域对齐特征分布时，我们将每个像素都考虑在内。为了这个目的，我们设计了一个模块来估计逐像素的目标和整幅图像的中心度，这使得我们的对齐过程关注于前景像素，而不是之前工作里面建议可能包含缠绕的前景/背景像素。为了预测逐像素的信息，我们重新研究研究目标检测框架并且采用全卷积层。结果是，通过域我们的方法旨在聚焦目标的中心区别部分。因此，这些区域对无关的背景像素敏感度比较低，并且采用分布对齐。尽我们所知，我们首次尝试利用逐像素目标和中心度来进行目标检测的域适配。

为了验证我么提出的方法，我们在三个域适配基准上进行了大量的实验：Cityscape到Foggy CityScape、SIM 10K到Cityscape、KITTI到Cityscape。实验结果表明我们的center-aware特征对齐相对于SOTA方法取得了较好的性能。更进一步地，我们提供了消融实验证明了每个组件的有用性。本文的主要贡献如下。首先我们提出在像素级上发现目标部分的差别来更好的解决目标检测的域适配问题。第二，提出了center-aware分布对齐和其对目标尺寸有效的多尺度的扩展方法，并且缓解在适配期间由于背景混乱导致的背景混乱问题。第三，客观的融合研究验证提出的center-aware特征对齐的有效性。

2、相关工作

这部分，我们回顾与我们工作有关系的研究，包括目标检测和目标检测的域适配。

2.1、目标检测

目标检测的研究可以分为基于锚的检测器和基于无锚的检测器。基于锚的检测器编制了一系列的锚来产生目标建议，并且通过建议将目标检测规划为一系列的分类任务。Faster R-CNN是基于锚的目标检测器的先驱，其中RPN用来产生锚。由于RPN的有效性，RPN被广泛地应用在许多基于锚的目标检测中。基于无锚的检测器跳过区域建议的产生的步骤，直接在全卷积上对目标进行定位。近年来，基于无锚的方法利用关键点(box的中心或核心)定位并且与基于锚的检测器相比达到了较好的性能。因此，这些方法需要需要复杂的定位后处理过程来来对检测到的点进行分组。为了避免这个过程，FCOS提出了一个逐像素的预测，在特征图上直接预测类别和每个位置对应到目标上的补偿。本文，我们采用基于无锚检测器的性质来确认对齐过程中的不同区域。

2.2、目标检测的UDA

Chen等人首先提出了两个对齐的方法，图像级和实例级对其，通过分别在图像和实例尺度上采用对抗学习。对图像级对齐，Saito等人进一步指明对齐低等级的特征更加有效，因为全局特征对齐有前景目标和背景混乱的域不变问题。为了提升实例级对齐，Zhu等人应用k-means聚类来对建议进行分组来获得聚类中心，这在全局和实例级对齐中间达到了平衡。然而，他们的方法引入了额外的数据独立的超参数来进行聚类，并且不是端对端训练的。其余提升特征对齐的变化是基于层次的模块，风格迁移来解决基于源域的问题，教师和学生策略被用来探究目标相关性和一个进步的对齐方法。

然而上述方法是两阶段的检测器，Kim等人提出了一个一阶段的适配方法来进行更快的推断，通过一个难负样本挖掘技巧来寻找更加可靠的伪标签。然而，他们的方法仅仅部分的缓解了由背景引起的问题，并且在特征对齐的过程中不考虑每个像素来减少域差距。我们也注意到所有上述的方法都是基于锚的检测器，在目标域中执行执行实例级对其可能对不准确的建议是敏感的，并且在一个建议中前景和背景像素会发生混合。相反地，我们强调通过预测逐像素目标来强调这些缺点，这仅仅在像素尺度上聚焦目标的不同部分。在表1上面，我们总结了上述技巧的对齐方法来进行目标检测的域适配。

3、提出的模型

这节我们，我们首先描述全局特征对齐，并且然后介绍提出的center-aware对齐，这利用逐像素目标和中心度。为了提升性能，我们进一步合并多尺度对齐在适配过程中考虑目标尺度。

3.1、算法概览

给定一个源域图像 I_s ，他们的标签bbox B_s 和无标签的目标域图像 I_t ，我们的目标是预测目标域图像上的bbox B_t 。为了这个目的，我们采用两个互相合并的对齐方法：图像级对齐的全局对齐和更加关注前景像素的center-aware对齐。整个过程如图2所示。在域上给定一个共享的特征提取器G，我们首先提取特征F=G(I)，并且通过使用全局鉴别器和域预测损失来执行全局对齐。第二，在G后面，一个全卷积模块P被用来预测逐像素的目标和中心度映射。通过用特征F合并这些特征，我们采用另一个center-aware鉴别器。

3.2、全局特征对齐

全局对齐的目的是对齐图像级上的特征来减少域差距。为了达到这个目的，通过利用全局鉴别器 $D_{GA}$ 我们应用对抗算法，这么做的目的确认确认每个特征图上的像素来自源域还是目标域。特别地，给定来自特征提取器的空间分辨率为HxW的K维特征图， $D_{GA}$ 的输出是一个域分类映射和F的尺寸是一样的。注意我们将源域和目标域的域标签分别设置为1和0。因此，鉴别器能通过最小化交叉熵损失来优化。对F上的位置(u,v)，损失函数可以写为：

为了执行对抗对齐，对源域和目标域图像我们应用梯度倒转层(GRL)，当优化通过GRL层的特征提取器时梯度的标志会被倒转过来。然后机制工作流程如下。鉴别器的损失通过(1)来最小化，特征提取器通过最大化这个损失来优化，目的是欺骗鉴别器。我们也发现大多数现存的方法(那些在表1中)利用这个全局对齐聚焦在图像级对齐(例如，在真实中更多的背景像素)。我们在我们的框架中我们也使用全局对齐来来完成提出的center-aware对齐，这聚焦在前景像素。

3.3、Center-aware对齐

正如第一节和表一提到的，现存的方法对实例级对齐是基于区域建议的，并且这些方法可能会影响背景。为了解决这个问题，我们提出了一个center-aware对齐方法使得我们可以聚焦在鉴别目标区域上。为了达到这个目的，在像素级上对高置信区域我们采用了一个center-aware鉴别器 $D_{CA}$ 来进行特征对齐。

定义：设计了一个全卷积网络P以后(在3.5节进行了详细的说明)和来自特征提取器G的特征图，我们将F转发过P，并且获得一个分类输出，其中C是目标的类别数。分类和中心度特征图上的每个位置分别表示对应的目标和中心度分数。

发现目标区域：为了发现包含前景目标的置信区域，我们利用上述来自我们目标检测器的两个线索：(1)、目标分数的类未知特征图(2)对目标中心重要的中心度特征图，因此对其能更多的聚焦于目标部分。首先，目标映射可以从分类输出 $M_{cls}$ 中获得。为了获得类未知映射，在每个通道上我们使用sigmoid激活，并且在类别上采用max操作。类似地，最终的类未知中心度映射通过应用中心度输出 $M_{ctr}$ 获得。总体上，最终的特征图 $M_{CA}$ 指导center-aware对齐的计算方式如下：

其中表示sigmoid激活，表示逐通道乘积，例如哈达玛乘积。因为 $M_{obj}$ 和 $\sigma (M_{ctr})$ 是从0到1排列，尺度因子 $\delta$ 引入的目的是防止乘积后值太小。在所有的实验中 $\delta$ 设置为20。

执行对齐：利用center-aware特征图 $M_{CA}$ ，我们能利用像素级的对齐应该更加获得关注。为了使用这个特征图作为我们center-aware对齐的指导，我们用特征图F乘它，并且然后向center-aware鉴别器 $D_{CA}$ 加入它：

我们注意到，因为 $M_{CA}$ 是一个分辨率为HXW的特征图，我们我们将它复制K份来计算它和特征图。然后，通过GRL层我们采用一个(1)类似的对齐过程。结果是，我们的模型对齐像素级的特征和目标类似，并且因此前景和背景的不匹配问题。整个center-aware对齐过程如图3所示。

3.4、提出框架的整个目标函数

给定源域图像Is，目标域图像It，和ground-truth和源域的ground-truth框 B_s ，我们的目标是预测无标签数据上的bounding box B_t 。我们已经描述了源域和目标域图像上的目标对齐函数。这里我们使用Is和It来介绍源域和目标域上损失函数的细节。

目标检测的损失函数：受FCOS的启发，整个模块P由分类、中心度和回归组成。三个分支输出分别为目标特征图 $M_{obj}$ 、中心度特征图 $M_{ctr}$ 和回归特征图 $M_{reg}$ 。对于分类和回归分支，对每个像素它们的目的是预测分类分数和到四个目标框对应的距离。我们将他们的损失表示为 $L_{cls}$ 和 $L_{reg}$ ，这可以分别来用focal loss和iou loss来优化。对于中心度读分支，它预测每个像素和对用目标框中心的距离，并且可以通过交叉熵损失来优化。源域整个检测器的损失可以表示为：

为了简化起见，对每个损失，我们忽略参数。
整个损失：为了通过源域和目标域获得域不变特征，基于两个鉴别器 $D_{GA}$ 和 $D_{CA}$ ，我们应用对抗学习，分别通过最小化目标函数和我们执行全局对齐和center-aware对齐。细节可以3.2节和3.3节发现。整个损失可以表示为：

其中和用来平衡这三部分的权重。

3.5、网络结构和讨论

和以前聚焦于实例级对齐有所不同的是，我们的center-aware特征对齐对目标和中心度特征图需要像素级的预测，因此我们不能直接在以前的网络中进行适配。这节，这节通过使用全卷积模块我们介绍我们的结构来进行像素级的预测，和在适配期间应对目标尺度的多尺度扩展。

网络结构：如3.4节提到的，我们用全卷积检测头P来连接特征图F，P由三部分组成：分类、中心度和回归分支。和以前的方法有所不同的是，所有分支通过全卷积网络来构建，因此预测在像素级上进行。特别地，三个分支由3X3的卷积层构成，每个有256个滤波器。对全局和center-aware对齐中的鉴别器，和，我们使用和检测分支相同的卷积结构，为了保持输出尺寸的一致性并且映射到原始的输入图像。

对尺度对齐：我们观察到这个全卷积结构对目标尺度是不鲁棒的，这对特征对齐的性能是关键的。因此，在特征提取器G中，我们使用特征金子塔FPN来解决不同的尺度问题。特别地，FPN利用五层的特征图，可以表示为。对应最小的目标，对应最大的目标。金字塔中的每个特征图都是256个通道。

我们用一个头网络将每个层连接起来，一个头有两个鉴别器例如和，因此(5)中的损失函数可以扩展到特征图的每个层。结果是通过(1)和(3)我们可以利用全局和center-aware对齐每个特征图 F^i 。它在每个对齐层的后面对一个确定的范围目标尺寸负责，同时使得整个对齐过程是连续的。

逐像素的预测如何帮助特征对齐：有必要提下我们采用逐像素的对齐的理由如下：

(1)、逐像素预测不包含任何固定的和锚相关的超参数来产生建议，在训练期间对源域是有偏向的。(2)、逐像素预测在训练期间考虑所有像素，这帮助提升模型的容量来确认目标域目标的差别区域。(3)、对齐可以在像素级上执行，关注前景像素，这使得模型学习到了更好的特征对齐。注意提出的方法仅仅依靠逐像素预测，因此使用全卷积模块我们的方法可以应用到其他类似的全卷积模型。

4、实验设置

我们首先提供实现细节，然后描述数据集和测试标准。接下来，在多个尺度上我们把我们方法和最先进的方法进行比较。最后，我们进一步理解我们模型中的每个组件。所有的代码和模型都是公开的。

4.1、实现细节

用Pytorch框架实现我们的模型。在所有实验中，我们将(5)中的和分别设置为0.01和0.1。考虑到center-aware对齐包含(2)的检测结果，在应用整个center-aware对齐和训练这个目标函数(5)之前，我们首先用全局对齐来预训练检测器作为一个预先预热的阶段来保证检测的可靠性。对对抗损失通过GRL使用倒转梯度，对和，我们将权重设置为0.01和0.02。模型训练的学习率为，动量为0.9，weight decay为。输入图像用它的短边缩放为800，长边小于或等于1333。

4.2、数据集

我们DAF中的数据集设置一样，天气、合成到真实和在道路景观上进行跨相机适配。

天气适配：Cityscape是驾驶场景的景观数据集，在干燥的天气获得。由2975张图像构成训练集，500张图像构成测试集。每个图像都提供了分割mask，由8个目标类：person, rider, car, truck, bus, train, motorcycle和bicycle。Foggy Cityscape数据集是一个从Cityscape合成的有雾天气。在实验中我们将模型从Cityscape适配到Foggy Cityscape来研究由天气条件导致的域迁移。

合成到真实：Sim10k是一个合成数据集的集合，由10000幅图像和它们对用的bbox标注构成。我们使用Sim10k作为源域，Cityscape作为目标域。从Sim10k到Cityscape用来评估从合成到真实图像的适配能力。文献后，仅仅考虑车类别。

跨相机适配：KITTI和Cityscape类似，表示expect有一个不同的相机设置。KITTI的训练集由7481张图像构成。我们使用KITTI和Cityscape分别作为源域和目标域，来评估跨相机适配。文献后，仅仅考虑车类别。

4.3、总体性能

在表2和表3中，我们将我们的方法和现存的最先进的方法进行比较，同时其余尺寸的评估结果如表4所示。我们给出两个baseline：基于区域建议的Faster R-CNN和我们的全卷积检测器表示为，都没有进行适配。在所有表格中，我们将全局对齐和center-aware对齐分别表示为GA和CA。为了研究我们的模型将域差距减少了多少，我们也给出了Oracle结果，模型在目标域上训练和测试。此外，我们考虑两个骨干结构作为我们的特征提取器：VGG-16和ResNet-101。

天气适配：在表2中，我们注意到我们的baseline在不使用适配时和Faster R-CNN的baseline类似，使用VGG-16骨干网络。适配后，我们的模型(GA+CA)，我们的方法(GA+CA)在baseline的基础上提升了17.6%，在上与其他方法相比达到了最好的性能，特别是和同时采用全局对齐和局部对齐的方法相比。总体上，对每个结构，我们一贯地认为使用提出的center-aware对齐比全局对齐效果更好，并且将两个组合起来组合起来是互不的并且达到了更加的性能。

合成到真实： 在表3的左边部分，我们展示了我们最终的模型(GA+CA)，使用VGG-16骨干模型比现有的方法效果更佳。我们注意到，和最近的方法相比，SW-DA*将增强数据加入到训练中了，通过逐像素的适配技巧，我们的结果依然比它们的好。我们也注意到从仅仅使用GA到GA+CA的提升，使用ResNet-101骨干网络是不充分的。然而，我们发现更多的性能增加可以通过使用其余的mAP标准来增加。

跨相机适配：在表3右边部分，我们展示我们的方法和其余方法相比获得了更好的效果，并且加入了CA连续地来提升结果，例如使用VGG-16和ResNet-101相比于baseline有分别有8.8%和9.7%的提升。

更多的讨论：尽管仅仅使用CA的模型比仅仅使用GA的模型效果更好，他们必要地聚焦在不同的任务上。对于全局对齐，它尽力对齐图像级分布，这有助于减少域差距但是会聚焦到更多背景像素上。对于我们的center-aware对齐，我们聚焦的更多像素可能是前景，对齐过程更多考虑前景分布。同样地，他们作为不同的角色，两者结合是互补的，可以进一步提高性能。

除此之外，我们注意到一些目标类别的精度不足例，如卡车和自行车的精度低于其他目标类。一个原因是这些类包含了源域中更少的前景像素，在其中我们的center-aware对齐对他们投入更少的精力(例如表2中的ResNet-101)来提升性能或者使用模型先验使得模型聚焦这些精度小的类，这不是这篇文章的工作，可以在将来的工作中进行讨论。

4.4、更多的结果和分析

这节，我们在提出的方法上利用更多mAP标准进行讨论。除此之外，我们将center-aware特征图进行可视化，在补充材料中给出更多的结果。

更多的mAP标准：在表4中，我们展示了比更多的mAP标准来分析我们的方法帮助检测器适配不同的场景。在Sim10k情况下，如4.3节所讨论的，我们观察到整个模型使用ResNet-101不会提升太多和仅仅使用GA相比。然而，我们展示在更加有挑战性饿情况，例如，和，加入CA分别提升了2.2%，1.4%和3.9%。这验证我们我们的center-aware对齐对更加有挑战性情况的适用性。类似的观察也可以在KITTI中发现。这些度量也表明了域适配目标检测的一个有趣的方面来更好的理解这些挑战。

多尺度对齐：为了核实我们多尺度对齐方法的有效性，我们在Sim 10k到Cityscape上进行了消融研究。在表5中，我们比较所有尺度的姐夫哦，通过移除最低的两层得到的三个尺度，通风移除最顶两个尺度的三个尺度，和单尺度。注意我们选择单尺度，因为它是中间的尺度，最具有影响力。我们注意到逐渐加入更多的尺度可以提升在所有标准上的性能，这验证了我们提出的多尺度对齐的有效性。更加重要的是F3到F5代表的是小目标，因此比更好。相反的，对来说效果更好，它处理大目标。这表明我们的多尺度训练对处理各种尺度的目标收拾有效的。

定性分析：我们首先展示一些响应映射的示例结果，我们的方法试图定位目标。在图4中，没有自适应的基线很难找到目标中心，而我们的全局对齐方法能够定位一些目标。增加了中心感知对齐的建议，使我们的方法可以发现更多的目标中心在不同的目标尺度。我们还注意到，在我们的模型中，每个比例可能关注不同大小的目标，例如。，图4中的上例可能会错过较大的物体。然而，那些在较小尺度上消失的物体可以在另一个尺度上被识别出来。

5、结论

本文提出了一种中心感知特征对齐方法来解决域自适应目标检测问题。具体来说，我们建议生成像素级地图来定位目标区域，然后使用它们作为特征对齐的指南。为此，我们开发了一种方法来发现中心感知区域，并通过对抗学习来执行对齐过程，允许识别器专注于来自目标区域的特征。此外，我们设计了多尺度特征对齐方案来处理不同大小的对象。最后，我们证明了整合全局和中心感知对齐可以改善对象检测的领域适应，并在众多基准数据集和设置上实现了最先进的性能。

承接Matlab、Python和C++的编程，机器学习、计算机视觉的理论实现及辅导，本科和硕士的均可，咸鱼交易，专业回答请走知乎，详谈请联系QQ号757160542，非诚勿扰。

本文同步分享在博客“于小勇”（CSDN）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。

ios – rac_signalForSelector：需要空实现

我有一个实现UICollectionViewDelegate协议的类.

我正在使用rac_signalForSelector：来注册这样的选择：

[self rac_signalForSelector:@selector(collectionView:didSelectItemAtIndexPath:)]

但是只有当我离开collectionView的一个空实现时它才会触发：didSelectItemAtIndexPath：像这样：

- (void)collectionView:(UICollectionView *)collectionView didSelectItemAtIndexPath:(NSIndexPath *)indexPath {
    // Empty
}

我尝试使用rac_signalForSelector：fromProtocol：也没有运气.

我正在使用Reactive Cocoa 2.2.4

谢谢,
的Mikkel

解决方法

在将对象设置为委托之前,请确保调用-rac_signalForSelector :.一些Apple框架将检查您的类是否在设置委托对象时响应某个委托方法选择器,并缓存该信息,因此如果您尚未调用-rac_signalForSelector：那么您没有明确地实现方法,那些委托方法永远不会被调用.

ios – – [NSObject(NSObject)doesNotRecognizeSelector：]调用时崩溃 – [ViewController prepareForSegue：sender：]

我正在使用Crashlytics来检测我的应用程序中的崩溃.我偶尔会得到以下崩溃报告.

关键崩溃点是 – [NSObject(NSObject)doesNotRecognizeSelector：]和MyViewController.m第596行 – [MyViewController prepareForSegue：sender：].我不知道日志中的问题是什么.是否可能出现多线程问题？我也在使用Parse SDK从Parse云中检索数据.而prepareForSegue：sender：方法将在用户点击披露指标时调用,它应该在主线程中运行.你能不能给我一些提示来解决这个问题.提前致谢.

这是我如何调用prepareForSegue：sender：method.

- (void)tableView:(UITableView *)tableView accessoryButtonTappedForRowWithIndexPath:(NSIndexPath *)indexPath
{
    [self performSegueWithIdentifier:@"onesegue" sender:indexPath];
}

- (void)prepareForSegue:(UIStoryboardSegue *)segue sender:(id)sender
{
    if ([segue.identifier isEqualToString:@"onesegue"]) {
        NSIndexPath *indexPath = (NSIndexPath*)sender;
        OneViewController *destViewController = segue.destinationViewController;
        OneClass* oneObject = self.array[indexPath.row];
        destViewController.objectName = oneObject.name;
    }
}

prepareForSegue：sender：方法由accessoryButtonTappedForRowWithIndexPath：方法触发.我看不到任何其他方式来调用prepareForSegue：sender：方法.所以我不知道为什么indexPath.row会导致异常.

Fatal Exception NSinvalidargumentexception
-[UITableViewCell row]: unrecognized selector sent to instance 0x1f8a6dd0
0    CoreFoundation  __exceptionPreprocess + 162
1    libobjc.A.dylib     objc_exception_throw + 30
2    **CoreFoundation    -[NSObject(NSObject) doesNotRecognizeSelector:] + 170**
3    CoreFoundation  ___forwarding___ + 392
4    CoreFoundation  _CF_forwarding_prep_0 + 24
5    MyApp  
MyViewController.m line 596
**-[MyViewController prepareForSegue:sender:]**
6    UIKit   -[UIStoryboardSegueTemplate _perform:] + 128
7    UIKit   -[UITableView _selectRowAtIndexPath:animated:scrollPosition:notifyDelegate:] + 828
8    UIKit   -[UITableView _userSelectRowAtPendingSelectionIndexPath:] + 156
9 ...    Foundation  __NSFireDelayedPerform + 450
10   CoreFoundation  __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 14
11   CoreFoundation  __CFRunLoopDoTimer + 272
12   CoreFoundation  __CFRunLoopRun + 1232
13   CoreFoundation  CFRunLoopRunSpecific + 356
14   CoreFoundation  CFRunLoopRunInMode + 104
15   GraphicsServices    GSEventRunModal + 74
16   UIKit   UIApplicationMain + 1120
17   MyApp  
main.m line 16
main
18   libdyld.dylib   start
9 Threads
com.apple.main-thread Crashed
0 ...    libsystem_kernel.dylib  __pthread_kill + 8
1    libsystem_c.dylib   pthread_kill + 58
2    libsystem_c.dylib   abort + 94
3    libc++abi.dylib     abort_message + 74
4    libc++abi.dylib     default_terminate() + 24
5    libobjc.A.dylib     _objc_terminate() + 146
6    libc++abi.dylib     safe_handler_caller(void (*)()) + 78
7    libc++abi.dylib     std::terminate() + 19
8    libc++abi.dylib     __cxa_current_exception_type
9    libobjc.A.dylib     objc_exception_rethrow + 12
10   CoreFoundation  CFRunLoopRunSpecific + 456
11   CoreFoundation  CFRunLoopRunInMode + 104
12   GraphicsServices    GSEventRunModal + 74
13   UIKit   UIApplicationMain + 1120
14   MyApp  
main.m line 16
main
com.apple.libdispatch-manager
0 ...    libsystem_kernel.dylib  kevent64 + 24
1    libdispatch.dylib   _dispatch_mgr_invoke + 796
2    libdispatch.dylib   _dispatch_mgr_thread$VARIANT$mp + 35
WebThread
0 ...    libsystem_kernel.dylib  mach_msg_trap + 20
1    libsystem_kernel.dylib  mach_msg + 40
2    CoreFoundation  __CFRunLoopServiceMachPort + 128
3    CoreFoundation  __CFRunLoopRun + 882
4    CoreFoundation  CFRunLoopRunSpecific + 356
5    CoreFoundation  CFRunLoopRunInMode + 104
6    WebCore     RunWebThread(void*) + 444
7    libsystem_c.dylib   _pthread_start + 308
com.crashlytics.MachExceptionServer
0    libsystem_kernel.dylib  mach_msg_trap + 20
1    libsystem_kernel.dylib  mach_msg + 40
2    MyApp   CLSMachExceptionServer
3    libsystem_c.dylib   _pthread_start + 308
com.apple.NSURLConnectionLoader
0 ...    libsystem_kernel.dylib  mach_msg_trap + 20
1    libsystem_kernel.dylib  mach_msg + 40
2    CoreFoundation  __CFRunLoopServiceMachPort + 128
3    CoreFoundation  __CFRunLoopRun + 882
4    CoreFoundation  CFRunLoopRunSpecific + 356
5    CoreFoundation  CFRunLoopRunInMode + 104
6    Foundation  +[NSURLConnection(Loader) _resourceLoadLoop:] + 308
7    Foundation  __NSThread__main__ + 972
8    libsystem_c.dylib   _pthread_start + 308
Thread 5
0 ...    libsystem_kernel.dylib  mach_msg_trap + 20
1    libsystem_kernel.dylib  mach_msg + 40
2    CoreFoundation  __CFRunLoopServiceMachPort + 128
3    CoreFoundation  __CFRunLoopRun + 882
4    CoreFoundation  CFRunLoopRunSpecific + 356
5    CoreFoundation  CFRunLoopRunInMode + 104
6    Foundation  -[NSRunLoop(NSRunLoop) runMode:beforeDate:] + 254
7    Foundation  -[NSRunLoop(NSRunLoop) run] + 80
8    MyApp  
PF_AFURLConnectionoperation.m line 151
+[PF_AFURLConnectionoperation networkRequestThreadEntryPoint:]
9    Foundation  __NSThread__main__ + 972
10   libsystem_c.dylib   _pthread_start + 308
Thread 6
0 ...    libsystem_kernel.dylib  __psynch_cvwait + 24
1    libsystem_c.dylib   _pthread_cond_wait + 646
2    libsystem_c.dylib   pthread_cond_wait + 40
3    Foundation  -[NSCondition wait] + 194
4    MyApp  
PFCommandCache.m line 495
-[PFCommandCache runLoop]
5    Foundation  __NSThread__main__ + 972
6    libsystem_c.dylib   _pthread_start + 308
com.apple.CFSocket.private
0 ...    libsystem_kernel.dylib  __select + 20
1    CoreFoundation  __CFSocketManager + 678
2    libsystem_c.dylib   _pthread_start + 308
Thread 8
0 ...    libsystem_kernel.dylib  __workq_kernreturn + 8
1    libsystem_c.dylib   _pthread_workq_return + 18
2    libsystem_c.dylib   _pthread_wqthread + 365
Blog Privacy

解决方法

这是因为在视图中你正在打开,在某个地方你试图在UITableViewCell上调用一个名为row的方法.

您可以在崩溃日志的第一行看到这一点：

-[UITableViewCell row]: unrecognized selector sent to instance 0x1f8a6dd0

您应该跟踪您正在调用行的对象,并确保在您认为自己的对象上调用它而不是UITableViewCell.

iOS关于-[NSProxy methodSignatureForSelector:] called!App崩溃的问题

具体问题是这样的：
App内部有退出登录事件，我点击退出登录按钮后，删除本地储存的token、头像之类的数据，然后跳到登录页面，代码也简单，如下图001：

configureLoginInWindow内部的方法如图002：

那么问题来了，每次退出到登录页面后一会，App马上崩溃，崩溃界面如图003，代码是这么的：

*** Terminating app due to uncaught exception ''NSInvalidArgumentException'', reason: ''*** -[NSProxy methodSignatureForSelector:] called!''
*** First throw call stack:
(0x1888c1ea4 0x187a91a50 0x1887c8484 0x18935db10 0x1888c7324 0x1888c946c 0x189376488 0x188852718 0x188852448 0x188851c7c 0x18884cb58 0x18884c0e0 0x18aac5584 0x1b5a5cc00 0x10077ed8c 0x18830abb4)
libc++abi.dylib: terminating with uncaught exception of type NSException

控制台打印说的是因为-[NSProxy methodSignatureForSelector:] called!

因为上个项目用的也是这样的退出跳转登录用的是一样的代码，没有问题，就思考是不是因为在这个项目我对AppDelegate增加各种功能分类，又在分类中加了属性引起的？我的分类代码如下图004：

有没有大神遇到过类似的问题呢

我们今天的关于objective-c – 为什么[self class]响应methodSignatureForSelector：？的分享已经告一段落，感谢您的关注，如果您想了解更多关于Every Pixel Matters: Center-aware Feature Alignment for Domain Adaptive Object Detector、ios – rac_signalForSelector：需要空实现、ios – – [NSObject(NSObject)doesNotRecognizeSelector：]调用时崩溃 – [ViewController prepareForSegue：sender：]、iOS关于-[NSProxy methodSignatureForSelector:] called!App崩溃的问题的相关信息，请在本站查询。

本文标签：