iOS设备的UDID是什么？苹果为什么拒绝获取iOS设备UDID的应用？如何替代UDID？
本文讲诉的主要是为什么苹果2011年8月发布iOS 5后就开始拒绝App获取设备的UDID以及UDID替补方案，特别提醒开发者苹果App Store禁止访问UDID的应用上架（相关推荐：APP被苹果App Store拒绝的N个原因），下面先来了解下UDID。
一、UDID是什么？
UDID的全称是Unique Device Identifier，顾名思义，它就是苹果IOS设备的唯一识别码，它由40个字符的字母和数字组成。
二、UDID有什么用？
移动网络可利用UDID来识别移动设备，如iPhone和iPad。UDID对每台设备而言都是唯一的，从而成为了广告公司、市场分析机构和APP测试系统跟踪用户行为的实用工具。
目前使用UDID主要原因分为：
- 1）用于统计与分析，例如第三方统计工具Flurry、友盟等，广告商ADMOB等；
- 2）将UDID作为用户ID来唯一识别用户，省去用户名，密码等注册过程。
由此可见UDID对于IOS应用开发者说，是个很重要的信息（虽然越狱的设备通过某些工具可以改变设备的UDID）。但是，从IOS5.0（2011年8月份）开始，苹果宣布将不再支持用以下方法获取设备的UDID。
| 1 | [UIDevice currentDevice] uniqueIdentifier]; |
三、拒绝 iOS 应用获取设备的 UDID的原因
UDID本来是为了方便一个应用来统计用户行为的，但是因为是一个唯一ID，而且直接看不到跟用户隐私的关系，所以是开放出来的。但是，当有大量的App在市场中，而UDID对于每个App都是一样的时候，用户的隐私其实受到了一定程度的侵犯。假设有很多App联合在一起，因为UDID是统一的，那么他们就可以拼凑出用户的隐私出来。所以从这个角度苹果去掉了UDID的支持，而每个应用可以自行生成自己的UUID，所以，单一app的统计仍旧不会发生问题。所以主要的原因是隐私问题。
四、必须使用UDID时建议的UUID替代方案
1、苹果公司建议的UUID替代方案
| 1 2 3 4 5 6 7 8 | -(NSString*) uuid { CFUUIDRef puuid = CFUUIDCreate( nil ); CFStringRef uuidString = CFUUIDCreateString( nil, puuid ); NSString * result = (NSString *)CFStringCreateCopy( NULL, uuidString); CFRelease(puuid); CFRelease(uuidString); return [result autorelease]; } |
苹果公司建议采用上述代码为应用生成唯一标识字符串。开发者可以在应用第一次启动时调用一次，然后将该串存储起来，以便以后替代UDID来使用。显而易见，这种方法问题很多。如果用户删除该应用再次安装时，又会生成新的字符串，所以不能保证唯一识别该设备；如果你从一台旧设备中备份文件到新设备中，两台设备就拥有相同的CFUUID；如果你从临时文件中备份操作系统，就会出现一个设备里存在不同CFUUID的情况。
2、使用开源方案OpenUDID
贡献者在readme文档中说：
OpenUDID is a drop-in replacement for the deprecated [UIDevice uniqueIdentifier] a.k.a. UDID on iOS, and otherwise is an industry-friendly equivalent for iOS and Android.
The agenda for this community driven project is to: – Provide a reliable proxy and replacement for a universal unique device identifier. That is, persistent and sufficiently unique, on a per device basis. – NOT use an obvious other sensitive unique identifier (like the MAC address) to avoid further deprecation and to protect device-level privacy concerns – Enable the same OpenUDID to be accessed by any app on the same device – Supply open-source code to generate and access the OpenUDID, for iOS and Android – Incorporate, from the beginning, a system that will enable user opt-out to match Apple’s initial intent.
愿景很好，也确实没有用到MAC地址，同时能保证同一台设备上的不同应用使用同一个OpenUDID。但是仔细分析，还是能发现问题。
OpenUDID生成唯一识别码的代码是：
| 1 2 3 4 5 6 7 8 9 10 | unsigned char result[16]; const char *cStr = [[[NSProcessInfo processInfo] globallyUniqueString] UTF8String]; CC_MD5( cStr, strlen(cStr), result ); _openUDID = [NSStringstringWithFormat: @"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%08x", result[0], result[1], result[2], result[3], result[4], result[5], result[6], result[7], result[8], result[9], result[10], result[11], result[12], result[13], result[14], result[15], arc4random() % 4294967295]; |
这里使用了NSProcessInfo类。
当设备上第一个使用OpenUDID解决方案的应用第一次调用时，确实会生成一个唯一的识别码。同时，为了与官方的UDID位数相同，还在MD5值后面追加了8位随机码。然后，该方案使用到了NSUserDefaults类（应用设置）。应用将获取到的唯一识别码保存到应用的UserDefaults中，如果程序以后需要使用唯一识别码，就从UserDefaults中获取，这样就保证可以拿到同一个识别码。但是，如果用户删除了应用，UserDefaults同样会被清空，为了避免重新生成唯一识别码，该方案还使用到了UIPasteboard类（设备剪切板）。应用在将唯一识别码保存到UserDefaults的同时，也会将其保存到以特殊的key标识的UIPasteboard中。代码如：
| 1 2 | UIPasteboard* slotPB = [UIPasteboardpasteboardWithName:availableSlotPBid create:YES]; [slotPB setData:[NSKeyedArchiver archivedDataWithRootObject:dict] forPasteboardType:kOpenUDIDDomain]; |
其中availableSlotPBid是一个字符串key，前缀是“org.OpenUDID.slot.”，点后面加上数字。这个数字默认是从0到99（当然你可以修改源代码使它更大或者更小）。
如果设备上安装了第二个使用OpenUDID解决方案的应用，当应用调用生成OpenUDID的方法时，将会从UIPasteboard中获取唯一识别码（遍历key从0到99的UIPasteboard），这里取到的就是之前第一个应用保存到UIPasteboard中的。也就是说，只要用户设备上有一个使用了OpenUDID的应用存在时，其他后续安装的应用如果获取OpenUDID，都将会获得第一个应用生成的那个。
看起来似乎很好，很复杂。但是仔细想想，还是有问题，如果把使用了OpenUDID方案的应用全部都删除，再重新获取OpenUDID，此时的OpenUDID就跟以前的不一样了（本人测了一下，确实如此）。可见，这种方法还是不保险。
3、开源方案SecureUDID
稍微看了下SecureUDID源码，发现其与OpenUDID其实差不多，只是初始获取的唯一识别码稍有不同。同时，从作者的Readme文档中可见，这个方案同样存在很多问题。如原文：
Is this a true UDID replacement?
SecureUDID has two properties that you should know about before you use it. First, as indicated above, the identifier is not derived from hardware attributes. Second, the persistence of an identifier cannot be guaranteed in all situations. This means that, while unlikely, it is technically possible for two distinct devices to report the same identifier, and for the same device to report different identifiers. Consider this carefully in your application. Here is a list of situations where this identifier will not exhibit the uniqueness/persistence of a traditional UDID.
* The user has opted-out of the SecureUDID system, in which case you will receive a well-formed string of zeroes.
* Device A is backed up and then restored to Device B, which is an identical model. This is common when someone breaks their phone, for example, and is likely desirable: you will receive Device A’s SecureUDID.
* The SecureUDID data is removed, via user intervention, UIPasteboard data purge, or by a malicious application.
* The SecureUDID backing store becomes corrupt.
* All SecureUDID applications are uninstalled from a device, followed by a UIPasteboard data purge.
我发现，其实前面的OpenUDID也基本存在以上问题，只是作者没写出来。看来还是SecureUDID的贡献者比较厚道。
4、与WIFI MAC地址相关
网上同样有一些与WIFI MAC地址相关的替代方案，主要分三种：第一种直接使用“MAC Address”；第二种，使用“MD5(MAC Address)”；第三种，“MD5(MAC Address+CFBundleIdentifier)”。github上有个开源项目（UIDevice-with-UniqueIdentifier-for-iOS-5）实现了这几种方法。
使用这种方法也存在问题：1、市面上有部分机器（虽然数量极少，但是本人在使用过程中确实发现过这种情况）无法获得MAC地址，有人说这部分机器是联通阉割无WIFI版的，具体不得而知了。2、MAC地址跟UDID一样，存在隐私问题。苹果现在禁用UDID，不能保证以后不会禁用MAC地址。
5、部分大公司私有的解决方案，但是他们怎么会告诉你呢？
所以，如果你想以一种万无一失的方法追踪某台设备，现在还没有比UDID更合适的选择。但是，苹果现在不让用了，苦逼的开发者们，该怎么办呢？