[转]对IOS设备中UDID的一些思考

[转]对IOS设备中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开始,苹果宣布将不再支持用以下方法获取设备的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地址。

        参考地址:http://blog.csdn.net/jwzbskywz/article/details/7703140

转载于:https://www.cnblogs.com/85538649/archive/2013/03/28/2986096.html

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请联系我们举报,一经查实,本站将立刻删除。

发布者:全栈程序员-站长,转载请注明出处:https://javaforall.net/110177.html原文链接:https://javaforall.net

(0)
全栈程序员-站长的头像全栈程序员-站长


相关推荐

  • protege5.5_ProE4.0

    protege5.5_ProE4.0OWL本体的重要组成部分Individuals:个体,代表一个领域里面的对象。可以理解成一个类的实例(instancesofclasses)。Properties:属性,是两个个体之间的双重联

    2022年8月4日
    9
  • 字符串常量池概述[通俗易懂]

    字符串常量池概述[通俗易懂]字符串常量池概述常量池表(Constant_Pooltable)Class文件中存储所有常量(包括字符串)的table。这是Class文件中的内容,还不是运行时的内容,不要理解它是个池子,其实就是Class文件中的字节码指令。运行时常量池(RuntimeConstantPool)JVM内存中方法区的一部分,这是运行时的内容。这部分内容(绝大部分)是随着JVM运行时候,从常量池转化而来,每个Class对应一个运行时常量池。上一句中说绝大部分是因为:除了Class中常量池内容,还可能包括

    2022年7月28日
    11
  • Empirical Evaluation of Rectified Activations in Convolutional Network笔记

    Empirical Evaluation of Rectified Activations in Convolutional Network笔记链接 https arxiv org abs 1505 00853 摘要论文研究集中不同的 ReLU 对网络性能的影响 包括 ReLU LeakyReLU 带参数的 LeakyReLU 就是 PReLU 以及参数随机的 RReLU 以往的看法是 ReLU 的良好性能来自参数的稀疏性 但实验结果表明负数部分斜率不为 0 的 ReLU 性能要好一些 在小的数据集上 采用 LeakyReLU 或者 PReLu 都容易造成过

    2025年10月4日
    4
  • Java动态加载类(java动态加载代码)

    通过java、JavaScript和css实现点击按钮后出现灰色遮罩层,并显示动态加载的字样,提高用户体验,废话不多说,上代码(写这个博客的原因是网上代码太多新手根本不知道哪里对哪里,这里剔除所有无关代码,只显示可以出现功能的最少代码)。第一:效果图为第二:实现如上效果的代码为1:遮罩层css代码#load{position:fixed;top:0px;right:0px;bottom:0…

    2022年4月13日
    44
  • 使用phpMyAdmin批量修改Mysql数据表前缀的方法

    使用phpMyAdmin批量修改Mysql数据表前缀的方法

    2021年10月14日
    38
  • 外地人在北京的真实状态(漫画)

    这就是外地人在北京的真实状态! 北京这个城市看似中国的首都,实则在这里很不容易,但是感谢阿Q的存在,能把这种苦逼包装成一种高大上的状态。早上每天5:30起床睡眠不足,我们包装成早期…

    2021年6月21日
    187

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注

关注全栈程序员社区公众号