字节对齐导致的iOS EXC_ARM_DA_ALIGN崩溃
本文原链接： http://www.cnblogs.com/zouzf/p/4455167.html
先看一下这个链接：http://www.cnblogs.com/ren54/archive/2013/01/11/2856207.html
我遇到情况和这位朋友很类似：用二进制方式从文件读取内容到内存，假设内容只有7个字节，前面三个字节是三个字符，后四个字节的内容是一个int数据，在把后四个字节转成int数据时如（pFileContent是char*指针，已指向第四个字节）：int intValue = *(pFileContent); 就会崩溃报EXC_ARM_DA_ALIGN错误。
查了一下资料：http://www.justinyan.me/post/1609 、http://www.shaoqun.com/a/54537.aspx 、http://blog.csdn.net/slay_cn/article/details/6221637 ，是因为字节对齐问题引起的，大概描述如下（摘自前面三篇资料）：
内存地址空间以byte划分，所以理论上访问内存地址可以从任意byte开始，但是事实上我们不是直接访问硬件地址，而是通过操作系统的虚拟内存地址来访问，虚拟内存地址是以字为单位的。一个32位机器的字长就是32位，所以32位机器一次访问内存大小就是4个byte。再者为了性能考虑，数据结构(尤其是栈)应该尽可能地在自然边界上对齐。原因在于，为了访问未对齐的内存，处理器需要作两次内存访问；而对齐的内存访问仅需要一次访问。
这个问题常见于对字节流进行处理解析，比如从网络收到一个数据包，读入本地缓存后进行处理，头两个字节是一个short标志，接下来四个字节是一个int参数，所以将指向这个位置的指针直接cast成int*来读取数据——于是问题就出现了，当读int*时，ARM要求字节对齐，而此时不对齐。则有可能出现EXC_ARM_DA_ALIGN异常而崩溃。
大概就是说，在进行强制数据类型转换的时候，（release版本）会要求内存字节对齐。编译release版本，编译器会对代码进行优化，在处理数据时要求数据结构在自然边界上对齐以提高CPU效率。
解决方法了http://www.shaoqun.com/a/54537.aspx：
方案1、在指针定义时加上编译器指令PACKED，则编译器在遇到此关键字时就不再要求字节对齐，而是自行进行正确的处理。
方案2、使用memcpy逐字节拷贝来绕过直接的int*指针读取。给memcpy传入参数时，先将参数转成void*类型，因为release的memcpy被优化掉了，在优化的版本中，将指针转成long型，4个4个字节的进行复制，于是又出现了字节对齐的问题。
我采用了方案2，给memcpy传参数时转成 void* 。
后记
当读取文件获取数据时经常会采用反序列化的方式来提高效率，如上篇文章提到的骨骼动画的优化，这个时候要特别注意字节对齐的问题，特别是现在做手游基本都会涉及到多平台，在定义一些struct时最好显示调用
#pragma pack(n)来指定字节对齐。windows下编译器默认是8字节对齐的，mac、iOS、Android（如果有误请指正）默认是4字节对齐的，而经常发生的时，在windows下对文件资源进行序列化，然后在iOS和Android上运行的时候读取文件进行反序列化，如果有个结构体如 struct myTest { char[5] name; int age; }；就出问题了，windows下写进文件需要16个字节，而ARM设备下读取文件反序列化需要12个字节~~
上面说到：windows下默认是8字节对齐的，mac、iOS、Android（如果有误请指正）默认是4字节对齐的 ，这个说法是不严谨的，应该更多的是跟编译器有关吧，而编译器会根据系统和CPU特性来决定的吧，这块了解得不多，有了解的朋友可以留下链接和看法，谢了。
另外还有个疑惑，那个EXC_ARM_DA_ALIGN 崩溃会出现在Xcode5.1.1 出的release版本，而Xcode5.0.1 出的release版本却没事，一个小版本的有必要差异那么大么。。。。
本文原链接： http://www.cnblogs.com/zouzf/p/4455167.html
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
