现象
在NSObject中我们可以看到
@interface NSObject <NSObject> {
Class isa;
}
通过打印NSObject的实例对象obj的内存大小
NSObject *obj = [[NSObject alloc]init];
NSLog(@"obj对象实际需要的内存大小：%zd", class_getInstanceSize([obj class]));
NSLog(@"obj对象实际分配的内存大小： %zd",malloc_size((__bridge const void*)obj));
2020-10-26 17:38:37.109617+0800 StudyRun[5269:428841] obj对象实际需要的内存大小：8
2020-10-26 17:38:37.110370+0800 StudyRun[5269:428841] obj对象实际分配的内存大小： 16
可以看到给 NSObject的实例对象分配了16个字节(byte)的空间, NSObject内只有一个属性isa，其实也只是用到了8个字节的内存空间，剩余的8个字节在空闲.
补充一下： 在创建对象的时候，runtime只会给实例对象的成员变量分配内存空间，不会给方法分配内存空间，因为每个实例对象的方法都是一样的，分配的话过多的浪费了内存空间，方法都存放在实例对象的类对象中，在类对象中分配过一次就可以了，实例直接去查找调用即可。
发现一个是8，一个16这是为什么。malloc_size我扒拉了一下libmalloc源码，还是对对象分配至少是16的倍数，那class_getInstanceSize呢，我又扒拉了一下objc源码，找到下图的返回方法
其中WORD_MASK为7，换种写法：return (x + 7) & (~7),这个算法保证返回一定是8的倍数。这就是为什么打印上面的结果
补充：如果去计算必须保持是几的倍数(Multiple)，采用这种方式(x+(Multiple-1))&(~(Multiple-1))。采用位运算还大大提升运算效率。加上(倍数的减去1)然后位与上(倍数的减去1的取反)
class_getInstanceSize()实类对象所需要内存的大小
malloc_size()操作系统所分别的内存大小
sizeof()不是一个函数，是一个运算符 是在编译的时候就已经确定了
比如：如果打印NSLog(@"传的指针 %zd", sizeof(obj)); //此时的obj是仅仅代表一个指针变量，不是obj地址指向的NSObject的实例对象了，而我们知道指针的内存大小是8个字节，所以这个在编译的时候就确定下来的，不需要运行时再去计算的
分析
为啥obj的内存会分配到16个字节？明明只需要8个字节。
我们通过runtime的底层去搜索：
objc rootAlloc -> callAlloc - > (fastpath) objc rootAllocWithZone -> _class_createInstanceFromeZone -> instanceSize -> calloc -> initInstanceIsa 在_class_createInstanceFromeZone中，分配size的时候 instanceSize方法内 if (size < 16) size = 16; 所以一个对象的内存最少是分配16个字节
iOS64位bit操作系统分配内存的时候有他自己的字节对齐方式<有一个类似于桶sizes[Buckets sized {16,32,48,64....256}]都是16的倍数，在堆中一块一块都分配好的，匹配好直接拿来用>
iOS内存对齐
每个特定平台上的编译器都有自己的默认“对齐系数”(也叫对齐模数)。程序员可以通过预编译命令#pragma pack(n)，n=1,2,4,8,16来改变这一系数，其中的n就是你要指定的“对齐系数”。
内存对齐的规则
- 1.数据成员对齐规则：结构(struct)(或联合(union))的数据成员，第一个数据成员放在offset为0的位置，以后每个数据成员存储的位置要从min(该成员大小或者该成员子成员大小(只要该成员有子成员，比如说数据，结构体),当前平台的对齐系数)的整数倍开始地址开始存储。
- 2.结构体作为成员：如果一个结构体里有某些结构体成员，则结构体成员要从min(内部最大元素大小或者子结构体最大元素大小,当前平台的对齐系数)的整数倍地址开始存储。
- 3.收尾工作：结构体的总大小，也就是sizeof的结果，必须是min(其内部最大成员或最大子成员大小,当前平台的对齐系数)中的整数倍，不足的要补齐。
struct ZHYStruct1 {
double b; // 8 从初始位置开始排 占0~7位
int c; // 4 从4的倍数开始排 占8~11位
char a; // 1 从1的倍数开始排 占第12位
short d; // 2 从2的倍数开始排 占14~15位
} MyStruct1;
struct ZHYStruct2 {
char a; // 1 0
short b; // 2 2-3
int c; // 4 4-7
double d; // 8 8-15
} MyStruct2;
struct ZHYStruct3 {
char a; // 1 从初始位置开始排 占0位
char b; // 1 从1的倍数开始排 占1位
struct ZHYStruct1 c; //16 从8的倍数开始排 占8-23位
double d; //8 从8的倍数开始排 占24-32位
int e; //4 从4的倍数开始 占36-39位
long long f; //8 从8的倍数开始 占40-48位
} MyStruct3;
MyStruct1---16
MyStruct2---16
MyStruct3---48
经过内存对齐之后可以发现，size反而变大了。那为什么还要进行内存对齐呢？因为cpu存取内存并不是以byte为单位的，而是以块为单位，每块可以为2/4/8/16字节，每次内存存取都会产生一个固定的开销，减少内存存取次数将提升程序的性能。所以 CPU 一般会以 2/4/8/16/32 字节为单位来进行存取操作。我们将上述这些存取单位也就是块大小称为（memory access granularity）内存存取粒度。如果没有内存对齐，会大大增加cpu在存取过程中的消耗。
OC中每个属性的字节大小
| OC | 32位 | 64位 |
|---|---|---|
| bool | 1 | 1 |
| BOOL | 1 | 1 |
| char | 1 | 1 |
| short | 2 | 2 |
| int | 4 | 4 |
| flot | 4 | 4 |
| long | 4 | 4 |
| NSInteger | 4 | 8 |
| CGFloat | 4 | 8 |
| 指针 | 4 | 8 |
| double | 8 | 8 |
| long long | 8 | 8 |
再看一个例子：
struct BCStruct1 {
char a; //1
int b; //4
short c; //2
struct BCStruct2 {
int a; // 4
double b; // 8
char c; // 1
short d; // 2
}struct2;
}struct1;
这次例子是结构体嵌套结构体，他的是多少呢？我们开始:a-【0】，b-【4-7】，c-【8-9】，下面进BCStruct2，a-【12-15】，b-【16-23】，c-【24】，d-【26-27】，那是不是可以认为这个struct需要大小为28了，28跟8的倍数对比，应该是32
上面的结果是错误的，原因很简单，没有考虑内存对齐，BCStruct2开始的起止位置应该是其内部最大值8的倍数（想想苹果为什么要内存对齐，就明白了）。所以BCStruct2应该是：a-【16-19】，b-【24-31】，c-【32】，d-【34-35】此时需要大小为36，整体也要是内部最大值8的倍数，故应该是40.
由上面可知：结构体的内存对齐是按照属性排下来，但对象的内存对齐却不是的，这是因为编译器对对象内存做了优化，至于怎么优化的，上面开始的时候我们已经讲过了。
总结与思考
通过上面我们了解到这些，对象属性在存储的时候是按照属性中最大值得倍数对齐（一般为8)，而16字节对齐则是针对整个对象，为什么会这样呢？因为系统开辟的内存如果按照属性大小来分配，可能会导致内存溢出。从测试我们知道结构体内部的属性排列不同，所需要的内存大小也不同。我们在日常开发中，对属性的排列顺序是否可以注意一下，然后使其申请的内存最少，积少成多，整个项目的下来，就会优化不少。
