OS_dispatch_data 的小探究

2018-07-19 iOS

背景

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 复制产生的:

  1. 对于大的的文件,复制前的对象是 NSConcreteMutableData 复制过后是 OS_dispatch_data
  2. 而对于小文件, 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;
}
Comments
Write a Comment
  • lovezieforever reply

    哇,真棒啊啊

  • 我是小可爱,ziememeza reply

    看了,是干货,很66