ios开发字典,ios字典怎么用

iOS 中数组和字典的可变拷贝

  在iOS开发过程中,我们有时候会有这样的需求,将一个 不可变的字典或者数组转换为可变的,可以使用系统的mutableCopy方法,但是这样只是第一层可变,如果数组或字典有多层时,我们去修改值深层次的值时,会发生崩溃,这样并不能达到预期的要求,可以给数组和字典添加分类来实现这个功能。

成都创新互联从2013年创立,先为静乐等服务建站,静乐等地企业,进行企业商务咨询服务。为静乐企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。

可以自己定义一个文件

.h 文件中

.m 文件中

只要导入头文件,字典调用mutableDicDeepCopy,字典中所有value(数组或者字典)无论多少层都是可变的,数组调用mutableArrayDeeoCopy,数组中所有的元素(数组或者字典) 无论多少层也是可变的,可以直接取修改字典或数组中元素的值。

iOS 开发:Runtime(详解六)字典转模型

在日常开发中,将网络请求中获取的 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。

iOS 字典的实现原理

一、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开发解析NSDictionary字典数据中Key值出现NSTaggedPointerString*类型的处理

废话少说,直接看图说问题

出现原因:

这个 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,@","];

//将其与一个@“逗号”拼接起来,然后拆分


本文标题:ios开发字典,ios字典怎么用
网页路径:http://myzitong.com/article/hogpds.html