swift 该死的派发机制--待完成

swift 该死的派发机制

final static

oc类型 多态类型 静态类型 动态函数  静态函数

nsobject:

1、缺省不再使用oc的动态派发机制;

2、可以使用nsobject暴露出来的接口函数;

3、其它行为与swift的class一样;

多态类型:class与protocol

静态类型:值类型;

所有的函数都是静态绑定函数;

动态函数:

1、多态类型的函数

2、扩展中oc修饰的函数;

static与class 都有类型成员的含义;相对于实例成员;

static的另一个意思是静态派发;所以不能被继承。

要使用动态派发和继承的机制必须使用class继承。

https://www.cnblogs.com/feng9exe/p/10497659.html

@objc vs @objc dynamic官方解释

Overriding non-@objc declarations from extensions is not supported

There are two keywords to keep in mind when dealing with interoperability:

  • @objc means you want your Swift code (class, method, property, etc.) to be visible from Objective-C.
  • dynamic means you want to use Objective-C dynamic dispatch.

swift 该死的派发机制--待完成

https://www.cnblogs.com/feng9exe/p/9460336.html

理解Swift的性能

理解Swift的性能,首先要清楚Swift的数据结构,组件关系和编译运行方式。

  • 数据结构

Swift的数据结构可以大体拆分为:Class,Struct,Enum。

  • 组件关系

组件关系可以分为:inheritance,protocols,generics。

  • 方法分派方式

方法分派方式可以分为Static dispatch和Dynamic dispatch。

https://www.cnblogs.com/feng9exe/p/10310050.html

Existential Container

Existential Container是一种特殊的内存布局方式,用于管理遵守了相同协议的数据类型Protocol Type,这些数据类型因为不共享同一继承关系(这是V-Table实现的前提),并且内存空间尺寸不同,使用Existential Container进行管理,使其具有存储的一致性。

swift 该死的派发机制--待完成

Existential Container的构成

结构如下:

  • 三个词大小的valueBuffer 这里介绍一下valueBuffer结构,valueBuffer有三个词,每个词包含8个字节,存储的可能是值,也可能是对象的指针。对于small value(空间小于valueBuffer),直接存储在valueBuffer的地址内, inline valueBuffer,无额外堆内存初始化。当值的数量大于3个属性即large value,或者总尺寸超过valueBuffer的占位,就会在堆区开辟内存,将其存储在堆区,valueBuffer存储内存指针。
  • value witness table的引用 因为Protocol Type的类型不同,内存空间,初始化方法等都不相同,为了对Protocol Type生命周期进行专项管理,用到了Value Witness Table。
  • protocol witness table的引用 管理Protocol Type的方法分派。

内存分布如下:

Protocol Witness TablePWT

为了实现Class多态也就是引用语义多态,需要V-Table来实现,但是V-Table的前提是具有同一个父类即共享相同的继承关系,但是对于Protocol Type来说,并不具备此特征,故为了支持Struct的多态,需要用到protocol oriented programming机制,也就是借助Protocol Witness Table来实现(细节可以点击Vtable和witness table实现,每个结构体会创造PWT表,内部包含指针,指向方法具体实现)。

swift 该死的派发机制--待完成

Point and Line PWT

Value Witness TableVWT

用于管理任意值的初始化、拷贝、销毁。

swift 该死的派发机制--待完成

VWT use existential container

  • Value Witness Table的结构如上,是用于管理遵守了协议的Protocol Type实例的初始化,拷贝,内存消减和销毁的。
  • Value Witness Table在SIL中还可以拆分为%relative_vwtable和%absolute_vwtable,我们这里先不做展开。
  • Value Witness Table和Protocol Witness Table通过分工,去管理Protocol Type实例的内存管理(初始化,拷贝,销毁)和方法调用。

https://www.cnblogs.com/feng9exe/p/10310050.html

Revealed in more detail in Session 416 of WWDC 2016, the container is a wrapper around parameters adhering to a protocol and is used non-generically. The container functions as a box of fixed size (we’ll get back to this in a sec), thus allowing all adherers of a protocol to be of the same size, which is necessary for them to be used interchangeably.

var vehicles: [Drivable]

The fixed size of the container also allows us to store classes/structs that adhere to a protocol in an array of type protocol (as seen above), since the elements are now of the same size and can be stored in contiguous memory.

https://www.cnblogs.com/feng9exe/p/10309983.html

@dynamicMemberLookup

https://www.cnblogs.com/feng9exe/p/9959824.html

These instructions perform dynamic lookup of class and generic methods.

The class_method and super_method instructions must reference Swift native methods and always use vtable dispatch.

The objc_method and objc_super_method instructions must reference Objective-C methods (indicated by the foreignmarker on a method reference, as in #NSObject.description!1.foreign).

https://www.cnblogs.com/feng9exe/p/9682336.html

上一篇:解決 centos -bash: vim: command not found


下一篇:Python基础之-----------函数