对IOS设备中UDID的一些思考

本文转载至 http://blog.csdn.net/happyrabbit456/article/details/11565209

http://blog.csdn.net/xiaoguan2008一家之言，难免存在纰漏，欢迎指正，勿吐槽。

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开始，苹果宣布将不再支持用以下方法获取设备的UDID。

1. [UIDevice currentDevice] uniqueIdentifier];

最近又爆出苹果App Store禁止访问UDID的应用上架，所以开发者应尽快弃用UDID，去寻找另外的替代方案。

我为此也花了不少时间去寻找比较好的替代方案，下面一一道来：
        一、苹果公司建议的UUID替代方案

1. -(NSString*) uuid {
2. CFUUIDRef puuid = CFUUIDCreate( nil );
3. CFStringRef uuidString = CFUUIDCreateString( nil, puuid );
4. NSString * result = (NSString *)CFStringCreateCopy( NULL, uuidString);
5. CFRelease(puuid);
6. CFRelease(uuidString);
7. return [result autorelease];
8. }

苹果公司建议采用上述代码为应用生成唯一标识字符串。开发者可以在应用第一次启动时调用一次，然后将该串存储起来，以便以后替代UDID来使用。显而易见，这种方法问题很多。如果用户删除该应用再次安装时，又会生成新的字符串，所以不能保证唯一识别该设备；如果你从一台旧设备中备份文件到新设备中，两台设备就拥有相同的CFUUID；如果你从临时文件中备份操作系统，就会出现一个设备里存在不同CFUUID的情况。

二、开源方案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. unsigned char result[16];
2. const char *cStr = [[[NSProcessInfo processInfo] globallyUniqueString] UTF8String];
3. CC_MD5( cStr, strlen(cStr), result );
4. _openUDID = [NSStringstringWithFormat:
5. @"%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%02x%08x",
6. result[0], result[1], result[2], result[3],
7. result[4], result[5], result[6], result[7],
8. result[8], result[9], result[10], result[11],
9. result[12], result[13], result[14], result[15],
10. arc4random() % 4294967295];

这里使用了NSProcessInfo类。
        当设备上第一个使用OpenUDID解决方案的应用第一次调用时，确实会生成一个唯一的识别码。同时，为了与官方的UDID位数相同，还在MD5值后面追加了8位随机码。然后，该方案使用到了NSUserDefaults类（应用设置）。应用将获取到的唯一识别码保存到应用的UserDefaults中，如果程序以后需要使用唯一识别码，就从UserDefaults中获取，这样就保证可以拿到同一个识别码。但是，如果用户删除了应用，UserDefaults同样会被清空，为了避免重新生成唯一识别码，该方案还使用到了UIPasteboard类（设备剪切板）。应用在将唯一识别码保存到UserDefaults的同时，也会将其保存到以特殊的key标识的UIPasteboard中。代码如：

1. UIPasteboard* slotPB = [UIPasteboardpasteboardWithName:availableSlotPBid create:YES];
2. [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就跟以前的不一样了（本人测了一下，确实如此）。可见，这种方法还是不保险。

三、开源方案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的贡献者比较厚道。

四、与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地址。

五、部分大公司私有的解决方案，但是他们怎么会告诉你呢？

所以，如果你想以一种万无一失的方法追踪某台设备，现在还没有比UDID更合适的选择。但是，苹果现在不让用了，苦逼的开发者们，该怎么办呢？

参考：

http://www.cnblogs.com/zhulin/archive/2012/03/26/2417860.html

http://www.iteye.com/news/24661