Swift内存管理
内存分配
堆
堆是完全二叉树,底层节点填充是按照从左到右的顺序进行,Swift的堆是通过双向链表实现的,由于堆可以reatin和release,所以很容易使内存不连续,采用链表的形式是为了将内存连起来,release通过链表来整合空间
Weak
Swift4.0以前是对象强引用技术为0后,看弱引用技术来决定是否保留释放对象所占用内存,如果引用计数不为0,那么内存还会保留原来的内存,知道引用计数为0才会被清理掉,,为了避免这总情况,新版Swift引入了SideTable,让对象弱引用指针指向对应的sidetable,这样做的好处是僵尸对象长期占用内存的情况,不需要保留僵尸对象,只保留引用计数和指向源对象指针内存占用空间小
栈
栈的结构比较简单只有push和pop,内存上只需要维护栈末端指针即可,
派发机制
Swift派发目的是为了让cpu知道被调用函数在哪里,Swift支持 直接派发、函数表派发、消息机制派发这三种机制。
直接派发
C++使用的是直接派发,这样做的优势是调用指令少,缺点是缺少动态性
函数表派发
Java使用的派发方式是函数表派发,通过Final修饰的方法为直接派发,而函数表派发具有动态性,一个类会用数组来存储函数指针,重写父类函数会替代以前的函数
举个例子
class Fish {
func swim() {}
func eat() {}
}
class FlyingFish: Finsh {
override func eat() {}
func fly() {}
}
编译器会给Fish和FlyingFish分别创建函数表,在Fish函数里有swim和eat函数没再FlyingFish函数里有父类Fish的Swim和覆盖了父类eat方法的函数以及新的fly函数
函数被调用有点读取对象的函数表,再根据该函数的偏移量的导函数地址在跳转到相应地址去,比直接派发慢
消息机制派发
消息机制派发是在运行时可以改变函数的行为,kvo是对这种机制的运用,oc使用的是动态派发机制,c用的是直接派发,所以c的性能高,Swift可以通过dynamic方式使其支持动态派发,当一个消息被派发程序就需要按照集成关系向上查找被调用的函数,但是这样做效率不高,所以通过缓存来提高效率,这样查找性能就和函数派发差不多了
派发使用场景
值类型使用的是直接派发
类和协议的extension是直接派发
类和协议的初始化使用的是函数表派发
@objc extension 使用的是消息机制派发
派发方式如下所示
final: 让类里的函数使用直接派发,这样该函数没有动态性程序运行也无法读取到这个函数
dynamic: 让类里的函数使用消息机制转发可以重载extension函数,
Swift会在派发上做优化,如果函数没有重载那么会用直接派发方式,如果属性绑定kvo,那么他的get set 方法可能会被优化成直接派发,从而导致kvo失效,所以需要加上dynamic来保证kvo有效。
基本数据内存管理/结构体内存管理
结构体和基本数据类型编译时就可以确定内存大小,所以程序运行时不需要额外内存空间因此函数调用就是直接传地址
内存对齐
操作系统在编译的过程中,会以结构体中成员的最大值作为其对齐的值,这是因为操作系统在数据读取的时候,其实并不是一个字节一个字节进行读取的,而是一段一段进行读取,我们假如是4bytes。假如我们要读取一个int,这个int是从第1位到第4位。那么读取的时候会发生什么事情呢?首先我们需要先读第一块数据,然后读取后三位的数据。接下来,读取第二块数据,然后只取第一位的数据。最后将两次的数据组合起来,就是我们想要的一个数据。对于操作系统来说,这种处理数据的方式并不是特别地高效。我们都知道,在计算机领域,有一个特别有名的优化手段,就是空间换时间。我们通过内存对齐,直接跳过部分空的字节,然后一次性读取所需数据。内存对齐的规则如下,基本类型的对齐值,其实就是他们的sizeof值。而结构体的对齐值,就是结构体中最大的对齐值。
那么,知道内存对齐了之后,有什么作用呢?假如我们的一个结构体有1个int,两个char, 那么不同的排列顺序,会造成结构体的大小不一致。
我们注意到,不同的排列顺序最终会让结构体占用不同的内存。虽然这些只是非常小的细节,但是在开发过程中,假如我们能够注意到这些细节,必将事半功倍。
class 内存管理
类本身实在对堆上进行分配的,在Heap上还需要保存class的Type信息,Type信息有个函数表,类的函数在派发的时候会按照函数表派发,子类需要继承父类时只要在type里记录自己信息即可
协议/泛型 内存管理
存储在一个existential container容器中,该容器的大致结构是{ heapObject, metadata, PWT }