iOS—NSCoding—将数据存储在PList vs Documents目录中

iOS—NSCoding—将数据存储在PList vs Documents目录中,ios,Ios,当我可以将编码数据存储在结构化字典中时,为什么要将其存储在plist中 例如,在苹果的学习材料中,他们这样做: “let notes = [note1, note2, note3]   let archivedNotes = NSKeyedArchiver.archiveRootObject(notes, toFile: archiveURL.path)” 基本上只是在某条路径中抛出一段数据 但我见过有人使用Plist文件存储NSCoded数据。一种策略相对于另一种策略有什么优势?是否有任何人

当我可以将编码数据存储在结构化字典中时,为什么要将其存储在plist中

例如,在苹果的学习材料中,他们这样做:

“let notes = [note1, note2, note3]
 
let archivedNotes = NSKeyedArchiver.archiveRootObject(notes,
toFile: archiveURL.path)”
基本上只是在某条路径中抛出一段数据

但我见过有人使用Plist文件存储NSCoded数据。一种策略相对于另一种策略有什么优势?是否有任何人都可以指导我使用存储数据的最佳实践

Plists似乎给了你一些有键的数据的价值(punn不是故意的),但是你不能用你的不同数据片段的键制作一个字典吗?

有关为什么,当你捕获一个层次对象图时,为什么要“编码”(由
NSCoder
及其子类实现)是使对象图持久化的首选方法:

序列化将Objective-C类型转换为与体系结构无关的字节流。与归档不同,基本序列化不记录值的数据类型或它们之间的关系;仅记录值本身。您有责任按正确的顺序反序列化数据

属性列表序列化不保留对象的完整类标识,只保留其一般类型—字典、数组等。因此,如果将属性列表序列化然后反序列化,则结果属性列表中的对象可能与原始属性列表中的对象不属于同一类。特别是,当序列化属性列表时,容器对象(
NSDictionary
NSArray
对象)的可变性不会保留。但是,在反序列化时,可以选择创建所有容器对象,使其可变或不可变

序列化也不会跟踪多次引用的对象的存在。对属性列表中对象的每个引用都单独序列化,在反序列化时会产生多个实例

由于序列化不会保留类信息或可变性,也不会处理多个引用,因此编码(由
NSCoder
及其子类实现)是使对象图持久化的首选方法

总之,您通常更喜欢使用
NSKeyedArchiver
(或者在Swift 4中,
PropertyListEncoder
),因为它捕获有关已编码类的信息,并且可以捕获更丰富的类型

话虽如此,plist非常简单,通常以文本格式呈现,这样可以方便地直观地检查生成的数据,并可以看到捕获的内容。通常,如果你在处理一个简单的列表,plists是一个简单的解决方案