iOS程序员面试(六级考～)

题目多源于项目中遇到的错误和平时的误区，要是能了如指掌，恭喜你六级过了－－。考点大概是对iOS框架、

Objective-C语言基础的理解以代码为主。

1、下面的代码分别输出什么？

123456789101112

@implementation Son : Father- (id)init{    self = [super init];    if (self)    {        NSLog(@"%@", NSStringFromClass([self class]));        NSLog(@"%@", NSStringFromClass([super class]));    }    return self;}@end

答案： 都输出"Son"

解释：Objc中super是编译器标示符，并不像self 一样是一个对象，遇到向super发的方法时会转译成objc_msgSendSuper(...),

而参数中的对象还是self,于是从父类开始沿继承链寻找- class这个方法，最后在NSobject中找到(若无override)，此时,

［self class］ 和 [super class]已经等价了;

2、下面的代码报错？警告？还是正常输出什么？

1234

Father *father = [Father new];BOOL b1 = [father responseToSelector:@selector(responseToSelector:)];BOOL b2 = [Father responseToSelector:@selector(responseToSelector:)];NSLog(@"%d, %d", b1, b2);

答案：都输出"1"(YES)

解释： objc中：

● 不论是实例对象还是Class，都是id类型的对象（类(Class)同样是对象）

●  实例对象的isa指针指向它的Class（储存所有减号方法）,Class对象的isa指向元类(储存所有加号方法)

●  向一个对象(id类型)发送消息时，都是从这个对象的isa指针指向的Class中寻找方法

题目当中，Father类发送一个实例方法 (- responseToSelector) 消息时：

● 会从它的isa，也就是Father元类对象中寻找，由于元类中的方法都是类方法，所以自然找不到。

● 于是沿继承链去父类NSObject元类中寻找，依然没有。

● 由于Objc对于这块的设计是，NSObject的元类的父类是NSObject类（也就是我们熟悉的NSObject类），

其中有所有的实例方法，因此找到了 - responseToSelector

补充：NSObject类中的所有实例方法很可能都对应实现了一个类方法（至少从开源的代码中可以看出来），

如+responseToSelector,但并非公开的API,如果真是如此，上面第二步就可以找到这个方法。

再补充：非NSObject的selector这样做无效。

3、请求很快就执行完成，但是completionBlock很久之后才设置，还能否执行呢？

123456789

...// 当前在主线程[request startAsync]; // 后台线程异步调用，完成后会在主线程调用completionBlocksleep(100); // sleep主线程，使得下面的代码在后台线程完成后才能执行[request setCompletionBlock:^{    NSLog(@"Can I be printed?");}];...

答案：可以(但是有条件)

解释：为了方便解释，我们将其考虑成GCD的两个线性Queue : main queue 和 back queue

当代码执行到sleep(100)时，这两个queue要执行的顺序看起来是这样的：

● main : *--------sleep -----------------------------------> | ----setCompletionBlock ---->

● back : *---netWork----->

于是网络请求很快回来，回调函数一般要执行如：

1234

// 回到主线程执行回调dispatch_async(dispatch_get_main_queue(), ^{  if (self.completionBlock) self.completionBlock();});

于是成了这样：

 - main : -- sleep----> | ----setCompletionBlock ----> | ----invoke completionBlock --->

 - back: 

所以，当sleep结束后，主线程保持了调用顺序

- main : * ---setCompletionBlock ---> | ---invoke completionBlock --->

此时，completionBlock的执行是在setCompletionBlock，之后的，所以可以正常回调。

⚠这个解释有一个限制条件，如果用下面的方式进行网络回调，则情况就会不一样：

12345

// 回到主线程执行回调if (self.completionBlock) {  dispatch_async(dispatch_get_main_queue(), ^{    self.completionBlock();});

4、下面的代码输出什么？

12345678910

- (void)viewDidLoad{    [super viewDidLoad];            NSLog(@"1");    dispatch_sync(dispatch_get_main_queue(), ^{        NSLog(@"2");    });    NSLog(@"3");}

答案： 输入1之后程序死锁

解释： dispatch_sync文档中提到：

Calls to dispatch_sync() targeting the current queue will result in dead-lock.Use of dispatch_sync() is also subject to the same multi-party dead-lock problems that may result from the use of a mutex.Use of dispatch_async() is preferred.

sync到当前线程的block会导致死锁，所以只会Log出1之后主线程就进入死锁状态，不会继续执行。

究其原因，还要看dispatch_sync做的事，它将一个block插入到queue中，这点和async没有区别，但是sync会等待到这个block执行完成后才回到调用点继续执行，而这个block的执行还依仗着viewDidLoad中dispatch_sync调用的结束，所以造成了循环等待，导致死锁。