2020 WWDC 大会 iOS 变化记录（一）—— 数据结构的变化

一、前言

去年 2020 年的 WWDC 大会时，因为我英语也不太好，我就边看录播边用谷歌翻译着，记录了一下这次会议的一些跟我们开发者有关的变化点。一直没有整理发出来，这次想着把这个记录发一下，不然 2021 的 WWDC 大会都要开始了。
变化点主要有三点，这篇主要讲一下第一点，“数据结构的变化”（Class data structures changes）

二、数据结构的变化

1、"clean memory" 和 "dirty memory"

先理解两个名词，"clean memory" 和 "dirty memory"，字面意思就是 “干净内存” 和 “脏内存”。

• clean memory 是指加载后不会发生改变的内存。
  class_ro_t 就属于clean memory， 因为它是只读的（ro 代表 readonly）
• dirty memory 是指在进程运行时会发生更改的内存，class_rw_t 是 dirty memory(rw 代表 read write)

在 objc4750 的源码中我们可以看到 class_rw_t 的结构，如下图：

class_ro_t 的结构，如下图：

类结构一经使用就会变成 dirty memory，因为运行时会向它写入新的数据，例如创建一个新的方法缓存并从类中指向它。
dirty memory 比 clean memory 要昂贵得多，只要进程在运行，它就必须一直存在。另一方面 clean memory 可以进行移除，从而节省更多的内存空间。因为如果你需要 clean memory，系统可以从磁盘中重新加载。macOS 可以选择换出 dirty memory，但因为 iOS 不使用 swap，所以 dirty memory 在 iOS 中代很大。

dirty memory 是这个类数据被分成两部分的原因，可以保持清洁的数据越多越好，通过分离出那些永远不会更改的数据，可以把大部分的类数据存储为 clean memory。虽然这些数据足以让我们开始，但运行时需要追踪每个类的更多信息，所以当一个类首次被使用，运行时会为它分配额外的存储容量，这个运行时分配的存储容量是 class_rw_t，用于读取-编写数据。在这个数据结构中，我们存储了只有在运行时才会生成的新信息。

例如，所有的类都会链接成一个树状结构，这是通过 First Subclass 和 Next Sibling Class 指针实现的。这允许运行时遍历当前使用的所有类，这对于使方法缓存无效非常有用。
但为什么方法和属性也在只读数据中时，我们这里还要有方法和属性呢？

因为他们可以在运行时进行更改。当 category 被加载时，它可以向类中添加新的方法，而且程序员可以使用运行时 API 动态地添加它们。因为 class_ro_t 是只读的，所以我们需要在 class_rw_t 中追踪这些东西。
现在，结果是这样做会占用相当多的内存。在任何给定的设备中都有许多类在使用，我们再 iPhone 上的整个系统中测量了大约 30 兆字节这些 class_rw_t 结构，那么我们如何缩小这些结构呢？记住，我们在读取-编写部分需要这些东西，因为它们可以在运行时进行更改。但是通过检查实际设备上的使用情况，大约只有 10% 的类真正地更改了它们的方法。而且只有 Swift 类会使用这个 demangled name 字段，并且 Swift 类并不需要这一字段，除非有东西询问它们的 Object-C 名称时才需要。

2、变化 —— 拆出了 class_rw_ext_t

所以，我们可以拆掉那些平时不用的部分，这将 class_rw_t 的大小减少了一半。拆出来的部分叫做 “class_rw_ext_t”，如下图所示：

这个 “class_rw_ext_t” 我们可以在最新的源码 objc4-818.2 中看到：

struct class_rw_ext_t {
    DECLARE_AUTHED_PTR_TEMPLATE(class_ro_t)
    class_ro_t_authed_ptr ro;
    method_array_t methods;
    property_array_t properties;
    protocol_array_t protocols;
    char *demangledName;
    uint32_t version;
};

对于那些确实需要额外信息的类，我们可以分配这些扩展记录中的一个，并把它滑到类中供其使用。

大约 90% 的类从来不需要这些扩展数据，这在系统范围内可节省大约14MB 的内存，这些内存现在可用于更有效的途径，比如存储你的 app 的数据。
因此，实际上你可以在你的 Mac 上看到这一变化带来的影响，这只需要在终端上运行一些简单的命令，现在让我们一起来看一下。
打开 MacBook 的终端，运行一个在任何 Mac上都可用的命令，叫做“heap”，它允许你检查正在运行的进程所使用的堆内存。我将在 Mac 中的 Mail app 上运行它，首先先打开 “邮件” 程序，

现在，如果我运行 heap Mail 命令，它会输出数千行，显示通过邮件进行的每个堆分配，所以我只要 grep 它为我们今天一直在讨论的 class_rw_t 类型，我还需要查询标头

heap Mail | egrep ‘class_rw|COUNT’

从返回的结果中，可以看到，我们在邮件 app 中使用了大概 9000 个这样的 class_rw_t 类型，但其中只有大约十分之一，900 多一点实际上需要使用这一扩展信息。所以，我们可以很容易地计算出通过这个改变所节省的内存，这是大小减半的类型。

所以，如果我们从这个数字 “152320” 中减去我们必须分配给扩展类型的内存量 ”21600”，我们可以看到我们节省了大约 1 兆字节数据的四分之一，这还只是对于邮件 app 而言。如果我们在系统范围内进行扩展，对 dirty memory 而言，这是真正的节省内存。

3、要用官方 API

现在，很多从类中获取数据的代码，必须同时处理那些有扩展数据和没有扩展数据的类，当然运行时会为你处理这一切，并且从外部看，一切都像往常一样工作，只是使用更少的内存。之所以会这样，是因为读取这些结构的代码，都在运行时内并且还会同时进行更新。坚持使用这些 API 真的很重要，因为任何试图直接访问这些数据结构的代码都将在今年的 OS 版本中停止工作，因为东西已经发生了改变，而且该代码不知道新的布局。我们看到，一些真实的代码由于这些变化而崩溃，除了你自己的代码之外，还要注意那些外部依赖性，你可能正把他们带入到你的 app 中，它们可能会在你没有意识到的情况下挖掘这些数据结构。这些结构中的所有信息都可通过官方API获得。

有一些函数，如 class_getName 和 class_getSuperclass，当你使用这些 API 访问信息时，你知道，无论我们在后台进行什么更改，他们都将继续工作。所有的 API 都可以在 Objective-C 运行时说明文档中找到
class_getName
class_getSuperclass
class_copyMethodList
而这个文档在 developer.apple.com 中。

接下来，让我们更深入地了解一下这些类的数据结构，并看看另一个变化，Relative method lists 相对方法列表。
下一章我会继续总结，敬请期待！

以上的我写的内容是根据：2020 WWDC 大会视频 总结记录的，想看原视频的可以前去观看。

转载请备注原文出处，不得用于商业传播——凡几多