背景
QA 报了一个 BUG，部分时间比较长的音频播放失败，经过定位后发现是音频格式判断出了问题，判断方法如下：
#define AMR_MAGIC_NUMBER "#!AMR\n"
+ (BOOL)isAmrData:(NSData *)data {
BOOL result = NO;
NSUInteger length = strlen(AMR_MAGIC_NUMBER);// length = 6
if (data.length > length) {
NSData *headerData = [data subdataWithRange:NSMakeRange(0, length)];
NSString *magicNumber = [NSString stringWithUTF8String:[headerData bytes]];
result = [magicNumber isEqualToString:@AMR_MAGIC_NUMBER];
}
return result;
}
这个方法的作用是取二进制数据的前几个字节作为 Magic number 从而判断该二进制是否是 AMR 格式的音频，通过调试发现，当音频二进制数据比较大时，magicNumber 拿到的值一直为 nil，怀疑是对 char* 编码出了问题，打印下 [headerData bytes]
(lldb) po (char *)[headerData bytes]
"#!AMR\n<\xffffffdeU^\xffffff90\xffffffe3\t\xffffff83\xffffff80\xffffff88z\xffffffaf\xfffffff3pT\x16\xffffff80"
好吧，问题就出在这了，前面我用 subdataWithRange 取了前面 6 个字节，但是通过 bytes 返回的地址，去取到的数据却是不止 6 个字节。
通过对比发现当 headerData 的类型为 _NSInlineData 时，bytes 取到的是正确的，而类型为 OS_dispatch_data 取到的是错误的。
(lldb) po [headerData class] // 正确
_NSInlineData
(lldb) po (char *)[headerData bytes]
"#!AMR\n"
==============================
(lldb) po [headerData class] // 错误
OS_dispatch_data
(lldb) po (char *)[headerData bytes]
"#!AMR\n<\xffffffdeU^\xffffff90\xffffffe3\t\xffffff83\xffffff80\xffffff88z\xffffffaf\xfffffff3pT\x16\xffffff80"
通过 Xcode 的 Memory Document，查看正确和错误 bytes 的内存对比发现：
OS_dispatch_data 这个类型用 bytes 方法获取内存地址后，第 7 个字节为 3C， 而能够正常编码的 _NSInlineData 类型，在 7 个字节是 00。
我们因为是用 UTF-8 编码的，一个英文占一个字节，而 00 这个字节对应 ASCII 的第 0 位，也就是空字符（Null），也就是 C 语言中的 '\0'，对于表示一串字符串， 它所的意义是“字符串结束符”。
由于 OS_dispatch_data 这个类型的 data，通过 bytes 拿到的值第七位并非 00，所以在编码的时候没有正确的截断导致出现了错误。
那为什么 OS_dispatch_data 这个类型的 headerData 取得的 bytes 地址指向的内存，第七位不是 00 呢？
看回最开始的源码
NSData *headerData = [data subdataWithRange:NSMakeRange(0, length)];
我们的 headerData 是 data 通过 subdataWithRange 取得的，而通过测试，而如果 data 是 _NSInlineData 这个类型，每次调用 subdataWithRange 创建一个新的对象（比如这里的新对象是 headerData），新的对象再调用 bytes 取得的地址每次都不一样。
而如果 data 是 OS_dispatch_data 类型，则每次截取后取到的 bytes 是一样的。
(lldb) po [data class]
_NSInlineData
(lldb) po [[data subdataWithRange:NSMakeRange(0, 6)] bytes];
0x0000000283caa930 // 地址不一样
(lldb) po [[data subdataWithRange:NSMakeRange(0, 6)] bytes];
0x0000000283ca8a50 // 地址不一样
==================================
(lldb) po [headerData class]
OS_dispatch_data
(lldb) po [[data subdataWithRange:NSMakeRange(0, 6)] bytes];
0x0000000116a7c000 // 地址一样
(lldb) po [[data subdataWithRange:NSMakeRange(0, 6)] bytes];
0x0000000116a7c000 // 地址一样
这里可以大概猜到 _NSInlineData 和 OS_dispatch_data 都是 NSData 的类簇，虽然方法名是一样的，但是底层实现是不一样的。
刨根问底
为什么会产生 OS_dispatch_data
前面已经提到，音频时间比较长的时候下载拿数据是 OS_dispatch_data 格式的，通过调试，发现是 AFNetworking 的 AFURLSessionManager 在对 response data 进行 copy 复制产生的：
- 对于大的的文件，复制前的对象是 NSConcreteMutableData 复制过后是 OS_dispatch_data
- 而对于小文件， copy 的结果是 _NSInlineData，个人猜测是 _NSInlineData 进行 subdataWithRange 会进行内存的复制和切割操作，分隔出来的数据末端用 00 填充，而对于较大的数据，copy 操作时会产生一个 OS_dispatch_data，其中对内存操作做了某些优化。
OS_dispatch_data 的 subdataWithRange 实现
通过 Xcode 的 Symbolic Breakpoint 给 -[OS_dispatch_data bytes] 下断点，
我们可以看到 OS_dispatch_data 的 bytes 实现是调用了 _dispatch_data_get_flattened_bytes，这串 GCD 代码，由于 GCD 是开源是，我们可以通过 GCD 代码一窥究竟。
我下载的是 libdispatch-913.30.4.tar.gz
通过调试发现对 OS_dispatch_data 对象调用 subdataWithRange， 实际上是调用了 -[_NSDispatchData subdataWithRange:] 这个方法，接着调用了 [NSByteCountFormatter allowedUnits]，最后再调用了 dispatch_data_create_subrange 这个 GCD 方法。
所以我们的关注点放在了 dispatch_data_create_subrange 这个方法上，打开 GCD 源码查看，下面是 这个方法 ， 我删掉了部分代码，完整版可以去 这里 看。
// offset 是起始偏移 length 是长度，比如我们是 NSMakeRange(0, 6) 那么 offset 就是 0， length 就是 6
dispatch_data_t
dispatch_data_create_subrange(dispatch_data_t dd, size_t offset,
size_t length)
{
dispatch_data_t data;
// 如果要是create_subrange 的数据是叶子数据（ dd->num_records == 0 ），代表改数据是存有内存地址的原始数据对象，而非引用别人的空壳对象
if (_dispatch_data_leaf(dd)) {
// 创建一个指向叶子的对象，将对象的 data_object 指向自身，并增加引用计数，将 from （offset）和 length 设置好
data = _dispatch_data_alloc(1, 0); // 第一个参数传 1 ，说明 records 有 1个对象，同时也说明非叶子数据（没有被其他人指向），下次 _dispatch_data_leaf(data) 的结果 为 false
data->size = length;
data->records[0].from = offset;
data->records[0].length = length;
data->records[0].data_object = dd;
_dispatch_data_retain(dd);
return data;// 直接将这指向叶子的对象返回
}
// Subrange of a composite dispatch data object
const size_t dd_num_records = _dispatch_data_num_records(dd);
size_t i = 0;
// if everything is from a single dispatch data object, avoid boxing it
// 数据是连续的 （records 数组只有一个元素）
if (offset + length <= dd->records[i].length) {
// 如果是指向叶子的对象，则找到原本的叶子，计算好 offset 和 length，调用一次 dispatch_data_create_subrange
return dispatch_data_create_subrange(dd->records[i].data_object,
dd->records[i].from + offset, length);
}
// .... 省略了很多代码 .....
// 数据有多个记录，可能内存是不连续的
data = _dispatch_data_alloc(count, 0);
data->size = length;
memcpy(data->records, dd->records + i, count * sizeof(range_record));
if (offset) {
data->records[0].from += offset;
data->records[0].length -= offset;
}
if (!to_the_end) {
data->records[count - 1].length = last_length;
}
for (i = 0; i < count; i++) {
_dispatch_data_retain(data->records[i].data_object);
}
return data;
}
这段代码，大概就是对 data 对象进行 切割，如果 data 中的数据是连续的，那么其实是啥也不干，只是创建了一个新的对象，并记录下偏移值，如果内存是不连续的，会进一步根据 offset 和 length 去复制所需要的内存块，值得注意的是，即使到了这一步，复制出来的块也至少包含了一个完整的内存卡，而不会根据 length 去裁剪的数据长度。
下面我们看看 bytes 的实现
OS_dispatch_data 的 _dispatch_data_get_flattened_bytes 实现
通过调试发现，对 OS_dispatch_data 对象调用 bytes 实际上是调用 _dispatch_data_get_flattened_bytes 这个 GCD 方法，该方法里，针对于连续的内存，调用 _dispatch_data_map_direct 可以直接拿到 bytes 地址，而对于非连续内存，他会调用 _dispatch_data_flatten 去遍历各个内存块并且复制拼接成一个连续完整的数据。
_dispatch_data_get_flattened_bytes(dispatch_data_t dd)
{
const void *buffer;
size_t offset = 0;
if (slowpath(!dd->size)) {
return NULL;
}
buffer = _dispatch_data_map_direct(dd, 0, &dd, &offset);
// 此处 buffer 不为 nil，说明是连续的内存，直接返回内存地址
if (buffer) {
return buffer;
}
// 内存非连续区域，需要调用 _dispatch_data_flatten 将分段其复制到一个区域
void *flatbuf = _dispatch_data_flatten(dd);
if (fastpath(flatbuf)) {
// we need a release so that readers see the content of the buffer
if (slowpath(!os_atomic_cmpxchgv2o(dd, buf, NULL, flatbuf,
&buffer, release))) {
free(flatbuf);
} else {
buffer = flatbuf;
}
} else {
return NULL;
}
return buffer + offset;
}
以下是 _dispatch_data_map_direct 的代码，可以看到无论是叶子数据，或者指向叶子的数据（用 subdataWithRange “切割” 过），最终都是返回叶子数据 buffer = dd->buf + offset; 所以每次返回的地址的一样的
_dispatch_data_map_direct(struct dispatch_data_s *dd, size_t offset,
struct dispatch_data_s **dd_out, size_t *from_out)
{
const void *buffer = NULL;
dispatch_assert(dd->size);
if (slowpath(!_dispatch_data_leaf(dd)) &&
_dispatch_data_num_records(dd) == 1) {
offset += dd->records[0].from;
dd = (struct dispatch_data_s *)dd->records[0].data_object;
}
if (fastpath(_dispatch_data_leaf(dd))) {
buffer = dd->buf + offset;
} else {
buffer = os_atomic_load((void **)&dd->buf, relaxed);
if (buffer) {
buffer += offset;
}
}
if (dd_out) *dd_out = dd;
if (from_out) *from_out = offset;
return buffer;
}
解决问题
既然 OS_dispatch_data 通过 bytes 拿到的数据不对，那将其转换成 _NSInlineData 或者 NSConcreteMutableData 可否行得通？
通过测试，对 OS_dispatch_data 对象调用 mutableCopy 即可解决问题。
(lldb) po [headerData class]
OS_dispatch_data
(lldb) po (char *)[headerData bytes]
"#!AMR\n<\xffffffdeU^\xffffff90\xffffffe3\t\xffffff83\xffffff80\xffffff88z\xffffffaf\xfffffff3pT\x16\xffffff80"
(lldb) p headerData = [headerData mutableCopy]
(NSConcreteMutableData *) $6 = 0x0000000282884ab0 6 bytes
(lldb) po [headerData class]
NSConcreteMutableData
(lldb) po (char *)[headerData bytes]
"#!AMR\n"
当然了 还有更优雅和快速的方式，直接使用 strncmp 对比指定长度的字符
+ (BOOL)isAmrData:(NSData *)data {
BOOL result = NO;
if (!strncmp([data bytes], AMR_MAGIC_NUMBER, strlen(AMR_MAGIC_NUMBER))) {
result = YES;
}
return result;
}
博客原文