首先通过一段代码来描述内存对齐的现象。
struct x_ {
char a; // 1 byte
int b; // 4 bytes
short c; // 2 bytes
char d; // 1 byte
} MyStruct1;
struct y_ {
int b; // 4 bytes
char a; // 1 byte
char d; // 1 byte
short c; // 2 bytes
} MyStruct2;
NSLog(@"%lu,%lu", sizeof(MyStruct1), sizeof(MyStruct2));
上述代码打印出来的结果为：12,8
为什么相同的结构体，只是交换了变量 ab 和 cd 在结构体中的顺序他们的大小就改变了呢？这就是“内存对齐”的现象。
内存对齐规则
在了解为什么要进行内存对齐之前，先来了解一下内存对齐的规则：
-
数据成员对齐规则：struct 或 union （以下统称结构体）的数据成员，第一个数据成员放在偏移为 0 的地方，以后每个数据成员的偏移为 #pragma pack 指定的数值和这个数据成员自身长度中较小那个的整数倍。
-
数据成员为结构体：如果结构体的数据成员还为结构体，则该数据成员的“自身长度”为其内部最大元素的大小。(struct a 里存有 struct b，b 里有char,int,double等元素，那 b “自身长度”为 8)
-
结构体的整体对齐规则：在数据成员按照 #1 完成各自对齐之后，结构体本身也要进行对齐。对齐会将结构体的大小增加为 #pragma pack 指定的数值和结构体最大数据成员长度中较小那个的整数倍。
#pragma pack (n) 表示设置为 n 字节对齐。 Xcode 默认为 8 字节对齐。当设置为 #pragma pack (1) 时就代表不进行内存对齐，上述代码打印的结果就都为 8。
MyStruct1 的进行对齐后结构为：
// Shows the actual memory layout
struct x_ {
char a; // 1 byte
char _pad0[3]; // padding to put 'b' on 4-byte boundary
int b; // 4 bytes
short c; // 2 bytes
char d; // 1 byte
char _pad1[1]; // padding to make sizeof(x_) multiple of 4
}
为了进行验证，我们通过如下代码打印结构体：
long a = (long)&MyStruct1.a;
long b = (long)&MyStruct1.b;
long c = (long)&MyStruct1.c;
long d = (long)&MyStruct1.d;
NSLog(@"%ld,%ld,%ld,%ld", a, b, c, d);
输出的结果为：4296671176,4296671180,4296671184,4296671186。他们的内存占用符合内存对齐的规则。
char a + char _pad0[3] : 4296671176 // 占用 6 7 8 9
int b : 4296671180 // 占用 0 1 2 3
short c : 4296671184 // 占用 4 5
char d + char _pad1[1] : 4296671186 // 占用 6 7 8 9
通过上述规则进行对齐后的 MyStruct1 增加了 4 个字节变为 12 字节。而 MyStruct2 的所有数据成员和结构体本身都正好符合了内存对齐的规则，所以没有增加任何大小正好为 8 字节。
为什么要进行内存对齐
内存对齐应该是编译器的管辖范围。编译器会为程序中的每个数据单元安排在适当的位置上，这个过程对于大部分程序员来说都应该是透明的。但如果你想了解更加底层的秘密，“内存对齐”就不应该对你透明了。
要想掌控这项技术，在了解内存对齐的规则后，还应该知道编译器为什么会进行内存对齐。
很多 CPU（如基于 Alpha，IA-64，MIPS，和 SuperH 体系的）拒绝读取未对齐数据。当一个程序要求这些 CPU 读取未对齐数据时，这时 CPU 会进入异常处理状态并且通知程序不能继续执行。举个例子，在 ARM，MIPS，和 SH 硬件平台上，当操作系统被要求存取一个未对齐数据时会默认给应用程序抛出硬件异常。所以，如果编译器不进行内存对齐，那在很多平台的上的开发将难以进行。
那么，为什么这些 CPU 会拒绝读取未对齐数据？是因为未对齐的数据，会大大降低 CPU 的性能。下边会进行详细的解释。
CPU 存取原理
程序员通常认为内存就像所有字节堆起来的数组。
但是，你的 CPU 并不是以字节为单位存取数据的。每次内存存取都会产生一个固定的开销，减少内存存取次数将提升程序的性能。所以 CPU 一般会以 2/4/8/16/32 字节为单位来进行存取操作。我们将上述这些存取单位称为内存存取粒度。
为了说明内存对齐背后的原理，我们通过一个例子来说明从未地址与对齐地址读取数据的差异。这个例子很简单：在一个存取粒度为 4 字节的内存中，先从地址 0 读取 4 个字节到寄存器，然后从地址 1 读取 4 个字节到寄存器。
当从地址 0 开始读取数据时，是读取对齐地址的数据，直接通过一次读取就能完成。当从地址 1 读取数据时读取的是非对齐地址的数据。需要读取两次数据才能完成。
而且在读取完两次数据后，还要将 0-3 的数据向上偏移 1 字节，将 4-7 的数据向下偏移 3 字节。最后再将两块数据合并放入寄存器。
这对 CPU 的开销很大。所以有些处理器才不情愿为你做这些工作。
历史
最初的 68000 处理器的存取粒度是双字节，没有应对非对齐内存地址的电路系统。当遇到非对齐内存地址的存取时，它将抛出一个异常。最初的 Mac OS 并没有妥善处理这个异常，它会直接要求用户重启机器。实在是悲剧。
随后的 680x0 系列，像 68020，放宽了这个的限制，支持了非对齐内存地址存取的相关操作。这解释了为什么一些在 68020 上正常运行的旧软件会在 68000 上崩溃。这也解释了为什么当时一些老 Mac 编程人员会将指针初始化成奇数地址。在最初的 Mac 机器上如果指针在使用前没有被重新赋值成有效地址，Mac 会立即跳到调试器。通常他们通过检查调用堆栈会找到问题所在。
所有的处理器都使用有限的晶体管来完成工作。支持非对齐内存地址的存取操作会消减“晶体管预算”，这些晶体管原本可以用来提升其他模块的速度或者增加新的功能。
以速度的名义牺牲非对齐内存存取功能的一个例子就是 MIPS。为了提升速度，MIPS 几乎废除了所有的琐碎功能。
PowerPC 各取所长。目前所有的 PowerPC 都在硬件上支持非对齐的 32 位整型的存取。虽然牺牲掉了一部分性能，但这些损失在逐渐减少。
Power 是 1991 年，Apple、IBM、Motorola 组成的 AIM 联盟所发展出的微处理器架构。PowerPC 是整个 AIM 联盟平台的一部分，并且是到目前为止唯一的一部分。但苹果电脑自 2005 年起，将旗下电脑产品转用 Intel CPU。
现今的 PowerPC 处理器缺少对非对齐的 64-bit 浮点型数据的存取的硬件支持。当被要求从非对齐内存读取浮点数时，PowerPC 会抛出异常并让操作系统在软件层面处理内存对齐。软件解决内存对齐要比硬件慢得多。经过 IBM 在 PowerPC 测试，他们效率的差异大概在 4610%。
总结
在 iOS 开发中编译器会帮我们进行内存对齐。所以这些问题都无需考虑。但如果编译器没有提供这些功能，而且 CPU 也不支持读取非对齐数据，CPU 就会抛出硬件异常交给操作系统处理，从而产生 4610% 的差异。如果 CPU 支持读取非对齐数据，相比对齐数据，你还是要承担额外的开销造成的损失。诚然，这种损失绝不会像 4610% 那么大，但还是不能忽略的。
了解了这些后，当我们再声明结构体时就应该合理的安排内部数据的顺序，从而使其占用尽可能小的内存。你也许觉得这并没有什么卵用，但苹果在 Runloop 的源码中就使用了 _padding[3] 来手动对齐内存。
struct __CFRunLoopMode {
CFRuntimeBase _base;
pthread_mutex_t _lock; /* must have the run loop locked before locking this */
CFStringRef _name;
Boolean _stopped;
char _padding[3];
CFMutableSetRef _sources0;
CFMutableSetRef _sources1;
CFMutableArrayRef _observers;
CFMutableArrayRef _timers;
//……
};
博客：xuyafei.cn
简书：jianshu.com/users/2555924d8c6e
微博：weibo.com/xuyafei86
Github：github.com/xiaofei86
网友评论