了解Objective-C语言的起源

Objective-C为C语言添加了面向对象特性，是其超集。Objective-C使用了消息结构，也就是说，在运行时才会检查对象类型。接收一条消息之后，究竟应执行何种代码，由运行期而非编译器来决定,运行时才会去查找所要执行的方法。
理解C语言的核心概念有助于写好Objective-C程序。尤其要掌握内存模型与指针。

使用了函数调用的语言（例如C++），则由编译器决定。

运行组件

其实现原理是由运行期组件（runtime component）来实现的，使用Objective-c的面向对象特性所需的全部数据结构和函数都在运行组件里面。运行组件本质上是一种与开发者所编代码相链接的“动态库”，其代码能把开发者编写的所有程序粘合起来，所以只要更新运行组件，即可提升程序性能。

OC内存模型与制作

Objective-C中的指针是用来指示对象的

对象分配到堆空间,指针分配到栈空间分配在堆中的内存必须直接管理，而分配在栈上用于保存变量的内存会在其栈帧弹出时自动清理。

不含*的变量，可能会使用栈空间。例如结构体CGRect，使用对象来做，影响性能。因为与结构体相比，创建对象类型需要额外的开销。

编译型语言派发机制

程序派发的目的是为了告诉 CPU 需要被调用的函数在哪里

编译型语言有三种基础的函数派发方式:

直接派发(Direct Dispatch)
函数表派发(Table Dispatch)
消息机制派发(Message Dispatch)

大多数语言都会支持一到两种, Java 默认使用函数表派发, 但你可以通过 final 修饰符修改成直接派发. C++ 默认使用直接派发, 但可以通过加上 virtual 修饰符来改成函数表派发. 而 Objective-C 则总是使用消息机制派发, 但允许开发者使用 C 直接派发来获取性能的提高. 这样的方式非常好, 但也给很多开发者带来了困扰,

直接派发 (Direct Dispatch)

直接派发是最快的, 不止是因为需要调用的指令集会更少, 并且编译器还能够有很大的优化空间, 例如函数内联等.直接派发也有人称为静态调用.

然而, 对于编程来说直接调用也是最大的局限, 而且因为缺乏动态性所以没办法支持继承.

函数表派发 (Table Dispatch )

函数表派发是编译型语言实现动态行为最常见的实现方式. 函数表使用了一个数组来存储类声明的每一个函数的指针. 大部分语言把这个称为 virtual table(虚函数表), Swift 里称为 witness table. 每一个类都会维护一个函数表, 里面记录着类所有的函数, 如果父类函数被 override 的话, 表里面只会保存被 override 之后的函数. 一个子类新添加的函数, 都会被插入到这个数组的最后. 运行时会根据这一个表去决定实际要被调用的函数.

举个例子, 看看下面两个类:

class ParentClass {
    func method1() {}
    func method2() {}
}
class ChildClass: ParentClass {
    override func method2() {}
    func method3() {}
}

在这个情况下, 编译器会创建两个函数表, 一个是 ParentClass 的, 另一个是 ChildClass的: 这张表展示了 ParentClass 和 ChildClass 虚数表里 method1, method2, method3 在内存里的布局.

let obj = ChildClass()
obj.method2()

当一个函数被调用时, 会经历下面的几个过程:

读取对象 0xB00 的函数表.
读取函数指针的索引. 在这里, method2 的索引是1(偏移量), 也就是 0xB00 + 1.
跳到 0x222 (函数指针指向 0x222)

查表是一种简单, 易实现, 而且性能可预知的方式. 然而, 这种派发方式比起直接派发还是慢一点. 从字节码角度来看,多了两次读和一次跳转, 由此带来了性能的损耗.另一个慢的原因在于编译器可能会由于函数内执行的任务导致无法优化. (如果函数带有副作用的话)

这种基于数组的实现, 缺陷在于函数表无法拓展，子类会在虚数函数表的最后插入新的函数, 没有位置可以让 extension 安全地插入函数。

消息机制派发 (Message Dispatch )

消息机制是调用函数最动态的方式. 也是 Cocoa 的基石, 这样的机制催生了 KVO, UIAppearence 和 CoreData 等功能. 这种运作方式的关键在于开发者可以在运行时改变函数的行为. 不止可以通过 swizzling 来改变, 甚至可以用 isa-swizzling 修改对象的继承关系, 可以在面向对象的基础上实现自定义派发.

举个例子, 看看下面两个类:

class ParentClass {
    dynamic func method1() {}
    dynamic func method2() {}
}
class ChildClass: ParentClass {
    override func method2() {}
    dynamic func method3() {}
}

Swift 会用树来构建这种继承关系:

这张图很好地展示了 Swift 如何使用树来构建类和子类.

当一个消息被派发, 运行时会顺着类的继承关系向上查找应该被调用的函数. 如果你觉得这样做效率很低, 它确实很低! 然而, 只要缓存建立了起来, 这个查找过程就会通过缓存来把性能提高到和函数表派发一样快. 但这只是消息机制的原理。

Swift的派发机制与内存机制

行数据解析、数据映射和数据存储的时候，Swift 的特性（协议、泛型、结构体和类）是如何影响应用性能的？

理解 Swift 派发机制

译者注: 想要了解 Swift 底层结构的人, 极度推荐这段视频

Swift 是一门静态语言，所有在 Swift 中声明的方法和属性都是静态编译期就确定了的，同时，Swift 也支持动态绑定和动态派发，只需要将class里的属性或方法声明为@objc dynamic即可，此时，Swift 的动态特性将使用 ObjC Runtime 来实现，完全兼容 ObjC

swift中有四个选择具体派发方式的因素存在:

声明的位置
引用类型
特定的行为
显式地优化(Visibility Optimizations)

Swift内存机制

对象的内存分配 (allocation) 和内存释放 (deallocation) 是代码中最大的开销之一，同时通常也是不可避免的。Swift 会自行分配和释放内存，此外它存在两种类型的分配方式。

基于栈 (stack-based) 的内存分配。Swift 会尽可能选择在栈上分配内存。栈是一种非常简单的数据结构；数据从栈的底部推入 (push)，从栈的顶部弹出 (pop)。由于我们只能够修改栈的末端，因此我们可以通过维护一个指向栈末端的指针来实现这种数据结构，并且在其中进行内存的分配和释放只需要重新分配该整数即可
基于堆 (heap-based) 的内存分配。这使得内存分配将具备更加动态的生命周期，但是这需要更为复杂的数据结构。要在堆上进行内存分配的话，您需要锁定堆当中的一个空闲块 (free block)，其大小能够容纳您的对象。因此，我们需要找到未使用的块，然后在其中分配内存。当我们需要释放内存的时候，我们就必须搜索何处能够重新插入该内存块。这个操作很缓慢。主要是为了线程安全，我们必须要对这些东西进行锁定和同步。

引用计数

引用计数是 Objective-C 和 Swift 中用于确定何时该释放对象的安全机制。目前，Swift 当中的引用计数是强制自动管理的，无法优化。

结构体

苹果推荐使用结构体，因为结构体会存储在栈上，并且通常会使用静态调度或者内联调度。

调度与对象

Swift 拥有三种类型的调度方式。Swift 会尽可能将函数内联 (inline)，这样的话使用这个函数将不会有额外的性能开销。这个函数可以直接调用。静态调度 (static dispatch) 本质上是通过 V-table 进行的查找和跳转，这个操作会花费一纳秒的时间。然后**动态调度(dynamic dispatch)**将会花费大概五纳秒的时间，如果您只有几个这样的方法调用的话，这实际上并不会带来多大的问题，问题是当您在一个嵌套循环或者执行上千次操作当中使用了动态调度的话，那么它所带来的性能耗费将成百上千地累积起来，最终影响应用性能。参考文档：
《Effective Objective-C 2.0》
《深入理解 Swift 派发机制》
《真实世界中的 Swift 性能优化》

001@了解Objective-C语言的起源