写在开头

缘于上篇文章OC底层-对象的alloc流程探究，在联想的时候想到了内存对齐，又查看了很多关于OC内存对齐的文章，感觉信息量还是挺大的，笔者决定自己下手一探究竟。

字节对照表

C	OC	32	64
bool	BOOL (64位)	1	1
signed char	(_ _signed char)int8_t、 BOOL(32位)	1	1
unsigned char	Boolean	1	1
short	int16_t	2	2
unsigned short	unichar	2	2
int int32_t	NSInteger(32位) 、boolean_t(32位)	4	4
unsigned int	NSUInteger(32位) 、boolean_t(64位)	4	4
long	NSInteger(64位)	4	8
unsigned long	NSUInteger(64位)	4	8
long long	int64_t	8	8
float	CGFloat(32位)	4	4
double	CGFloat(64位)	8	8

类的对象内存排列

创建自定义类MuPerson

@interface MuPerson : NSObject

@property (nonatomic, copy) NSString *name;
@property (nonatomic, copy) NSString *nickName;
@property (nonatomic, copy) NSString *gender;

@end

给对象赋值，进行打印内存地址如下，

int main(int argc, char * argv[]) {
    NSString * appDelegateClassName;
    @autoreleasepool {
        // Setup code that might create autoreleased objects goes here.
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
        
        
        MuPerson *person = [MuPerson alloc];
        person.name      = @"Qianxiaomu";
        person.nickName  = @"mu";
        person.gender = @"male";


        NSLog(@"%@",person);
        
        
    }
    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}
2020-09-09 09:09:49.752767+0800 Mu[2668:38094] <MuPerson: 0x6000001ff700>
(lldb) x 0x6000001ff700
0x6000001ff700: d0 50 26 00 01 00 00 00 a0 40 26 00 01 00 00 00  .P&......@&.....
0x6000001ff710: c0 40 26 00 01 00 00 00 e0 40 26 00 01 00 00 00  .@&......@&.....
(lldb) x/4gx 0x6000001ff700
0x6000001ff700: 0x00000001002650d0 0x00000001002640a0
0x6000001ff710: 0x00000001002640c0 0x00000001002640e0
(lldb) x/6gx 0x6000001ff700
0x6000001ff700: 0x00000001002650d0 0x00000001002640a0
0x6000001ff710: 0x00000001002640c0 0x00000001002640e0
0x6000001ff720: 0x00007fff87b354d8 0x00007fe3d400b600
(lldb) po 0x00000001002650d0
MuPerson

(lldb) po 0x00000001002640a0
Qianxiaomu

(lldb) po 0x00000001002640c0
mu

(lldb) po 0x00000001002640e0
male

从lldb调试的信息可以看到，在给对象赋值后，我分别用x、x/4gx、x/6gx对person对象进行地址打印，从拿到的地址中进行po,可以清晰的看到isa指针以及各个属性。因为添加的属性都是NSString，我们可以看到每个属性都是占了8字节。这种情况的内存排列如下图

MuPerson内存排列01.png

因为刚才添加的都是NSString，这里我添加了多个不同的类型属性如下

@interface MuPerson : NSObject

@property (nonatomic, copy) NSString *name;
@property (nonatomic, copy) NSString *nickName;
 @property (nonatomic, copy) NSString *gender;
@property (nonatomic, assign) int age;
@property (nonatomic, assign) long height;

@property (nonatomic) char c1;
@property (nonatomic) char c2;

@end

int main(int argc, char * argv[]) {
    NSString * appDelegateClassName;
    @autoreleasepool {
        // Setup code that might create autoreleased objects goes here.
        appDelegateClassName = NSStringFromClass([AppDelegate class]);
        
        MuPerson *person = [MuPerson alloc];
        person.name      = @"Qianxiaomu";
        person.nickName  = @"mu";
        person.gender = @"male";
        person.age       = 26;
        person.c1        = 'a';
        person.c2        = 'b';


        NSLog(@"%@",person);
 
    }
    return UIApplicationMain(argc, argv, nil, appDelegateClassName);
}

这里的打印结果就跟上次不一样了，我用截图的方式来分析下这种情况下属性的内存排列

当我们打印isa指针的时候，还是正常的，继续往下打印8个字节的内存，我发现是乱码，先留着，后续打印出了三个NSString对象是正常的。回过头我们来分析，有没有可能这个8字节把我们的int年龄和2个char属性都装进去了，4+2+2刚好是8，不会这么巧吧。拆分打印一探究竟，结果和笔者猜想的一模一样。先把这种情况的内存分析贴出来。 MuPerson内存排列02.png

思考

问题来了，我们的内存不是对齐向下的吗？为什么属性会出现在这里？
查询资料后恍然大悟，原来是系统对内存对齐的优化重排，我们在对齐的同时也不能浪费已经开辟的空间。

验证

如何验证，因为类的在OC底层实际上结构体的形式，笔者决定去结构体的内存对齐一探究竟

struct MuStruct1 {
    double a; //8
    char b;  //1
    int c;   //4
    short d; //2
}struct1;
struct MuStruct2 {
    double a; //8
    int b;    //4
    char c;   //1
    short d;  //2
}struct2;
NSLog(@"%lu-%lu",sizeof(struct1),sizeof(struct2));

2020-09-09 10:04:37.712801+0800 Mu[2978:62419] 24-16

结构体对齐原则

1、数据成员对⻬规则：结构(struct)(或联合(union))的数据成员，第一个数据成员放在offset为0的地方，以后每个数据成员存储的起始位置要从该成员大小或者成员的子成员大小(只要该成员有子成员，比如说是数组，结构体等)的整数倍开始（比如int为4字节,则要从4的整数倍地址开始存储）。

2、结构体作为成员：如果一个结构里有某些结构体成员,则结构体成员要从其内部最大元素大小的整数倍地址开始存储.(struct a里存有struct b,b里有char,int ,double等元素,那b应该从8的整数倍开始存储.)

3、收尾工作：结构体的总大小，也就是sizeof的结果，必须是其内部最大成员的整数倍，不足的要补⻬

这里对struct1,struct2的内存分析也做了图

结构体内存分析.png

结构体内存三步走总结

1. 存放数据的起始位置是数据成员字节的整数倍
2. 找到最大字节数的成员
3. 结构体总大小是最大成员字节数的整数倍

熟悉了对齐规则，我又尝试了结构体嵌套结构体的情况如下

struct MuStruct1 {
    double a; //8
    char b;   //1
    int c;    //4
    short d;  //2
}struct1;
struct MuStruct2 {
    double a;//8
    int b;   //4
    char c;  //1
    short d; //2
    struct MuStruct1  e;
}struct2;
NSLog(@"%lu-%lu",sizeof(struct1),sizeof(struct2));

2020-09-09 10:05:13.686632+0800 Mu[2995:63088] 24-40

这里注释掉一个小属性，继续验证总结的规律

struct MuStruct1 {
    double a;  //8
    char b;    //1 
    int c;     //4
    //short d; //2
}struct1;
struct MuStruct2 {
    double a; //8
    int b;    //4
    char c;   //1
    short d;  //2
    struct MuStruct1  e;
}struct2;
NSLog(@"%lu-%lu",sizeof(struct1),sizeof(struct2));

2020-09-09 10:05:53.140186+0800 Mu[3009:63639] 16-32

这里就不画图分析了，只要掌握了三步走的原则，只需要验证答案就行了。

探究过程的细节思考和知识联想

1. 内存对齐原则其实是系统在用空间换取时间。
2. 内存优化，从结构体中我们可以看到相同的成员排列方式的不同就会造成开辟空间的大小不同。如果我们合理去使用这些空间，就不会造成不必要的浪费。而系统正是做了这部分的工作。这里猜想下结构体数据成员是字节大的在前排列好还是字节小的在前排列好，答案应该是字节大的在前排列更优雅，因为字节大的在前我们需要的补位padding就会少很多。
3. 我们回到类的对象在看，系统在为对象开辟空间的时候，对象实际上需要的是8个字节以及更少，但OS系统最为更长远的考虑，防止容错采用了16字节对齐。
   我们可以假想一下，两个对象的内存很紧凑的挨着，访问的时候会不会访问到另一个对象的首地址isa指针。