Swift 5.0的Runtime机制浅析

也许你会觉得这不是一个最优的解决方案，而且如果当再次出现一个派生类时，还会继续增加条件分支的判断。 这是一个多么低级的优化啊!但是为什么还是要这么做呢?个人觉得还是性能和包大小的问题。对于性能来说如果我们通过间接调用的形式可能需要增加更多的指令以及进行间接的寻址处理和指令跳转，而如果采用简单的类型判断则只需要更少的指令就可以解决多态调用的问题了，这样性能就会得到提升。至于第二个包大小的问题这里有必要重点说一下。

编译链接优化的一个非常重要的能力就是减少程序的体积，其中一个点即是链接时如果发现某个一个函数没有被任何地方调用或者引用，链接器就会把这个函数的实现代码整体删除掉。这也是符合逻辑以及正确的优化方式。回过头来Swift函数调用的虚函数表方式，因为根据虚函数表的定义需要把一个类的所有方法函数地址都存放到类的虚函数表中，而不管类中的函数是否有被调用或者使用。而通过虚函数表的形式间接调用时是无法在编译链接时明确哪个函数是否会被调用的，所以当采用虚函数表时就不得不把类中的所有方法的实现都链接到可执行程序中去，这样就有可能无形中增加了程序的体积。而前面提供的当编译链接优化打开后，系统尽可能的对对象的方法调用改为内联，同时对多态的支持改为根据类型来进行条件判断处理，这样就可以减少对虚函数表的使用，一者加快了程序运行速度，二者删除了程序中那些永远不会调用的代码从而减少程序包的体积。但是这种减少包体积的行为又因为内联的引入也许反而增加了程序包的体积。而这二者之间的平衡对于链接优化器是如何决策的我们就不得而知了。

综上所述，在编译器优化模式下虚函数调用的间接模式改变为直接模式了，所以我们几乎很难在运行时通过修改虚表来实现方法调用的替换。而且Swift本身又不再支持运行时从方法名到方法实现地址的映射处理，所有的机制都是在编译时静态决定了。正是因为Swift语言的特性，使得原本在OC中可以做的很多事情在Swift中都难以实现，尤其是一些公司的无痕埋点日志系统的建设，APM的建设，以及各种监控系统的建设，以及模拟系统的建设都将失效，或者说需要寻找另外一些途径去做这些事情。对于这些来说，您准备好了吗?

本文的结论是在Swift5中通过程序运行时观察汇编代码所得出的结论。为了能让大家更好的理解，我将大部分代码翻译为了用C语言伪代码来实现。因为没有参考任何官方文档，所以难免可能有一些错误的描述，欢迎大家指正批评。

（编辑：晋中站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!