iOS开发之32位与64位，以及结构体对齐访问的问题

1.首先说32位与64位的问题

之前不清楚iOS是32位还是64位的时候，看见sizeof(int) 打印出来的结果是4的时候，就单纯地以为是32位的系统，即便是看到Mac的“关于本机”里的内存大小清清楚楚地写着是16G（64位OS内存一般为16G，即2的64次方），我也天真地以为大概macOS 和iOS 两者位宽大概不一样吧。因为楼主以前学Linux的，我清清楚楚地记得老师说：int 整型 的“整”体现在它与CPU本身的位宽一样。那iOS是基于Unix，Linux又是高仿的Unix，我就以为一样啊....所以是一直都是这么测的啊，直到，脑抽直接把指针传给sizeof，打印出来是8，

char *p = NULL; printf("------- sizeof(p) = %ld ----\n", sizeof(p));

打印结果：

------- sizeof(p) = 8 ----

8字节，那为什么int只有4字节？凌乱....

然后在网上好一顿搜索，确实也找到了一些资料：（来自iOS32位和64位的坑  这篇文章挺好）

对于iOS设备来说

32位编译器

char ：1个字节 char*（即指针变量）: 4个字节（32位的寻址空间是2^32, 即32个bit，也就是4个字节。同理64位编译器） short int : 2个字节 int： 4个字节 unsigned int : 4个字节 float: 4个字节 double: 8个字节 long: 4个字节，最大是2147483648，再大则溢出 long long: 8个字节 unsigned long: 4个字节

64位编译器

char ：1个字节 char*(即指针变量): 8个字节 short int : 2个字节 int： 4个字节 unsigned int : 4个字节 float: 4个字节 double: 8个字节 long: 8个字节，最大是18446744073709552000 long long: 8个字节 unsigned long: 8个字节

比较得知，32与64区别主要在long，64位比32位大得多。 （这部分都是粘贴自iOS32位和64位的坑  这篇文章）

那现在已经明白了，目前在用的是64位系统，跟Linux毕竟还是不一样，不纠结这个问题了，继续下一个。

2.其次是结构体对齐访问的问题

前面既然已经说了是64位，可是新疑问又来了

typedef struct my_Header { char msgHead[4]; short tag; int length; }My_Header; My_Header myHeader; memset(&myHeader, 0, sizeof(myHeader)); printf("------- head len = %d ----\n", sizeof(myHeader)); 按照结构体的对齐访问，OS的位宽又是8字节，所以猜测打印出来的结果应该是16字节，... 但是实际打印的是12字节， 这又是怎么肥事？要不是找到了上面的那篇资料，我真的又要以为iOS是32位的了，网上搜了好多，基本也是讲32位下的4字节对齐访问方式。 既然说到结构体的对齐访问，不如一起来复习一下，（以下内容都是基于Linux的32位平台下的，iOS平台下的内容有待考究，不过可以参考）

结构体的对齐访问：

What：

struct header { char a; int b; }; struct header haed; 在这个结构体中，打印输出该结构体的字节，发现它占了8个字节。char a 本应是1字节，但实际在这个结构体中，占4字节，这就是“对齐访问”。

Why：为何要对齐访问

1.硬件限制 2.提高效率： 关于效率这方面，我们要从汇编语言这方面切入理解，比较对齐与不对齐访问： 1）对齐访问： 如上图，此时的b，通过一次ldr指令，即可访问到 2）非对齐访问： 如下图 则读取b的步骤变成了： 1.  读取这3个字节 2. 读取这一个字节 3. 结合

综上，1. 速度降低了2/3，所以效率低。

           2. 对齐访问是牺牲了内存空间，换取了速度。

How：

编译器默认是4字节对齐（32bit），可以通过设置对齐指令来更改对齐方式（1字节对齐、4、8、128字节对齐等） #prama pack(n) // 开头。n = 1, 4, 8... ...... ...... #prama pack() // 结尾

现在再来看看 sizeof(myHeader) 值为 12这事，还是觉得像4字节对齐。 不如再给myHeader加一个类型为long的成员： typedef struct my_Header { char msgHead[4]; short tag; int length; long test; }My_Header; My_Header myHeader;long为8字节，按照上面所讲，如果结构体是4字节对齐： （图误，应该和下一张图是一样的） 应该得出结构体所占大小为20字节； 如果是8字节对齐，则： 结构体所占大小为24字节 既然之前sizeof(myHeader) 值为 12，暂时认为是4字节对齐吧，那么按照刚才的分析，结构体所占大小应该为20字节 我们来实际运行看一看 …… ------- head len = 24 ---- 这下怎么圆回来？前面已经说了那么多 这要怎么理解？此处暂时存疑吧…… 我已经尽我最大努力画图了，看不看得懂全凭缘分了。 不过4字节对齐，8毕竟也是它的倍数，按刚刚的思路，仿佛是不影响…也没有找到什么确切的文章，只能理解成它是默认按4字节对齐的吧。…… ======================= 8月3日，更新  ======================= 其实刚刚最后一张图画完，就已经有点思路了，倒数第二张画的图有误，因为之前说了是在64位的条件下，所以画成4字节的位宽是不对的。 重新更正为： 如果结构体是4字节对齐，情况和下面一张图是一样的。 同理， typedef struct my_Header { char msgHead[4]; short tag; int length; }My_Header;结构体大小为12也可以被理解： 如果真的是8字节对齐访问的话，大小应该为8的倍数，所以可以判断OS并不是按8字节对齐的。 想要验证也很简单，用上面刚刚说的#prama pack(8)测试一下，可以得到结果为16 。

总结：

iOS情况下，是位宽为8字节，结构体对齐方式为按4字节对齐。