鉴于ABRecordID可以在云同步和其他情况下在我无法控制的情况下更改，我如何维护对IOS通讯簿记录的长期引用？
Apple提供以下指导:
“建议长期保留对特定记录的引用的方法是，除了标识符之外，还存储名字和姓氏，或者名字和姓氏的哈希值。当您通过ID查找记录时，请进行比较记录的名称与您存储的名称。如果它们不匹配，请使用存储的名称查找记录，并存储该记录的新ID。”
但是我不明白这个指导。如果地址簿中可以包含重复的名称，并且由于用户可以在记录中修改名称，那么该建议将如何工作？
例如，如果用户修改了地址簿记录的名称，则我的例程将无法通过ABRecordID找到它，因此，如果我认为按我存储的名称哈希搜索无法找到该特定名称的重复名称，而不是新的ABRecordID我以前引用的记录？
最后，获得对IOS AddressBook记录的长期引用的最佳方法是什么？如果上述建议确实有效，那我会缺少什么呢？
最佳答案
最健壮的方法(尚未完全失效保护)是对ABRecord字段进行优先级排序，并从该列表中将尽可能多的可用记录与ABRecordID一起存储为您自己的(散列)私有(private)记录格式。检索私有(private)记录时(或在其他方便的时间)，您可以验证私有(private)记录是否与ABRecord匹配，并通过一系列后备检查来确保其准确性。
优先级排序示例:
检索记录时，您可以首先匹配
ABRecordID。如果没有返回结果，则可以搜索FirstName + LastName。然后，您可以将这些结果与PhoneNumber ...等进行匹配。这样，您就可以区分2个Bob Smiths，因为它们可能具有不同的电话号码(或者一个可能没有电话号码)。当然，根据优先级列表的长短，此机制将更可靠。不得已而为之的是提示用户区分两个Bob Smiths和两个新的
ABRecordID，它们的记录在其他方面是相同的-毕竟，这种不便的提示比允许用户联系错误的Bob Smith(就像我说的那样，将是不得已的选择)。但是，AB的此解决方案可能涉及一些同步问题。
对于使用iOS Media Player的任何人来说，这都是一个熟悉的问题。具体来说，用户音乐库中的
MPMediaItems具有MPMediaItemPropertyPersistentID属性，文档将其描述为:换句话说，
PersistentID不能保证是持久的。解决方案包括对MediaItem属性进行类似的后备检查。关于iphone - 长期引用IOS地址簿条目，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/14763688/