类的内存结构优化
WWDC2020对runtime的优化
- 视频的观看地址：https://developer.apple.com/videos/play/wwdc2020/10163/ （最好用Safari浏览器打开）
- LLVM源码地址：https://github.com/apple/llvm-project
看完视频后总结：本次改动不需要改动任何代码，也不用学习新的API，这次主要是runtime关于内存的优化。在这种环境下我们不用改APP也会运行得比之前更快更高效。
类的数据结构
在《类的探究分析》一文中就详细地解读了类的结构。在APP编译成二进制文件中，类的数据结构发生了变化，其中包含了最常被访问的信息，指向元类、父类和方法缓存的指针。以下是类的数据结构图：
类的数据结构
Clean Memory 和 Dirty Memory的区别
Clean Memory
Clean Memory指的是在程序运行中不会发生改变的内存。class_ro_t就是属于Clean Memory的，class_ro_t`内存图解：
class_ro_t数据结构
-
clean memory加载后不会发生改变的内存 -
class_ro_t就属于clean memory，因为它是只读的，不会对齐内存进行修改 -
clean memory是可以进行移除的，从而节省更多的内存空间，因为如果你有需要clean memory，系统可以从磁盘中重新加载
Dirty Memory
Dirty Memory指的是在程序运行中会发生改变的内存，也就是我们俗称的脏数据。类的结构一经使用就会变成Dirty Memory，因为运行时会向它写入新的数据。例如往类中添加方法又或者加载类的子类或父类，这里指的是class_rw_t。class_rw_t内存图解如下：
class_rw_t数据结构
-
Dirty Memory是这个类被分成两部分的原因，可以保持类加载后不会发生更改的数据越多越好，通过分离永远不会更改的数据，可以把大量的类数据存储为Clean Memory。 -
class_rw_t(读写)：类在加载的时候，属性（properties）、协议（prococols）和方法（methods）会被运行时动态的添加，也可以动态的修改（Method Swizzling）。所以类需要保存在class_rw_t中。 -
First Subclass、Next Subling Class:包含了运行时才会生成的信息First Subclass、Next Subling Class，所有的类都会变成一个树状结构，就是通过First Subclass和Next Subling Class指针实现的，它允许运行时遍历当前使用的所有类 -
Demangled Name:这个字段使用的频率是比较少的，swift中才会使用。
总结：
dirty memory要比clean memory更有价值而且要多，只要进行运行它就必须一直存在，通过分离出那些不会被改变的数据，可以把大部分的类数据存储为clean memory，这样才能不断的提高程序的性能。
class_rw_t 的优化
dirty memory在类第一次加载的时候就一直存在，runtime会为它分配额外的内存。运行时分配的存储容量时class_rw_t用于读取-编写数据，但是dirty memory中仍然存在着比较多的clean memory，为了提高空间的利用率，拆分出更多的clean memory，减少dirty memory容量是比奴可少的。
第一步：拆分出class_ro_t，即运行时不被修改的内存。如下图：
提取lass_ro_t
注意：由上图发现一个疑点，为什么方法，属性在
class_ro_t中时，class_rw_t还要有方法，属性呢？
- 属性和方法在运行时中有可能会
发生更改，这需要放在class_rw_t中。 - 在类加载的时候，可以往类中添加属性和方法。
-
class_ro_t只是可读的，需要放在class_rw_t中跟踪类的相关信息。
第二步：拆分class_rw_t，提取其中的clean memory
在读取-编写属性和方法的时候，只有10%的类都需要修改或者添加的，那么90%类可以说是不被修改的，那么就可以对class_rw_t进行拆分，拆分如下：
class_rw_t拆分
这样的话class_rw_t的大小就会减少一半，对于真的用到了被拆分出去的数据的时候，可以使用扩展(extension)来完成这些，添加到类中供其使用（大约90%的类不需要这个扩展）如下图：
优化后的结构
总结
- 当有类使用了
category的时候，那么此时的类就有了class_rw_t的结构，如果未使用分类，那么类就是一个单纯的class_ro_t的结构。 - 类结构的优化其实最要是分离出
class_ro_t和class_rw_t优化，其实就是对class_rw_t不常用的部分进行了剥离。如果需要用到这部分就从扩展记录中分配一个，滑到类中供其使用。
成员变量/实例变量和属性的区别
《类的探究分析》一文中提到了成员变量存放在class_ ro_t中，那么我们用过查找objc4源码得出下图：
实例变量存放位置
代码层面探究：
@interface XXPerson : NSObject
{
int hobby; //成员变量
NSObject *objc; //实例变量
}
@property (nonatomic,strong) NSString *name; //属性
@property (nonatomic,strong) NSString *nickName;
@property (nonatomic,assign) int age;
@end
通过xrun编译成main.cpp文件，查看底层代码：
xcrun -sdk iphonesimulator clang -arch arm64 -rewrite-objc main.m -o main-arm64.cpp (模拟器)-
xcrun -sdk iphoneos clang -arch arm64 -rewrite-objc main.m -o main-arm64.cpp (手机)
main.cpp分析
结论： - 属性在编译过程中自动加上
setter和getter方法。 - 属性在底层编译阶段会变成
_方式的成员变量。
补充
官方类型编码
官方类型编码
注意：
- 编码文档存放在Apple Documents地址
-
Objective-C不支持long double类型，@encode(long double)返回d，和double类型的编码值一样。
案例分析：
案例分析
setName（v24@0:8@16）分析结果： -
v：void，代表无返回值。 -
24：setName函数的占用字节数。 -
@：参数，id或者self。 -
0：从0号位置开始。 -
:：SEL。 -
8：从8号位置开始。 -
@：参数，setName。 -
16：从16号位置开始。
objc_setProperty与copy的关系
objc_setProperty方法相当于一个中间层方法，主要是避免了每个类都调用底层的objc_setProperty方法。当用copy关键字修饰属性时，该属性在编译时候setter方法就会从定向到objc_setProperty方法，不像其他属性·setter·方法使用首地址+内存偏移的方式找到方法实现。
示例代码：
@interface XJPerson : NSObject
@property (nonatomic,copy) NSString *name; //注意每个属性的关键字
@property (nonatomic,strong) NSString *nickName;
@property (atomic,copy) NSString *address;
@property (atomic) NSString *school;
@end
编译之后查看main.cpp，得到下图：
main.cpp源码结果
结论：
- 使用
copy关键字修饰的属性底层setter方法重定向到objc_setProperty方法 - 没使用
copy关键字修饰的属性底层setter方法通过首地址+内存偏移来寻找并实现。
LLVM验证对象属性为copy时，setter方法的访问
验证流程图：
LLVM验证流程图
LLVM源码流程：
objc_setProperty -> getSetPropertyFn -> GetPropertySetFunction -> PropertyImplStrategy -> IsCopy(判断copy关键字)结论：无论属性是否是原子性还是非原子性的，用到copy关键字修饰的属性setter方法底层都用
objc_setProperty实现，strong关键字无法通过最后得判断，需要通过首地址+内存偏移的方式实现。
总结：
底层代码的分析需要很好的耐心，过程也是非常的枯燥。但是当你弄明白了原理之后，就会发现知识是环环相扣的。非常高兴自己又多了一分收获，加油！
