189 8069 5689
在iOS开发过程中，我们有时候会有这样的需求，将一个 不可变的字典或者数组转换为可变的，可以使用系统的mutableCopy方法，但是这样只是第一层可变，如果数组或字典有多层时，我们去修改值深层次的值时，会发生崩溃，这样并不能达到预期的要求，可以给数组和字典添加分类来实现这个功能。
成都创新互联从2013年创立，先为静乐等服务建站，静乐等地企业，进行企业商务咨询服务。为静乐企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
可以自己定义一个文件
.h 文件中
.m 文件中
只要导入头文件，字典调用mutableDicDeepCopy，字典中所有value(数组或者字典)无论多少层都是可变的，数组调用mutableArrayDeeoCopy，数组中所有的元素(数组或者字典) 无论多少层也是可变的，可以直接取修改字典或数组中元素的值。
在日常开发中，将网络请求中获取的 JSON 数据转为数据模型，是我们开发中必不可少的操作。
通常我们会选用诸如 YYModel 、 JSONModel 或者 MJExtension 等第三方框架来实现这一过程。这些框架实现原理的核心就是 Runtime 和 KVC ，以及 Getter / Setter 。
实现的大体思路如下：借助 Runtime 可以动态获取 成员列表 的特性，遍历模型中所有属性，然后以获取到的属性名为 key ，在 JSON 字典中寻找对应的值 value ；再使用 KVC 或直接调用 Getter / Setter 将每一个对应 value 赋值给模型，就完成了字典转模型的目的。
从这份 JSON 中可以看出，字典中取值除了 字符串 之外，还有 数组 和 字典 。那么在将字典转换成数据模型的时候，就要考虑 模型嵌套模型 、 模型嵌套模型数组 的情况了。
经过分析，我们总共需要三个模型： XXStudentModel、XXAdressModel、XXCourseModel。
NSObject+XXModel.h、NSObject+XXModel.m 就是我们用来解决字典转模型所创建的分类，协议中的 + (NSDictionary *)modelContainerPropertyGenericClass 方法用来告诉分类特殊字段的处理规则，比如 id -- uid。
一、NSDictionary使用原理
1.NSDictionary（字典）是使用hash表来实现key和value之间的映射和存储的，hash函数设计的好坏影响着数据的查找访问效率。
-(void)setObject:(id)anObject forKey:(id)aKey;
2.Objective-C中的字典NSDictionary底层其实是一个哈希表，实际上绝大多数语言中字典都通过哈希表实现.
二、哈希的原理
1.根据key计算出它的哈希值h。
2.假设箱子的个数为n，那么这个键值对应该放在第(h % n)个箱子中。
3.如果该箱子中已经有了键值对，就使用 开放寻址法 或者 拉链法 解决冲突。
在使用拉链法解决哈希冲突时，每个箱子其实是一个链表，属于同一个箱子的所有键值对都会排列在链表中。
哈希表还有一个重要的属性:负载因子(load factor)，它用来衡量哈希表的空/满程度，一定程度上也可以体现查询的效率，计算公式为:
负载因子=总键值对数/箱子个数
负载因子越大，意味着哈希表越满，越容易导致冲突，性能也就越低。因此，一般来说，当负载因子大于某个常数(可能是1，或者0.75等)时，哈希表将自动扩容。
哈希表在自动扩容时，一般会创建两倍于原来个数的箱子，因此即使key的哈希值不变，对箱子个数取余的结果也会发生改变，因此所有键值对的存放位置都有可能发生改变，这个过程也称为重哈希(rehash)。
哈希表的扩容并不总是能够有效解决负载因子过大的问题。假设所有key的哈希值都一样，那么即使扩容以后他们的位置也不会变化。虽然负载因子会降低，但实际存储在每个箱子中的链表长度并不发生改变，因此也就不能提高哈希表的查询性能。
四、总结，细心的读者可能会发现哈希表的两个问题:
1.如果哈希表中本来箱子就比较多，扩容时需要重新哈希并移动数据，性能影响较大。
2.如果哈希函数设计不合理，哈希表在极端情况下会变成线性表，性能极低。
关于hash表
想想一下，我们有一个数组，数组长度是100个，现在的需求是：给出这个数组是否包含一个对象obj？
如果这是个无序的数组，那么我们只能用遍历的方法来查找是否包含这个对象obj了。这是我们的时间复杂度就是O(n)。
这种查找效率是很低的，所以hash表应运而生。
hash表其实也是一个数组，区别数组的地方是它会建立 存储的值 到 存储的下标 索引的一个映射，也就是散列函数。
我们来举一个通俗易懂的例子：
现在我们有个hash表，表长度count = 16，现在我们依次把3，12，24，30依次存入hash表中。
首先我们来约定一个简单的映射关系：存储的索引下表(index) = 存储值(value) % hash表长度(count)；
[注：实际的映射并不是简单的存储值，而是经过计算得到的hash值]
算下来hash表的存储分布是这样的：hash[3] = 3、hash[12] = 12、hash[8] = 24、hash[14] = 30
还是一样的需求，当我们给出24的时候，求出hash表中是否存有24？
此时，按照原先约定的映射关系：index = 24 % 16 = 8，然后我们在hash[8]查询等于24。这样，通过数组需要O(n)的时间复杂度，通过hash表只需要O(1)；
散列碰撞
上面提到的hash表在存入3，12，24，30后，如果要面临存入19呢？
此时index = 19 % 16 = 3，而之前hash[3] 已经存入了3这个值了！这种情况就是发送了散列碰撞。
此时，我们可以改进一下我们的hash表，让它存储的是一个链表。这样发送散列碰撞的元素就可以以链表的形式共处在hash表的某一个下标位置了。
废话少说，直接看图说问题
出现原因：
这个 iOS升级为64位系统后，指针也是64位，苹果为了速度和节省内存，整出来的taggedpointer如果整数值能用60位表示，就生成NSTaggedPointerNumber的类，如果ascii字符串 小于等于9位 就生成NSTaggedPointerString的类，这个对开发者使用和NSStringNSNumber没什么区别，还能提升性能，只不要直接访问类的 isa指针就好了。（引用作者说明： 朱晓晓的技术博客 关注 ）
也就是说，当OC中的数据，所占用的内存字节数9位的时候，系统回对数据做优化处理。
解决方法：
1:将NSString类型的修饰词改为copy形式
2:将解析出来的数据直接深拷贝一份mutableCopy
3:上述方法若不行，直接采取最笨的方式，将NSTaggedPointerString类型的字符串与另外一个字符串拼接，注意一定是与其他字符拼接起来，然后再拆分。
如：假设 a是“NSTaggedPointerString类型”的字符串，a = @"110"；
NSString b = [NSString stringWithFormat:@"%@%@",a,@","];
//将其与一个@“逗号”拼接起来，然后拆分