Swift教程

iOS 14 苹果对 Objective-C Runtime 的优化

本文主要是介绍iOS 14 苹果对 Objective-C Runtime 的优化,对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

作者:Damien,iOS 开发者。目前就职于携程。

Session:developer.apple.com/wwdc20/1016…

概述

Objective-C 是一门古老的语言,诞生于 1984 年,跟随 Apple 一路浮沉,见证了乔布斯创建了 NeXT,也见证了乔布斯重回 Apple 重创辉煌,它用它特立独行的语法,堆砌了 UIKit,AppKit, Foundation 等一个个基石,时间来到 2020 年,面对汹涌的"后浪" Swift,"老前辈" Objective-C 也在发挥着自己的余热,即使面对越来越多阵地失守,唯有“老兵不死,只会慢慢凋亡"才能体现的悲壮。今年,Apple 给 Objective-C Runtime 带来了新的优化,接下来,让我们深入理解这些变化。

类数据结构变化

首先我们先来了解一下二进制类在磁盘中的表示

首先是类对象本身,包含最常访问的信息:指向元类,超类和方法缓存的指针,在类结构之中有指向包含更多数据的结构体class_ro_t的指针,包含了类的名称,方法,协议,实例变量等等编译期确定的信息。其中 ro 表示 read only 的意思。

当类被 Runtime 加载之后,类的结构会发生一些变化,在了解这些变化之前,我们需要知道2个概念: **Clean Memory:**加载后不会发生更改的内存块,class_ro_t属于Clean Memory,因为它是只读的。 **Dirty Memory:**运行时会进行更改的内存块,类一旦被加载,就会变成Dirty Memory,例如,我们可以在 Runtime 给类动态的添加方法。

这里要明确,Dirty MemoryClean Memory要昂贵得多。因为它需要更多的内存信息,并且只要进程正在运行,就必须保留它。对于我们来说,越多的Clean Memory显然是更好的,因为它可以节约更多的内存。我们可以通过分离出永不更改的数据部分,将大多数类数据保留为Clean Memory,如何怎么做的呢? 在介绍优化方法之前,我们先来看一下,在类加载之后,类的结构会变成如何呢?

在类加载到 Runtime 中后会被分配用于读取/写入数据的结构体class_rw_t

Tips:class_ro_t是只读的,存放的是编译期间就确定的字段信息;而class_rw_t是在 runtime 时才创建的,它会先将class_ro_t的内容拷贝一份,再将类的分类的属性、方法、协议等信息添加进去,之所以要这么设计是因为 Objective-C 是动态语言,你可以在运行时更改它们方法,属性等,并且分类可以在不改变类设计的前提下,将新方法添加到类中。

事实证明,class_rw_t会占用比class_ro_t占用更多的内存,在 iPhone 中,我们在系统测量了大约 30MB 的这些class_rw_t结构。应该如何优化这些内存呢?通过测量实际设备上的使用情况,我们发现大约 10% 的类实际会存在动态的更改行为,如动态添加方法,使用 Category 方法等。因此,我们能可以把这部分动态的部分提取出来,我们称之为class_rw_ext_t,所以,结构会变成这个样子。

经过拆分,可以把 90% 的类优化为Clean Memory,在系统层面,取得效果是节省了大约 14MB 的内存,使内存可用于更有效的用途。

Tips:heap xxxxx | egrep 'class_rw|COUNT’ 你可以使用此命令来查看 class_rw_t 消耗的内存。xxxx可以替换为需要测量的 App 名称。如:heap Mail | egrep 'class_rw|COUNT’\'查看 Mail 应用的使用情况。

相对方法地址

现在,我们来看看 Runtime 的第二处的变化,方法地址的优化。 每个类都包含一个方法列表,以便 Runtime 可以查找和消息发送。结构大概如下图所示:

方法包含了3部分的内容:

  • Selector:方法名称或选择器。选择器是字符串,但是它们是唯一的
  • 方法类型编码:方法类型编码标识(详情可以查看参考链接)
  • IMP:方法实现的函数指针

在 64 位系统中,它们占用了 24 字节的空间

了解了方法的结构之后,我们来看下进程中内存的简化视图

这是一个 64 位的地址空间,其中各种块分别表示了栈,堆以及各种库。我们把焦点放在 AppKit 库中的init方法。

如图所示,图中的3个地址分别为方法的 3 个部分的表示的绝对地址,我们知道,库的地址取决于动态链接库加载之后的位置,ASLR(Address space layout randomization 地址空间布局随机化)的存在,动态链接器需要修正真实的指针地址,这也是一种代价。由于方法实现地址不会脱离当前库的地址范围的特性存在,所以实际上,方法列表并不需要使用 64 位的寻址范围空间。他们只需要能够在自己的库地址中查找引用函数地址即可,这些函数将始终在附近。所以我们可以使用 32 位相对偏移来代替绝对 64 位地址。

现在我们地址将变成这样

这么做有几个优点:

  1. 无论将库加载到内存中的任何位置,偏移量始终是相同的,因此从加载后不需要进行修正指针地址。
  2. 它们可以保存在只读存储器中,这会更加的安全。
  3. 使用 32 位偏移量在 64 位平台上所需的内存量减少了一半。在 iPhone 中我们可以节省约 40MB 的内存大小。

优化后,指针所需的内存占用量可以减少一半。

相对方法地址会引发另外一个问题,那就是在Method Swizzling如何处理呢?众所皆知,Method Swizzling替换的是 2 个方法函数指针指向,方法函数实现可以在任意地方实现,使用了相对偏移地址了之后,这样就无法工作了。 针对Method Swizzling我们使用全局映射表来解决这个问题,在映射表中维护Swizzles方法对应的实现函数指针地址。由于Method Swizzling的操作并不常见,所以这个表不会变得很大,新的Method Swizzling机制如下图。

Tagged Pointer 格式的变化

接下来我们会深入了解 Tagged Pointer 在 ARM CPU 下的格式变化 首先,让我们先来了解下 Tagged Pointer 是什么 **Tagged Pointer:**一种特殊标记的对象,Tagged Pointer 通过在其最后一个 bit 位设置为特殊标记位,并且把数据直接保存在指针本身中。Tagged Pointer 是一个"伪"对象,使用 Tagged Pointer 有 3 倍的访问速度提升,100 倍的创建、销毁速度提升。

Tips:Advances in Objective-C

在我们查看对象指针时,在 64 位系统中,我们会看到 16 进制地址如0x00000001003041e0,我们把它转换为二进制表示如下图

在 64 位系统中,我们有 64 位可以表示一个对象指针,但是我们通常没有真正使用到所有这些位,由于内存对齐要求的存在,低位始终为0,对象必须始终位于指针大小倍数的地址中。高位也始终为0。实际上我们只是用中间这一部分的位。
因此,我们可以把最低位设置为 1,表示这个对象是一个 Tagged Pointer 对象。设置为 0 则表示为正常的对象
在设置为 1 表示为 Tagged Pointer 对象之后,在最低位之后的 3 位,我们给他赋予类型意义,由于只有 3 位,所以它可以表示 7 种数据类型

OBJC_TAG_NSAtom            = 0, 
OBJC_TAG_1                 = 1, 
OBJC_TAG_NSString          = 2, 
OBJC_TAG_NSNumber          = 3, 
OBJC_TAG_NSIndexPath       = 4, 
OBJC_TAG_NSManagedObjectID = 5, 
OBJC_TAG_NSDate            = 6, 
OBJC_TAG_7                 = 7
复制代码

在剩余的字段中,我们可以赋予他所包含的数据。在 Intel 中,我们 Tagged Pointer 对象的表示如下

OBJC_TAG_7类型的 Tagged Pointer 是个例外,它可以将接下来后 8 位作为它的扩展类型字段,基于此我们可以多支持 256 中类型的 Tagged Pointer,如 UIColors 或 NSIndexSets 之类的对象。

上文中,我们介绍的是在 Intel 中 Tagged Pointer 的表示,在 ARM64 中,我们情况有些变化。

我们使用最高位代表 Tagged Pointer 标识位,最低位 3 位标识 Tagged Pointer 的类型,接下去的位来表示包含的数据(可能包含扩展类型字段),为什么我们使用高位指示 ARM上 的 Tagged Pointer,而不是像 Intel 一样使用低位标记?

它实际是对 objc_msgSend 的微小优化。我们希望 msgSend 中最常用的路径尽可能快。最常用的路径表示普通对象指针。我们有两种不常见的情况:Tagged Pointer 指针和 nil。事实证明,当我们使用最高位时,可以通过一次比较来检查两者。与分别检查 nil 和 Tagged Pointer 指针相比,这会为 msgSend 中的节省了条件分支。

总结

在 2020 年中,Apple 针对 Objective-C 做了三项优化

  • 类数据结构变化:节约了系统更多的内存。
  • 相对方法地址:节约了内存,并且提高了性能。
  • Tagged Pointer 格式的变化:提高了 msgSend 性能。

通过优化,希望大家可以享受 iPhone 更好,更快的使用体验。

Tips: 类结构的数据变更会在最新的 Runtime 版本中体现,实测 MacOS 10.5.5 中已经存在。 相对方法地址的优化在 Xcode developmentTarget > 14 时会自动进行处理。 Tagged Pointer 的变化则会在 iOS 14, MacOS Big Sur, iPadOS 14 上生效。

参考链接

TypeEncodeing

Lets build Tagged Pointers

Advances in Objective-C

限时福利

这篇文章的内容来自于 《WWDC20 内参》。在这里给大家推荐一下这个专栏。

「WWDC 内参」系列是由老司机周报、知识小集合以及 SwiftGG 几个技术组织发起的。已经做了几年了,口碑一直不错。主要是针对每年的 WWDC 的内容,做一次精选,并号召一群一线互联网的 iOS 开发者,结合自己的实际开发经验、苹果文档和视频内容做二次创作。

今年一共有 213 个 Session 的内容。《WWDC20 内参》挑选了其中的 135 个 Session,短短两周,已经创作了 83 篇文章。目前正在限时优惠销售,只需要 9.9 元,十分优惠。

看了文章还不过瘾的朋友,抓紧订阅 《WWDC20 内参》 xiaozhuanlan.com/wwdc20 继续阅读把~

关注我们

我们开通了公众号「老司机技术周报」,每期发布时公众号(LSJCoiding)会推送消息,欢迎关注。

这篇关于iOS 14 苹果对 Objective-C Runtime 的优化的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!