1.举一个例子：有一个 Father 类，实现了 load 方法，打印类名，一个 Son 类继承自前者，没有实现 load 方法。实例出一个 Son 的对象时，结果是会输出父类的名字。但这个例子与之前的结论并不矛盾，这里说的是父类先被加载了，所以调用了父类的 load 方法，而子类被加载时没有调用父类的 load 方法。 暂时没找到例子可以严格的证明此前的结论，所以还是去看源码吧。↩
463 | 464 | ### 参考资料 465 | 466 | * [iOS开发基础面试题系列](http://blog.csdn.net/xunyn/article/details/8302787) 467 | * [10个Objective-C基础面试题，iOS面试必备](http://www.oschina.net/news/42288/10-objective-c-interview) 468 | * [Objective-C中“私有方法”的实现"](http://blog.sina.com.cn/s/blog_74e9d98d01013au8.html) 469 | * [Objective-C中@property详解](http://www.cnblogs.com/andyque/archive/2011/08/03/2125728.html) 470 | * [Objective-C中的protocol和delegate](http://www.cnblogs.com/whyandinside/archive/2013/02/28/2937217.html) 471 | * [Objective-C——消息，Category 与 Protocol](http://www.cnblogs.com/chijianqiang/archive/2012/06/22/objc-category-protocol.html) 472 | * [深入理解Objective-C中的@class](http://www.cnblogs.com/martin1009/archive/2012/06/24/2560218.html) 473 | * [Objective-C +load vs +initialize](http://blog.leichunfeng.com/blog/2015/05/02/objective-c-plus-load-vs-plus-initialize/) 474 | * [深入理解Objective-C：Category](http://tech.meituan.com/DiveIntoCategory.html) 475 | * https://stackoverflow.com/questions/19784454/when-should-i-use-synthesize-explicitly 476 | * http://www.fantageek.com/blog/2014/07/13/property-in-protocol/ 477 | * http://www.friday.com/bbum/2009/09/06/iniailize-can-be-executed-multiple-times-load-not-so-much/ 478 | -------------------------------------------------------------------------------- /source/iOS/ObjC-Basic/Objective-C-Introspection.md: -------------------------------------------------------------------------------- 1 | 在 Objective-C 以及其他很多动态语言当中，自省是一种用于判断对象是哪个类型的对象，以及这个对象能处理哪个消息的方法，特别是当你得到的对象是`id`类型时，自省更显得尤其有用。 2 | 3 | ## 类 4 | 5 | `- class` 返回接受者类的类对象 6 | `- isKindOfClass:` 返回一个布尔值，指示接受者是不是一个给定类（或者其子类）的实例 7 | `- isMemberOfClass:` 返回一个布尔值，指示接受者是不是给定类的实例 8 | 9 | ## 消息 10 | 11 | `-respondsToSelector:` 返回一个布尔值，指示接受者是否实现或者继承了父类的方法，可以对给定的消息进行处理。 12 | 13 | ## 代理 14 | 15 | 代理是一种用于替代其他对象或者替代还没有出现的对象的对象。通常情况下，传给代理的消息会被传递给真正的对象，或者使得代理去加载真正的对象。 16 | 17 | `-isProxy` 返回一个布尔值，指示接受者是不是继承自`NSObject`(?) -------------------------------------------------------------------------------- /source/iOS/ObjC-Basic/Objective-C-Message.md: -------------------------------------------------------------------------------- 1 | ## 消息 2 | 3 | 在C++或Java里，类与类的行为方法之间的关系非常紧密，一个方法必定属于一个类，且于编译时就已经绑定在一起，所以你不可能调用一个类里没有的方法。而在Objective-C中就比较简单了，类和消息之间是松耦合的，方法调用只是向某个类发送一个消息，该类可以在运行时再确定怎么处理接受到的消息。也就是说，一个类不保证一定会响应接收到的消息，如果收到了一个无法处理的消息，那么程序就是简单报一个错而已。 4 | 5 | Objective-C 是 C 语言的超集，所有的方法在底层都是简单朴素的 C 方法，运行时决定了当传入一个消息时具体哪个方法被调用。 6 | 7 | 像对象发送一个消息的代码类似于这个： 8 | 9 | ```objectivec 10 | id returnValue = [someObject messageName:parameter]; 11 | ``` 12 | 13 | 最终这个代码会变成类似下面这个C方法： 14 | 15 | ```objectivec 16 | id returnValue = objc_msgSend(someObject, @selector(messageName:), parameter); 17 | ``` 18 | 19 | ## 消息传递 20 | 21 | 当一个对象接受到它不能理解的消息时，消息传递机制会被启用。 22 | 23 | 在消息真正“不被处理”之前，有三次可以处理它的机会。 24 | 25 | **第一次是动态方法解析** 26 | 27 | 当一个对象接受到它不能理解的消息时，第一个被调用的方法是一个类方法： 28 | 29 | ```objectivec 30 | + (BOOL)resolveInstanceMethod:(SEL)selector; 31 | ``` 32 | 33 | 这个方法以传入对象的 selector 作为参数，返回一个布尔值，这个值指示了有没有一个实例方法被添加到类中，使得类现在可以处理这个 selector。 34 | 35 | 36 | **如果失败，使用替代接收者** 37 | 38 | 第二次尝试是询问接受这个消息的类，有没有一个替代接受者可以处理这个未知消息，对应的函数是： 39 | 40 | ```objectivec 41 | - (id)forwardingTargetForSelector:(SEL)selector; 42 | ``` 43 | 44 | 未知 selector 被传入，如果有替代者，那么替代者对象会被返回，否则返回nil 45 | 46 | **最后，使用消息传递机制** 47 | 48 | 如果上面这些尝试都失败了，只能使用完成的消息传递机制。首先创建一个`NSInvocation`对象来包装好这个没有处理的消息的所有细节。 49 | 50 | 用于传递消息的方法是： 51 | 52 | ```objectivec 53 | - (void)forwardInvocation:(NSInvocation *)invocation; 54 | ``` 55 | 56 | 这个方法的实现应该总是调用其父类的实现。最终`NSObject`的实现会唤醒`doesNotRecognizeSelector`来触发一个“未处理的 selector” 异常。 57 | 58 | ## Method Swizzling 59 | 60 | 当消息传入一个函数时，实际调用的方法是在运行时决定的。这就允许我们改变某个消息传入时实际调用的方法。通常这种办法用于改变那些看不到源码的类的功能。 61 | 62 | 类的方法列表包含了一系列的 selector 名字和对应的实现之间的映射，用于指导动态消息系统去哪里找某个消息对应的实现。这些对应的实现存储为一种叫做`IMP`的函数指针，其原型如下： 63 | 64 | ```objectivec 65 | id (*IMP)(id, SEL, ...) 66 | ``` 67 | 68 | 要想得到某个 selector 对应的实现，可以使用下面的函数： 69 | 70 | ```objectivec 71 | Method class_getInstanceMethod(Class aClass, SEL aSelector) 72 | ``` 73 | 74 | 想添加一个实现，可以使用下面的函数： 75 | 76 | ```objectivec 77 | BOOL class_addMethod(Class class, SEL originalSelector, Method m1, const char* encoding) 78 | ``` 79 | 80 | 要想交换两个实现，可以使用： 81 | 82 | ```objectivec 83 | void method_exchangeImplementations(Method m1, Method m2) 84 | ``` 85 | 86 | Swizzling 通常被认为是一种黑科技，它容易导致不可预测的行为和难以预知的结果。尽管它不是十分安全，但是只要能做到下面几点，使用它相对而言还是比较安全的： 87 | 88 | * 总是调用方法本来的实现（除非你真的不需要这么做） 89 | * 避免冲突 90 | * 明白你在干什么 91 | * 小心谨慎 92 | 93 | ### 参考资料 94 | 95 | * [Objective-C——消息、Category和Protocol](http://www.cnblogs.com/chijianqiang/archive/2012/06/22/objc-category-protocol.html) -------------------------------------------------------------------------------- /source/iOS/ObjC-Basic/README.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HIT-Alibaba/interview/33748d78515dae0edc5bd613c9852625b6ade3c3/source/iOS/ObjC-Basic/README.md -------------------------------------------------------------------------------- /source/iOS/ObjC-Basic/Runloop.md: -------------------------------------------------------------------------------- 1 | Runloop 2 | ======= 3 | 4 | Runloop 是和线程紧密相关的一个基础组件，是很多线程有关功能的幕后功臣。尽管在平常使用中几乎不太会直接用到，理解 Runloop 有利于我们更加深入地理解 iOS 的多线程模型。 5 | 6 | ## Runloop 基本概念 7 | 8 | Runloop 是什么？Runloop 还是比较顾名思义的一个东西，说白了就是一种循环，只不过它这种循环比较高级。一般的 while 循环会导致 CPU 进入忙等待状态，而 Runloop 则是一种“闲”等待，这部分可以类比 Linux 下的 epoll。当没有事件时，Runloop 会进入休眠状态，有事件发生时， Runloop 会去找对应的 Handler 处理事件。Runloop 可以让线程在需要做事的时候忙起来，不需要的话就让线程休眠。 9 | 10 | 11 | 盗一张苹果官方文档的图，也是几乎每个讲 Runloop 的文章都会引用的图，大体说明了 Runloop 的工作模式： 12 | 13 |  14 | 15 | 图中展现了 Runloop 在线程中的作用：从 input source 和 timer source 接受事件，然后在线程中处理事件。 16 | 17 | ### Runloop 与线程 18 | 19 | Runloop 和线程是绑定在一起的。每个线程（包括主线程）都有一个对应的 Runloop 对象。我们并不能自己创建 Runloop 对象，但是可以获取到系统提供的 Runloop 对象。 20 | 21 | 主线程的 Runloop 会在应用启动的时候完成启动，其他线程的 Runloop 默认并不会启动，需要我们手动启动。 22 | 23 | ### Input Source 和 Timer Source 24 | 25 | 这两个都是 Runloop 事件的来源，其中 Input Source 又可以分为三类 26 | 27 | * Port-Based Sources，系统底层的 Port 事件，例如 CFSocketRef ，在应用层基本用不到 28 | * Custom Input Sources，用户手动创建的 Source 29 | * Cocoa Perform Selector Sources， Cocoa 提供的 performSelector 系列方法，也是一种事件源 30 | 31 | Timer Source 顾名思义就是指定时器事件了。 32 | 33 | ### Runloop Observer 34 | 35 | Runloop 通过监控 Source 来决定有没有任务要做，除此之外，我们还可以用 Runloop Observer 来监控 Runloop 本身的状态。 Runloop Observer 可以监控下面的 runloop 事件： 36 | 37 | * The entrance to the run loop. 38 | * When the run loop is about to process a timer. 39 | * When the run loop is about to process an input source. 40 | * When the run loop is about to go to sleep. 41 | * When the run loop has woken up, but before it has processed the event that woke it up. 42 | * The exit from the run loop. 43 | 44 | ### Runloop Mode 45 | 46 | 在监视与被监视中，Runloop 要处理的事情还挺复杂的。为了让 Runloop 能专心处理自己关心的那部分事情，引入了 Runloop Mode 概念。 47 | 48 |  49 | 50 | 如图所示，Runloop Mode 实际上是 Source，Timer 和 Observer 的集合，不同的 Mode 把不同组的 Source，Timer 和 Observer 隔绝开来。Runloop 在某个时刻只能跑在一个 Mode 下，处理这一个 Mode 当中的 Source，Timer 和 Observer。 51 | 52 | 苹果文档中提到的 Mode 有五个，分别是： 53 | 54 | * NSDefaultRunLoopMode 55 | * NSConnectionReplyMode 56 | * NSModalPanelRunLoopMode 57 | * NSEventTrackingRunLoopMode 58 | * NSRunLoopCommonModes 59 | 60 | iOS 中公开暴露出来的只有 NSDefaultRunLoopMode 和 NSRunLoopCommonModes。 NSRunLoopCommonModes 实际上是一个 Mode 的集合，默认包括 NSDefaultRunLoopMode 和 NSEventTrackingRunLoopMode。 61 | 62 | ### 与 Runloop 相关的坑 63 | 64 | 日常开发中，与 runLoop 接触得最近可能就是通过 NSTimer 了。一个 Timer 一次只能加入到一个 RunLoop 中。我们日常使用的时候，通常就是加入到当前的 runLoop 的 default mode 中，而 ScrollView 在用户滑动时，主线程 RunLoop 会转到 UITrackingRunLoopMode 。而这个时候， Timer 就不会运行。 65 | 66 | 有如下两种解决方案： 67 | 68 | - 第一种: 设置 RunLoop Mode，例如 NSTimer,我们指定它运行于 NSRunLoopCommonModes ，这是一个 Mode 的集合。注册到这个 Mode 下后，无论当前 runLoop 运行哪个 mode ，事件都能得到执行。 69 | - 第二种: 另一种解决 Timer 的方法是，我们在另外一个线程执行和处理 Timer 事件，然后在主线程更新 UI。 70 | 71 | 在 AFNetworking 3.0 中，就有相关的代码，如下： 72 | 73 | ```objectivec 74 | - (void)startActivationDelayTimer { 75 | self.activationDelayTimer = [NSTimer 76 | timerWithTimeInterval:self.activationDelay target:self selector:@selector(activationDelayTimerFired) userInfo:nil repeats:NO]; 77 | [[NSRunLoop mainRunLoop] addTimer:self.activationDelayTimer forMode:NSRunLoopCommonModes]; 78 | } 79 | ``` 80 | 81 | 这里就是添加了一个计时器，由于指定了 NSRunLoopCommonModes，所以不管 RunLoop 出于什么状态，都执行这个计时器任务。 82 | 83 | 84 | #### 参考资料 85 | 86 | * https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Multithreading/RunLoopManagement/RunLoopManagement.html#//apple_ref/doc/uid/10000057i-CH16-SW1 87 | * http://chun.tips/blog/2014/10/20/zou-jin-run-loopde-shi-jie-%5B%3F%5D-:shi-yao-shi-run-loop%3F/ 88 | * http://www.hrchen.com/2013/07/tricky-runloop-on-ios/ 89 | * http://www.cocoachina.com/ios/20150601/11970.html 90 | * http://www.cocoachina.com/ios/20111111/3487.html 91 | * http://mobile.51cto.com/iphone-386596.htm 92 | * http://blog.ibireme.com/2015/05/18/runloop/ 93 | -------------------------------------------------------------------------------- /source/iOS/ObjC-Basic/Runtime.md: -------------------------------------------------------------------------------- 1 | ## Objective-C Runtime 2 | 3 | ### Runtime 是什么？ 4 | 5 | Runtime 是 Objective-C 区别于 C 语言这样的静态语言的一个非常重要的特性。对于 C 语言，函数的调用会在编译期就已经决定好，在编译完成后直接顺序执行。但是 OC 是一门动态语言，函数调用变成了消息发送，在编译期不能知道要调用哪个函数。所以 Runtime 无非就是去解决如何在运行时期找到调用方法这样的问题。 6 | 7 | 对于实例变量有如下的思路： 8 | 9 | > instance -> class -> method -> SEL -> IMP -> 实现函数 10 | 11 | 实例对象中存放 isa 指针以及实例变量，有 isa 指针可以找到实例对象所属的类对象 (类也是对象，面向对象中一切都是对象)，类中存放着实例方法列表，在这个方法列表中 SEL 作为 key，IMP 作为 value。 在编译时期，根据方法名字会生成一个唯一的 Int 标识，这个标识就是 SEL。IMP 其实就是函数指针 指向了最终的函数实现。整个 Runtime 的核心就是 objc_msgSend 函数，通过给类发送 SEL 以传递消息，找到匹配的 IMP 再获取最终的实现。如下的这张图描述了对象的内存布局。 12 | 13 |  14 | 15 | 类中的 super_class 指针可以追溯整个继承链。向一个对象发送消息时，Runtime 会根据实例对象的 isa 指针找到其所属的类，并自底向上直至根类(NSObject)中 去寻找 SEL 所对应的方法，找到后就运行整个方法。 16 | 17 | metaClass是元类，也有 isa 指针、super_class 指针。其中保存了类方法列表。 18 | 19 | 如下是 objc/runtime.h 中定义的类的结构: 20 | 21 | ```objectivec 22 | struct objc_class { 23 | Class isa OBJC_ISA_AVAILABILITY; 24 | 25 | #if !__OBJC2__ 26 | Class super_class OBJC2_UNAVAILABLE; 27 | const char *name OBJC2_UNAVAILABLE; 28 | long version OBJC2_UNAVAILABLE; 29 | long info OBJC2_UNAVAILABLE; 30 | long instance_size OBJC2_UNAVAILABLE; 31 | struct objc_ivar_list *ivars OBJC2_UNAVAILABLE; // 成员变量地址列表 32 | struct objc_method_list **methodLists OBJC2_UNAVAILABLE; // 方法地址列表 33 | struct objc_cache *cache OBJC2_UNAVAILABLE; // 缓存最近使用的方法地址，以避免多次在方法地址列表中查询，提升效率 34 | struct objc_protocol_list *protocols OBJC2_UNAVAILABLE; // 遵循的协议列表 35 | #endif 36 | 37 | } OBJC2_UNAVAILABLE; 38 | /* Use `Class` instead of `struct objc_class *` */ 39 | ``` 40 | 41 | ### SEL 与 IMP 42 | 43 | SEL 可以将其理解为方法的 ID. 结构如下： 44 | 45 | ```objectivec 46 | typedef struct objc_selector *SEL; 47 | 48 | struct objc_selector { 49 | char *name; OBJC2_UNAVAILABLE; 50 | char *types; OBJC2_UNAVAILABLE; 51 | }; 52 | ``` 53 | 54 | IMP 可以理解为函数指针，指向了最终的实现。 55 | 56 | SEL 与 IMP 的关系非常类似于 HashTable 中 key 与 value 的关系。OC 中不支持函数重载的原因就是因为一个类的方法列表中不能存在两个相同的 SEL 。但是多个方法却可以在不同的类中有一个相同的 SEL，不同类的实例对象执行相同的 SEL 时，会在各自的方法列表中去根据 SEL 去寻找自己对应的IMP。这使得OC可以支持函数重写。 57 | 58 | ### 消息传递机制 59 | 60 | - objc_msgSend函数的消息处理过程 61 | - 不涵盖消息cache机制 62 | - 需要对Objective-C runtime有一定的了解 63 | 64 | 如下用于描述 objc_msgSend 函数的调用流程： 65 | 66 | - 1.检测 SEL 是否应该被忽略 67 | - 2.检测发送的 target 是否为 nil ，如果是则忽略该消息 68 | - 3. 69 | - 当调用实例方法时，通过 isa 指针找到实例对应的 class 并且在其中的缓存方法列表以及方法列表中进行查询，如果找不到则根据 super_class 指针在父类中查询，直至根类(NSObject 或 NSProxy). 70 | - 当调用类方法时，通过 isa 指针找到实例对应的 metaclass 并且在其中的缓存方法列表以及方法列表中进行查询，如果找不到则根据 super_class 指针在父类中查询，直至根类(NSObject 或 NSProxy). (根据此前的开篇中的图，Root Meta Class 还是有根类的。) 71 | - 如果还没找到则进入消息动态解析过程。 72 | 73 | *由于苹果对OC 2.0 Runtime的具体实现细节未完全开源，本节所引用源代码大部分来自OC 1.0，如有错误，敬请更正* 74 | 75 | 当一个对象 sender 调用代码`[receiver message];`的时候，实际上是调用了runtime的`objc_msgSend`函数，所以OC的方法调用并不像C函数一样能按照地址直接取用，而是经过了一系列的过程。这样的机制使得 runtime 可以在接收到消息后对消息进行特殊处理，这才使OC的一些特性譬如：给 nil 发送消息不崩溃，给类动态添加方法和消息转发等成为可能。也正因为每一次调用方法的时候实际上是调用了一些 runtime 的消息处理函数，OC的方法调用相对于C来说会相对较慢，但 OC 也通过引入 cache 机制来很大程度上的克服了这个缺点。下面我们就从一个对象 sender 调用代码`[receiver message];`这个情景开始，了解消息传递的过程。 76 | 77 | 首先这行代码会被改写成`objc_msgSend(self, _cmd);`，这是一个runtime的函数，其原型为： 78 | 79 | `id objc_msgSend(id self, SEL op, ...)` 80 | 81 | self与_cmd是两个编译器会自动添加的隐藏参数，self是一个指向接收对象的指针，_cmd为方法选择器。这个函数的实现为汇编版本，苹果开源的项目中共有6种对不同平台的汇编实现，本节选取其在x86_64实现的文件objc-msg-x86_64.s 82 | 83 | ```asm 84 | #objc-msg-x86_64.s# 85 | ENTRY _objc_msgSend 86 | // ... 87 | GetIsaFast NORMAL // r11 = self->isa 88 | CacheLookup NORMAL // calls IMP on success 89 | // ... 90 | // cache miss: go search the method lists 91 | LCacheMiss: 92 | // isa still in r11 93 | MethodTableLookup %a1, %a2 // r11 = IMP 94 | cmp %r11, %r11 // set eq (nonstret) for forwarding 95 | jmp *%r11 // goto *imp 96 | END_ENTRY _objc_msgSend 97 | ``` 98 | 99 | 可以看到其调用了`GetIsaFast`，由于self是id类型，而id的原型为`struct objc_object *id;`，所以需要通过id的isa指针获取其所属的类对象，之后调用`CacheLookup`在获取到的类中根据传入的_cmd查找对应方法实现的IMP指针。这两个函数的实现均在同一个文件下，因为暂时我还不了解cache的机制，所以这部分先不深入讨论。CacheLookup函数在命中后会直接调用相应的IMP方法，这就完成了方法的调用。如果cache落空，则跳转至LCacheMiss标签，调用MethodTableLookup方法，这个方法将IMP的值存在r11寄存器里，之后`jmp *%r11`从IMP开始执行，完成方法调用。MethodTableLookup函数实现如下， 100 | 101 | ```asm 102 | .macro MethodTableLookup 103 | MESSENGER_END_SLOW 104 | SaveRegisters 105 | // _class_lookupMethodAndLoadCache3(receiver, selector, class) 106 | movq $0, %a1 107 | movq $1, %a2 108 | movq %r11, %a3 109 | call __class_lookupMethodAndLoadCache3 110 | // IMP is now in %rax 111 | movq %rax, %r11 112 | RestoreRegisters 113 | .endmacro 114 | ``` 115 | 116 | 可以看到其实际上将receiver（即self)， selector(即_cmd)，class(即self->isa)传递给了_class_lookupMethodAndLoadCache3这个函数，查看该函数的实现后，欢迎重新回到C语言的世界。 117 | 118 | ```objectivec 119 | #objc-class-old.mm# 120 | IMP _class_lookupMethodAndLoadCache3(id obj, SEL sel, Class cls) 121 | { 122 | return lookUpImpOrForward(cls, sel, obj, 123 | YES/*initialize*/, NO/*cache*/, YES/*resolver*/); 124 | } 125 | ``` 126 | 127 | 这个函数进一步调用了`lookUpImpOrForward`，并把cache标签置为NO，意味着忽略第一次不加锁的cache查找。这个函数的返回值要么是对应方法的IMP指针，要么是一个__objc_msgForward_impcache汇编方法的入口，后者对应着消息转发机制，即如果在该对象及其继承链上方的的对象都找不到选择器_cmd的响应方法的话，就调用消息转发函数尝试将该消息转发给其他对象。下面是lookUpImpOrForward的实现，由于代码过长，注释将写在代码之中。 128 | 129 | ```objectivec 130 | #objc-class-old.mm# 131 | IMP lookUpImpOrForward(Class cls, SEL sel, id inst, 132 | bool initialize, bool cache, bool resolver) 133 | { 134 | Class curClass; // 当前类对象 135 | IMP methodPC = nil; // 用于保存最终查找到的函数指针并返回 136 | Method meth; // 定义了方法的一个结构体，可通过meth->imp获取函数指针 137 | bool triedResolver = NO; // 方法解析的标志变量 138 | 139 | methodListLock.assertUnlocked(); 140 | // 不加锁地查找cache，由于之前cache落空，所以肯定找不到，就忽略 141 | // Optimistic cache lookup 142 | if (cache) { 143 | methodPC = _cache_getImp(cls, sel); 144 | if (methodPC) return methodPC; 145 | } 146 | // Check for freed class 147 | if (cls == _class_getFreedObjectClass()) 148 | return (IMP) _freedHandler; 149 | // 确保该类已被初始化，如果没有就调用类方法+initialize，这里也说明了为什么OC的类会在 150 | // 第一次接收消息后调用+initialize进行初始化，相反的，如果想要代码在类注册runtime的 151 | // 时候就运行，可以将代码写在+load方法里 152 | // Check for +initialize 153 | if (initialize && !cls->isInitialized()) { 154 | _class_initialize (_class_getNonMetaClass(cls, inst)); 155 | // If sel == initialize, _class_initialize will send +initialize and 156 | // then the messenger will send +initialize again after this 157 | // procedure finishes. Of course, if this is not being called 158 | // from the messenger then it won't happen. 2778172 159 | } 160 | // The lock is held to make method-lookup + cache-fill atomic 161 | // with respect to method addition. Otherwise, a category could 162 | // be added but ignored indefinitely because the cache was re-filled 163 | // with the old value after the cache flush on behalf of the category. 164 | // 上述英文已述：对消息查找和填充cache加锁，由于填充cache是写操作，所以需要对其 165 | // 加锁以免加入了category之后的cache被旧的cache冲掉，导致category失效。 166 | 167 | // 实际上，如果cache没有命中，但在方法列表中找到了对应的IMP，函数也是会进行cache 168 | // 写入操作。 169 | retry: 170 | methodListLock.lock(); 171 | // 在开启GC选项后忽略retain, release等方法(猜测GC 是 Garbage Collection) 172 | // 这也体现了OC的灵活性，runtime完全有权力忽略一些方法 173 | if (ignoreSelector(sel)) { 174 | methodPC = _cache_addIgnoredEntry(cls, sel); 175 | goto done; 176 | } 177 | // 在加锁的状态下再查找一次cache，如果命中就直接返回IMP指针 178 | // 个人认为再次在加锁状态下查找是因为在与上次查找的间隙中可能 179 | // 有其他类填充了这个cache 180 | methodPC = _cache_getImp(cls, sel); 181 | if (methodPC) goto done; 182 | 183 | // 如果还是没有命中的话就查找该类的方法列表 184 | meth = _class_getMethodNoSuper_nolock(cls, sel); 185 | if (meth) { 186 | // 命中，填充cache，返回IMP指针 187 | log_and_fill_cache(cls, cls, meth, sel); 188 | methodPC = method_getImplementation(meth); 189 | goto done; 190 | } 191 | 192 | // 没有命中，沿着class的继承链向上查找，最后找到的是NSObject(NSProxy除外) 193 | // 而NSObject的superclass为nil 194 | curClass = cls; 195 | while ((curClass = curClass->superclass)) { 196 | // 尝试从超类的cache中加载 197 | meth = _cache_getMethod(curClass, sel, _objc_msgForward_impcache); 198 | if (meth) { 199 | // 如果不是forward 200 | if (meth != (Method)1) { 201 | // 在超类中找到IMP，在当前类中进行cache 202 | log_and_fill_cache(cls, curClass, meth, sel); 203 | methodPC = method_getImplementation(meth); 204 | goto done; 205 | } 206 | else { 207 | // 找到forward，跳出循环 208 | // Found a forward:: entry in a superclass. 209 | // Stop searching, but don't cache yet; call method 210 | // resolver for this class first. 211 | break; 212 | } 213 | } 214 | // 超类cache没有命中，从超类的方法列表寻找 215 | meth = _class_getMethodNoSuper_nolock(curClass, sel); 216 | if (meth) { 217 | log_and_fill_cache(cls, curClass, meth, sel); 218 | methodPC = method_getImplementation(meth); 219 | goto done; 220 | } 221 | } 222 | // 使用方法解析并再尝试一次 223 | if (resolver && !triedResolver) { 224 | methodListLock.unlock(); 225 | _class_resolveMethod(cls, sel, inst); 226 | triedResolver = YES; 227 | goto retry; 228 | } 229 | // 没有找到IMP指针，方法解析也没有用，使用消息转发，并将其填充入cache 230 | _cache_addForwardEntry(cls, sel); 231 | methodPC = _objc_msgForward_impcache; 232 | done: 233 | methodListLock.unlock(); 234 | // paranoia: look for ignored selectors with non-ignored implementations 235 | assert(!(ignoreSelector(sel) && methodPC != (IMP)&_objc_ignored_method)); 236 | return methodPC; 237 | } 238 | 239 | ``` 240 | 241 | 我们可以看到每一个类都维护了一个cache，在一个对象调用runtime的objc_msgSend函数后，runtime在接收者所属的类的cache中查找与_cmd所对应的IMP，如果没有命中就寻找当前类的方法列表，再找不到就跳入while循环寻找超类的cache和方法列表，如果这些方法都失效，就调用`_class_resolveMethod`查找正在插入这个类的方法，之后再重新尝试整一个流程，如果最后还是没能找到一个对应的IMP，则调用消息转发机制。 242 | 243 | ### 动态消息解析 244 | 245 |  246 | 247 | 如下用于描述动态消息解析的流程: 248 | 249 | - 1.通过 resolveInstanceMethod 得知方法是否为动态添加，YES则通过 class_addMethod 动态添加方法，处理消息，否则进入下一步。dynamic 属性就与这个过程有关，当一个属性声明为 dynamic 时 就是告诉编译器：开发者一定会添加 setter/getter 的实现，而编译时不用自动生成。 250 | - 2.这步会进入 forwardingTargetForSelector 用于指定哪个对象来响应消息。如果返回nil 则进入第三步。这种方式把消息原封不动地转发给目标对象，有着比较高的效率。如果不能自己的类里面找到替代方法，可以重载这个方法，然后把消息转给其他的对象。 251 | - 3.这步调用 methodSignatureForSelector 进行方法签名，这可以将函数的参数类型和返回值封装。如果返回 nil 说明消息无法处理并报错 `unrecognized selector sent to instance`，如果返回 methodSignature，则进入 forwardInvocation ，在这里可以修改实现方法，修改响应对象等，如果方法调用成功，则结束。如果依然不能正确响应消息，则报错 `unrecognized selector sent to instance`. 252 | 253 | 可以利用 2、3 中的步骤实现对接受消息对象的转移，可以实现“多重继承”的效果。 254 | 255 | #### 参考资料 256 | * http://yulingtianxia.com/blog/2014/11/05/objective-c-runtime/ 257 | * http://www.cocoawithlove.com/2010/01/what-is-meta-class-in-objective-c.html 258 | * https://github.com/opensource-apple/objc4 259 | -------------------------------------------------------------------------------- /source/iOS/Questions.md: -------------------------------------------------------------------------------- 1 | 2 | * https://github.com/ChenYilong/iOSInterviewQuestions 3 | 4 | * http://draveness.me/guan-yu-xie-ios-wen-ti-de-jie-da/ 5 | 6 | * https://github.com/lzyy/iOS-Developer-Interview-Questions -------------------------------------------------------------------------------- /source/iOS/README.md: -------------------------------------------------------------------------------- 1 | ### iOS 工程师技能树 2 | 3 | http://segmentfault.com/a/1190000002946644 4 | 5 | #### Objective-C 6 | 7 | * Objective-C语言基础 8 | * library,framework的制作 9 | * Runtime 编程 10 | * LLVM 原理和调优 11 | 12 | #### 操作系统 13 | 14 | * iOS内存管理和调优 15 | * iOS的文件系统和沙盒机制 16 | * iOS多线程编程（Thread,GCD,NSOperation） 17 | * iOS网络和服务器编程（NSURLConnection,NSURLSession） 18 | * iOS系统的各种安全机制 19 | 20 | #### 网络编程 21 | 22 | * iOS网络发送机制调整和优化（NSURLSession） 23 | * Socket编程 24 | * 网络传输中的各种保障 25 | * 对传输协议的调整优化 26 | 27 | #### 数据库&持久化方案 28 | 29 | * 常规持久化方案（Keychain,NSUserDefaults,Sqlite,CoreData） 30 | * 数据库的使用和设计（Sqlite） 31 | * 数据结构优化，Sql调优 32 | 33 | #### 图形图像编程 34 | 35 | * UIKit,Core Animation和Core Text的绘制 36 | * Core Graphics, Quartz 2D, Media Player, AV Foundation 37 | * OpenGL ES, GLKit, SpriteKit, SceneKit, Metal 38 | 39 | 40 | #### 数据结构 & 算法 41 | 42 | * 基本的算法和数据结构（排序搜索算法, 数组, 队列） 43 | * 较复杂数据结构的灵活应用（二叉树, 图等） 44 | * 复杂的专项算法（图像识别算法, 拓扑定位等等） 45 | 46 | #### 安全方案 47 | 48 | * 本地数据存储安全（Keychain） 49 | * 授权和身份验证 50 | * 传输安全（对称, 非对称, SSL） 51 | * App代码安全 52 | 53 | #### 业务能力 54 | 55 | * 一般性业务功能需求分析及实现 56 | * 重要业务模块的需求分析及实现 57 | * 中小规模产品的架构，系统设计和实现 58 | * 大规模产品或产品线的架构，系统设计和实现 59 | * 平台级产品的架构，系统设计和实现 60 | -------------------------------------------------------------------------------- /source/iOS/Swift/Class.md: -------------------------------------------------------------------------------- 1 | ## -------------------------------------------------------------------------------- /source/iOS/Swift/Function-And-Closure.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HIT-Alibaba/interview/33748d78515dae0edc5bd613c9852625b6ade3c3/source/iOS/Swift/Function-And-Closure.md -------------------------------------------------------------------------------- /source/iOS/Swift/README.md: -------------------------------------------------------------------------------- 1 | ## Swift 2 | 3 | 现在已经出来 Swift 5 了，然而作者已经不做 iOS 了，本部分内容可能很长一段时间都不会更新了。感兴趣的同学欢迎提 PR。 4 | 5 | -------------------------------------------------------------------------------- /source/iOS/Swift/Struct-And-Enum.md: -------------------------------------------------------------------------------- https://raw.githubusercontent.com/HIT-Alibaba/interview/33748d78515dae0edc5bd613c9852625b6ade3c3/source/iOS/Swift/Struct-And-Enum.md -------------------------------------------------------------------------------- /update.sh: -------------------------------------------------------------------------------- 1 | #!/bin/sh 2 | git pull --rebase 3 | git add -A 4 | git commit -am "update `date`" 5 | git push 6 | if which gitbook > /dev/null; then 7 | cd source 8 | gitbook build 9 | cd _book 10 | cp -R * ../../../interview-gitbook/ 11 | cd ../../../interview-gitbook/ 12 | git add -A 13 | git commit --author="skyline75489