iOS平台UDID方案比较

http://www.cnblogs.com/zhw511006/p/3152179.html

苹果在iOS6中禁用了[UIDevice uniqueIdentifier]，在iOS7中又把mac地址的获取给堵上了。没办法，毕竟人家是老大，说不让你用，你也没办法。
在这边总结一下现有的一部分UDID获取方法（有苹果推荐的，也有第三方的），目的在于抛砖，没有切实的说明哪种方法好用。用哪种方法，完全由大家自己根据需要来决定。

iOS2~iOS7目前已有的技术方案

方案	提供方	实现方法	用途及使用情况
传统UDID	苹果API	UIDevice的实例方法uniqueIdentifier直接可获取	● 获取设备的唯一识别码 ● 在iOS5及之前的版本中，基本上使用该方法来获取UDID。
MAC+MD5	UNIX系统调用	使用UNIX API获取设备的MAC地址，再使用MD5加密算法生成一个字符串	● 由于苹果在iOS6后停用了UDID方案，所以大部分应用都开始使用这种方案来生成设备的唯一识别码
CFUUID/NSUUID	苹果API	通过唯一标识设备的一个值(通常是以太网硬件地址)和一个时间值来生成一个唯一标识串	● 苹果建议基于CFUUID来生成一个UDID，然后将其存在程序中使用
IDFV	苹果API	UIDevice的实例方法identifierForVendor	● 用于标识供应商
ADID	苹果API	ASIdentifierManager的实例方法advertisingIdentifier	● 用于广告服务
OpenUDID	第三方开源代码	以CFUUID为基础生成一个串，并同时存储于系统剪切板和程序的沙盒(NSUserDefault)中，应用程序从这两个地方之一获取UDID	● 在苹果宣布禁用传统UDID方案后，这是目前使用较为广泛的开源方案，包括友盟在内的很多开发商都使用这一方案。
SecureUDID	第三方开源代码	以CFUUID为基础生成一个串，并同时存储于程序剪切板中，程序可以从该剪切板中获取UDID	●在苹果宣布禁用传统UDID方案后，部分应用也采用了该方案(目前github上数据显示该方案下载量仅次于OpenUDID，具体使用情况未知)

系统支持情况
苹果在iOS6以后，已禁用了UIDevice的uniqueIdentifier方法，所以传统的UDID方法在iOS6以后已不能使用；而从iOS7开始，获取MAC地址的方法统一返回02:00:00:00:00:00，所以使用MAC+MD5方法已无意义。
                                                                                                                              

方案	iOS 2	iOS 3	iOS 4	iOS 5	iOS 6	iOS 7
UDID	√	√	√	√	×	×
MAC+MD5	√	√	√	√	√	×
CFUUID	√	√	√	√	√	√
NSUUID	×	×	×	×	√	√
IDFV	×	×	×	×	√	√
Ad ID	×	×	×	×	√	√
OpenUDID	?	√	√	√	√	√
SecureUDID	?	√	√	√	√	√

持久化情况
                                                                                                                                                

	启动程序	从后台返回	重置广告标识	重新安装程序	系统重启	系统还原设置	升级系统	重装系统
传统UDID	√	√	√	√	√	√	√	√
MAC+MD5	√	√	√	√	√	√	√	√
CFUUID/NSUUID	×	×	×	×	×	×	×	×
IDFV	√	√	√	×	√	×	？√	？×
ADID	√	√	×	√	√	×	？√	？×
OpenUDID	√	√	√	√	√	×	？√	？×
SecureUDID	√	√	√	×	√	×	？√	？×

注：

√表示能够保证UDID的持久化，

×表示该情况下UDID可能会丢失改变，?表示该种情况没有实际验证过，纯属猜测(毕竟升级系统什么的太麻烦)

 

优缺点
                                    

	优点	缺点
CFUUID/NSUUID		● 删除程序再安装时，会生成新的UDID
IDFV	● 对于运行于同一设备上的同一供应商的所有程序，该值都是相同的。	● 对于同一设备上不同供应商的程序，该值是不同的   ● 所谓同一供应商是由CFBundleIdentifier中的反转DNS前两部分来确定，如com.test1和com.test2即认为不是同一供应商   ● 用户如果删除同一供应商的所有程序，再安装该供应商的程序时，该值会改变。   ● 该值在程序运行于后台时，或用户在重启系统后第一次解锁设备可能返回nil值。
ADID	● 该值由系统持久化   ● 即使用户限制广告跟踪，也可以使用该值来统计用户数量、安全等方面的操作   ● 该值对于所有的供应商都是一样的	● 只能用于广告服务的程序访问一个唯一标识   ● 如果用户还原所有系统设置或还原广告标识符时，可能重置该值。   ● 该值在程序运行于后台时，或用户在重启系统后第一次解锁设备可能返回nil值。
OpenUDID	● 同一台设备上使用OpenUDID的所有程序其获取到的UDID都是相同的   ● 没有用到取MAC地址等可能被苹果禁用的API	● 在系统恢复设置或刷机的情况下会丢失   ● 非苹果原生API
SecureUDID	●对于运行于同一设备上的同一供应商的所有程序，该值都是相同的(供应商自己控制)。这样防止因一个程序外泄UDID，而导致设备的UDID外泄   ● 与硬件设备无关	● 不能确保不同设备上的UDID不同   ● 用户可以选择阻止SecureUDID收集UDID信息   ● 如果用户备份A设备系统并将其恢复到B设备，则B设备将得到A设备的UDID   ● 删除程序并清空剪切板可能会导致丢失   ● 非苹果原生的API

注：优缺点是个人判断，还请各位看官指正


参考文献
● http://www.doubleencore.com/2013/04/unique-identifiers/
● Apple开发文档

http://www.cocoachina.com/bbs/read.php?tid=144524

http://mobile.51cto.com/iphone-390802.htm

以下为亲测：

openudid对于相同开发者账号下的应用，值唯一，可用作设备唯一标识，对于不同开发者账号下的应用，值仍然不同。

而真正可用于设备唯一标识的只有广告id，弊端是苹果禁止没有广告功能的应用乱用该id

至于identifierForVendor，对于不同应用的值是不同的，对于同一应用卸载充装值是一样的，因此openudid可用作设备中某一应用的唯一标识（有点类似devicetoken）

结合下表，其实把广告id存放在keychain中就可以最大限度得到设备唯一标识，但在设备抹掉所有数据后仍然会改变，这种情况下算是无解了

情况	IDFA	存于Keychain的IDFA	OpenUDID	存于Keychain的OpenUDID
删除应用	不会改变	不会改变，也不会被删除	不会改变	不会改变，也不会被删除
手机还原所有设置	不会改变	不会改变，也不会被删除	不会改变	不会改变，也不会被删除
手机抹掉所有数据	改变	被删除	改变	被删除
还原广告标识符	改变	原存于Keychain的数据没变化 除非重新写入	不会改变	不会改变，也不会被删除
同一设备 不同开发者的应用	不会改变	不会改变，也不会被删除	改变	如果没有重新写入keychain，则为NULL

现在苹果明确的表明你应该使用-[UIDevice identifierForVendor]或是-[ASIdentifierManager advertisingIdentifier]来作为你框架和应用的唯一标示符。坦白的来说，应对这些变化也不是那么的难，见以下代码片段：

    NSString *identifierForVendor = [[UIDevice currentDevice].identifierForVendor UUIDString];
    NSString *identifierForAdvertising = [[ASIdentifierManager sharedManager].advertisingIdentifier UUIDString];

每种方法都适配一种特别的用法：

　　identifierForVendor对供应商来说是唯一的一个值，也就是说，由同一个公司发行的的app在相同的设备上运行的时候都会有这个相同的标识符。然而，如果用户删除了这个供应商的app然后再重新安装的话，这个标识符就会不一致。

　　advertisingIdentifier会返回给在这个设备上所有软件供应商相同的 一个值，所以只能在广告的时候使用。这个值会因为很多情况而有所变化，比如说用户初始化设备的时候便会改变。