设备 UDID 的替代方案 - 准备自己 [重复]答案

【问题标题】：An alternative to the device UDID - preparing ourselves [duplicate]设备 UDID 的替代方案 - 准备自己 [重复]
【发布时间】：2012-04-09 04:09:03
【问题描述】：

可能重复：
UIDevice uniqueIdentifier Deprecated - What To Do Now?

我知道有很多关于 SO 的问题，但我认为由于 Apple 提前并积极拒绝使用 UDID 的应用程序 (http://pulse.me/s/7mzKE)，我们的开发人员需要采取积极的行动接近并批量讨论这个问题。

所以问题是 - 除了访问它的 UDID 属性之外，什么是唯一设备标识的良好、稳定和正确的替代方案？

【问题讨论】：

标签： ios app-store udid

【解决方案1】：

虽然我认为这不是典型的“我如何克服这个特定的技术挑战”，但我同意它非常重要，并且可以在 SO 中以某种方式很好地讨论（不确定 - wiki？论坛？）。我很想知道是否有关于Flurry beat this 的讨论。

【讨论】：

他们不是唯一能够克服这个问题的人。我阅读了其他几种方法，但主要问题是现在我们正在寻找一种非集中式解决方案，这对我们的开发人员来说将是一个巨大的痛苦。感谢您的回复

【解决方案2】：

这取决于您的需求...如果您正在寻找一个简单的设备标识符供您的应用程序使用，那么关于已弃用的 uniqueIdentifier 方法的文档几乎可以为您提供答案：

不要使用 uniqueIdentifier 属性。要创建特定于您的应用的唯一标识符，您可以调用 CFUUIDCreate 函数来创建 UUID，然后使用 NSUserDefaults 类将其写入默认数据库。

CFUUIDCreate 将返回一个对您的应用程序唯一的手机标识符。您需要将其存储在NSUserDefaults 中，因为如果您进行后续调用，它会改变。对于大多数用途来说，这已经足够了，而且 Apple 并没有就这一变化提供足够的警告（iOS 5 已经发布了六个多月，而开发者文档的时间也更长了）。

其他场景是您需要在应用程序（即移动广告网络）之间共享您的设备标识符。这是一个更复杂的问题，有许多替代选项（也不能保证它们将来会继续存在：Apple 弃用 UDID API 的主要原因可能是停止跨应用程序用户跟踪） .

【讨论】：

当用户删除并重新安装您的应用时，CFUUID 会有所不同。
您始终可以将其保存到钥匙串中，而不是用户默认值，在这种情况下，普通的删除/重新安装不会影响它。为最终用户合理删除钥匙串条目的唯一方法是彻底擦除设备。
但是当备份恢复时，NSUserDefaults 不会恢复到新设备上吗？在这种情况下，它不是唯一的设备标识符。
没有 UDID 的推送通知如何工作
推送通知不使用 UDID - 当用户选择接收通知时，它们使用设备生成的设备令牌。它们可以而且确实因应用而异。

【解决方案3】：

在任何无线通信期间，协议规范已经公开了设备 2 或 3 MAC 地址中的一个。

【讨论】：

不能再使用mac地址了

【解决方案4】：

我个人最喜欢的是 OpenUDID。

您可以获取 GitHub here。

我已经总结了我的想法并简要描述了它here。

【讨论】：

查看代码，它只是执行 NSUserDefaults 中的 UUID 技巧，如此处另一个答案中所述。
@Nestor - 我错过了。不过，将它放在 lib 中非常好，特别是如果它被广泛采用并且我们再次获得标准设备标识符！
OpenUDID 不是恢复安全的。如果用户恢复设备，OpenUDID 会更改。这让它没那么有用了，恕我直言。
现已弃用，请参阅以下链接：github.com/ylechelle/OpenUDID 和 blog.appsfire.com/…

【解决方案5】：

SecureUDID，基于 OpenUDID 但更安全，只能由域（和 salt）访问

More info.

【讨论】：