??在iOS開發(fā)過程中，我們有時(shí)候會(huì)有這樣的需求，將一個(gè) 不可變的字典或者數(shù)組轉(zhuǎn)換為可變的，可以使用系統(tǒng)的mutableCopy方法，但是這樣只是第一層可變，如果數(shù)組或字典有多層時(shí)，我們?nèi)バ薷闹瞪顚哟蔚闹禃r(shí)，會(huì)發(fā)生崩潰，這樣并不能達(dá)到預(yù)期的要求，可以給數(shù)組和字典添加分類來實(shí)現(xiàn)這個(gè)功能。
成都創(chuàng)新互聯(lián)從2013年創(chuàng)立，先為靜樂等服務(wù)建站，靜樂等地企業(yè)，進(jìn)行企業(yè)商務(wù)咨詢服務(wù)。為靜樂企業(yè)網(wǎng)站制作PC+手機(jī)+微官網(wǎng)三網(wǎng)同步一站式服務(wù)解決您的所有建站問題。
可以自己定義一個(gè)文件
.h 文件中
.m 文件中
只要導(dǎo)入頭文件，字典調(diào)用mutableDicDeepCopy，字典中所有value(數(shù)組或者字典)無論多少層都是可變的，數(shù)組調(diào)用mutableArrayDeeoCopy，數(shù)組中所有的元素(數(shù)組或者字典) 無論多少層也是可變的，可以直接取修改字典或數(shù)組中元素的值。
在日常開發(fā)中，將網(wǎng)絡(luò)請(qǐng)求中獲取的 JSON 數(shù)據(jù)轉(zhuǎn)為數(shù)據(jù)模型，是我們開發(fā)中必不可少的操作。
通常我們會(huì)選用諸如 YYModel 、 JSONModel 或者 MJExtension 等第三方框架來實(shí)現(xiàn)這一過程。這些框架實(shí)現(xiàn)原理的核心就是 Runtime 和 KVC ，以及 Getter / Setter 。
實(shí)現(xiàn)的大體思路如下：借助 Runtime 可以動(dòng)態(tài)獲取 成員列表 的特性，遍歷模型中所有屬性，然后以獲取到的屬性名為 key ，在 JSON 字典中尋找對(duì)應(yīng)的值 value ；再使用 KVC 或直接調(diào)用 Getter / Setter 將每一個(gè)對(duì)應(yīng) value 賦值給模型，就完成了字典轉(zhuǎn)模型的目的。
從這份 JSON 中可以看出，字典中取值除了 字符串 之外，還有 數(shù)組 和 字典 。那么在將字典轉(zhuǎn)換成數(shù)據(jù)模型的時(shí)候，就要考慮 模型嵌套模型 、 模型嵌套模型數(shù)組 的情況了。
經(jīng)過分析，我們總共需要三個(gè)模型： XXStudentModel、XXAdressModel、XXCourseModel。
NSObject+XXModel.h、NSObject+XXModel.m 就是我們用來解決字典轉(zhuǎn)模型所創(chuàng)建的分類，協(xié)議中的 + (NSDictionary *)modelContainerPropertyGenericClass 方法用來告訴分類特殊字段的處理規(guī)則，比如 id -- uid。
一、NSDictionary使用原理
1.NSDictionary（字典）是使用hash表來實(shí)現(xiàn)key和value之間的映射和存儲(chǔ)的，hash函數(shù)設(shè)計(jì)的好壞影響著數(shù)據(jù)的查找訪問效率。
-(void)setObject:(id)anObject forKey:(id)aKey;
2.Objective-C中的字典NSDictionary底層其實(shí)是一個(gè)哈希表，實(shí)際上絕大多數(shù)語言中字典都通過哈希表實(shí)現(xiàn).
二、哈希的原理
1.根據(jù)key計(jì)算出它的哈希值h。
2.假設(shè)箱子的個(gè)數(shù)為n，那么這個(gè)鍵值對(duì)應(yīng)該放在第(h % n)個(gè)箱子中。
3.如果該箱子中已經(jīng)有了鍵值對(duì)，就使用 開放尋址法 或者 拉鏈法 解決沖突。
在使用拉鏈法解決哈希沖突時(shí)，每個(gè)箱子其實(shí)是一個(gè)鏈表，屬于同一個(gè)箱子的所有鍵值對(duì)都會(huì)排列在鏈表中。
哈希表還有一個(gè)重要的屬性:負(fù)載因子(load factor)，它用來衡量哈希表的空/滿程度，一定程度上也可以體現(xiàn)查詢的效率，計(jì)算公式為:
負(fù)載因子=總鍵值對(duì)數(shù)/箱子個(gè)數(shù)
負(fù)載因子越大，意味著哈希表越滿，越容易導(dǎo)致沖突，性能也就越低。因此，一般來說，當(dāng)負(fù)載因子大于某個(gè)常數(shù)(可能是1，或者0.75等)時(shí)，哈希表將自動(dòng)擴(kuò)容。
哈希表在自動(dòng)擴(kuò)容時(shí)，一般會(huì)創(chuàng)建兩倍于原來個(gè)數(shù)的箱子，因此即使key的哈希值不變，對(duì)箱子個(gè)數(shù)取余的結(jié)果也會(huì)發(fā)生改變，因此所有鍵值對(duì)的存放位置都有可能發(fā)生改變，這個(gè)過程也稱為重哈希(rehash)。
哈希表的擴(kuò)容并不總是能夠有效解決負(fù)載因子過大的問題。假設(shè)所有key的哈希值都一樣，那么即使擴(kuò)容以后他們的位置也不會(huì)變化。雖然負(fù)載因子會(huì)降低，但實(shí)際存儲(chǔ)在每個(gè)箱子中的鏈表長度并不發(fā)生改變，因此也就不能提高哈希表的查詢性能。
四、總結(jié)，細(xì)心的讀者可能會(huì)發(fā)現(xiàn)哈希表的兩個(gè)問題:
1.如果哈希表中本來箱子就比較多，擴(kuò)容時(shí)需要重新哈希并移動(dòng)數(shù)據(jù)，性能影響較大。
2.如果哈希函數(shù)設(shè)計(jì)不合理，哈希表在極端情況下會(huì)變成線性表，性能極低。
關(guān)于hash表
想想一下，我們有一個(gè)數(shù)組，數(shù)組長度是100個(gè)，現(xiàn)在的需求是：給出這個(gè)數(shù)組是否包含一個(gè)對(duì)象obj？
如果這是個(gè)無序的數(shù)組，那么我們只能用遍歷的方法來查找是否包含這個(gè)對(duì)象obj了。這是我們的時(shí)間復(fù)雜度就是O(n)。
這種查找效率是很低的，所以hash表應(yīng)運(yùn)而生。
hash表其實(shí)也是一個(gè)數(shù)組，區(qū)別數(shù)組的地方是它會(huì)建立 存儲(chǔ)的值 到 存儲(chǔ)的下標(biāo) 索引的一個(gè)映射，也就是散列函數(shù)。
我們來舉一個(gè)通俗易懂的例子：
現(xiàn)在我們有個(gè)hash表，表長度count = 16，現(xiàn)在我們依次把3，12，24，30依次存入hash表中。
首先我們來約定一個(gè)簡單的映射關(guān)系：存儲(chǔ)的索引下表(index) = 存儲(chǔ)值(value) % hash表長度(count)；
[注：實(shí)際的映射并不是簡單的存儲(chǔ)值，而是經(jīng)過計(jì)算得到的hash值]
算下來hash表的存儲(chǔ)分布是這樣的：hash[3] = 3、hash[12] = 12、hash[8] = 24、hash[14] = 30
還是一樣的需求，當(dāng)我們給出24的時(shí)候，求出hash表中是否存有24？
此時(shí)，按照原先約定的映射關(guān)系：index = 24 % 16 = 8，然后我們?cè)趆ash[8]查詢等于24。這樣，通過數(shù)組需要O(n)的時(shí)間復(fù)雜度，通過hash表只需要O(1)；
散列碰撞
上面提到的hash表在存入3，12，24，30后，如果要面臨存入19呢？
此時(shí)index = 19 % 16 = 3，而之前hash[3] 已經(jīng)存入了3這個(gè)值了！這種情況就是發(fā)送了散列碰撞。
此時(shí)，我們可以改進(jìn)一下我們的hash表，讓它存儲(chǔ)的是一個(gè)鏈表。這樣發(fā)送散列碰撞的元素就可以以鏈表的形式共處在hash表的某一個(gè)下標(biāo)位置了。
廢話少說，直接看圖說問題
出現(xiàn)原因：
這個(gè) iOS升級(jí)為64位系統(tǒng)后，指針也是64位，蘋果為了速度和節(jié)省內(nèi)存，整出來的taggedpointer如果整數(shù)值能用60位表示，就生成NSTaggedPointerNumber的類，如果ascii字符串 小于等于9位 就生成NSTaggedPointerString的類，這個(gè)對(duì)開發(fā)者使用和NSStringNSNumber沒什么區(qū)別，還能提升性能，只不要直接訪問類的 isa指針就好了。（引用作者說明： 朱曉曉的技術(shù)博客 ? 關(guān)注 ）
也就是說，當(dāng)OC中的數(shù)據(jù)，所占用的內(nèi)存字節(jié)數(shù)9位的時(shí)候，系統(tǒng)回對(duì)數(shù)據(jù)做優(yōu)化處理。
解決方法：
1:將NSString類型的修飾詞改為copy形式
2:將解析出來的數(shù)據(jù)直接深拷貝一份mutableCopy
3:上述方法若不行，直接采取最笨的方式，將NSTaggedPointerString類型的字符串與另外一個(gè)字符串拼接，注意一定是與其他字符拼接起來，然后再拆分。
如：假設(shè) a是“NSTaggedPointerString類型”的字符串，a = @"110"；
NSString b =??[NSString stringWithFormat:@"%@%@",a,@","];
//將其與一個(gè)@“逗號(hào)”拼接起來，然后拆分
重慶分公司
重慶分公司
