鉴于 ABRecordID 可以在云同步之间以及在我无法控制的其他情况下更改，我如何才能保持对 IOS 通讯录记录的长期引用？
Apple 提供以下指导：
“保持对特定记录的长期引用的推荐方法是存储名字和姓氏，或名字和姓氏的哈希值，以及标识符。当您通过 ID 查找记录时，比较将记录的名称与您的存储名称匹配。如果它们不匹配，请使用存储的名称查找记录，并为记录存储新的 ID。
但我不明白这个指导。如果地址簿中可以有重复的名称，并且由于用户可以修改记录中的名称，那么这个建议如何工作？
例如，如果用户修改了地址簿记录的名称，我的例程将无法通过 ABRecordID 找到它，所以如果我认为按我存储的名称哈希搜索我找不到重复的名称而不是新的 ABRecordID我之前引用的记录？
最后，获得对 IOS 地址簿记录的长期引用的最佳方法是什么？如果上述建议确实有效，我错过了什么？
最强大（但不是完全故障保护）的方法是对 ABRecord 字段进行优先级排序，并将该列表中可用的尽可能多的内容与 ABRecordID 一起存储到您自己的（散列的）私有记录格式中。在检索私人记录时（或在其他方便的时间），您可以验证私人记录是否与 ABRecord 匹配，并通过一系列后备检查来确保其准确无误。
优先级排序示例：
检索记录时，您可以先匹配ABRecordID. 如果没有返回结果，您可以搜索FirstName + LastName. 然后，您可以将这些结果与PhoneNumber... 等进行匹配。通过这种方式，您可以潜在地区分 2 个 Bob Smith，因为它们可能有不同的电话号码（或者一个可能没有电话号码）。当然，根据你的优先级列表有多长，这个机制会越健壮。
最后的手段是提示用户将 2 Bob Smiths 与其他记录相同的全新 Bob Smiths 区分开来ABRecordID——毕竟，这样不方便的提示比允许用户联系错误的 Bob Smith（和正如我所说，将是最后的手段）。
但是，此 AB 解决方案可能涉及一些同步问题。
对于使用过 iOS 媒体播放器的任何人来说，这都是一个熟悉的问题。特别MPMediaItems是在用户的音乐库中有一个属性MPMediaItemPropertyPersistentID，文档描述为：
不保证该值在同步/非同步/同步周期内保持不变。
换句话说，PersistentID不保证是持久的。MediaItem解决方案包括对属性进行类似的后备检查。
RecordID 仅在删除或重置时更改，完成此操作后，所有新记录也将具有新的 createdProperty 和 modifiedProperty。
当我第一次阅读地址簿时，我会将记录的所有条目连同 RecordID 一起保存在我的数据库中。
我将保存联系人上次从联系人同步到我的数据库的时间（将其命名为：lastSyncedTime）并将其存储在某个位置。
我已经完成了第一次同步联系人的工作，现在请执行以下操作以便将来随时同步。
在遍历所有记录时，
检查 createdTime(kABPersonCreationDateProperty) 与 lastSyncedTime。如果 createdTime > lastSyncedTime，将 recordID 存储在“newRecords”NSArray 中。
如果！（步骤 1）然后检查 modifiedDate(kABPersonModificationDateProperty) 与 lastSyncedTime。如果 modifiedDate > lastSyncedTime，则将 recordID 存储在“modifiedRecords”NSArray 中。
if !(1) && !(2) 将所有 recordID 存储在“unModifiedRecords”中。
现在我将从本地数据库中读取所有联系人，
我将删除在“modifiedRecords”或“unModifiedRecords”中找不到的所有本地数据库记录。
我将更新本地数据库中的所有“modifiedRecords”。
我将为“newRecords”中的所有记录创建新记录。
相应地更新 lastSyncedTime。
该文档正在与您沟通，您不能将 ABRecordID 视为永久标识符。
考虑这种情况：用户有“Bob Smith”的记录。然后用户删除他的“Bob Smith”记录，然后通过 iTunes 同步从他的计算机导入他的联系人（创建一个新 ID）。
因此，如果您想保留对现有联系人的永久引用，您可以保留对姓名和 ID 的引用，以暗示它与您之前使用的记录相同——但没有真正的永久引用。
如果您保留对地址簿联系人的永久引用，则您必须始终准备好处理这样一个事实，即它可能与您以前使用的联系人不同。