iosopenudid过滤

『壹』 ios应用可以根据哪些数据识别设备

凡是接触过iOS的开发者都清楚每一台iOS设备都有一个唯一的识别号：UDID，这个40位的字符串是你的设备区别于其他任何一台设备的唯一标识。
这个字符串用处非常大，我们可以把它作为用户的唯一ID，跳过用户登陆这一步，直接有效并且安全地与数据库中的用户记录进行绑定。
虽然UDID本身并不含有任何用户信息，但是由于应用开发者可以将UDID与服务器上用户信息进行绑定，从而带来了诸多隐私泄漏等问题，所以苹果最终还是拒绝开发者访问UDID的官方接口，建议开发者使用CFUUID来代替UDID。CFUUID有很多问题，如果从一台设备将系统备份到另一个设备，两个设备就会拥有相同的CFUUID，如果从临时文件中备份系统，就会出现一个设备中出现不同的CFUUID，但是尽管如此，CFUUID还是所有UDID替代品中最靠谱的一个。
除此之外，一些第三方开发者也基于CFUUID包装了对用户更友好的类，OpenUDID是开发者使用的比较广泛的一个。
对于AIR开发者来说，仅此还是不够的。今天我给大家开放一个基于OpenUDID的ANE，使用它可以在AIR项目中通过ActionScript接口来获得设备的OpenUDID。
AS类OpenUDID是一个静态类，它只有一个静态属性UDID，使用方法用一行代码表示如下：
var id:String = OpenUDID.UDID;

就这么简单。

『贰』 ios怎么获取openudid

查看IOS固件验证关闭的方法：1、使用itunes刷机时会提示3194错误，代表当前固件验证已经关闭。2、检查刷入固件的版本是否为最新的，若固件版本为IOS8.1，而苹果推出的最新固件为IOS8.1.1，则IOS8.1的固件肯定被关闭。3、使用第三方刷机助手，检测SHSH是否已经无法获取，无法获取表明固件已经关闭验证。

『叁』 ios 第三方分享组件 哪个最好

网络通信
1、ASIHTTPRequest
这是一个经典的老库，功能完全而强大，但已经停止更新很久了(iOS5.0停止更新，但是我最近看github上这个项目有新改动)。在不同iOS版本上略微有一些小问题(提醒显示上的)，所以用的时候还是稍微修改一下比较好。
下载地址：https://github.com/pokeb/asi-http-request

2、AFNetworking
轻量级的通讯类库，使用非常简单。
下载地址：https://github.com/AFNetworking/AFNetworking
3、MKNetworkKit
最近做的不错的一个通讯类库，具有AFNetworking和ASIHTTPRequest双方的优点，甚至功能更丰富一些，但是本人还没有使用过。
下载地址：https://github.com/MugunthKumar/MKNetworkKit
Socket
1、CocoaAsyncSocket
CocoaAsyncSocket是用的最广泛的socket开发库，省略了程序员与CFNetwork接触的时间，延长了程序员寿命。
下载地址：https://github.com/robbiehanson/CocoaAsyncSocket
2、SocketRocket
SocketRocket是Square开发的一个实现webSocket的库，可以轻松的实现即时通信。
下载地址：https://github.com/square/SocketRocket
数据解析
1、SBJSON
SBJson的解析速度其实是比较慢的，但是不知道为什么它却是用的最广的。
下载地址：

2、JSONKit
JSONKit解析速度上最接近iOS原生解析类，当然iOS5.0才开始支持原生解析，所以选择一个库还是很必要的。
下载地址：https://github.com/johnezang/JSONKit

3、TouchJSON
TouchJSON用的也比较广泛.
下载地址：https://github.com/TouchCode/TouchJSON

4、json-framework
没有用过。
下载地址：https://github.com/stig/json-framework
5、TBXML
TBXML是一套轻量级的DOM方式的XML解析类库，有很好的性能和低内存占用，不过它不对XML格式进行校验，不支持XPath，并且只支持解析，不支持对XML进行修改。
下载地址：https://github.com/71squared/TBXML

6、TouchXML
TouchXML这也是一套DOM方式的XML解析类库，支持XPath，不支持XML的修改。
下载地址：https://github.com/TouchCode/TouchXML

7、KissXML
KissXML这是一套基于TouchXML的XML解析类库，只不过实现了支持XML的修改。
下载地址：https://github.com/robbiehanson/KissXML

8、GDataXML
GDataXML是Google开发的DOM方式XML解析类库，支持读取和修改XML文档，支持XPath方式查询。
下载地址：

第三方管理
1、fmdb
fmdb是一个数据库管理库，封装了sqlite相关的sql语句，简化数据库操作。
下载地址：https://github.com/ccgus/fmdb
2、ssziparchive
ssziparchive与sstoolkit是同一个作者，这哥们儿简直是个天才。
https://github.com/soffes/ssziparchive
3、ZipArchive
ZipArchive同样是minizip的封装。
https://github.com/mattconnolly/ZipArchive
4、Objective-Zip
Objective-Zip将Zlib和MiniZip用Objective-C进行了封装，使用起来非常简单。
https://github.com/flyingdolphinstudio/Objective-Zip
5、zxing
zxing是一个开源Java类库用于解析多种格式的1D/2D条形码。目标是能够对QR编码、DataMatrix、UPC的1D条形码进行解码。 其提供了多种平台下的客户端。
https://github.com/zxing/zxing
6、ZBar
ZBar 是款桌面电脑用条形码/二维码扫描工具，支持摄像头及图片扫描，支持多平台包括 iPhone 手机。同时 ZBar提供了二维码扫描的 API 开发包。
https://github.com/ZBar/ZBar
7、ObjQREncoder
ObjQREncoder 是 Objective-C 的二维码的编码器，用于生成二维码图像。
https://github.com/jverkoey/ObjQREncoder
8、OpenUDID
OpenUDID是iOS禁止使用系统UDID之后的新解决方法。
https://github.com/ylechelle/OpenUDID
9、RegexKitLite
RegexKitLite 是一个轻量级的 Objective-C 的正则表达式库，支持 Mac OS X 和 iOS，使用ICU 库开发。
https://github.com/wezm/RegexKitLite
10、STUtils
STUtils是一系列的工具集，包含了很多对于iOS原生类的扩展，当然也包含一个用于安全保存用户密码STKeyChain。
https://github.com/ldandersen/STUtils
11、scifihifi-iphone
scifihifi-iphone用于安全保存用户密码到keychain中。
https://github.com/ldandersen/scifihifi-iphone
12、sskeychain
sskeychain同scifihifi-iphone一样，不过属于轻量级。
https://github.com/soffes/sskeychain
13、SDWebImage
SDWebImage调用网站上的图片，跟本地调用内置在应用包里的图片一样简单。操作也很简单。
https://github.com/rs/SDWebImage
14、umeng
umeng既有统计分析，也有社会化组件。但是统计分析的用户数似乎明显多于其社会化组件的用户。
http://dev.umeng.com/analytics/ios/sdk-download

第三方UI
1、appirater
appirater是一个可以直接使用到任何iPhone应用中的开源类，用于提醒用户在打开App时，对应用进行评论或打分。
下载地址：https://github.com/arashpayan/appirater
2、FDStatusBarNotifierView
FDStatusBarNotifierView 实现了在状态栏中显示自定义提醒信息的功能。
下载地址：https://github.com/frankdilo/FDStatusBarNotifierView
3、MTStatusBarOverlay
MTStatusBarOverlay 是一个定制的 iOS状态栏，用于覆盖系统默认的状态栏。
下载地址：https://github.com/myell0w/MTStatusBarOverlay
4、iCarousel
iCarousel 是一个用来简化在 iOS 上实现旋转木马时的视图切换效果，支持 iPad，提供多种切换效果。
下载地址：https://github.com/nicklockwood/iCarousel
5、MBProgressHUD
MBProgressHUD就不多说了，伟大的菊花。
下载地址：https://github.com/jdg/MBProgressHUD
6、SVProgressHUD
SVProgressHUD是一个轻量级的菊花。
下载地址：https://github.com/samvermette/SVProgressHUD
7、MWPhotoBrowser
MWPhotoBrowser 实现了一个照片浏览器类似 iOS自带的相册应用，可显示来自手机的图片或者是网络图片，可自动从网络下载图片并进行缓存。可对图片进行缩放等操作。
下载地址：https://github.com/mwaterfall/MWPhotoBrowser
8、ShareSDK
ShareSDK支持分享到新浪微博、微信好友、微信朋友圈、QQ好友、腾迅微博、QQ空间、人人网、开心网、豆瓣、搜狐微博、网易微博、短信、邮件、打印、拷贝等。但是由于这个SDK包很大，所以用的时候一定要精简一下。下载地址：http://sharesdk.cn/Download

『肆』 如何在cocos2d-x中获取手机设备ID

你是指唯一标识吗 ？
目前的版本 苹果禁掉了大多数的唯一标识获取方式 包括以前的UUID mac地址等 现在我们采用OpenUDID 一个开源的方法 你可以网络
每台iOS设备的UDID是唯一且永远不会改变；
每台iOS设备的OpenUDID是通过第一个带有OpenUDID SDK包的App生成，如果你完全删除全部带有OpenUDID SDK包的App（比如恢复系统等），那么OpenUDID会重新生成，而且和之前的值会不同，相当于新设备；
是否足够替代
普通的iOS设备用户不会没事就去恢复系统或者抹掉系统，所以一般OpenUDID的值是不会改变的；
在iOS系统升级换代时，会产生较大的影响，毕竟95%以上的iOS设备用户都会选择升级到最新的系统；
是否足够替代就看你对UDID的需求是什么了，如果要求怎么都不能变，那OpenUDID可能还是不能满足你的需求！

『伍』 ios开发者 能拿到 iphone用户什么id

下面我将列出iOS中目前支持的，以及被废弃的唯一标示符方法，并对其做出相应的解释，希望可以帮你做出正确的确定。

CFUUID
从iOS2.0开始，CFUUID就已经出现了。它是CoreFoundatio包的一部分，因此API属于C语言风格。CFUUIDCreate方法用来创建CFUUIDRef，并且可以获得一个相应的NSString，如下代码：
CFUUIDRef cfuuid = CFUUIDCreate(kCFAllocatorDefault);NSString *cfuuidString = (NSString*)CFBridgingRelease(CFUUIDCreateString(kCFAllocatorDefault, cfuuid));

获得的这个CFUUID值系统并没有存储。每次调用CFUUIDCreate，系统都会返回一个新的唯一标示符。如果你希望存储这个标示符，那么需要自己将其存储到NSUserDefaults, Keychain, Pasteboard或其它地方。

NSUUID
NSUUID在iOS 6中才出现，这跟CFUUID几乎完全一样，只不过它是Objective-C接口。+ (id)UUID 是一个类方法，调用该方法可以获得一个UUID。通过下面的代码可以获得一个UUID字符串：
NSString *uuid = [[NSUUID UUID] UUIDString];

跟CFUUID一样，这个值系统也不会存储，每次调用的时候都会获得一个新的唯一标示符。如果要存储的话，你需要自己存储。在我读取NSUUID时，注意到获取到的这个值跟CFUUID完全一样（不过也可能不一样）：
示例: 68753A44-4D6F-1226-9C60-0050E4C00067

广告标示符（IDFA-identifierForIdentifier）
这是iOS 6中另外一个新的方法，advertisingIdentifier是新框架AdSupport.framework的一部分。ASIdentifierManager单例提供了一个方法advertisingIdentifier，通过调用该方法会返回一个上面提到的NSUUID实例。
NSString *adId = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];

跟CFUUID和NSUUID不一样，广告标示符是由系统存储着的。不过即使这是由系统存储的，但是有几种情况下，会重新生成广告标示符。如果用户完全重置系统（(设置程序 -> 通用 -> 还原 -> 还原位置与隐私) ，这个广告标示符会重新生成。另外如果用户明确的还原广告(设置程序-> 通用 -> 关于本机 -> 广告 -> 还原广告标示符) ，那么广告标示符也会重新生成。关于广告标示符的还原，有一点需要注意：如果程序在后台运行，此时用户“还原广告标示符”，然后再回到程序中，此时获取广告标示符并不会立即获得还原后的标示符。必须要终止程序，然后再重新启动程序，才能获得还原后的广告标示符。之所以会这样，我猜测是由于ASIdentifierManager是一个单例。

针对广告标示符用户有一个可控的开关“限制广告跟踪”。Nick Arnott的文章中已经指出了。将这个开关打开，实际上什么也没有做，不过这是希望限制你访问广告标示符。这个开关是一个简单的boolean标志，当将广告标示符发到任意的服务器端时，你最好判断一下这个值，然后再做决定。
示例: 1E2DFA89-496A-47FD-9941-DF1FC4E6484A

Vindor标示符 (IDFV-identifierForVendor)
这种叫法也是在iOS 6中新增的，不过获取这个IDFV的新方法被添加在已有的UIDevice类中。跟advertisingIdentifier一样，该方法返回的是一个NSUUID对象。
NSString *idfv = [[[UIDevice currentDevice] identifierForVendor] UUIDString];

苹果官方的文档中对identifierForVendor有如下这样的一段描述 ：
The value of this property is the same for apps that come from the same vendor running on the same device. A different value is returned for apps on the same device that come from different vendors, and for apps on different devices regardless of vendor.

如果满足这样的条件，那么获取到的这个属性值就不会变：相同的一个程序里面-相同的vindor-相同的设备。如果是这样的情况，那么这个值是不会相同的：相同的程序-相同的设备-不同的vindor，或者是相同的程序-不同的设备-无论是否相同的vindor。

看完上面的内容，我有这样的一个疑问“vendor是什么”。我首先想到的是苹果开发者账号。但事实证明这是错误的。接着我想可能是有一个AppIdentifierPrefix东西，跟钥匙串访问一样，可以在多个程序间共享。同样，这个想法也是的。最后证明，vendor非常简单：一个Vendor是CFBundleIdentifier（反转DNS格式）的前两部分。例如，com.doubleencore.app1 和 com.doubleencore.app2 得到的identifierForVendor是相同的，因为它们的CFBundleIdentifier 前两部分是相同的。不过这样获得的identifierForVendor则完全不同：com.massivelyoverrated 或 net.doubleencore。

在这里，还需要注意的一点就是：如果用户卸载了同一个vendor对应的所有程序，然后在重新安装同一个vendor提供的程序，此时identifierForVendor会被重置。
示例: 599F9C00-92DC-4B5C-9464-7971F01F8370

UDID
在之前的版本中是可用的，但是在iOS5以及之后的版本中，以及被弃用了。虽然，这个UDID用得很广泛，但是，不得不说的是，它在慢慢的远离开发者，不能在考虑使用UDID了。至于这个标示符是转为私有方法，或者完全从以后的iOS版本中移除，还有待观察。不过，这个UDID在部署企业级签名程序时，非常方便。获取UDID的方法如下：
NSString *udid = [[UIDevice currentDevice] uniqueIdentifier];
示例:

OpenUDID
在iOS 5发布时，uniqueIdentifier被弃用了，这引起了广大开发者需要寻找一个可以替代UDID，并且不受苹果控制的方案。由此OpenUDID成为了当时使用最广泛的开源UDID替代方案。OpenUDID在工程中实现起来非常简单，并且还支持一系列的广告提供商。
NSString *openUDID = [OpenUDID value];

OpenUDID利用了一个非常巧妙的方法在不同程序间存储标示符 — 在粘贴板中用了一个特殊的名称来存储标示符。通过这种方法，别的程序（同样使用了OpenUDID）知道去什么地方获取已经生成的标示符（而不用再生成一个新的）。

之前已经提到过，在将来，苹果将开始强制使用advertisingIdentifier 或identifierForVendor。如果这一天到来的话，即使OpenUDID看起来是非常不错的选择，但是你可能不得不过渡到苹果推出的方法。
示例:

『陆』 UDID和OPENUDID被禁用之后如何进行APP的数据分析呢

现阶段而言，这些方式可能都要改变，主要有以下几点：
1、iOS7中，已经无法访问mac地址，通过api访问mac地址得到的是 02：00：00：00这个，完全没用了；
2、以前的UDID的替换方式是 mac address + bundle identifer 然后md5生成的一个字串；
3、综上所述，OpenUDID 以及 UDID都不是最终的解决方案。

貌似iOS里面有一个Ad identifer的东西，类似mac地址，但是这个东西可以用户人为的重置，所以也不是上佳方案。暂时还没用完整的解决方案。

『柒』 OpenUDID 是什么

UDID是设备的识别码。一般运用在电子产品上。Open UDID就是告诉你要输入识别码。现在苹果目前在 iOS 应用审核中加入了一项新政策，禁止应用访问设备的唯一身份标识符（UDID）

『捌』 OpenUDID 是否足够替代 UDID 使用有何不同

每台iOS设备的OpenUDID是通过第一个带有OpenUDID SDK包的App生成，如果你完全删除全部带有OpenUDID SDK包的App（比如恢复系统等），那么OpenUDID会重新生成，而且和之前的值会不同，相当于新设备；是否足够替代
普通的iOS设备用户不会没事就去恢复系统或者抹掉系统，所以一般OpenUDID的值是不会改变的；

『玖』 苹果手机的设备识别码是什么东西

1、UDID ，全称是 （Unique Device Identifier），顾名思义，它就是苹果 iOS 设备的唯一识别码，它由 40 个字符的字母和数字组成，为了保护用户隐私苹果已经禁止读取这个标识了。

2、UUID，全称是（Universally Unique IDentifier），是基于 iOS 设备上面某个单个的应用程序，只要用户没有完全删除应用程序，则这个 UUID 在用户使用该应用程序的时候一直保持不变。如果用户删除了这个应用程序，然后再重新安装，那么这个 UUID 已经发生了改变。UUID 不好的地方就是用户删除了你开发的程序以后，基本上你就不可能获取之前的数据了。

3、MAC 地址，用来定义网络设备的位置。一个主机会有一个 MAC 地址，MAC 地址是网卡决定的，是固定的，为了保护用户隐私苹果已经禁止读取这个标识了。

4、OpenUDID，不是苹果官方的，是一个替代 UDID 的第三发解决方案， 缺点是如果你完全删除全部带有 OpenUDID SDK 包的 App（比如恢复系统等），那么 OpenUDID 会重新生成，而且和之前的值会不同，相当于新设备；

5、IDFA 广告标示符，适用于对外：例如广告推广，换量等跨应用的用户追踪等。IDFA 是苹果 iOS 6 开始新增的广告标识符，英文全称是 Identifier for Advertising ，用于给开发者跟踪广告效果用的，可以简单理解为 iPhone 的设备临时身份证，说是临时身份证是因为它允许用户更换，IDFA 存储在用户 iOS 系统上，同一设备上的应用获取到的 IDFA 是相同的。iOS 用户可以通过「设置」-「通用」-「还原」-「还原位置与隐私」更换 IDFA，iOS 10 系统开始提供禁止广告跟踪功能，用户勾选这个功能后，应用程序将无法读取到设备的 IDFA。

6、IDFV，Vindor 标示符 (IDFV-identifierForVendor)，来自同一个开发商（例如 com.hu.app1 和 com.hu.app2）的应用运行在同一个设备上，此属性的值是相同的；不同的运营商应用运行在同一个设备上值不同。

『拾』 明明就是iOS系统的，结果微信要安装苹果定制版的居然提示这个，求助怎么回事，有谁知道的求告知

您好！很高兴能为您解答， 拒绝 iOS 应用获取设备的 UDID的原因
UDID本来是为了方便一个应用来统计用户行为的，但是因为是一个唯一ID，而且直接看不到跟用户隐私的关系，所以是开放出来的。但是，当有大量的App在市场中，而UDID对于每个App都是一样的时候，用户的隐私其实受到了一定程度的侵犯。假设有很多App联合在一起，因为UDID是统一的，那么他们就可以拼凑出用户的隐私出来。所以从这个角度苹果去掉了UDID的支持，而每个应用可以自行生成自己的UUID，所以，单一app的统计仍旧不会发生问题。所以主要的原因是隐私问题。
、必须使用UDID时建议的UUID替代方案

-(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 instry-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。但是仔细分析，还是能发现问题。

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 = [: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更合适的选择。但是，苹果现在不让用了，苦逼的开发者们，该怎么办呢？