AppDelegate上的Window上有一个UIViewController *ViewController, 然后在ViewController.view 上按顺序添加viewA和viewB，viewB稍微覆盖viewA一部分用来测试， 给viewA，viewB 分别添加点击手势tapA 和 tapB，然后把viewB.userInteractionEnabled = NO，让viewB不能响应点击。

然后我们点击重复的那块区域，会发现viewA响应了tap手势，执行了tapA的事件。 我们知道viewB设置了viewB.userInteractionEnabled = NO，不响应tap手势是正常的，但怎么会透过viewB，viewA响应了手势？

我们知道nextResponder指针指向的规则：

• UIView
• 如果 view 是一个 view controller 的 root view，nextResponder 是这个 view controller.
• 如果 view 不是 view controller 的 root view，nextResponder 则是这个 view 的 superview
• UIViewController
• 如果 view controller 的 view 是 window 的 root view, view controller 的 nextResponder 是这个 window
• 如果 view controller 是被其他 view controller presented调起来的，那么 view controller 的 nextResponder 就是发起调起的那个 view controller
• UIWindow
• window 的 nextResponder 是 UIApplication 对象.
• UIApplication
• UIApplication 对象的 nextResponder 是 app delegate， 但是 app delegate 必须是 UIResponder 对象，并且不能使 view ，view controller 或 UIApplication 对象他本身.

那么上述情况下，viewB所在的响应者链应该是： viewB -> ViewController.view -> ViewController -> Window -> Application 这种情况下怎么也轮不到viewA去响应啊。

所以，当有事件需要响应时，nextResponder 并不是链接响应链的那根绳子，响应链的工作方式另有别的方式

2. 那么响应链是如何工作，正确找到应该响应该事件的响应者的？

UIKit使用基于视图的hit-testing来确定touch事件发生的位置。具体解释就是，UIKit将touch的位置和视图层级中的view的边界进行了比较，UIView的方法 hitTest:withEvent: 在视图层级中进行，寻找包含指定touch的最深子视图。这个视图成为touch事件的第一个响应者。

说白了就是，当有touch事件来的时候，会从最下面的视图开始执行 hitTest:withEvent: ，如果符合成为响应者的条件，就会继续遍历它的 subviews 继续执行 hitTest:withEvent: ，直到找到最合适的view成为响应者。

这里要注意几个点：

• 符合响应者的条件包括
• touch事件的位置在响应者区域内
• 响应者 hidden 属性不为 YES
• 响应者 透明度 不是 0
• 响应者 userInteractionEnabled 不为 NO
• 遍历 subview 时，是从上往下顺序遍历的，即 view.subviews 的 lastObject 到 firstObject 的顺序，找到合适的响应者view，即停止遍历.

所以再回看上面的例子，当我们点击中间的重复区域时，流程其实是这样：

• AppDelegate 的 window 收到事件，并开始执行 hitTest:withEvent: ，发现符合要求，开始遍历子view.
• window 上只有 viewcontroller.view ,所以viewcontroller.view 开始执行 hitTest:withEvent: ，发现符合要求，开始遍历子view.
• viewcontroller.view 有两个子view， viewA 和 viewB ，但是viewB 在 viewA 上边，所以先 viewB 执行 hitTest:withEvent: ，结果发现viewB 不符合要求，因为viewB 的 userInteractionEnabled 为 NO.
• 接下来 viewA 执行 hitTest:withEvent: ，发现符合条件，并且viewA 也没有子view可去遍历，于是返回viewA.
• viewA成了最终事件的响应者.

这样就完美解释了，最开始例子的响应状况.

那么如果 viewB 的 userInteractionEnabled 属性为YES的话，是怎么样的呢？

如果 viewB 的 userInteractionEnabled 属性为YES，上面流程的第三部就会发现viewB是符合要求的，而直接返回viewB作为最终响应者，中断子view的遍历，viewA都不会被遍历到了.

这就是响应链相关的点，如果有什么不对的请留言提示，然后有什么别的需要补充的我会及时补充~

18.什么是iOS的动态绑定 ?

—在运行时确定要调用的方法

动态绑定将调用方法的确定也推迟到运行时。在编译时，方法的调用并不和代码绑定在一起，只有在消实发送出来之后，才确定被调用的代码。通过动态类型和动态绑定技术，您的代码每次执行都可以得到不同的结果。运行时因子负责确定消息的接收者和被调用的方法。运行时的消息分发机制为动态绑定提供支持。当您向一个动态类型确定了的对象发送消息时，运行环境系统会通过接收者的isa指针定位对象的类，并以此为起点确定被调用的方法，方法和消息是动态绑定的。而且，您不必在Objective-C 代码中做任何工作，就可以自动获取动态绑定的好处。您在每次发送消息时，

特别是当消息的接收者是动态类型已经确定的对象时，动态绑定就会例行而透明地发生。

19.iOS单元测试框架有哪些？

OCUnit 是 OC 官方测试框架， 现在被 XCTest 所取代。 XCTest 是与 Foundation 框架平行的测试框架。 GHUnit 是第三方的测试框架。github地址OCMock都是第三方的测试框架。

20.iOS ARC全解?

考查点

我记得在刚接触iOS的时候对这个ARC和MRC就讨论颇深，认为ARC是对程序员的一种福利，让我们节省了大量的代码，那么ARC是什么呢？

ARC 是苹果在 WWDC 2011 提出来的技术，因此很多新入行的同学可能对此技术细节并不熟悉。但是，虽然 ARC 极大地简化了我们的内存管理工作，但是引用计数这种内存管理方案如果不被理解，那么就无法处理好那些棘手的循环引用问题。所以，这道面试题其实是考查同学对于 iOS 程序内存管理的理解深度。 答案

自动的引用计数（Automatic Reference Count 简称 ARC），是苹果在 WWDC 2011 年大会上提出的用于内存管理的技术。

引用计数（Reference Count）是一个简单而有效的管理对象生命周期的方式。当我们创建一个新对象的时候，它的引用计数为 1，当有一个新的指针指向这个对象时，我们将其引用计数加 1，当某个指针不再指向这个对象是，我们将其引用计数减 1，当对象的引用计数变为 0 时，说明这个对象不再被任何指针指向了，这个时候我们就可以将对象销毁，回收内存。由于引用计数简单有效，除了 Objective-C 语言外，微软的 COM（Component Object Model ）、C++11（C++11 提供了基于引用计数的智能指针 share_prt） 等语言也提供了基于引用计数的内存管理方式。

引用计数这种内存管理方式虽然简单，但是手工写大量的操作引用计数的代码不但繁琐，而且容易被遗漏。于是苹果在 2011 年引入了 ARC。ARC 顾名思义，是自动帮我们填写引用计数代码的一项功能。

ARC 的想法来源于苹果在早期设计 Xcode 的 Analyzer 的时候，发现编译器在编译时可以帮助大家发现很多内存管理中的问题。后来苹果就想，能不能干脆编译器在编译的时候，把内存管理的代码都自动补上，带着这种想法，苹果修改了一些内存管理代码的书写方式（例如引入了 @autoreleasepool 关键字）后，在 Xcode 中实现了这个想法。

ARC 的工作原理大致是这样：当我们编译源码的时候，编译器会分析源码中每个对象的生命周期，然后基于这些对象的生命周期，来添加相应的引用计数操作代码。所以，ARC 是工作在编译期的一种技术方案，这样的好处是：

编译之后，ARC 与非 ARC 代码是没有什么差别的，所以二者可以在源码中共存。实际上，你可以通过编译参数 -fno-objc-arc 来关闭部分源代码的 ARC 特性。

相对于垃圾回收这类内存管理方案，ARC 不会带来运行时的额外开销，所以对于应用的运行效率不会有影响。相反，由于 ARC 能够深度分析每一个对象的生命周期，它能够做到比人工管理引用计数更加高效。例如在一个函数中，对一个对象刚开始有一个引用计数 +1 的操作，之后又紧接着有一个 -1 的操作，那么编译器就可以把这两个操作都优化掉。

但是也有人认为，ARC 也附带有运行期的一些机制来使 ARC 能够更好的工作，他们主要是指 weak 关键字。weak 变量能够在引用计数为 0 时被自动设置成 nil，显然是有运行时逻辑在工作的。我通常并没有把这个算在 ARC 的概念当中，当然，这更多是一个概念或定义上的分歧，因为除开 weak 逻辑之外，ARC 核心的代码都是在编译期填充的。

21.iOS内存的使用和优化的注意事项

重用问题：

如UITableViewCells、UICollectionViewCells、UITableViewHeaderFooterViews

设置正确的reuseIdentifier，充分重用；

尽量把views设置为不透明：

当opque为NO的时候，图层的半透明取决于图片和其本身合成的图层为结果，可提高性能；

不要使用太复杂的XIB/Storyboard：

载入时就会将XIB/storyboard需要的所有资源，

包括图片全部载入内存，即使未来很久才会使用。

那些相比纯代码写的延迟加载，性能及内存就差了很多；

选择正确的数据结构：

学会选择对业务场景最合适的数组结构是写出高效代码的基础。

比如，数组: 有序的一组值。

使用索引来查询很快，使用值查询很慢，插入/删除很慢。

字典: 存储键值对，用键来查找比较快。

集合: 无序的一组值，用值来查找很快，插入/删除很快。

gzip/zip压缩：

当从服务端下载相关附件时，可以通过gzip/zip压缩后再下载，使得内存更小，下载速度也更快。

延迟加载：

对于不应该使用的数据，使用延迟加载方式。

对于不需要马上显示的视图，使用延迟加载方式。

比如，网络请求失败时显示的提示界面，可能一直都不会使用到，因此应该使用延迟加载。

数据缓存：

对于cell的行高要缓存起来，使得reload数据时，效率也极高。

而对于那些网络数据，不需要每次都请求的，应该缓存起来，

可以写入数据库，也可以通过plist文件存储。

处理内存警告：

一般在基类统一处理内存警告，将相关不用资源立即释放掉

重用大开销对象：

一些objects的初始化很慢，

比如NSDateFormatter和NSCalendar，但又不可避免地需要使用它们。

通常是作为属性存储起来，防止反复创建。

避免反复处理数据：

许多应用需要从服务器加载功能所需的常为JSON或者XML格式的数据。

在服务器端和客户端使用相同的数据结构很重要;

使用Autorelease Pool：

在某些循环创建临时变量处理数据时，自动释放池以保证能及时释放内存;

22.什么是iOS的目标-动作机制 ?

目标是动作消息的接收者。一个控件，或者更为常见的是它的单元，以插座变量（参见"插座变量"部分）

的形式保有其动作消息的目标。

动作是控件发送给目标的消息，或者从目标的角度看，它是目标为了响应动作而实现的方法。

程序需要某些机制来进行事件和指令的翻译。这个机制就是目标-动作机制。

23.iOS 事件传递的完整过程?

先将事件对象由上往下传递(由父控件传递给子控件)，找到最合适的控件来处理这个事件。

调用最合适控件的touches….方法

如果调用了[super touches….];就会将事件顺着响应者链条往上传递，传递给上一个响应者
接着就会调用上一个响应者的touches….方法

如何判断上一个响应者：
如果当前这个view是控制器的view,那么控制器就是上一个响应者
如果当前这个view不是控制器的view,那么父控件就是上一个响应者

24.什么是iOS的响应者链?

• 响应者链条：是由多个响应者对象连接起来的链条
• 作用：能很清楚的看见每个响应者之间的联系，并且可以让一个事件多个对象处理。
• 响应者对象：能处理事件的对象

 + (id)initWithCString:(c*****t char *)nullTerminatedCString  encoding:(NSStringEncoding)encoding;** 

+ (id) stringWithCString: (c*****t char*)nullTerminatedCString  


        encoding: (NSStringEncoding)encoding 


  { 


   NSString *obj; 


   obj = [self allocWithZone: NSDefaultMallocZone()]; 


   obj = [obj initWithCString: nullTerminatedCString encoding:  encoding]; 

return AUTORELEASE(obj); 


  } 

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event;

- (BOOL)pointInside:(CGPoint)point withEvent:(UIEvent *)event;

- (UIView *)hitTest:(CGPoint)point withEvent:(UIEvent *)event

{

// 1.判断当前控件能否接收事件
if (self.userInteractionEnabled == NO || self.hidden == YES || self.alpha <= 0.01) return nil;

// 2. 判断点在不在当前控件
if ([self pointInside:point withEvent:event] == NO) return nil;

// 3.从后往前遍历自己的子控件

   NSInteger count = self.subviews.count;

for (NSInteger i = count - 1; i >= 0; i--) {

       UIView *childView = self.subviews[i];

// 把当前控件上的坐标系转换成子控件上的坐标系

       CGPoint childP = [self convertPoint:point toView:childView];


       UIView *fitView = [childView hitTest:childP withEvent:event];


if (fitView) { // 寻找到最合适的view
return fitView;

       }

   }
// 循环结束,表示没有比自己更合适的view
return self;

}