李洪强经典面试题43
李洪强iOS经典面试题下html
21. 下面的代码输出什么？
@implementation Son : Father - (id)init { self = [super init]; if (self) { NSLog(@"%@", NSStringFromClass([self class])); NSLog(@"%@", NSStringFromClass([super class])); } return self; } @end
答案：ios
都输出 Songit
NSStringFromClass([self class]) = Son NSStringFromClass([super class]) = Son
这个题目主要是考察关于 Objective-C 中对 self 和 super 的理解。github
咱们都知道：self 是类的隐藏参数，指向当前调用方法的这个类的实例。那 super 呢？web
不少人会想固然的认为“ super 和 self 相似，应该是指向父类的指针吧！”。这是很广泛的一个误区。其实 super 是一个 Magic Keyword， 它本质是一个编译器标示符，和 self 是指向的同一个消息接受者！他们两个的不一样点在于：super 会告诉编译器，调用 class 这个方法时，要去父类的方法，而不是本类里的。面试
上面的例子无论调用[self class]仍是[super class]，接受消息的对象都是当前 Son ＊xxx 这个对象。api
当使用 self 调用方法时，会从当前类的方法列表中开始找，若是没有，就从父类中再找；而当使用 super 时，则从父类的方法列表中开始找。而后调用父类的这个方法。数组
这也就是为何说“不推荐在 init 方法中使用点语法”，若是想访问实例变量 iVar 应该使用下划线（ _iVar ），而非点语法（self.iVar ）。缓存
点语法（ self.iVar ）的坏处就是子类有可能覆写 setter 。假设 Person 有一个子类叫 ChenPerson，这个子类专门表示那些姓“陈”的人。该子类可能会覆写 lastName 属性所对应的设置方法：安全
//
// ChenPerson.m // // // Created by https://github.com/ChenYilong on 15/8/30. // Copyright (c) 2015年 http://weibo.com/luohanchenyilong/ 微博@iOS程序犭袁. All rights reserved. // #import "ChenPerson.h" @implementation ChenPerson @synthesize lastName = _lastName; - (instancetype)init { self = [super init]; if (self) { NSLog(@"类名与方法名：%s（在第%d行），描述：%@", __PRETTY_FUNCTION__, __LINE__, NSStringFromClass([self class])); NSLog(@"类名与方法名：%s（在第%d行），描述：%@", __PRETTY_FUNCTION__, __LINE__, NSStringFromClass([super class])); } return self; } - (void)setLastName:(NSString*)lastName { //设置方法一：若是setter采用是这种方式，就可能引发崩溃 // if (![lastName isEqualToString:@"陈"]) // { // [NSException raise:NSInvalidArgumentException format:@"姓不是陈"]; // } // _lastName = lastName; //设置方法二：若是setter采用是这种方式，就可能引发崩溃 _lastName = @"陈"; NSLog(@"类名与方法名：%s（在第%d行），描述：%@", __PRETTY_FUNCTION__, __LINE__, @"会调用这个方法,想一下为何？"); } @end
在基类 Person 的默认初始化方法中，可能会将姓氏设为空字符串。此时若使用点语法（ self.lastName ）也即 setter 设置方法，那么调用将会是子类的设置方法，若是在刚刚的 setter 代码中采用设置方法一，那么就会抛出异常，
为了方便采用打印的方式展现，究竟发生了什么，咱们使用设置方法二。
若是基类的代码是这样的：
//
// Person.m // nil对象调用点语法 // // Created by https://github.com/ChenYilong on 15/8/29. // Copyright (c) 2015年 http://weibo.com/luohanchenyilong/ 微博@iOS程序犭袁. All rights reserved. // #import "Person.h" @implementation Person - (instancetype)init { self = [super init]; if (self) { self.lastName = @""; //NSLog(@"类名与方法名：%s（在第%d行），描述：%@", __PRETTY_FUNCTION__, __LINE__, NSStringFromClass([self class])); //NSLog(@"类名与方法名：%s（在第%d行），描述：%@", __PRETTY_FUNCTION__, __LINE__, self.lastName); } return self; } - (void)setLastName:(NSString*)lastName { NSLog(@"类名与方法名：%s（在第%d行），描述：%@", __PRETTY_FUNCTION__, __LINE__, @"根本不会调用这个方法"); _lastName = @"炎黄"; } @end
那么打印结果将会是这样的：
类名与方法名：-[ChenPerson setLastName:]（在第36行），描述：会调用这个方法,想一下为何？ 类名与方法名：-[ChenPerson init]（在第19行），描述：ChenPerson 类名与方法名：-[ChenPerson init]（在第20行），描述：ChenPerson
我在仓库里也给出了一个相应的 Demo（名字叫：Demo_21题_下面的代码输出什么）。有兴趣能够跑起来看一下，主要看下他是怎么打印的，思考下为何这么打印。
接下来让咱们利用 runtime 的相关知识来验证一下 super 关键字的本质，使用clang重写命令:
$ clang -rewrite-objc test.m
将这道题目中给出的代码被转化为:
NSLog((NSString *)&__NSConstantStringImpl__var_folders_gm_0jk35cwn1d3326x0061qym280000gn_T_main_a5cecc_mi_0, NSStringFromClass(((Class (*)(id, SEL))(void *)objc_msgSend)((id)self, sel_registerName("class")))); NSLog((NSString *)&__NSConstantStringImpl__var_folders_gm_0jk35cwn1d3326x0061qym280000gn_T_main_a5cecc_mi_1, NSStringFromClass(((Class (*)(__rw_objc_super *, SEL))(void *)objc_msgSendSuper)((__rw_objc_super){ (id)self, (id)class_getSuperclass(objc_getClass("Son")) }, sel_registerName("class"))));
从上面的代码中，咱们能够发如今调用 [self class] 时，会转化成 objc_msgSend函数。看下函数定义：
id objc_msgSend(id self, SEL op, ...)
咱们把 self 作为第一个参数传递进去。
而在调用 [super class]时，会转化成 objc_msgSendSuper函数。看下函数定义:
id objc_msgSendSuper(struct objc_super *super, SEL op, ...)
第一个参数是 objc_super 这样一个结构体，其定义以下:
struct objc_super {
__unsafe_unretained id receiver; __unsafe_unretained Class super_class; };
结构体有两个成员，第一个成员是 receiver, 相似于上面的 objc_msgSend函数第一个参数self 。第二个成员是记录当前类的父类是什么。
因此，当调用 ［self class] 时，实际先调用的是 objc_msgSend函数，第一个参数是 Son当前的这个实例，而后在 Son 这个类里面去找 - (Class)class这个方法，没有，去父类 Father里找，也没有，最后在 NSObject类中发现这个方法。而 - (Class)class的实现就是返回self的类别，故上述输出结果为 Son。
objc Runtime开源代码对- (Class)class方法的实现:
- (Class)class {
return object_getClass(self); }
而当调用 [super class]时，会转换成objc_msgSendSuper函数。第一步先构造 objc_super 结构体，结构体第一个成员就是 self 。 第二个成员是 (id)class_getSuperclass(objc_getClass(“Son”)) , 实际该函数输出结果为 Father。
第二步是去 Father这个类里去找 - (Class)class，没有，而后去NSObject类去找，找到了。最后内部是使用objc_msgSend(objc_super->receiver, @selector(class))去调用，
此时已经和[self class]调用相同了，故上述输出结果仍然返回 Son。
参考连接：微博@Chun_iOS的博文刨根问底Objective－C Runtime（1）－ Self & Super
22. runtime如何经过selector找到对应的IMP地址？（分别考虑类方法和实例方法）
每个类对象中都一个方法列表,方法列表中记录着方法的名称,方法实现,以及参数类型,其实selector本质就是方法名称,经过这个方法名称就能够在方法列表中找到对应的方法实现.
23. 使用runtime Associate方法关联的对象，须要在主对象dealloc的时候释放么？
- 在ARC下不须要。
-
在MRC下也不须要在MRC中,对于使用retain或copy策略的须要 。
不管在MRC下仍是ARC下均不须要。
2011年版本的Apple API 官方文档 - Associative References 一节中有一个MRC环境下的例子：
// 在MRC下，使用runtime Associate方法关联的对象，不须要在主对象dealloc的时候释放
// http://weibo.com/luohanchenyilong/ (微博@iOS程序犭袁) // https://github.com/ChenYilong // 摘自2011年版本的Apple API 官方文档 - Associative References static char overviewKey; NSArray *array = [[NSArray alloc] initWithObjects:@"One", @"Two", @"Three", nil]; // For the purposes of illustration, use initWithFormat: to ensure // the string can be deallocated NSString *overview = [[NSString alloc] initWithFormat:@"%@", @"First three numbers"]; objc_setAssociatedObject ( array, &overviewKey, overview, OBJC_ASSOCIATION_RETAIN ); [overview release]; // (1) overview valid [array release]; // (2) overview invalid
文档指出
At point 1, the string
overviewis still valid because theOBJC_ASSOCIATION_RETAINpolicy specifies that the array retains the associated object. When the array is deallocated, however (at point 2),overviewis released and so in this case also deallocated.
咱们能够看到，在[array release];以后，overview就会被release释放掉了。
既然会被销毁，那么具体在什么时间点？
根据 WWDC 2011, Session 322 (第36分22秒) 中发布的内存销毁时间表，被关联的对象在生命周期内要比对象自己释放的晚不少。它们会在被 NSObject -dealloc 调用的 object_dispose() 方法中释放。
对象的内存销毁时间表，分四个步骤：
// 对象的内存销毁时间表
// http://weibo.com/luohanchenyilong/ (微博@iOS程序犭袁)
// https://github.com/ChenYilong
// 根据 WWDC 2011, Session 322 (36分22秒)中发布的内存销毁时间表
1. 调用 -release ：引用计数变为零
* 对象正在被销毁，生命周期即将结束.
* 不能再有新的 __weak 弱引用， 不然将指向 nil.
* 调用 [self dealloc]
2. 子类 调用 -dealloc
* 继承关系中最底层的子类 在调用 -dealloc
* 若是是 MRC 代码 则会手动释放实例变量们（iVars）
* 继承关系中每一层的父类 都在调用 -dealloc
3. NSObject 调 -dealloc
* 只作一件事：调用 Objective-C runtime 中的 object_dispose() 方法
4. 调用 object_dispose()
* 为 C++ 的实例变量们（iVars）调用 destructors
* 为 ARC 状态下的 实例变量们（iVars） 调用 -release
* 解除全部使用 runtime Associate方法关联的对象
* 解除全部 __weak 引用
* 调用 free()
对象的内存销毁时间表：参考连接。
24. objc中的类方法和实例方法有什么本质区别和联系？
类方法：
- 类方法是属于类对象的
- 类方法只能经过类对象调用
- 类方法中的self是类对象
- 类方法能够调用其余的类方法
- 类方法中不能访问成员变量
- 类方法中不能直接调用对象方法
实例方法：
- 实例方法是属于实例对象的
- 实例方法只能经过实例对象调用
- 实例方法中的self是实例对象
- 实例方法中能够访问成员变量
- 实例方法中直接调用实例方法
- 实例方法中也能够调用类方法(经过类名)
25. _objc_msgForward函数是作什么的，直接调用它将会发生什么？
_objc_msgForward是 IMP 类型，用于消息转发的：当向一个对象发送一条消息，但它并无实现的时候，_objc_msgForward会尝试作消息转发。
咱们能够这样建立一个_objc_msgForward对象：
IMP msgForwardIMP = _objc_msgForward;
在上篇中的《objc中向一个对象发送消息[obj foo]和objc_msgSend()函数之间有什么关系？》曾提到objc_msgSend在“消息传递”中的做用。在“消息传递”过程当中，objc_msgSend的动做比较清晰：首先在 Class 中的缓存查找 IMP （没缓存则初始化缓存），若是没找到，则向父类的 Class 查找。若是一直查找到根类仍旧没有实现，则用_objc_msgForward函数指针代替 IMP 。最后，执行这个 IMP 。
Objective-C运行时是开源的，因此咱们能够看到它的实现。打开 Apple Open Source 里Mac代码里的obj包 下载一个最新版本，找到 objc-runtime-new.mm，进入以后搜索_objc_msgForward。
里面有对_objc_msgForward的功能解释：
/***********************************************************************
* lookUpImpOrForward. * The standard IMP lookup. * initialize==NO tries to avoid +initialize (but sometimes fails) * cache==NO skips optimistic unlocked lookup (but uses cache elsewhere) * Most callers should use initialize==YES and cache==YES. * inst is an instance of cls or a subclass thereof, or nil if none is known. * If cls is an un-initialized metaclass then a non-nil inst is faster. * May return _objc_msgForward_impcache. IMPs destined for external use * must be converted to _objc_msgForward or _objc_msgForward_stret. * If you don't want forwarding at all, use lookUpImpOrNil() instead. **********************************************************************/
对 objc-runtime-new.mm文件里与_objc_msgForward有关的三个函数使用伪代码展现下：
// objc-runtime-new.mm 文件里与 _objc_msgForward 有关的三个函数使用伪代码展现
// Created by https://github.com/ChenYilong // Copyright (c) 微博@iOS程序犭袁(http://weibo.com/luohanchenyilong/). All rights reserved. // 同时，这也是 obj_msgSend 的实现过程 id objc_msgSend(id self, SEL op, ...) { if (!self) return nil; IMP imp = class_getMethodImplementation(self->isa, SEL op); imp(self, op, ...); //调用这个函数，伪代码... } //查找IMP IMP class_getMethodImplementation(Class cls, SEL sel) { if (!cls || !sel) return nil; IMP imp = lookUpImpOrNil(cls, sel); if (!imp) return _objc_msgForward; //_objc_msgForward 用于消息转发 return imp; } IMP lookUpImpOrNil(Class cls, SEL sel) { if (!cls->initialize()) { _class_initialize(cls); } Class curClass = cls; IMP imp = nil; do { //先查缓存,缓存没有时重建,仍旧没有则向父类查询 if (!curClass) break; if (!curClass->cache) fill_cache(cls, curClass); imp = cache_getImp(curClass, sel); if (imp) break; } while (curClass = curClass->superclass); return imp; }
虽然Apple没有公开_objc_msgForward的实现源码，可是咱们仍是能得出结论：
_objc_msgForward是一个函数指针（和 IMP 的类型同样），是用于消息转发的：当向一个对象发送一条消息，但它并无实现的时候，_objc_msgForward会尝试作消息转发。在上篇中的《objc中向一个对象发送消息
[obj foo]和objc_msgSend()函数之间有什么关系？》曾提到objc_msgSend在“消息传递”中的做用。在“消息传递”过程当中，objc_msgSend的动做比较清晰：首先在 Class 中的缓存查找 IMP （没缓存则初始化缓存），若是没找到，则向父类的 Class 查找。若是一直查找到根类仍旧没有实现，则用_objc_msgForward函数指针代替 IMP 。最后，执行这个 IMP 。
为了展现消息转发的具体动做，这里尝试向一个对象发送一条错误的消息，并查看一下_objc_msgForward是如何进行转发的。
首先开启调试模式、打印出全部运行时发送的消息： 能够在代码里执行下面的方法：
(void)instrumentObjcMessageSends(YES);
或者断点暂停程序运行，并在 gdb 中输入下面的命令：
call (void)instrumentObjcMessageSends(YES)
以第二种为例，操做以下所示：
以后，运行时发送的全部消息都会打印到/tmp/msgSend-xxxx文件里了。
终端中输入命令前往：
open /private/tmp
可能看到有多条，找到最新生成的，双击打开
在模拟器上执行执行如下语句（这一套调试方案仅适用于模拟器，真机不可用，关于该调试方案的拓展连接： Can the messages sent to an object in Objective-C be monitored or printed out? ），向一个对象发送一条错误的消息：
//
// main.m // CYLObjcMsgForwardTest // // Created by http://weibo.com/luohanchenyilong/. // Copyright (c) 2015年 微博@iOS程序犭袁. All rights reserved. // #import <UIKit/UIKit.h> #import "AppDelegate.h" #import "CYLTest.h" int main(int argc, char * argv[]) { @autoreleasepool { CYLTest *test = [[CYLTest alloc] init]; [test performSelector:(@selector(iOS程序犭袁))]; return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); } }
你能够在/tmp/msgSend-xxxx（我这一次是/tmp/msgSend-9805）文件里，看到打印出来：
+ CYLTest NSObject initialize
+ CYLTest NSObject alloc
- CYLTest NSObject init
- CYLTest NSObject performSelector:
+ CYLTest NSObject resolveInstanceMethod:
+ CYLTest NSObject resolveInstanceMethod:
- CYLTest NSObject forwardingTargetForSelector:
- CYLTest NSObject forwardingTargetForSelector:
- CYLTest NSObject methodSignatureForSelector:
- CYLTest NSObject methodSignatureForSelector:
- CYLTest NSObject class
- CYLTest NSObject doesNotRecognizeSelector:
- CYLTest NSObject doesNotRecognizeSelector:
- CYLTest NSObject class
结合《NSObject官方文档》，排除掉 NSObject 作的事，剩下的就是_objc_msgForward消息转发作的几件事：
-
调用
resolveInstanceMethod:方法 (或resolveClassMethod:)。容许用户在此时为该 Class 动态添加实现。若是有实现了，则调用并返回YES，那么从新开始objc_msgSend流程。这一次对象会响应这个选择器，通常是由于它已经调用过class_addMethod。若是仍没实现，继续下面的动做。 -
调用
forwardingTargetForSelector:方法，尝试找到一个能响应该消息的对象。若是获取到，则直接把消息转发给它，返回非 nil 对象。不然返回 nil ，继续下面的动做。注意，这里不要返回 self ，不然会造成死循环。 -
调用
methodSignatureForSelector:方法，尝试得到一个方法签名。若是获取不到，则直接调用doesNotRecognizeSelector抛出异常。若是能获取，则返回非nil：建立一个 NSlnvocation 并传给forwardInvocation:。 -
调用
forwardInvocation:方法，将第3步获取到的方法签名包装成 Invocation 传入，如何处理就在这里面了，并返回非ni。 -
调用
doesNotRecognizeSelector:，默认的实现是抛出异常。若是第3步没能得到一个方法签名，执行该步骤。
上面前4个方法均是模板方法，开发者能够override，由 runtime 来调用。最多见的实现消息转发：就是重写方法3和4，吞掉一个消息或者代理给其余对象都是没问题的
也就是说_objc_msgForward在进行消息转发的过程当中会涉及如下这几个方法：
-
resolveInstanceMethod:方法 (或resolveClassMethod:)。 -
forwardingTargetForSelector:方法 -
methodSignatureForSelector:方法 -
forwardInvocation:方法 -
doesNotRecognizeSelector:方法
为了能更清晰地理解这些方法的做用，git仓库里也给出了一个Demo，名称叫“ _objc_msgForward_demo ”,可运行起来看看。
下面回答下第二个问题“直接_objc_msgForward调用它将会发生什么？”
直接调用_objc_msgForward是很是危险的事，若是用很差会直接致使程序Crash，可是若是用得好，能作不少很是酷的事。
就好像跑酷，干得好，叫“耍酷”，干很差就叫“做死”。
正如前文所说：
_objc_msgForward是 IMP 类型，用于消息转发的：当向一个对象发送一条消息，但它并无实现的时候，_objc_msgForward会尝试作消息转发。
如何调用_objc_msgForward？ _objc_msgForward隶属 C 语言，有三个参数 ：
| -- | _objc_msgForward参数 |
类型 |
|---|---|---|
| 1. | 所属对象 | id类型 |
| 2. | 方法名 | SEL类型 |
| 3. | 可变参数 | 可变参数类型 |
首先了解下如何调用 IMP 类型的方法，IMP类型是以下格式：
为了直观，咱们能够经过以下方式定义一个 IMP类型 ：
typedef void (*voidIMP)(id, SEL, ...)
一旦调用_objc_msgForward，将跳过查找 IMP 的过程，直接触发“消息转发”，
若是调用了_objc_msgForward，即便这个对象确实已经实现了这个方法，你也会告诉objc_msgSend：
“我没有在这个对象里找到这个方法的实现”
想象下objc_msgSend会怎么作？一般状况下，下面这张图就是你正常走objc_msgSend过程，和直接调用_objc_msgForward的先后差异：
有哪些场景须要直接调用_objc_msgForward？最多见的场景是：你想获取某方法所对应的NSInvocation对象。举例说明：
JSPatch （Github 连接）就是直接调用_objc_msgForward来实现其核心功能的：
JSPatch 以小巧的体积作到了让JS调用/替换任意OC方法，让iOS APP具有热更新的能力。
做者的博文《JSPatch实现原理详解》详细记录了实现原理，有兴趣能够看下。
同时 RAC(ReactiveCocoa) 源码中也用到了该方法。
26. runtime如何实现weak变量的自动置nil？
runtime 对注册的类， 会进行布局，对于 weak 对象会放入一个 hash 表中。 用 weak 指向的对象内存地址做为 key，当此对象的引用计数为0的时候会 dealloc，假如 weak 指向的对象内存地址是a，那么就会以a为键， 在这个 weak 表中搜索，找到全部以a为键的 weak 对象，从而设置为 nil。
在上篇中的《runtime 如何实现 weak 属性》有论述。（注：在上篇的《使用runtime Associate方法关联的对象，须要在主对象dealloc的时候释放么？》里给出的“对象的内存销毁时间表”也提到__weak引用的解除时间。）
咱们能够设计一个函数（伪代码）来表示上述机制：
objc_storeWeak(&a, b)函数：
objc_storeWeak函数把第二个参数--赋值对象（b）的内存地址做为键值key，将第一个参数--weak修饰的属性变量（a）的内存地址（&a）做为value，注册到 weak 表中。若是第二个参数（b）为0（nil），那么把变量（a）的内存地址（&a）从weak表中删除，
你能够把objc_storeWeak(&a, b)理解为：objc_storeWeak(value, key)，而且当key变nil，将value置nil。
在b非nil时，a和b指向同一个内存地址，在b变nil时，a变nil。此时向a发送消息不会崩溃：在Objective-C中向nil发送消息是安全的。
而若是a是由assign修饰的，则： 在b非nil时，a和b指向同一个内存地址，在b变nil时，a仍是指向该内存地址，变野指针。此时向a发送消息极易崩溃。
下面咱们将基于objc_storeWeak(&a, b)函数，使用伪代码模拟“runtime如何实现weak属性”：
// 使用伪代码模拟：runtime如何实现weak属性
// http://weibo.com/luohanchenyilong/ // https://github.com/ChenYilong id obj1; objc_initWeak(&obj1, obj); /*obj引用计数变为0，变量做用域结束*/ objc_destroyWeak(&obj1);
下面对用到的两个方法objc_initWeak和objc_destroyWeak作下解释：
整体说来，做用是： 经过objc_initWeak函数初始化“附有weak修饰符的变量（obj1）”，在变量做用域结束时经过objc_destoryWeak函数释放该变量（obj1）。
下面分别介绍下方法的内部实现：
objc_initWeak函数的实现是这样的：在将“附有weak修饰符的变量（obj1）”初始化为0（nil）后，会将“赋值对象”（obj）做为参数，调用objc_storeWeak函数。
obj1 = 0；
obj_storeWeak(&obj1, obj);
也就是说：
weak 修饰的指针默认值是 nil （在Objective-C中向nil发送消息是安全的）
而后obj_destroyWeak函数将0（nil）做为参数，调用objc_storeWeak函数。
objc_storeWeak(&obj1, 0);
前面的源代码与下列源代码相同。
// 使用伪代码模拟：runtime如何实现weak属性
// http://weibo.com/luohanchenyilong/ // https://github.com/ChenYilong id obj1; obj1 = 0; objc_storeWeak(&obj1, obj); /* ... obj的引用计数变为0，被置nil ... */ objc_storeWeak(&obj1, 0);
objc_storeWeak函数把第二个参数--赋值对象（obj）的内存地址做为键值，将第一个参数--weak修饰的属性变量（obj1）的内存地址注册到 weak 表中。若是第二个参数（obj）为0（nil），那么把变量（obj1）的地址从weak表中删除。
27. 可否向编译后获得的类中增长实例变量？可否向运行时建立的类中添加实例变量？为何？
- 不能向编译后获得的类中增长实例变量；
- 能向运行时建立的类中添加实例变量；
解释下：
-
由于编译后的类已经注册在 runtime 中，类结构体中的
objc_ivar_list实例变量的链表 和instance_size实例变量的内存大小已经肯定，同时runtime 会调用class_setIvarLayout或class_setWeakIvarLayout来处理 strong weak 引用。因此不能向存在的类中添加实例变量； -
运行时建立的类是能够添加实例变量，调用
class_addIvar函数。可是得在调用objc_allocateClassPair以后，objc_registerClassPair以前，缘由同上。
28. runloop和线程有什么关系？
总的说来，Run loop，正如其名，loop表示某种循环，和run放在一块儿就表示一直在运行着的循环。实际上，run loop和线程是紧密相连的，能够这样说run loop是为了线程而生，没有线程，它就没有存在的必要。Run loops是线程的基础架构部分， Cocoa 和 CoreFundation 都提供了 run loop 对象方便配置和管理线程的 run loop （如下都以 Cocoa 为例）。每一个线程，包括程序的主线程（ main thread ）都有与之相应的 run loop 对象。
runloop 和线程的关系：
-
主线程的run loop默认是启动的。
iOS的应用程序里面，程序启动后会有一个以下的main()函数
int main(int argc, char * argv[]) { @autoreleasepool { return UIApplicationMain(argc, argv, nil, NSStringFromClass([AppDelegate class])); } }重点是UIApplicationMain()函数，这个方法会为main thread设置一个NSRunLoop对象，这就解释了：为何咱们的应用能够在无人操做的时候休息，须要让它干活的时候又能立马响应。
-
对其它线程来讲，run loop默认是没有启动的，若是你须要更多的线程交互则能够手动配置和启动，若是线程只是去执行一个长时间的已肯定的任务则不须要。
-
在任何一个 Cocoa 程序的线程中，均可以经过如下代码来获取到当前线程的 run loop 。
NSRunLoop *runloop = [NSRunLoop currentRunLoop];
参考连接：《Objective-C之run loop详解》。
29. runloop的mode做用是什么？
model 主要是用来指定事件在运行循环中的优先级的，分为：
- NSDefaultRunLoopMode（kCFRunLoopDefaultMode）：默认，空闲状态
- UITrackingRunLoopMode：ScrollView滑动时
- UIInitializationRunLoopMode：启动时
- NSRunLoopCommonModes（kCFRunLoopCommonModes）：Mode集合
苹果公开提供的 Mode 有两个：
- NSDefaultRunLoopMode（kCFRunLoopDefaultMode）
- NSRunLoopCommonModes（kCFRunLoopCommonModes）
30. 以+ scheduledTimerWithTimeInterval...的方式触发的timer，在滑动页面上的列表时，timer会暂定回调，为何？如何解决？
RunLoop只能运行在一种mode下，若是要换mode，当前的loop也须要停下重启成新的。利用这个机制，ScrollView滚动过程当中NSDefaultRunLoopMode（kCFRunLoopDefaultMode）的mode会切换到UITrackingRunLoopMode来保证ScrollView的流畅滑动：只能在NSDefaultRunLoopMode模式下处理的事件会影响ScrollView的滑动。
若是咱们把一个NSTimer对象以NSDefaultRunLoopMode（kCFRunLoopDefaultMode）添加到主运行循环中的时候, ScrollView滚动过程当中会由于mode的切换，而致使NSTimer将再也不被调度。
同时由于mode仍是可定制的，因此：
Timer计时会被scrollView的滑动影响的问题能够经过将timer添加到NSRunLoopCommonModes（kCFRunLoopCommonModes）来解决。代码以下：
//
// http://weibo.com/luohanchenyilong/ (微博@iOS程序犭袁) // https://github.com/ChenYilong //将timer添加到NSDefaultRunLoopMode中 [NSTimer scheduledTimerWithTimeInterval:1.0 target:self selector:@selector(timerTick:) userInfo:nil repeats:YES]; //而后再添加到NSRunLoopCommonModes里 NSTimer *timer = [NSTimer timerWithTimeInterval:1.0 target:self selector:@selector(timerTick:) userInfo:nil repeats:YES]; [[NSRunLoop currentRunLoop] addTimer:timer forMode:NSRunLoopCommonModes];
31. 猜测runloop内部是如何实现的？
通常来说，一个线程一次只能执行一个任务，执行完成后线程就会退出。若是咱们须要一个机制，让线程能随时处理事件但并不退出，一般的代码逻辑 是这样的：
function loop() {
initialize();
do {
var message = get_next_message();
process_message(message);
} while (message != quit);
}
或使用伪代码来展现下:
//
// http://weibo.com/luohanchenyilong/ (微博@iOS程序犭袁)
// https://github.com/ChenYilong
int main(int argc, char * argv[]) {
//程序一直运行状态
while (AppIsRunning) {
//睡眠状态，等待唤醒事件
id whoWakesMe = SleepForWakingUp();
//获得唤醒事件
id event = GetEvent(whoWakesMe);
//开始处理事件
HandleEvent(event);
}
return 0;
}
参考连接：
- 《深刻理解RunLoop》
- 摘自博文CFRunLoop，原做者是微博@我就叫Sunny怎么了
32. objc使用什么机制管理对象内存？
经过 retainCount 的机制来决定对象是否须要释放。 每次 runloop 的时候，都会检查对象的 retainCount，若是retainCount 为 0，说明该对象没有地方须要继续使用了，能够释放掉了。
33. ARC经过什么方式帮助开发者管理内存？
编译时根据代码上下文，插入 retain/release
在编译期，ARC用的是更底层的C接口实现的retain/release/autorelease，这样作性能更好，也是为何不能在ARC环境下手动retain/release/autorelease，同时对同一上下文的同一对象的成对retain/release操做进行优化（即忽略掉没必要要的操做）；ARC也包含运行期组件，这个地方作的优化比较复杂，但也不能被忽略。【TODO:后续更新会详细描述下】
34. 不手动指定autoreleasepool的前提下，一个autorealese对象在什么时刻释放？（好比在一个vc的viewDidLoad中建立）
分两种状况：手动干预释放时机、系统自动去释放。
- 手动干预释放时机--指定autoreleasepool 就是所谓的：当前做用域大括号结束时释放。
-
系统自动去释放--不手动指定autoreleasepool
Autorelease对象出了做用域以后，会被添加到最近一次建立的自动释放池中，并会在当前的 runloop 迭代结束时释放。
释放的时机总结起来，能够用下图来表示：
下面对这张图进行详细的解释：
从程序启动到加载完成是一个完整的运行循环，而后会停下来，等待用户交互，用户的每一次交互都会启动一次运行循环，来处理用户全部的点击事件、触摸事件。
咱们都知道： 全部 autorelease 的对象，在出了做用域以后，会被自动添加到最近建立的自动释放池中。
可是若是每次都放进应用程序的 main.m 中的 autoreleasepool 中，早晚有被撑满的一刻。这个过程当中一定有一个释放的动做。什么时候？
在一次完整的运行循环结束以前，会被销毁。
那什么时间会建立自动释放池？运行循环检测到事件并启动后，就会建立自动释放池。
子线程的 runloop 默认是不工做，没法主动建立，必须手动建立。
自定义的 NSOperation 和 NSThread 须要手动建立自动释放池。好比： 自定义的 NSOperation 类中的 main 方法里就必须添加自动释放池。不然出了做用域后，自动释放对象会由于没有自动释放池去处理它，而形成内存泄露。
但对于 blockOperation 和 invocationOperation 这种默认的Operation ，系统已经帮咱们封装好了，不须要手动建立自动释放池。
@autoreleasepool 当自动释放池被销毁或者耗尽时，会向自动释放池中的全部对象发送 release 消息，释放自动释放池中的全部对象。
若是在一个vc的viewDidLoad中建立一个 Autorelease对象，那么该对象会在 viewDidAppear 方法执行前就被销毁了。
参考连接：《黑幕背后的Autorelease》
35. BAD_ACCESS在什么状况下出现？
访问了野指针，好比对一个已经释放的对象执行了release、访问已经释放对象的成员变量或者发消息。 死循环
36. 苹果是如何实现autoreleasepool的？
autoreleasepool 以一个队列数组的形式实现,主要经过下列三个函数完成.
objc_autoreleasepoolPushobjc_autoreleasepoolPopobjc_autorelease
看函数名就能够知道，对 autorelease 分别执行 push，和 pop 操做。销毁对象时执行release操做。
举例说明：咱们都知道用类方法建立的对象都是 Autorelease 的，那么一旦 Person 出了做用域，当在 Person 的 dealloc 方法中打上断点，咱们就能够看到这样的调用堆栈信息：
37. 使用block时什么状况会发生引用循环，如何解决？
一个对象中强引用了block，在block中又强引用了该对象，就会发射循环引用。
解决方法是将该对象使用__weak或者__block修饰符修饰以后再在block中使用。
- id weak weakSelf = self; 或者 weak __typeof(&*self)weakSelf = self该方法能够设置宏
- id __block weakSelf = self;
或者将其中一方强制制空 xxx = nil。
检测代码中是否存在循环引用问题，可以使用 Facebook 开源的一个检测工具 FBRetainCycleDetector 。
38. 在block内如何修改block外部变量？
默认状况下，在block中访问的外部变量是复制过去的，即：写操做不对原变量生效。可是你能够加上 __block 来让其写操做生效，示例代码以下:
__block int a = 0; void (^foo)(void) = ^{ a = 1; }; foo(); //这里，a的值被修改成1
这是 微博@唐巧_boy的《iOS开发进阶》中的第11.2.3章节中的描述。你一样能够在面试中这样回答，但你并无答到“点子上”。真正的缘由，并无书这本书里写的这么“神奇”，并且这种说法也有点牵强。面试官确定会追问“为何写操做就生效了？”真正的缘由是这样的：
咱们都知道：Block不容许修改外部变量的值，这里所说的外部变量的值，指的是栈中指针的内存地址。
__block所起到的做用就是只要观察到该变量被 block 所持有，就将“外部变量”在栈中的内存地址放到了堆中。进而在block内部也能够修改外部变量的值。
Block不容许修改外部变量的值。Apple这样设计，应该是考虑到了block的特殊性，block也属于“函数”的范畴，变量进入block，实际就是已经改变了做用域。在几个做用域之间进行切换时，若是不加上这样的限制，变量的可维护性将大大下降。又好比我想在block内声明了一个与外部同名的变量，此时是容许呢仍是不容许呢？只有加上了这样的限制，这样的情景才能实现。因而栈区变成了红灯区，堆区变成了绿灯区。
咱们能够打印下内存地址来进行验证：
__block int a = 0; NSLog(@"定义前：%p", &a); //栈区 void (^foo)(void) = ^{ a = 1; NSLog(@"block内部：%p", &a); //堆区 }; NSLog(@"定义后：%p", &a); //堆区 foo();
2016-05-17 02:03:33.559 LeanCloudChatKit-iOS[1505:713679] 定义前：0x16fda86f8 2016-05-17 02:03:33.559 LeanCloudChatKit-iOS[1505:713679] 定义后：0x155b22fc8 2016-05-17 02:03:33.559 LeanCloudChatKit-iOS[1505:713679] block内部： 0x155b22fc8
“定义后”和“block内部”二者的内存地址是同样的，咱们都知道 block 内部的变量会被 copy 到堆区，“block内部”打印的是堆地址，于是也就能够知道，“定义后”打印的也是堆的地址。
那么如何证实“block内部”打印的是堆地址？
把三个16进制的内存地址转成10进制就是：
- 定义后前：6171559672
- block内部：5732708296
- 定义后后：5732708296
中间相差438851376个字节，也就是 418.5M 的空间，由于堆地址要小于栈地址，又由于iOS中一个进程的栈区内存只有1M，Mac也只有8M，显然a已是在堆区了。
这也证明了：a 在定义前是栈区，但只要进入了 block 区域，就变成了堆区。这才是 __block 关键字的真正做用。
__block 关键字修饰后，int类型也从4字节变成了32字节，这是 Foundation 框架 malloc 出来的。这也一样能证明上面的结论。（PS：竟然比 NSObject alloc 出来的 16 字节要多一倍）。
理解到这是由于堆栈地址的变动，而非所谓的“写操做生效”，这一点相当重要，要否则你如何解释下面这个现象：
如下代码编译能够经过，而且在block中成功将a的从Tom修改成Jerry。
NSMutableString *a = [NSMutableString stringWithString:@"Tom"]; NSLog(@"\n 定之前：------------------------------------\n\ a指向的堆中地址：%p；a在栈中的指针地址：%p", a, &a); //a在栈区 void (^foo)(void) = ^{ a.string = @"Jerry"; NSLog(@"\n block内部：------------------------------------\n\ a指向的堆中地址：%p；a在栈中的指针地址：%p", a, &a); //a在栈区 a = [NSMutableString stringWithString:@"William"]; }; foo(); NSLog(@"\n 定之后：------------------------------------\n\ a指向的堆中地址：%p；a在栈中的指针地址：%p", a, &a); //a在栈区
这里的a已经由基本数据类型，变成了对象类型。block会对对象类型的指针进行copy，copy到堆中，但并不会改变该指针所指向的堆中的地址，因此在上面的示例代码中，block体内修改的实际是a指向的堆中的内容。
但若是咱们尝试像上面图片中的65行那样作，结果会编译不经过，那是由于此时你在修改的就不是堆中的内容，而是栈中的内容。
上文已经说过：Block不容许修改外部变量的值，这里所说的外部变量的值，指的是栈中指针的内存地址。栈区是红灯区，堆区才是绿灯区。
39. 使用系统的某些block api（如UIView的block版本写动画时），是否也考虑引用循环问题？
系统的某些block api中，UIView的block版本写动画时不须要考虑，但也有一些api 须要考虑：
所谓“引用循环”是指双向的强引用，因此那些“单向的强引用”（block 强引用 self ）没有问题，好比这些：
[UIView animateWithDuration:duration animations:^{ [self.superview layoutIfNeeded]; }];
[[NSOperationQueue mainQueue] addOperationWithBlock:^{ self.someProperty = xyz; }];
[[NSNotificationCenter defaultCenter] addObserverForName:@"someNotification" object:nil queue:[NSOperationQueue mainQueue] usingBlock:^(NSNotification * notification) { self.someProperty = xyz; }];
这些状况不须要考虑“引用循环”。
但若是你使用一些参数中可能含有 ivar 的系统 api ，如 GCD 、NSNotificationCenter就要当心一点：好比GCD 内部若是引用了 self，并且 GCD 的其余参数是 ivar，则要考虑到循环引用：
__weak __typeof__(self) weakSelf = self;
dispatch_group_async(_operationsGroup, _operationsQueue, ^ { __typeof__(self) strongSelf = weakSelf; [strongSelf doSomething]; [strongSelf doSomethingElse]; } );
相似的：
__weak __typeof__(self) weakSelf = self;
_observer = [[NSNotificationCenter defaultCenter] addObserverForName:@"testKey" object:nil queue:nil usingBlock:^(NSNotification *note) { __typeof__(self) strongSelf = weakSelf; [strongSelf dismissModalViewControllerAnimated:YES]; }];
self --> _observer --> block --> self 显然这也是一个循环引用。
检测代码中是否存在循环引用问题，可以使用 Facebook 开源的一个检测工具 FBRetainCycleDetector 。
40. GCD的队列（dispatch_queue_t）分哪两种类型？
- 串行队列Serial Dispatch Queue
- 并行队列Concurrent Dispatch Queue
41. 如何用GCD同步若干个异步调用？（如根据若干个url异步加载多张图片，而后在都下载完成后合成一张整图）
使用Dispatch Group追加block到Global Group Queue,这些block若是所有执行完毕，就会执行Main Dispatch Queue中的结束处理的block。
dispatch_queue_t queue = dispatch_get_global_queue(DISPATCH_QUEUE_PRIORITY_DEFAULT, 0); dispatch_group_t group = dispatch_group_create(); dispatch_group_async(group, queue, ^{ /*加载图片1 */ }); dispatch_group_async(group, queue, ^{ /*加载图片2 */ }); dispatch_group_async(group, queue, ^{ /*加载图片3 */ }); dispatch_group_notify(group, dispatch_get_main_queue(), ^{ // 合并图片 });
42. dispatch_barrier_async的做用是什么？
在并行队列中，为了保持某些任务的顺序，须要等待一些任务完成后才能继续进行，使用 barrier 来等待以前任务完成，避免数据竞争等问题。 dispatch_barrier_async 函数会等待追加到Concurrent Dispatch Queue并行队列中的操做所有执行完以后，而后再执行 dispatch_barrier_async 函数追加的处理，等 dispatch_barrier_async 追加的处理执行结束以后，Concurrent Dispatch Queue才恢复以前的动做继续执行。
打个比方：好比大家公司周末跟团旅游，高速休息站上，司机说：你们都去上厕所，速战速决，上完厕所就上高速。超大的公共厕所，你们同时去，程序猿很快就结束了，但程序媛就可能会慢一些，即便你第一个回来，司机也不会出发，司机要等待全部人都回来后，才能出发。 dispatch_barrier_async 函数追加的内容就如同 “上完厕所就上高速”这个动做。
（注意：使用 dispatch_barrier_async ，该函数只能搭配自定义并行队列 dispatch_queue_t 使用。不能使用：dispatch_get_global_queue ，不然 dispatch_barrier_async 的做用会和 dispatch_async 的做用如出一辙。 ）
43. 苹果为何要废弃dispatch_get_current_queue？
dispatch_get_current_queue容易形成死锁
44. 如下代码运行结果如何？
- (void)viewDidLoad
{
[super viewDidLoad];
NSLog(@"1");
dispatch_sync(dispatch_get_main_queue(), ^{
NSLog(@"2");
});
NSLog(@"3");
}
只输出：1 。发生主线程锁死。
45. addObserver:forKeyPath:options:context:各个参数的做用分别是什么，observer中须要实现哪一个方法才能得到KVO回调？
// 添加键值观察
/* 1 观察者，负责处理监听事件的对象 2 观察的属性 3 观察的选项 4 上下文 */ [self.person addObserver:self forKeyPath:@"name" options:NSKeyValueObservingOptionNew | NSKeyValueObservingOptionOld context:@"Person Name"];
observer中须要实现一下方法：
// 全部的 kvo 监听到事件，都会调用此方法
/* 1. 观察的属性 2. 观察的对象 3. change 属性变化字典（新／旧） 4. 上下文，与监听的时候传递的一致 */ - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary *)change context:(void *)context;
46. 如何手动触发一个value的KVO
所谓的“手动触发”是区别于“自动触发”：
自动触发是指相似这种场景：在注册 KVO 以前设置一个初始值，注册以后，设置一个不同的值，就能够触发了。
想知道如何手动触发，必须知道自动触发 KVO 的原理：
键值观察通知依赖于 NSObject 的两个方法: willChangeValueForKey: 和 didChangevlueForKey: 。在一个被观察属性发生改变以前， willChangeValueForKey: 必定会被调用，这就 会记录旧的值。而当改变发生后，observeValueForKey:ofObject:change:context: 会被调用，继而 didChangeValueForKey: 也会被调用。若是能够手动实现这些调用，就能够实现“手动触发”了。
那么“手动触发”的使用场景是什么？通常咱们只在但愿能控制“回调的调用时机”时才会这么作。
具体作法以下：
若是这个 value 是 表示时间的 self.now ，那么代码以下：最后两行代码缺一不可。
相关代码已放在仓库里。
// .m文件
// Created by https://github.com/ChenYilong // 微博@iOS程序犭袁(http://weibo.com/luohanchenyilong/). // 手动触发 value 的KVO，最后两行代码缺一不可。 //@property (nonatomic, strong) NSDate *now; - (void)viewDidLoad { [super viewDidLoad]; _now = [NSDate date]; [self addObserver:self forKeyPath:@"now" options:NSKeyValueObservingOptionNew context:nil]; NSLog(@"1"); [self willChangeValueForKey:@"now"]; // “手动触发self.now的KVO”，必写。 NSLog(@"2"); [self didChangeValueForKey:@"now"]; // “手动触发self.now的KVO”，必写。 NSLog(@"4"); }
可是平时咱们通常不会这么干，咱们都是等系统去“自动触发”。“自动触发”的实现原理：
好比调用
setNow:时，系统还会以某种方式在中间插入wilChangeValueForKey:、didChangeValueForKey:和observeValueForKeyPath:ofObject:change:context:的调用。
你们可能觉得这是由于 setNow: 是合成方法，有时候咱们也能看到有人这么写代码:
- (void)setNow:(NSDate *)aDate { [self willChangeValueForKey:@"now"]; // 没有必要 _now = aDate; [self didChangeValueForKey:@"now"];// 没有必要 }
这彻底没有必要，不要这么作，这样的话，KVO代码会被调用两次。KVO在调用存取方法以前老是调用willChangeValueForKey: ，以后老是调用 didChangeValueForkey: 。怎么作到的呢?答案是经过 isa 混写（isa-swizzling）。下文《apple用什么方式实现对一个对象的KVO？》会有详述。
参考连接： Manual Change Notification---Apple 官方文档
47. 若一个类有实例变量 NSString *_foo ，调用setValue:forKey:时，能够以foo仍是 _foo 做为key？
均可以。
48. KVC的keyPath中的集合运算符如何使用？
- 必须用在集合对象上或普通对象的集合属性上
- 简单集合运算符有@avg， @count ， @max ， @min ，@sum，
- 格式 @"@sum.age"或 @"集合属性.@max.age"
49. KVC和KVO的keyPath必定是属性么？
KVO支持实例变量
50. 如何关闭默认的KVO的默认实现，并进入自定义的KVO实现？
请参考：
51. apple用什么方式实现对一个对象的KVO？
Apple 的文档对 KVO 实现的描述：
Automatic key-value observing is implemented using a technique called isa-swizzling... When an observer is registered for an attribute of an object the isa pointer of the observed object is modified, pointing to an intermediate class rather than at the true class ...
从Apple 的文档能够看出：Apple 并不但愿过多暴露 KVO 的实现细节。不过，要是借助 runtime 提供的方法去深刻挖掘，全部被掩盖的细节都会原形毕露：
当你观察一个对象时，一个新的类会被动态建立。这个类继承自该对象的本来的类，并重写了被观察属性的 setter 方法。重写的 setter 方法会负责在调用原 setter 方法以前和以后，通知全部观察对象：值的更改。最后经过
isa 混写（isa-swizzling）把这个对象的 isa 指针 ( isa 指针告诉 Runtime 系统这个对象的类是什么 ) 指向这个新建立的子类，对象就神奇的变成了新建立的子类的实例。我画了一张示意图，以下所示：
KVO 确实有点黑魔法：
Apple 使用了
isa 混写（isa-swizzling）来实现 KVO 。
下面作下详细解释：
键值观察通知依赖于 NSObject 的两个方法: willChangeValueForKey: 和 didChangevlueForKey: 。在一个被观察属性发生改变以前， willChangeValueForKey: 必定会被调用，这就会记录旧的值。而当改变发生后，observeValueForKey:ofObject:change:context: 会被调用，继而 didChangeValueForKey: 也会被调用。能够手动实现这些调用，但不多有人这么作。通常咱们只在但愿能控制回调的调用时机时才会这么作。大部分状况下，改变通知会自动调用。
好比调用 setNow: 时，系统还会以某种方式在中间插入 wilChangeValueForKey: 、 didChangeValueForKey: 和observeValueForKeyPath:ofObject:change:context: 的调用。你们可能觉得这是由于 setNow: 是合成方法，有时候咱们也能看到有人这么写代码:
- (void)setNow:(NSDate *)aDate { [self willChangeValueForKey:@"now"]; // 没有必要 _now = aDate; [self didChangeValueForKey:@"now"];// 没有必要 }
这彻底没有必要，不要这么作，这样的话，KVO代码会被调用两次。KVO在调用存取方法以前老是调用willChangeValueForKey: ，以后老是调用 didChangeValueForkey: 。怎么作到的呢?答案是经过 isa 混写（isa-swizzling）。第一次对一个对象调用 addObserver:forKeyPath:options:context: 时，框架会建立这个类的新的 KVO 子类，并将被观察对象转换为新子类的对象。在这个 KVO 特殊子类中， Cocoa 建立观察属性的 setter ，大体工做原理以下:
- (void)setNow:(NSDate *)aDate { [self willChangeValueForKey:@"now"]; [super setValue:aDate forKey:@"now"]; [self didChangeValueForKey:@"now"]; }
这种继承和方法注入是在运行时而不是编译时实现的。这就是正确命名如此重要的缘由。只有在使用KVC命名约定时，KVO才能作到这一点。
KVO 在实现中经过 isa 混写（isa-swizzling） 把这个对象的 isa 指针 ( isa 指针告诉 Runtime 系统这个对象的类是什么 ) 指向这个新建立的子类，对象就神奇的变成了新建立的子类的实例。这在Apple 的文档能够获得印证：
Automatic key-value observing is implemented using a technique called isa-swizzling... When an observer is registered for an attribute of an object the isa pointer of the observed object is modified, pointing to an intermediate class rather than at the true class ...
然而 KVO 在实现中使用了 isa 混写（ isa-swizzling） ，这个的确不是很容易发现：Apple 还重写、覆盖了 -class 方法并返回原来的类。 企图欺骗咱们：这个类没有变，就是本来那个类。。。
可是，假设“被监听的对象”的类对象是 MYClass ，有时候咱们能看到对 NSKVONotifying_MYClass 的引用而不是对MYClass 的引用。借此咱们得以知道 Apple 使用了 isa 混写（isa-swizzling）。具体探究过程可参考 这篇博文 。
那么 wilChangeValueForKey: 、 didChangeValueForKey: 和 observeValueForKeyPath:ofObject:change:context: 这三个方法的执行顺序是怎样的呢？
wilChangeValueForKey: 、 didChangeValueForKey: 很好理解，observeValueForKeyPath:ofObject:change:context:的执行时机是何时呢？
先看一个例子：
代码已放在仓库里。
- (void)viewDidLoad {
[super viewDidLoad]; [self addObserver:self forKeyPath:@"now" options:NSKeyValueObservingOptionNew context:nil]; NSLog(@"1"); [self willChangeValueForKey:@"now"]; // “手动触发self.now的KVO”，必写。 NSLog(@"2"); [self didChangeValueForKey:@"now"]; // “手动触发self.now的KVO”，必写。 NSLog(@"4"); } - (void)observeValueForKeyPath:(NSString *)keyPath ofObject:(id)object change:(NSDictionary<NSString *,id> *)change context:(void *)context { NSLog(@"3"); }
若是单单从下面这个例子的打印上，
顺序彷佛是 wilChangeValueForKey: 、 observeValueForKeyPath:ofObject:change:context: 、didChangeValueForKey: 。
其实否则，这里有一个 observeValueForKeyPath:ofObject:change:context: , 和 didChangeValueForKey: 到底谁先调用的问题：若是 observeValueForKeyPath:ofObject:change:context: 是在 didChangeValueForKey: 内部触发的操做呢？ 那么顺序就是： wilChangeValueForKey: 、 didChangeValueForKey: 和observeValueForKeyPath:ofObject:change:context:
不信你把 didChangeValueForKey: 注视掉，看下 observeValueForKeyPath:ofObject:change:context: 会不会执行。
了解到这一点很重要，正如 46. 如何手动触发一个value的KVO 所说的：
“手动触发”的使用场景是什么？通常咱们只在但愿能控制“回调的调用时机”时才会这么作。
而“回调的调用时机”就是在你调用 didChangeValueForKey: 方法时。
52. IBOutlet连出来的视图属性为何能够被设置成weak?
参考连接： Should IBOutlets be strong or weak under ARC?
文章告诉咱们：
由于既然有外链那么视图在xib或者storyboard中确定存在，视图已经对它有一个强引用了。
不过这个回答漏了个重要知识，使用storyboard（xib不行）建立的vc，会有一个叫_topLevelObjectsToKeepAliveFromStoryboard的私有数组强引用全部top level的对象，因此这时即使outlet声明成weak也不要紧
53. IB中User Defined Runtime Attributes如何使用？
它可以经过KVC的方式配置一些你在interface builder 中不能配置的属性。当你但愿在IB中做尽量多得事情，这个特性可以帮助你编写更加轻量级的viewcontroller
54. 如何调试BAD_ACCESS错误
- 重写object的respondsToSelector方法，现实出现EXEC_BAD_ACCESS前访问的最后一个object
-
经过 Zombie
-
设置全局断点快速定位问题代码所在行
- Xcode 7 已经集成了BAD_ACCESS捕获功能：Address Sanitizer。 用法以下：在配置中勾选✅Enable Address Sanitizer
55. lldb（gdb）经常使用的调试命令？
- breakpoint 设置断点定位到某一个函数
- n 断点指针下一步
- po打印对象
更多 lldb（gdb） 调试命令可查看
- The LLDB Debugger ；
- 苹果官方文档： iOS Debugging Magic 。
- 1. 李洪强经典面试题21
- 2. 李洪强经典面试题37
- 3. 李洪强经典面试题38
- 4. 李洪强经典面试题17
- 5. 李洪强经典面试题18
- 6. 李洪强经典面试题27
- 7. 李洪强经典面试题1
- 8. 李洪强iOS经典面试题
- 9. 李洪强经典面试题20
- 10. 李洪强经典面试题41-iOS选择题
- 更多相关文章...
- • Swift 字典 - Swift 教程
- • Lua 调试(Debug) - Lua 教程
- • 为了进字节跳动，我精选了29道Java经典算法题，带详细讲解
- • 使用阿里云OSS+CDN部署前端页面与加速静态资源
-
每一个你不满意的现在，都有一个你没有努力的曾经。
- 1. 李洪强经典面试题21
- 2. 李洪强经典面试题37
- 3. 李洪强经典面试题38
- 4. 李洪强经典面试题17
- 5. 李洪强经典面试题18
- 6. 李洪强经典面试题27
- 7. 李洪强经典面试题1
- 8. 李洪强iOS经典面试题
- 9. 李洪强经典面试题20
- 10. 李洪强经典面试题41-iOS选择题