iOS底层原理(二) 对象的内存对齐

对象的内存分布

今天我们来研究一下对象的内存对齐,首先我们定义一个Person类:

@interface Person : NSObject

@property (nonatomic, copy)   NSString *name;
@property (nonatomic, assign) int age;
@property (nonatomic, assign) double height;
@property (nonatomic, assign) BOOL sex;
@property (nonatomic, strong) NSString *hobby;

@end

@implementation Person

@end

我们可以通过 lldb 来观察 Person 对象在内存中的分布。

        Person *person = [[Person alloc] init];
        person.name = @"leeyii";
        person.age = 18;
        person.height = 180;
        person.hobby = @"女";
        person.sex = true;

通过 lldb 命令 x 读取内存内容,在 lldb 控制台输入 x/6gx person 来查看 对象 person 的内容:

接着输入 po 0x0000000109d86780 结果为

这个表示对象的 isa,储存对象的 Class 相关信息,这里就不展开讨论,后面会进行深入研究。

接着输入 po 0x0000001200000001

打印乱码。

让我们来仔细观察一下 0x0000001200000001 这个能够分成两个部分 0x00000012 对应10进制数正好是 180x00000001 对应 bool 为 true, 和我们定义的 agesex 正好对应。

接着输入 po 0x0000000109d840a0

打印出来了 name

接着打印 0x4066800000000000,这一部分不能再使用 po 进行打印了,因为我们定义的 heightdouble 类型, 打印 double 类型,要使用 p/f

打印出来的正是我们的 height

接着打印的应该是我们 hobby

打印结果正如我们猜测的一样。

通过 clang 验证

我们通过 lldb 读取内存的方式找到了定义的属性的值,但是会发现内存中属性的分布和我们属性定义的顺序并不一致。

接下来我们通过 clang 来证明刚才的结果并不是巧合。

打开命令行,进入到源文件所在目录,输入命令 clang -x objective-c -rewrite-objc -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk main.m 会得到一个 main.cpp 文件,在这个文件中,我们可以找到 Person 类的底层实现

struct Person_IMPL {
    struct NSObject_IMPL NSObject_IVARS;
    BOOL _sex;
    int _age;
    NSString *_name;
    double _height;
    NSString *_hobby;
};

实际上在 oc 中的通过编译,都会在底层产生一个对应的结构体。

通过上面的定义能够发现除了 sexage 和我们刚才输出的顺序不一样之外, 其他属性的内存分布和我们上面结论是相同。

出现上面的原因是因为在iOS设备中使用的是小端模式:低字节存放低位,我们打印出的结果为了便于我们查看,实际上是倒序展示的,我们可以通过 x 0x6000010ffab8 按字节序查看 sexage 在内存中的分布

内存优化重排

为什么在底层的结构体中变量的顺序和我们在类中定义的顺序不一样呢?

出现这种情况的原因是因为在编译的过程中进行了内存优化重排,属性不同的排列顺序对结构体占用内存的大小是不一样的。通过优化重排,能够减少内存的占用。

结构体内存对齐

在开始之前我们先来看一个例子,这里声明了两个结构体:


// 结构体1
struct Sturct1 {
    double  a;  // 8字节
    char    b;  // 1字节
    int     c;  // 4字节
    short   d;  // 2字节
} struct1;

// 结构体2
struct Struct2 {
    char    a;  // 1字节
    short   b;  // 2字节
    int     c;  // 4字节
    double  d;  // 8字节
} struct2;

上面两个结构体占用的内存应该是多少呢?我们来打印一下。

    NSLog(@"Struct1占用内存大小: - %lu", sizeof(struct1));
    NSLog(@"Struct2占用内存大小: - %lu", sizeof(struct2));

接下来我们来看一下输出的内容:

Struct1占用内存大小: - 24
Struct2占用内存大小: - 16

上面两个结构体明明差别不大,变量类型都是一样的,区别仅在于两个结构体的定义变量的顺序不一致

内存对齐规则

  1. 数据成员对齐规则:结构体的数据成员,第一个数据成员放在offset为0的地方,以后每个成员储存的起始位置都要该改成员大小或者成员的子成员大小(只要该成员有子成员,比如数组,结构体等)的整数倍开始。
  2. 结构体作为成员:如果一个结构体里有某些结构体成员,则结构体成员要从其内部最大元素的整数倍开始存储。
  3. 收尾工作: 结构体的总大小,也就是 sizeof 的结构,必须是其内部的最大成员的整数倍。不足要补齐。

根据上面的规则,我们依次分析 struct Sturct1struct Sturct2 内存分布。

struct Sturct1 内存大小计算

double a 占用 8字节 内存, 从 offset -> 0 开始储存, 此时 offset -> [0, 7] 被占用。

char b 占用 1字节 内存, 从 offset -> 8 开始储存,符合规则1: 8可以被1整除, offset -> 8 被占用。

int c 占用 4字节 内存, 从 offset -> 9 开始储存, 不符合规则1:9不可以被4整除,接着向后找,直到 offset -> 12 符合规则1,所以 int coffset -> 12 处开始储存,占用 offset -> [12, 15]

short d 占用 2字节 内存, 从 offset -> 16 开始储存, 占用 offset -> [16, 17]

此时上面4个变量共占用 18字节 内存, 但是根据规则3:结构体占用的内存应该为最大占用内存成员的整数倍, 即应该为8的整数倍, 所以结构体共占用 24字节 内存, 最后加上 填充字节(trailing padding)

struct Sturct2 内存大小计算

char a 占用 1字节 内存,从 offset -> 0 开始储存。offset -> 0 储存 a

short b 占用 2字节 内存,接着应该存在 offset -> 1, 根据 数据成员对齐规则, 1不能整除2,所以接着向后找, offset -> 2 能够整除, 所以 short boffset -> 2 处开始存放,占用连续的2个字节内存。 ab 之间为 填充字节 (internal padding), 此时 offset -> [2, 3] 被占用。

int c 占用 4字节 内存, 从 offset -> 4 处开始存放, 此时 offset -> [4, 7] 被占用。

double d 占用 8字节 内存, 从 offset -> 8 处开始存放, offset -> [8, 15] 被占用。

4个变量共占用 16字节 内存。

结构体嵌套

上面讨论的都是普通变量类型的结构体,接下来我们来研究一下结构体嵌套结构体的情况。我们定义一个结构体:

struct Struct3 {
    double  a;  // 8字节
    int     b;  // 4字节
    short   c;  // 2字节
    char    d;  // 1字节
    struct {
        double a;   // 8字节
        char b;     // 1字节
    } f;
} struct3;

我们来分析一下上面的结构体占用多少内存

double a 占用 8字节 内存, 从 offset -> 0 开始储存, offset -> [0, 7] 储存 a

int b 占用 4字节 内存, 从 offset -> 8 开始储存,offset -> [8, 11] 储存 b

short c 占用 2字节 内存,从 offset -> 12 开始储存,offset -> [12, 13] 储存 c

char d 占用 1字节 内存,从 offset -> 14 开始储存,offset -> 14 储存 d

结构体f 占用 16字节 内存,根据内存对齐规则2结构体必须从其内部最大的成员的整数被开始存储,结构体中最大的成员是 double 类型占用 8字节,所以 结构体f 应该从 8 的整数倍的位置开始存储。 offset -> 15 显然不符和,接着向后找,offset -> 16 符合条件, offset -> [16, 31] 存放 f

所以上面结构体共占用 32字节, 验证结果也如我们分析的一样。

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 219,188评论 6 508
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 93,464评论 3 395
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 165,562评论 0 356
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 58,893评论 1 295
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 67,917评论 6 392
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 51,708评论 1 305
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 40,430评论 3 420
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 39,342评论 0 276
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 45,801评论 1 317
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 37,976评论 3 337
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 40,115评论 1 351
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 35,804评论 5 346
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 41,458评论 3 331
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 32,008评论 0 22
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 33,135评论 1 272
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 48,365评论 3 373
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 45,055评论 2 355