欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

詳解Objective-C中的語法糖@{}究竟是什么

 更新時間:2021年04月07日 09:53:11   作者:iOS成長指北  
這篇文章主要給大家介紹了關(guān)于Objective-C中語法糖@{}究竟是什么的相關(guān)資料,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧

最近在技術(shù)群里有一個群友提出了一個問題,就是為什么下面代碼打印的結(jié)果不一樣?

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

對此,筆者稍微研究了一下,在此,我闡述一下理由并簡述實驗步驟

@{} 到底是什么?

造成這個數(shù)據(jù)結(jié)果的可能性之一,應該是

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

本身就是一個 key 為 a, 值為 1 的字典 。

通過測試代碼,如下:

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

發(fā)現(xiàn)其本身就是一個 key 為 a, 值為 1 的字典 。

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

實驗步驟

基于網(wǎng)上找到的 NSDictionary 的偽代碼,無論如何,當我們創(chuàng)建一個字典時,其最終都會執(zhí)行

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

那么假使我們通過 hook 監(jiān)聽這個方法,我們就知道在初始化時傳入的 objects 和 keys 究竟是什么?但是,可惜的是,沒有 hook 住。

難道是我的做法有問題嗎?

筆者發(fā)現(xiàn)在使用 @{} 時根本就不執(zhí)行這個步驟?是其他的嗎?

然后筆者選擇通過添加符號斷點 +[NSDictionary dictionaryWithObjects:forKeys:count:] 發(fā)現(xiàn),當我們賦值時,其符號斷點會掛住。

我們在使用  @{} 創(chuàng)建字典的時候會調(diào)用這個方法嗎?值得一試?

通過 hook 了字典的這個方法,我們在分類中做一個接受,當系統(tǒng)調(diào)用時,掛上斷點

+ (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

并等到下面的結(jié)果,我們在初始化設置的時候,傳入的值都已經(jīng)進入代碼中,但是結(jié)果并沒有

繼續(xù)探究一下  +[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];
}

猜測

這時候可能會讓改變數(shù)據(jù)的地方只有兩個:

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

由于上述兩個問題筆者都無辦法斷點到,如果讀者大大有辦法的話,希望讀者大大嘗試。筆者根據(jù)兩個方法的代碼進行了自己的「大膽猜測」——也就是瞎猜

很可惜,都沒有改掉。在代碼中沒看到任何一個方法可以做到對 objects 和 keys 的選擇遍歷。

CFBasicHashAddValue 和 CFBasicHashSetValue

看來應該不是其初始化方法的問題,然后筆者比較了字典的 setObject:forKey 的實現(xiàn)。發(fā)現(xiàn)如題的兩個方法:

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 這個方法語義上是一個替換。那么其本質(zhì)應該就是 CFBasicHashAddValue ,當存在同值的 key 的時候,并不會再次加入,并且也解釋了,最終的結(jié)果是設置為前面的值而不是設置在后面的值。

同樣你也可以得出下面的值了,歡迎把答案寫在評論區(qū)哦。

[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: 時,我們需要謹慎斷點的時間,包括當不限于系統(tǒng)的狀態(tài)欄等信息最終都會存進一個字典中,其存入的時機就是項目運行的時候,最好在NSDictionary *dic = @{@"a":@1, @"a":@2};之前掛上斷點,然后在放開dictionaryWithObjects:forKeys:count: 斷點。

到此這篇關(guān)于Objective-C中的語法糖@{}究竟是什么的文章就介紹到這了,更多相關(guān)Objective-C語法糖@{}內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家!

相關(guān)文章

  • IOS實現(xiàn)視頻動畫效果的啟動圖

    IOS實現(xiàn)視頻動畫效果的啟動圖

    這篇文章實現(xiàn)的是一個關(guān)于啟動頁或者引導頁的視頻動畫效果的實現(xiàn)過程,對于大家開發(fā)APP具有一定的參考借鑒價值,有需要的可以來看看。
    2016-09-09
  • iOS 生成plist文件,在項目中代碼創(chuàng)建plist的實例

    iOS 生成plist文件,在項目中代碼創(chuàng)建plist的實例

    下面小編就為大家分享一篇iOS 生成plist文件,在項目中代碼創(chuàng)建plist的實例,具有很好的參考價值,希望對大家有所幫助。一起跟隨小編過來看看吧
    2018-02-02
  • Flutter之可滾動組件實例詳解

    Flutter之可滾動組件實例詳解

    這篇文章主要為大家介紹了Flutter之可滾動組件實例詳解,有需要的朋友可以借鑒參考下,希望能夠有所幫助,祝大家多多進步,早日升職加薪
    2022-10-10
  • 淺談Xcode9 和iOS11適配和特性

    淺談Xcode9 和iOS11適配和特性

    本篇文章主要介紹了Xcode9 和iOS11適配和特性,小編覺得挺不錯的,現(xiàn)在分享給大家,也給大家做個參考。一起跟隨小編過來看看吧
    2017-09-09
  • 開發(fā)繪圖、手勢綜合App注意點

    開發(fā)繪圖、手勢綜合App注意點

    本篇文章主要給大家詳細講述了在IOS開發(fā)繪圖、手勢綜合App容易遇到的坑以及注意事項等內(nèi)容,有興趣的朋友參考下吧。
    2018-02-02
  • 詳解iOS中跨頁面狀態(tài)同步方案比較

    詳解iOS中跨頁面狀態(tài)同步方案比較

    這篇文章主要介紹了詳解iOS中跨頁面狀態(tài)同步方案比較,文中通過示例代碼介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
    2019-09-09
  • IOS之構(gòu)造方法與自定義構(gòu)造方法的區(qū)別與實現(xiàn)

    IOS之構(gòu)造方法與自定義構(gòu)造方法的區(qū)別與實現(xiàn)

    本篇文章主要介紹了構(gòu)造方法以及自定義構(gòu)造方法的實現(xiàn),需要的朋友可以參考下
    2015-07-07
  • iOS中仿QQ側(cè)滑菜單功能

    iOS中仿QQ側(cè)滑菜單功能

    這篇文章主要介紹了iOS中仿QQ側(cè)滑菜單功能,在實現(xiàn)此功能之前,需要先了解UITabBarController的層級結(jié)構(gòu),具體實現(xiàn)思路大家可以參考下本文
    2017-07-07
  • iOS UISegmentControl實現(xiàn)自定義分欄效果

    iOS UISegmentControl實現(xiàn)自定義分欄效果

    這篇文章主要為大家詳細介紹了iOS UISegmentControl實現(xiàn)自定義分欄效果,文中示例代碼介紹的非常詳細,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2022-03-03
  • 值得收藏的iOS開發(fā)常用代碼塊

    值得收藏的iOS開發(fā)常用代碼塊

    這篇文章主要為大家詳細介紹了iOS開發(fā)常用代碼塊,具有一定的參考價值,感興趣的小伙伴們可以參考一下
    2016-10-10

最新評論