最近在技术群里有一个群友提出了一个问题,就是为什么下面代码打印的结果不一样?

NSMutableDictionary *mDic1 = [NSMutableDictionary dictionaryWithDictionary:@{@"a":@1, @"a":@2}];
//'a': 1
NSMutableDictionary *mDic2 = [NSMutableDictionary dictionary];
[mDic2 setObject:@(1) forKey:@"a"];
[mDic2 setObject:@(2) forKey:@"a"];
 //'a': 2

对此,笔者稍微研究了一下,在此,我阐述一下理由并简述实验步骤

@{} 到底是什么?

造成这个数据结果的可能性之一,应该是

@{@"a":@1, @"a":@2}

本身就是一个 key 为 a, 值为 1 的字典 。

通过测试代码,如下:

NSDictionary *dic = @{@"a":@1, @"a":@2};
NSLog(@"%@", dic);

发现其本身就是一个 key 为 a, 值为 1 的字典 。

那么 @{} 到底是什么呢?其实如何操作的呢?他的分配方式究竟是什么?

实验步骤

基于网上找到的 NSDictionary 的伪代码,无论如何,当我们创建一个字典时,其最终都会执行

- (id)initWithObjects:(const id [])objects forKeys:(const id <NSCopying> [])keys count:(NSUInteger)cnt

那么假使我们通过 hook 监听这个方法,我们就知道在初始化时传入的 objects 和 keys 究竟是什么?但是,可惜的是,没有 hook 住。

难道是我的做法有问题吗?

笔者发现在使用 @{} 时根本就不执行这个步骤?是其他的吗?

然后笔者选择通过添加符号断点 +[NSDictionary dictionaryWithObjects:forKeys:count:] 发现,当我们赋值时,其符号断点会挂住。

我们在使用  @{} 创建字典的时候会调用这个方法吗?值得一试?

通过 hook 了字典的这个方法,我们在分类中做一个接受,当系统调用时,挂上断点

+ (id)xxx_dictionaryWithObjects:(const id [])objects forKeys:(const id <NSCopying> [])keys count:(NSUInteger)cnt{
 for (NSUInteger i = 0; i < cnt; i++) {
 id key = keys[i];
 id obj = objects[i];
 NSLog(@"key = %@", key);
 NSLog(@"obj = %@", obj);
 }
 return [[NSDictionary class] xxx_dictionaryWithObjects:objects forKeys:keys count:cnt];
}

2021-03-30 17:13:40.971674+0800 suspenseRoad[28886:413231] key = a
2021-03-30 17:13:40.971743+0800 suspenseRoad[28886:413231] obj = 1
2021-03-30 17:13:40.971814+0800 suspenseRoad[28886:413231] key = a
2021-03-30 17:13:40.971896+0800 suspenseRoad[28886:413231] obj = 2

并等到下面的结果,我们在初始化设置的时候,传入的值都已经进入代码中,但是结果并没有

继续探究一下  +[NSDictionary dictionaryWithObjects:forKeys:count:] 的方法

+ (id)dictionaryWithDictionary:(NSDictionary *)dict
{
 size_t count = [dict count];
 id *objects = NULL;
 id *keys = NULL;

 if (count > 0) {
 objects = malloc(sizeof(id) * count);
 if (UNLIKELY(objects == NULL)) {
  return NULL;
 }
 keys = malloc(sizeof(id) * count);
 if (UNLIKELY(keys == NULL)) {
  free(objects);
  return NULL;
 }
 }

 [dict getObjects:objects andKeys:keys];
 id obj = [[self alloc] initWithObjects:objects forKeys:keys count:count];

 if (objects != NULL) {
 free(objects);
 }
 if (keys != NULL) {
 free(keys);
 }

 return [obj autorelease];
}

猜测

这时候可能会让改变数据的地方只有两个:

 [dict getObjects:objects andKeys:keys];
//或者
 id obj = [[self alloc] initWithObjects:objects forKeys:keys count:count];

由于上述两个问题笔者都无办法断点到,如果读者大大有办法的话,希望读者大大尝试。笔者根据两个方法的代码进行了自己的「大胆猜测」——也就是瞎猜

很可惜,都没有改掉。在代码中没看到任何一个方法可以做到对 objects 和 keys 的选择遍历。

CFBasicHashAddValue 和 CFBasicHashSetValue

看来应该不是其初始化方法的问题,然后笔者比较了字典的 setObject:forKey 的实现。发现如题的两个方法:

CF_PRIVATE Boolean CFBasicHashAddValue(CFBasicHashRef ht, uintptr_t stack_key, uintptr_t stack_value) {
 ···
 CFBasicHashBucket bkt = __CFBasicHashFindBucket(ht, stack_key);
 if (0 < bkt.count) {
  ht->bits.mutations++;
  if (ht->bits.counts_offset && bkt.count < LONG_MAX) { // if not yet as large as a CFIndex can be... otherwise clamp and do nothing
   __CFBasicHashIncSlotCount(ht, bkt.idx);
   return true;
  }
 } else {
  __CFBasicHashAddValue(ht, bkt.idx, stack_key, stack_value);
  return true;
 }
 return false;
}

CF_PRIVATE void CFBasicHashSetValue(CFBasicHashRef ht, uintptr_t stack_key, uintptr_t stack_value) {
 ···
 CFBasicHashBucket bkt = __CFBasicHashFindBucket(ht, stack_key);
 if (0 < bkt.count) {
  __CFBasicHashReplaceValue(ht, bkt.idx, stack_key, stack_value);
 } else {
  __CFBasicHashAddValue(ht, bkt.idx, stack_key, stack_value);
 }
}

感觉胜利不远了,因为__CFBasicHashReplaceValue 这个方法语义上是一个替换。那么其本质应该就是 CFBasicHashAddValue ,当存在同值的 key 的时候,并不会再次加入,并且也解释了,最终的结果是设置为前面的值而不是设置在后面的值。

同样你也可以得出下面的值了,欢迎把答案写在评论区哦。

[NSDictionary dictionaryWithObjects:@[@1,@2,@3,@4,@5,@6,@7,@8,@9,@0] forKeys:@[@"a",@"b", @"a", @"b", @"a", @"a", @"b", @"b", @"a", @"b"]]

其他

在 hook 字典本身的dictionaryWithObjects:forKeys:count: 时,我们需要谨慎断点的时间,包括当不限于系统的状态栏等信息最终都会存进一个字典中,其存入的时机就是项目运行的时候,最好在NSDictionary *dic = @{@”a”:@1, @”a”:@2};之前挂上断点,然后在放开dictionaryWithObjects:forKeys:count: 断点。

到此这篇关于Objective-C中的语法糖@{}究竟是什么的文章就介绍到这了,更多相关Objective-C语法糖@{}内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

声明:本站所有文章,如无特殊说明或标注,均为本站原创发布。任何个人或组织,在未征得本站同意时,禁止复制、盗用、采集、发布本站内容到任何网站、书籍等各类媒体平台。如若本站内容侵犯了原著者的合法权益,可联系我们进行处理。