The Objective-C Runtime is one of the overlooked features of Objective-C initially when people are generally introduced to Cocoa/Objective-C. The reason for this is that while Objective-C (the language) is easy to pick up in only a couple hours, newcomers to Cocoa spend most of their time wrapping their heads around the Cocoa Framework and adjusting to how it works. However the runtime is something that everybody should at least know how it works in some detail beyond knowing that code like [target doMethodWith:var1];
gets translated intoobjc_msgSend(target,@selector(doMethodWith:),var1);
by the compiler. Knowing what the Objective-C runtime is doing will help you gain a much deeper understanding of Objective-C itself and how your app is run. I think Mac/iPhone Developers will gain something from this, regardless of your level of experience.
Objective-C运行时对于刚刚学习cocoa/Objective-c的新手来讲是一个很宏观的基础特征。这个缘由是Ojbective-c是一门在几个小时以内就能够学会的语言,可是初学者将会花费大量的时间纠结在Cocoa Framework和弄明白他是怎么工做的。可是每个人都至少得知道运行时在细节上是怎么工做的要超过像这样的代码 [target doMethodWith:var1](能够被编译器翻译成objc_msgSend(target,@selector(doMethodWith:),var1);)理解运行时能够帮助你对objective-c有一个更深的认识,而且知道本身的程序是怎样原型的。我想Mac/iphone开发者将可以从这里获取不少东西,忽略掉你的经验。html
The Objective-C Runtime is Open Sourceobjective-c
Objective-c运行时是开源的
The Objective-C Runtime is open source and available anytime from http://opensource.apple.com. In fact examining the Objective-C is one of the first ways I went through to figure out how it worked, beyond reading Apples documentation on the matter. You can download the current version of the runtime (as of this writting) for Mac OS X 10.6.2 here objc4-437.1.tar.gz.
Objective-c运行时是一开源的,而且能够从 得到。实际上测试Objective-c是我解释它怎么运行的第一种方法,要比阅读拼过的文档要好,在这个问题上。你能够下载当前版本的运行时。
Dynamic vs Static Languages设计模式
动态语言和静态语言的比较
Objective-C is a runtime oriented language, which means that when it's possible it defers decisions about what will actually be executed from compile & link time to when it's actually executing on the runtime. This gives you a lot of flexibility in that you can redirect messages to appropriate objects as you need to or you can even intentionally swap method implementations, etc. This requires the use of a runtime which can introspect objects to see what they do & don't respond to and dispatch methods appropriately. If we contrast this to a language like C. In C you start out with a main()
method and then from there it's pretty much a top down design of following your logic and executing functions as you've written your code. A C struct can't forward requests to perform a function onto other targets. Pretty much you have a program like so
Objective-c是一个运行时的面向对象的怨言,这意味着它将在运行时决定执行什么而不是在编译时。这给了你很大的便利性,直接按照你的须要向对象发送消息。或者你甚至能够故意的改变方法实现等等。。。这须要对可以对对象内省来看起可以和不可以执行哪些方法而且将方法发送给对象的运行时的使用。若是咱们和像C同样的语言比较。使用C语言,你从main()方法开始,而后彻底看着你设计的逻辑和你的代码自上而下的执行。一个c结构体不能直接的讲一个函数运行在一个对象上。就像这个程序:
api
#include < stdio.h > int main(int argc, const char **argv[]) { printf("Hello World!"); return 0; }
which a compiler parses, optimizes and then transforms your optimized code into assembly数组
编译器语法分析,优化而后将你最佳化的代码翻译成汇编语言
缓存
.text .align 4,0x90 .globl _main _main: Leh_func_begin1: pushq %rbp Llabel1: movq %rsp, %rbp Llabel2: subq $16, %rsp Llabel3: movq %rsi, %rax movl %edi, %ecx movl %ecx, -8(%rbp) movq %rax, -16(%rbp) xorb %al, %al leaq LC(%rip), %rcx movq %rcx, %rdi call _printf movl $0, -4(%rbp) movl -4(%rbp), %eax addq $16, %rsp popq %rbp ret Leh_func_end1: .cstring LC: .asciz "Hello World!"
and then links it together with a library and produces a executable. This contrasts from Objective-C in that while the process is similar the code that the compiler generates depends on the presence of the Objective-C Runtime Library. When we are all initially introduced to Objective-C we are told that (at a simplistic level) what happens to our Objective-C bracket code is something like…数据结构
而后将库和它连接起来,产生一个可执行文件。这和Objective-C相比依赖Objective-C库的编译器产生了相同的代码。当咱们刚开始接触Objective-C的时候,咱们被告诉像这样被中括号包裹的Objective-C代码app
[self doSomethingWithVar:var1];
gets translated to…less
被翻译成
iphone
objc_msgSend(self,@selector(doSomethingWithVar:),var1);
but beyond this we don't really know much till much later on what the runtime is doing.
可是超过这,实际上咱们并不知道以后运行时作了些什么。
What is the Objective-C Runtime?
什么是Objective-C运行时环境?
The Objective-C Runtime is a Runtime Library, it's a library written mainly in C & Assembler that adds the Object Oriented capabilities to C to create Objective-C. This means it loads in Class information, does all method dispatching, method forwarding, etc. The Objective-C runtime essentially creates all the support structures that make Object Oriented Programming with Objective-C Possible.
Objective-C运行时是一个运行时库。,这是一个用C和汇编写的库,为了给C语言提供面向对象的可以,以创造Objective-C。这意味它加载类信息,分配方法,执行方法等等。Objective-c主要提供了让Objective-C面向对象的能力。
Objective-C Runtime Terminology
Ojbective-C 运行时术语
So before we go on much further, let's get some terminology out of the way so we are all on the same page about everything. 2 Runtimes As far as Mac & iPhone Developers are concerned there are 2 runtimes: The Modern Runtime & the Legacy Runtime Modern Runtime: Covers all 64 bit Mac OS X Apps & all iPhone OS Apps Legacy Runtime: Covers everything else (all 32 bit Mac OS X Apps) Method There are 2 basic types of methods. Instance Methods (begin with a '-' like -(void)doFoo;
that operate on Object Instances. And Class Methods (begin with a '+' like + (id)alloc
. Methods are just like C Functions in that they are a grouping of code that performs a small task like
因而在咱们更进一步以前,咱们先了解一些在这个页面中出现的基本术语。对于Mac和Iphone开发者而言有两个运行时环境:现代运行时环境和遗留下来的运行时环境,涵盖64位Mac OS X程序和全部Iphone OS程序的遗留下来的运行时环境,涵盖全部程序。这里有两个种基本的方法。 实例方法(以“-”开始),一个做用于对象实例的动做。还有类方法(以“+”开始)。这种方法就像C方法同样是一段代码的结合一完成一个简单的任务,好比
-(NSString *)movieTitle { return @"Futurama: Into the Wild Green Yonder"; }
Selector A selector in Objective-C is essentially a C data struct that serves as a mean to identify an Objective-C method you want an object to perform. In the runtime it's defined like so…
选择器A 选择器在Objective-C中是一个重要的C数据结构提供了辨识具体的Objective-C方法在你须要的对象上执行的方法。在运行时这个定义像:
typedef struct objc_selector *SEL;
and used like so…
而且使用时像
SEL aSel = @selector(movieTitle);
Message
消息
[target getMovieTitleForObject:obj];
An Objective-C Message is everything between the 2 brackets '[ ]' and consists of the target you are sending a message to, the method you want it to perform and any arguments you are sending it. A Objective-C message while similar to a C function call is different. The fact that you send a message to an object doesn't mean that it'll perform it. The Object could check who the sender of the message is and based on that decide to perform a different method or forward the message onto a different target object. Class If you look in the runtime for a class you'll come across this…
一个Objective-C消息是在[]之间的全部东西,它由你要发送消息的对象和你要执行的方法以及你要发送的参数组成。一个Objective-C消息与C函数调用相比是不一样的。实际上你发送了一个消息给一个对象并不意味着这个对象会执行这个方法。对象将会检车谁是这个这小的发送者而后决定是执行一个别的方法仍是传递这个消息给其余的对象。若是你观察类在运行时的状况,你将会发现
typedef struct objc_class *Class; typedef struct objc_object { Class isa; } *id;
Here there are several things going on. We have a struct for an Objective-C Class and a struct for an object. All the objc_object has is a class pointer defined as isa, this is what we mean by the term 'isa pointer'. This isa pointer is all the Objective-C Runtime needs to inspect an object and see what it's class is and then begin seeing if it responds to selectors when you are messaging objects. And lastly we see the id pointer. The id pointer by default tells us nothing about Objective-C objects except that they are Objective-C objects. When you have a id pointer you can then ask that object for it's class, see if it responds to a method, etc and then act more specifically when you know what the object is that you are pointing to. You can see this as well on Blocks in the LLVM/Clang docs
很明显这里有不少东西正在进行。咱们有一个Objective-C的数据结构。全部的objc对象有一个ISA的类指针。这就是咱们用“isa pointer”所描述的。 ISA指针是全部Ojective-c运行时所须要的,去辨别对象,和对象类型而后判断其是否对一个选择器有响应当你发送小时时。而后咱们看到了对象指针。对象指针默认没有告诉我任何东西,除了这是个Objective-C对象以外。当你有一个对象指针,你能够询问这个对象的类型,检查是否响应某个方法等等,而后执行当你知道这个指针指向的是一个什么对象。你能发现一样的东西关于Blocks在LLVM/CLang文档中。
struct Block_literal_1 { void *isa; // initialized to &_NSConcreteStackBlock or &_NSConcreteGlobalBlock int flags; int reserved; void (*invoke)(void *, ...); struct Block_descriptor_1 { unsigned long int reserved; // NULL unsigned long int size; // sizeof(struct Block_literal_1) // optional helper functions void (*copy_helper)(void *dst, void *src); void (*dispose_helper)(void *src); } *descriptor; // imported variables };
Blocks themselves are designed to be compatible with the Objective-C runtime so they are treated as objects so they can respond to messages like -retain
,-release
,-copy
,etc. IMP (Method Implementations)
Block被设计成可以与Objective-C运行时结合,方便把他们当成对象处理,以使他们可以相应这些消息。
typedef id (*IMP)(id self,SEL _cmd,...);
IMP's are function pointers to the method implementations that the compiler will generate for you. If your new to Objective-C you don't need to deal with these directly until much later on, but this is how the Objective-C runtime invokes your methods as we'll see soon. Objective-C Classes So what's in an Objectve-C Class? The basic implementation of a class in Objective-C looks like
IMP是编译器将会产生给你的函数指针。若是你刚接触Objective-C,你不用直接处理这些知道很长一段时间以后,可是这是Objective-C运行时像你看到的同样之行你的方法的基础实现。对于Objective-C类来讲什么是一个Objetive-C的类呢?一个Objective-C的累的基础实现像这样:
@interface MyClass : NSObject { //vars NSInteger counter; } //methods -(void)doFoo; @end
but the runtime has more than that to keep track of
可是运行时有更多的东西以追踪
#if !__OBJC2__ Class super_class OBJC2_UNAVAILABLE; const char *name OBJC2_UNAVAILABLE; long version OBJC2_UNAVAILABLE; long info OBJC2_UNAVAILABLE; long instance_size OBJC2_UNAVAILABLE; struct objc_ivar_list *ivars OBJC2_UNAVAILABLE; struct objc_method_list **methodLists OBJC2_UNAVAILABLE; struct objc_cache *cache OBJC2_UNAVAILABLE; struct objc_protocol_list *protocols OBJC2_UNAVAILABLE; #endif
We can see a class has a reference to it's superclass, it's name, instance variables, methods, cache and protocols it claims to adhere to. The runtime needs this information when responding to messages that message your class or it's instances.
咱们能够看到累有一个指向它弗雷的引用,它的名字,实例变量,实例方法,缓存和它所支持的协议。运行时须要这些信息当你发送消息给你的类或者实例时响应这些消息。
So Classes define objects and yet are objects themselves? How does this work
因而类定义对象而不是对象自己。这是怎样实现的
Yes earlier I said that in objective-c classes themselves are objects as well, and the runtime deals with this by creating Meta Classes. When you send a message like [NSObject alloc]
you are actually sending a message to the class object, and that class object needs to be an instance of the MetaClass which itself is an instance of the root meta class. While if you say subclass from NSObject, your class points to NSObject as it's superclass. However all meta classes point to the root metaclass as their superclass. All meta classes simply have the class methods for their method list of messages that they respond to. So when you send a message to a class object like [NSObject alloc]
then objc_msgSend()
actually looks through the meta class to see what it responds to then if it finds a method, operates on the Class object.
正像我遭袭时候说过的同样Objective-C类自己也是对象。而且运行时经过建立元信息来处理它。当你发送一个消息,你其实是发送了一个消息给类对象。而且类对象必须是一个元类型的实例。当你说要从NSObject继承的时候,你的类指针指向NSObject作为它的父类。不管怎样,全部元类型都指向根元类型作为他们的弗雷。全部的元类型很简单的有用类方法他们可以响应的消息的列表。因此,当你发送一个小时给一个类对象的时候,实际上检查了元类型来肯定它时候可以响应,而且若是能够找到一个方法,在类上执行该方法。
Why we subclass from Apples Classes
为何咱们从苹果的类型继承
So initially when you start Cocoa development, tutorials all say to do things like subclass NSObject and start then coding something and you enjoy a lot of benefits simply by inheriting from Apples Classes. One thing you don't even realize that happens for you is setting your objects up to work with the Objective-C runtime. When we allocate an instance of one of our classes it's done like so…
在你最开始开发Cocoa程序的时候,教程都出要从NSobject结成,而后开始写代码,你会享受从苹果的类继承带来的乐趣。一件事情你甚至没有注意到,就是到底法身了什么当你组织你的对象在Objectiv-C运行时环境上。但你实例化了你的类,像这样:
MyObject *object = [[MyObject alloc] init];
the very first message that gets executed is +alloc
. If you look at the documentation it says that "The isa instance variable of the new instance is initialized to a data structure that describes the class; memory for all other instance variables is set to 0." So by inheriting from Apples classes we not only inherit some great attributes, but we inherit the ability to easily allocate and create our objects in memory that matches a structure the runtime expects (with a isa pointer that points to our class) & is the size of our class.
第一个执行的消息是alloc。若是你查阅文档,它说“一个新实例的ISA实例被初始化成描述这个类的一个数据结构,全部其余的实例的没存被设置成0”。因而从苹果累继承咱们不止继承了一些属性,并且咱们还继承了简单的内存分配和在内存中建立符合运行时指望大小的咱们的对象。
So what's with the Class Cache? ( objc_cache *cache )
类Cache是个什么东西?
When the Objective-C runtime inspects an object by following it's isa pointer it can find an object that implements many methods. However you may only call a small portion of them and it makes no sense to search the classes dispatch table for all the selectors every time it does a lookup. So the class implements a cache, whenever you search through a classes dispatch table and find the corresponding selector it puts that into it's cache. So whenobjc_msgSend()
looks through a class for a selector it searches through the class cache first. This operates on the theory that if you call a message on a class once, you are likely to call that same message on it again later. So if we take this into account this means that if we have a subclass of NSObject
called MyObject
and run the following code
当Objective-C运行时经过跟踪一个对象的ISA指针来检查一个对象的时候,它将会发现一个实现了不少方法的对象。不管怎样,你只会调用他们不多的一部分而且彻底没有意义去检查类的方法执行表每次检查的时候。因而类实现了一个Cache,当你查找类的dispatch table而且想找到对应的方法的时,将会把方法放入cache中。因而当Ojbc_msgSend()检查一个类查找一个方法的时候,它会先检查cache。这个操做基于这样的理论,当你在一个类上执行一个方法一次以后,你将会执行相同的方法在以后的一段时间内。因而,若是咱们着重考虑一下这个,若是咱们有一个叫作MyObject的NSObject的子类,而且运行下列代码
MyObject *obj = [[MyObject alloc] init]; @implementation MyObject -(id)init { if(self = [super init]){ [self setVarA:@”blah”]; } return self; } @end
the following happens
这些将会发生,
(1) [MyObject alloc]
gets executed first. MyObject class doesn't implement alloc so we will fail to find +alloc
in the class and follow the superclass pointer which points to NSObject
(1) [MyObject alloc]
将会第一个执行。MyObject类没有实现alloc,因而咱们查找 +alloc
失败在这个类中,而后咱们跟踪着他的父类指针 NSObject
(2) We ask NSObject
if it responds to +alloc
and it does. +alloc
checks the receiver class which is MyObject
and allocates a block of memory the size of our class and initializes it's isa pointer to the MyObject class and we now have an instance and lastly we put +alloc in NSObject's class cache for the class object
咱们查询 NSObject
是否对 +alloc
响应,而且的确如此. +alloc
查找接受类 MyObject
而且分配内存,将ISA指针指向MyObject类而且咱们有了一个实例,最后咱们将alloc放入这个类的缓存中
(3) Up till now we were sending a class messages but now we send an instance message which simply calls -init
or our designated initializer. Of course our calss responds to that message so -(id)init
get's put into the cache
如今咱们正在发送一个类消息,可是咱们发送了一个实例消息(被乘坐init或者咱们的构造器)。固然咱们的类响应该消息而且放入了cache。
(4) Then self = [super init]
gets called. Super being a magic keyword that points to the objects superclass so we go to NSObject
and call it's init method. This is done to insure that OOP Inheritance works correctly in that all your super classes will initialize their variables correctly and then you (being in the subclass) can initialize your variables correctly and then override the superclasses if you really need to. In the case of NSObject, nothing of huge importance goes on, but that is not always the case. Sometimes important initialization happens. Take this…
而后 self = [super inti]被调用。super是一个神奇的关键字指向类的父类(NSObject),而且调用父类的初始化方法。这是为了确保OOP继承工做正常。在全部的弗雷初始化他们的变量正常以后,你能够初始化你的变量。而后推翻你的父类,若是你真的要这么作。在NSObject的状况下,没有什么很是中的事情进行,可是这并非常态。有些时候很重要的初始化会发生,考虑:
#import < Foundation/Foundation.h> @interface MyObject : NSObject { NSString *aString; } @property(retain) NSString *aString; @end @implementation MyObject -(id)init { if (self = [super init]) { [self setAString:nil]; } return self; } @synthesize aString; @end int main (int argc, const char * argv[]) { NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init]; id obj1 = [NSMutableArray alloc]; id obj2 = [[NSMutableArray alloc] init]; id obj3 = [NSArray alloc]; id obj4 = [[NSArray alloc] initWithObjects:@"Hello",nil]; NSLog(@"obj1 class is %@",NSStringFromClass([obj1 class])); NSLog(@"obj2 class is %@",NSStringFromClass([obj2 class])); NSLog(@"obj3 class is %@",NSStringFromClass([obj3 class])); NSLog(@"obj4 class is %@",NSStringFromClass([obj4 class])); id obj5 = [MyObject alloc]; id obj6 = [[MyObject alloc] init]; NSLog(@"obj5 class is %@",NSStringFromClass([obj5 class])); NSLog(@"obj6 class is %@",NSStringFromClass([obj6 class])); [pool drain]; return 0; }
Now if you were new to Cocoa and I asked you to guess as to what would be printed you'd probably say
如今若是你刚接触Cocoa,若是我问你将会打印什么你会说。
NSMutableArray NSMutableArray NSArray NSArray MyObject MyObject
but this is what happens
obj1 class is __NSPlaceholderArray obj2 class is NSCFArray obj3 class is __NSPlaceholderArray obj4 class is NSCFArray obj5 class is MyObject obj6 class is MyObject
This is because in Objective-C there is a potential for +alloc
to return an object of one class and then -init
to return an object of another class.
由于在Objective-C中存在这样的可能,alloc返回一个类型,而init返回另一个类型。
So what happens in objc_msgSend anyway?
在objc_msgSend时发生了什么?
There is actually a lot that happens in objc_msgSend()
. Lets say we have code like this…
实际上在objc_msgSend()中发生了不少事情。让我看一下假设咱们有这样的代码...
[self printMessageWithString:@"Hello World!"];
it actually get's translated by the compiler to…
它实际上被编译器翻译成了
objc_msgSend(self,@selector(printMessageWithString:),@"Hello World!");
From there we follow the target objects isa pointer to lookup and see if the object (or any of it's superclasses) respond to the selector@selector(printMessageWithString:)
. Assuming we find the selector in the class dispatch table or it's cache we follow the function pointer and execute it. Thus objc_msgSend()
never returns, it begins executing and then follows a pointer to your methods and then your methods return, thus looking like objc_msgSend()
returned. Bill Bumgarner went into much more detail ( Part 1, Part 2 & Part 3) on objc_msgSend()
than I will here. But to summarize what he said and what you'd see looking at the Objective-C runtime code… 从这里咱们跟踪目标对象的ISA指针来查找和判断这个对象是否响应 @selector(printMessageWithString:)。假设咱们找到了这个选择器在这个类的dispatch表或者cache中。咱们循着函数指针而后执行它。而后objc_msgSend()历来不返回。它开始执行,而且跟踪指向你的方法的指针,而后你的方法返回。这看起来像objc_msgSend()返回的同样。Bill Bumgarner 想要解释更多的东西关于objc_msgSend()比我在这里。可是总结起来,他说的和你在运行时看到的。
1. Checks for Ignored Selectors & Short Circut - Obviously if we are running under garbage collection we can ignore calls to -retain
,-release
, etc 检查忽略的Selector和Short Circuit,很明显当咱们运行在有垃圾回收机制的状况的时候咱们将会忽略retai和release等等2. Check for nil target. Unlike other languages messaging nil in Objective-C is perfectly legal & there are some valid reasons you'd want to. Assuming we have a non nil target we go on…检查nil目标。不想其余语言,nil在objective-C中是一个彻底合法,而且这里有不少缘由你也愿意这样。若是咱们有一个非空的对象咱们将会继续 3. Then we need to find the IMP on the class, so we first search the class cache for it, if found then follow the pointer and jump to the function而后咱们查找IMP在这个雷尚,咱们如今cache中检查它,若是找到了就循着指针跳转到这个函数 4. If the IMP isn't found in the cache then the class dispatch table is searched next, if it's found there follow the pointer and jump to the pointer若是IMP没有在cache中找到,咱们就检查dispatch table。若是找到了咱们就跳转到这个函数之行 5. If the IMP isn't found in the cache or class dispatch table then we jump to the forwarding mechanism This means in the end your code is transformed by the compiler into C functions. So a method you write like say…
若是IMP没有在cahce和dispatch table中找到,咱们就会跳转到转发机制。这意味着在你的代码被编译器转化成了C函数。
-(int)doComputeWithNum:(int)aNum
would be transformed into...
int aClass_doComputeWithNum(aClass *self,SEL _cmd,int aNum)
And the Objective-C Runtime calls your methods by invoking function pointers to those methods. Now I said that you cannot call those translated methods directly, however the Cocoa Framework does provide a method to get at the pointer…
而且Objective-C运行时经过调用对应的函数指针来调用你的方法。如今我说你不能直接调用这些翻译后的方法,虽然cocoa framework提供了方法来获取这些指针。
//declare C function pointer int (computeNum *)(id,SEL,int); //methodForSelector is COCOA & not ObjC Runtime //gets the same function pointer objc_msgSend gets computeNum = (int (*)(id,SEL,int))[target methodForSelector:@selector(doComputeWithNum:)]; //execute the C function pointer returned by the runtime computeNum(obj,@selector(doComputeWithNum:),aNum);
In this way you can get direct access to the function and directly invoke it at runtime and even use this to circumvent the dynamism of the runtime if you absolutely need to make sure that a specific method is executed. This is the same way the Objective-C Runtime invokes your method, but usingobjc_msgSend()
.
经过这种方法你能够直接找到函数入口而且在运行时调用它。甚至使用它改变运行时,当你真的想这么作,而且知道什么方法被执行的时候。这是一样的方法来之行你的方法,可是应该使用objc_msgSend();
Objective-C Message Forwarding
Objective-C消息转发
In Objective-C it's very legal (and may even be an intentional design decision) to send messages to objects to which they don't know how to respond to. One reason Apple gives for this in their docs is to simulate multiple inheritance which Objective-C doesn't natively support, or you may just want to abstract your design and hide another object/class behind the scenes that deals with the message. This is one thing that the runtime is very necessary for. It works like so
在Objective-c中发送一个消息给一个你不知道它会怎么响应的对象是彻底合法的(甚至有些是有是一种设计模式)。苹果在他们的文档中给出的一个缘由是来模拟没有提供的多重继承。或者你想绝对化你的设计,而且隐藏消息实现。这是一件运行时很是须要的事情。它这样工做
1. The Runtime searches through the class cache and class dispatch table of your class and all the super classes, but fails to to find the specified method
运行时检查累缓存和累的dipatch表还有他的弗雷的,可是没有找到特定方法
2. The Objective-C Runtime will call + (BOOL) resolveInstanceMethod:(SEL)aSEL
on your class. This gives you a chance to provide a method implementation and tell the runtime that you've resolved this method and if it should begin to do it's search it'll find the method now. You could accomplish this like so... define a function…
运行时将会调用在你的类上调用 + (BOOL) resolveInstanceMethod:(SEL)aSEL 。这给了你一个机会去提供一个方法实现而且告诉运行时你如何解决这个方,而且若是它开始检查将会获得这个方法。你必须这样作:
void fooMethod(id obj, SEL _cmd) { NSLog(@"Doing Foo"); }
you could then resolve it like so using class_addMethod()
...
+(BOOL)resolveInstanceMethod:(SEL)aSEL { if(aSEL == @selector(doFoo:)){ class_addMethod([self class],aSEL,(IMP)fooMethod,"v@:"); return YES; } return [super resolveInstanceMethod]; }
The "v@:" in the last part of class_addMethod()
is what the method is returning and it's arguments. You can see what you can put there in the Type Encodings section of the Runtime Guide.
在函数最后的“v@:”是这个函数方法的返回值和参数列表。你能够查看Type Encodings章节看看你可以在这里放些什么。
3. The Runtime then calls - (id)forwardingTargetForSelector:(SEL)aSelector
. What this does is give you a chance (since we couldn't resolve the method (see #2 above)) to point the Objective-C runtime at another object which should respond to the message, also this is better to do before the more expensive process of invoking - (void)forwardInvocation:(NSInvocation *)anInvocation
takes over. You could implement it like so
运行时而后调用方法 - (id)forwardingTargetForSelector:(SEL)aSelector。这样作给了你一个机会重定向运行时到另一个能够响应该消息的对象。这比之行花费更多的要好。你能够这么作
- (id)forwardingTargetForSelector:(SEL)aSelector { if(aSelector == @selector(mysteriousMethod:)){ return alternateObject; } return [super forwardingTargetForSelector:aSelector]; }
Obviously you don't want to ever return self from this method or it could result in an infinite loop.
很明显你不会想在这个方法中返回self,这回致使一个死循环。
4. The Runtime then tries one last time to get a message sent to it's intended target and calls - (void)forwardInvocation:(NSInvocation *)anInvocation
. If you've never seen NSInvocation
, it's essentially an Objective-C Message in object form. Once you have an NSInvocation you essentially can change anything about the message including it's target, selector & arguments. So you could do…
运行时将会至少尝试一次将消息发送到这个重定向的目标上。若是你历来没有见到错NSInvocation,这是一个很重要的Objective-C对象形式的消息。一旦你有了一个NSINvocation你能够改变任何东西包括他的目标,方法,参数。任何你能够作的。。。。
-(void)forwardInvocation:(NSInvocation *)invocation { SEL invSEL = invocation.selector; if([altObject respondsToSelector:invSEL]) { [invocation invokeWithTarget:altObject]; } else { [self doesNotRecognizeSelector:invSEL]; } }
by default if you inherit from NSObject it's - (void)forwardInvocation:(NSInvocation *)anInvocation
implementation simply calls -doesNotRecognizeSelector:
which you could override if you wanted to for one last chance to do something about it.
默认状况下继承NSobject的方法实现,只是简单的调用 -doesNotRecognizeSelector: 。你能够重载这个方法,若是你想得到一次机会作点什么。
Non Fragile ivars (Modern Runtime)
没有易损的实例
One of the things we recently gained in the modern runtime is the concept of Non Fragile ivars. When compiling your classes a ivar layout is made by the compiler that shows where to access your ivars in your classes, this is the low level detail of getting a pointer to your object, seeing where the ivar is offset in relation to the beginning of the bytes the object points at, and reading in the amount of bytes that is the size of the type of variable you are reading in. So your ivar layout may look like this, with the number in the left column being the byte offset.
一个咱们最近从现代运行时中华uode的好处没有易碎的Ivars的概念。当编译你的类时,一个ivar将会被编译器制造依赖显示从哪里来进入你类的的ivars。看一下相对于类开始处的偏移量,而后这个bytes数量就是你的变量的大小。因而你的ivar就想这样
Here we have the ivar layout for NSObject and then we subclass NSObject to extend it and add on our own ivars. This works fine until Apple ships a update or all new Mac OS X 10.x release and this happens
这里咱们有一个NSObject的ivar,而后咱们继承NSObject而且添加咱们本身的ivar。这个在MAC OS X 10.x上工做良好。
Your custom objects get wiped out because we have an overlapping superclass. The only alternative that could prevent this is if Apple sticked with the layout it had before, but if they did that then their Frameworks could never advance because their ivar layouts were frozen in stone. Under fragile ivars you have to recompile your classes that inherit from Apples classes to restore compatibility. So what Happens under non fragile ivars?
你自定义的对象被擦除掉了,由于咱们有一个父类。一个可选的方法来阻止这个发生的方式是若是苹果保持和原先的layout的联系,可是若是他们这样作的话他们的framewors将会永远被冻结。在易损的ivar上你必须从新编译你的类来从苹果的累继承以兼容。因此发生了什么?
Under Non Fragile ivars the compiler generates the same ivar layout as under fragile ivars. However when the runtime detects an overlapping superclass it adjusts the offsets to your additions to the class, thus your additions in a subclass are preserved.
在Non fragile ivars下编译器产生了相同的ivar 与fragile ivars相比。不管怎样,若是运行时检测到一个父类适合你的类,那么你添加的东西将会被保留。
Objective-C Associated Objects
Objective-C 联合对象
One thing recently introduced in Mac OS X 10.6 Snow Leopard was called Associated References. Objective-C has no support for dynamically adding on variables to objects unlike some other languages that have native support for this. So up until now you would have had to go to great lengths to build the infrastructure to pretend that you are adding a variable onto a class. Now in Mac OS X 10.6, the Objective-C Runtime has native support for this. If we wanted to add a variable to every class that already exists like say NSView we could do so like this…
一个最近被添加进 Mac OS X 10.6 Snow Leopard 的东西是联合引用。Objective-c不支持动态添加成员变量,不像其余一些原生支持这个的语言。因此在次以前你必须构件一个很是大的数据结构来伪装你正在个体一个类添加一个变量。如今在 Mac OS X 10.6 Snow Leopard 运行时原生支持这个。若是咱们想要添加一个变量给每个已经存在的类,好比NSView,咱们能够这么作
#import < Cocoa/Cocoa.h> //Cocoa #include < objc/runtime.h> //objc runtime api’s @interface NSView (CustomAdditions) @property(retain) NSImage *customImage; @end @implementation NSView (CustomAdditions) static char img_key; //has a unique address (identifier) -(NSImage *)customImage { return objc_getAssociatedObject(self,&img_key); } -(void)setCustomImage:(NSImage *)image { objc_setAssociatedObject(self,&img_key,image, OBJC_ASSOCIATION_RETAIN); } @end
you can see in runtime.h the options for how to store the values passed to objc_setAssociatedObject()
.
/* Associated Object support. */ /* objc_setAssociatedObject() options */ enum { OBJC_ASSOCIATION_ASSIGN = 0, OBJC_ASSOCIATION_RETAIN_NONATOMIC = 1, OBJC_ASSOCIATION_COPY_NONATOMIC = 3, OBJC_ASSOCIATION_RETAIN = 01401, OBJC_ASSOCIATION_COPY = 01403 };
These match up with the options you can pass in the @property
syntax.
Hybrid vTable Dispatch
If you look through the modern runtime code you'll come across this (in objc-runtime-new.m)...
/*********************************************************************** * vtable dispatch * * Every class gets a vtable pointer. The vtable is an array of IMPs. * The selectors represented in the vtable are the same for all classes * (i.e. no class has a bigger or smaller vtable). * Each vtable index has an associated trampoline which dispatches to * the IMP at that index for the receiver class's vtable (after * checking for NULL). Dispatch fixup uses these trampolines instead * of objc_msgSend. * Fragility: The vtable size and list of selectors is chosen at launch * time. No compiler-generated code depends on any particular vtable * configuration, or even the use of vtable dispatch at all. * Memory size: If a class's vtable is identical to its superclass's * (i.e. the class overrides none of the vtable selectors), then * the class points directly to its superclass's vtable. This means * selectors to be included in the vtable should be chosen so they are * (1) frequently called, but (2) not too frequently overridden. In * particular, -dealloc is a bad choice. * Forwarding: If a class doesn't implement some vtable selector, that * selector's IMP is set to objc_msgSend in that class's vtable. * +initialize: Each class keeps the default vtable (which always * redirects to objc_msgSend) until its +initialize is completed. * Otherwise, the first message to a class could be a vtable dispatch, * and the vtable trampoline doesn't include +initialize checking. * Changes: Categories, addMethod, and setImplementation all force vtable * reconstruction for the class and all of its subclasses, if the * vtable selectors are affected. **********************************************************************/
The idea behind this is that the runtime is trying to store in this vtable the most called selectors so this in turn speeds up your app because it uses fewer instructions than objc_msgSend
. This vtable is the 16 most called selectors which make up an overwheling majority of all the selectors called globally, in fact further down in the code you can see the default selectors for Garbage Collected & non Garbage Collected apps...
static const char * const defaultVtable[] = { "allocWithZone:", "alloc", "class", "self", "isKindOfClass:", "respondsToSelector:", "isFlipped", "length", "objectForKey:", "count", "objectAtIndex:", "isEqualToString:", "isEqual:", "retain", "release", "autorelease", }; static const char * const defaultVtableGC[] = { "allocWithZone:", "alloc", "class", "self", "isKindOfClass:", "respondsToSelector:", "isFlipped", "length", "objectForKey:", "count", "objectAtIndex:", "isEqualToString:", "isEqual:", "hash", "addObject:", "countByEnumeratingWithState:objects:count:", };
So how will you know if your dealing with it? You'll see one of several methods called in your stack traces while your debugging. All of these you should basically treat just like they are objc_msgSend()
for debugging purposes...objc_msgSend_fixup
happens when the runtime is assigning one of these methods that your calling a slot in the vtable.objc_msgSend_fixedup
occurs when your calling one of these methods that was supposed to be in the vtable but is no longer in there objc_msgSend_vtable[0-15]
you'll might see a call to something like objc_msgSend_vtable5
this means you are calling one of these common methods in the vtable. The runtime can assign and unassign these as it wants to, so you shouldn't count on the fact thatobjc_msgSend_vtable10
corresponds to -length
on one run means it'll ever be there on any of your next runs.
Conclusion
I hope you liked this, this article essentially makes up the content I covered in my Objective-C Runtime talk to the Des Moines Cocoaheads (a lot to pack in for as long a talk as we had.) The Objective-C Runtime is a great piece of work, it does a lot powering our Cocoa/Objective-C apps and makes possible so many features we just take for granted. Hope I hope if you haven't yet you'll take a look through these docs Apple has that show how you can take advantage of the Objective-C Runtime. Thanks! Objective-C Runtime Programming Guide Objective-C Runtime Reference
Posted by Colin Wheeler at 3:53 PM
Labels: CocoaHeads, Objective-C, Objective-C Runtime