&>&&>&&>&&>&利用网卡地址和OpenUDID，实现获取设备唯一标识的一种方案
利用网卡地址和OpenUDID，实现获取设备唯一标识的一种方案
上传大小：38KB
网卡地址（&iOS7的系统）
通过Unix级别的API去获取Wifi的网卡地址
该方法属于UDID替代方案中最为准确的一种 因为网卡地址不会因为刷机 还原设备而发生改变 故追求唯一性的厂商多选择此种方案
在iOS7之后 应用已经无法获取网卡地址 该方案在iOS7中也已经被废弃 所以可用于iOS7以前的系统
OpenUDID & iOS7的系统
开源的一个UDID替代方案 原理是利用应用间的剪贴板共享和本地一些必要的缓存信息 让多个应用间共享一个UUID
OpenUDID在官方废弃UDID接口之后 受到广泛的欢迎 可以说是现在大多数应用的UDID替代方法
OpenUDID在刷机 还原设备后就会产生新的UDID 事实上 由于剪贴板的特殊性 如果所有使用了OpenUDID的应用被全部卸载之后 再次安装的应用取到的OpenUDID将会是一个全新的值 &&网卡地址（&iOS7的系统）
通过Unix级别的API去获取Wifi的网卡地址
该方法属于UDID替代方案中最为准确的一种 因为网卡地址不会因为刷机 还原设备而发生改变 故追求唯一性的厂商多选择此种方案
在iOS7之后 应用已经无 [更多]...展开收缩
综合评分：4.8（4位用户评分）
所需积分：0
下载次数：57
审核通过送C币
创建者：nigelyq
创建者：liuyujie0514
课程推荐相关知识库
上传者其他资源上传者专辑
移动开发热门标签
VIP会员动态
您因违反CSDN下载频道规则而被锁定帐户，如有疑问，请联络:!
android服务器底层网络模块的设计方法
所需积分：0
剩余积分：720
您当前C币：0
可兑换下载积分：0
兑换下载分：
兑换失败，您当前C币不够，请先充值C币
消耗C币：0
你当前的下载分为234。
利用网卡地址和OpenUDID，实现获取设备唯一标识的一种方案
会员到期时间：
剩余下载次数：
你还不是VIP会员
开通VIP会员权限，免积分下载
你下载资源过于频繁，请输入验证码
您因违反CSDN下载频道规则而被锁定帐户，如有疑问，请联络:!
若举报审核通过，可奖励20下载分
被举报人：
举报的资源分：
请选择类型
资源无法下载
资源无法使用
标题与实际内容不符
含有危害国家安全内容
含有反动色情等内容
含广告内容
版权问题，侵犯个人或公司的版权
*详细原因：3239人阅读
Android开发（23）
首先结论是令人失望的，对于android来说，这是一个没有完美方案的问题。大家只能努力提高它的准确性，对于大的公司来说，可以自己开发出一套自己的机制，例如我上家公司成立过一个手机指纹的项目，专门处理设备唯一性的问题防止用户刷单，原理很简单，就是尽可能的把手机能读取到的信息获取到上传到后台，甚至令人发指的连当前电量都上传了，然后后台动态调整算法得出结论。如果目前对设备唯一标志敏感度不高，可以参考友盟的思路，实现一套自己简易版的deviceId，正常情况下应该够用了。友盟ID思路如下文：
简单来说，
Android系统根据IMEI号+MAC地址标识设备（独立用户）的唯一性；iOS系统根据OpenUDID标识设备（用户）的唯一性；WP系统根据ANID标识设备（用户）的唯一性，用户联网启动应用之后才能统计到。
但一个统计平台不可能以简单叠加的方式来统计最基础的用户数量数据，下文介绍了友盟UMID的基本原理和方案解析。
1.&基本概念
根据能否追踪到单个独立的设备, 可以将一个统计系统分为可区分统计（Discriminative Statistics）和不可区分统计（Non-Discriminative Statistics）。友盟提供的是可区分统计，也就是会利用一个身份标识符（Unique ID，以后简称 ID）长期追踪单个设备的数据。作为对比，早期的网站统计都是不可区分统计，例如页面访问次数，独立 IP 数等；现代的网站统计都是基于 Cookie 或硬件指纹的可区分统计。由于智能设备提供了足够多的硬件指纹和计算能力，友盟从第一天开始就专注于可区分统计。
大多数移动统计的 ID 都是通过系统 ID 生成的，包括但不限于 IMEI、MAC、Android ID。最著名的 ID 莫过于 UDID， 迫于隐私的压力，苹果最终废弃了 UDID 和 MAC 地址。
大多数网站统计都是基于 Cookie的，因此是暂态ID（Temporal ID）。OpenUDID 就是一个典型的暂态ID。
苹果的 IDFA 和 IDFV 都是系统ID，但是他们同时也是暂态ID。
由于可区分统计涉及到用户隐私，因此友盟在计算中使用的都不是系统 ID ，而是自己的 UMID。友盟不会向第三方[1]提供包含原始 ID 或 UMID 的数据，而是提供聚合后的结果。UMID 既不是系统ID也不是暂态ID，它是一个在不断演化的ID解决方案。本文将会解释友盟为什么要设计 UMID，又为何要不断地改进这个方案。
进行可区分统计的基础是确立一个可靠的身份标识符，这看上去是一个很简单的事情，只需要选择一个ID，或者人为构造一个类Cookie ID，就可以完成独立用户量、留存等分析。但遗憾的是，除了苹果已经废除的UDID，几乎没有一个接近完美的ID。
为了方便讨论，首先忽略假数据的存在，假设每个设备都有一个真实的身份标识X。可区分统计的目标是选择一个合适的身份标识I，使得基于I的统计结果尽可能地和 X 一致。
首先，我们引入两个概念ID冲突（Collision）和ID漂移（Jitter）。
对于某个设备集合（Device Cohort），在某个时间段内，总是可以测量 X 和 I 的数量，用 Count(X) 和 Count (I) 来表示。如果在足够短的时间内
[Java]&纯文本查看&复制代码
& Count(I)
我们称 I 是一个存在冲突的 ID。
对于某个设备集合（Device Cohort），在某个时间段内，总是可以测量 X 和 I 的数量，用 Count(X) 和 Count (I) 来表示。如果在足够长的时间内
[Java]&纯文本查看&复制代码
& Count(I)
则我们称 I 是一个存在漂移的 ID。
Android 设备的IMEI 就是一个存在严重冲突的 ID，根据我们的估算，其冲突率大于 3%。这是因为很多山寨机的IMEI 是相同的。
Android 设备的 MAC 也是一个存在冲突的ID，因为很多山寨机的MAC也是相同的。此外，MAC还是一个典型的存在严重漂移的 ID，这是因为 Android 的源代码中有一段随机生成MAC&&地址后24位的代码被滥用了（参考阅读:&）。
接下来，我们可以定性分析一下ID冲突和漂移对统计数据的影响：
当一个ID仅存在冲突的时候，利用这个ID统计的DAU和安装都会被低估，但是有可能会高估留存。但是这些影响都是温和的，例如5% 的ID冲突仅仅会导致DAU至多被低估 5%，而对留存的影响几乎可以忽略。
当一个ID仅存在漂移的时候，利用这个ID统计的DAU和安装都会被高估，同时会影响留存。当漂移较大的时候，对统计指标的影响是剧烈的。例如，一个每日漂移为5%的ID，可能会造成DAU被高估2%，但是会每天造成5%的虚假安装（这是因为漂移会影响所有用户，包括不活跃用户），同时这些虚假安装的留存在短期内偏高，但是长期留存则偏低（短期内没有漂移的时候就会偏高，时间长了，漂移了就会偏低）。任何类Cookie的ID都会有类似的性质，因此传统的网站统计正在全面转向更为可靠的设备指纹。
当一个ID既存在冲突又存在漂移的时候，利用这个ID统计出来的DAU和安装是完全不可靠的。以MAC地址为例，存在漂移的这部分设备的MAC地址会频繁变化，因此会制造大量的虚假安装，同时留存率非常低。对于用户量不大的应用而言，选择存在这类ID的后果是灾难性的。
综上所述，当ID的漂移和冲突足够小的时候，他们对可区分统计的影响都是可以忽略的。当这些误差不可忽略的时候，ID的冲突造成的影响是温和的，而ID的漂移则会严重干扰安装和留存统计。
3. ID选择iOS平台
随着苹果废弃UDID、MAC地址, 并且通过在iOS7上对剪贴板限制导致OpenUDID无法在不同应用间共享，标志着设备ID的控制权回到了苹果手中，也表明了苹果对用户隐私保护的决心。
在后iOS7时代，ID的选择是再清楚不过的，业内通用的ID主要是IDFA（即广告标示符，advertisingIdentifier）和IDFV（即vendor标示符，identifierForVendor）。IDFA适用于对外的广告推广、交叉推荐等跨应用的用户追踪；IDFV适用于用户在应用内的行为追踪。
当然，对于移动统计平台而言，必须要保证统计的兼容性和容错性。这也是为什么我们一直强调的是使用一个不断优化的UMID解决方案，而不是任何一个具体的ID。
Android平台
对于Android平台，由于系统生态的开放性，ID的选择也一直是一个头疼的问题。
（1）单一ID
如前文所述，IMEI和MAC都不是最好的ID。特别是MAC地址，几乎是一个不可用的ID。
（2）组合ID
有些开发者会选择使用多个ID合并成一个组合ID，例如
[Java]&纯文本查看&复制代码
= MD5( imei+mac+android_id)
利用前面的分析不难得出，组合ID将会极大地降低冲突，但是会放大漂移。对于组合ID而言，任何一个源ID的漂移都会造成它的漂移。
开发者应该尽量避免CID，一定要使用也需要避免使用MAC地址。如果已经在使用CID，那么请确保在下一个版本把CID当作一个Cookie ID持久化，只有在Cookie丢失的情况下才重新生成CID。这样的策略可以尽量保证ID的延续性，同时缓解漂移造成的影响。
4. 友盟的ID方案UMID
由于UMID还在演化之中，这里只能简单地解释UMID的生命周期。UMID是一个极度保守的ID，当一个设备被分配了某个UMID以后，友盟会尽量保证这个UMID不会发生变化。因此，UMID的生成策略受到了友盟历史数据的限制，最重要的设计目标是确保稳定性和数据一致性。友盟会持续地监控冲突和漂移，并且会尽量降低漂移，将冲突控制在合理的范围内。正如世界上没有永动机一样，UMID并不是一个完美的ID。
Prime Radiant
为进一步的提高ID质量，友盟推出了全新的SDK。这个版本的SDK从设计到发布用了差不多一年，内部代号是 Prime Radiant，来自阿西莫夫的科幻小说。通过Prime Radiant提供的新特性，友盟将能更好地监控ID信号源的质量，并且能够根据实际的数据来调整策略，充分利用设备ID和暂态ID的优势和劣势。Prime Radiant 还充分利用了智能设备的计算能力，利用密码学手段来提高数据质量和可靠性。
正是得益于Prime Radiant 测试阶段的数据，友盟才能精确地对各类ID的质量进行定量分析。本文的很多结论都离不开这些数据。对于关心数据质量和数据安全的开发者，建议升级友盟新版SDK 进行体验、测评。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：281690次
积分：2131
积分：2131
排名：第15699名
原创：29篇
评论：47条
(1)(1)(1)(2)(1)(2)(1)(2)(2)(1)(1)(2)(6)(2)(2)(3)(1)(1)(1)(2)(1)(1)(1)(1)小知识（159）
原文地址：/kf/648.html
英文原文：In iOS 7 and later, if you ask for the MAC address of an iOS device, the system returns the value 02:00:00:00:00:00. If you need to identify the device, use the identifierForVendor property of UIDevice instead. (Apps that need an identifier for their own
advertising purposes should consider using the advertisingIdentifier property of ASIdentifierManager instead.)
翻译：从iOS7及更高版本往后，如果你向ios设备请求获取mac地址，系统将返回一个固定值“02:00:00:00:00:00”，如果你需要识别设备的 唯一性，请使用UIDevice的identifierForVendor属性。（因广告目的而需要识别设备的应用，请考虑使用 ASIdentifierManager的advertisingIdentifier属性作为替代）
这个MAC地址是指什么？有什么用？
&&&&&& MAC(Medium/Media Access Control)地址，用来表示互联网上每一个站点的标识符，采用十六进制数表示，共六个字节（48位）。其中，前三个字节是由IEEE的注册管理机构 RA负责给不同厂家分配的代码(高位24位)，也称为“编制上唯一的标识符” （Organizationally Unique Identifier)，后三个字节(低位24位)由各厂家自行指派给生产的适配器接口，称为扩展标识符（唯一性）。
&&& MAC地址在网络上用来区分设备的唯一性，接入网络的设备都有一个MAC地址，他们肯定都是不同的，是唯一的。一部iPhone上可能有多个MAC地址，包括WIFI的、SIM的等，但是iTouch和iPad上就有一个WIFI的，因此只需获取WIFI的MAC地址就好了，也就是en0的地址。
&&&&& 形象的说，MAC地址就如同我们身份证上的身份证号码，具有全球唯一性。这样就可以非常好的标识设备唯一性，类似与苹果设备的UDID号，通常的用途有：1）用于一些统计与分析目的，利用用户的操作习惯和数据更好的规划产品；2）作为用户ID来唯一识别用户，可以用游客身份使用app又能在服务器端保存相应的信息，省去用户名、密码等注册过程。
那么，如何使用Mac地址生成设备的唯一标识呢？主要分三种：
1、直接使用“MAC Address”
2、使用“MD5(MAC Address)”
3、使用“MD5(Mac Address+bundle_id)”获得“机器＋应用”的唯一标识（bundle_id 是应用的唯一标识）
&&&&& iOS7之前，因为Mac地址是唯一的， 一般app开发者会采取第3种方式来识别安装对应app的设备。为什么会使用它？在iOS5之前，都是使用UDID的，后来被禁用。苹果推荐使用UUID 但是也有诸多问题，从而使用MAC地址。而MAC地址跟UDID一样，存在隐私问题，现在苹果新发布的iOS7上，如果请求Mac地址都会返回一个固定 值，那么Mac Address+bundle_id这个值大家的设备都变成一致的啦，跟UDID一样相当于被禁用。那么，要怎么标识设备唯一呢？
在iOS系统中，获取设备唯一标识的方法有很多：
一.UDID(Unique Device Identifier)
二.UUID(Universally Unique Identifier)
三.MAC Address
四.OPEN UDID
五.广告标示符（IDFA-identifierForIdentifier）
六.Vindor标示符 (IDFV-identifierForVendor)
七.推送token＋bundle_id
UDID的全称是Unique Device Identifier，它就是苹果IOS设备的唯一识别码，它由40个字符的字母和数字组成（越狱的设备通过某些工具可以改变设备的UDID）。移动网络可利用UDID来识别移动设备，但是，从IOS5.0（2011年8月份）开始，苹果宣布将不再支持用uniqueIdentifier方法获取设备的UDID，iOS5以下是可以用的。在日苹果已经通知开发者：从日起，访问UIDIDs的程序将不再被审核通过，替代的方案是开发者应该使用“在iOS 6中介绍的Vendor或Advertising标示符”。所以UDID是绝对不能用啦。
OPEN UDID，没有用到MAC地址，同时能保证同一台设备上的不同应用使用同一个OpenUDID，只要用户设备上有一个使用了OpenUDID的应用存在时，其他后续安装的应用如果获取OpenUDID，都将会获得第一个应用生成的那个。但是根据贡献者的代码和方法，和一些开发者的经验，如果把使用了OpenUDID方案的应用全部都删除，再重新获取OpenUDID，此时的OpenUDID就跟以前的不一样。可见，这种方法还是不保险。
广告标示符，是iOS 6中另外一个新的方法，提供了一个方法advertisingIdentifier，通过调用该方法会返回一个NSUUID实例，最后可以获得一个UUID，由系统存储着的。不过即使这是由系统存储的，但是有几种情况下，会重新生成广告标示符。如果用户完全重置系统（(设置程序 -& 通用 -& 还原 -& 还原位置与隐私) ，这个广告标示符会重新生成。另外如果用户明确的还原广告(设置程序-& 通用 -& 关于本机 -& 广告 -& 还原广告标示符) ，那么广告标示符也会重新生成。关于广告标示符的还原，有一点需要注意：如果程序在后台运行，此时用户“还原广告标示符”，然后再回到程序中，此时获取广
告标示符并不会立即获得还原后的标示符。必须要终止程序，然后再重新启动程序，才能获得还原后的广告标示符。
Vindor标示符，也是在iOS 6中新增的，跟advertisingIdentifier一样，该方法返回的是一个 NSUUID对象，可以获得一个UUID。如果满足条件“相同的一个程序里面-相同的vindor-相同的设备”，那么获取到的这个属性值就不会变。如果是“相同的程序-相同的设备-不同的vindor，或者是相同的程序-不同的设备-无论是否相同的vindor”这样的情况，那么这个值是不会相同的。
推送token＋bundle_id的方法：
1、应用中增加推送用来获取token
2、获取应用bundle_id
3、根据token+bundle_id进行散列运算
apple push token保证设备唯一，但必须有网络情况下才能工作，该方法不依赖于设备本身，但依赖于apple push，而苹果push有时候会抽风的。
UUID是Universally Unique Identifier的缩写，中文意思是通用唯一识别码。它是让分布式系统中的所有元素，都能有唯一的辨识资讯，而不需要透过中央控制端来做辨识资讯的指定。这样，每个人都可以建立不与其它人冲突的 UUID。在此情况下，就不需考虑数据库建立时的名称重复问题。苹果公司建议使用UUID为应用生成唯一标识字符串。
iOS中获取UUID的代码如下:&
-(NSString*)
&&&&CFUUIDRef
puuid = CFUUIDCreate( nil );&&
&&&&CFStringRef
uuidString = CFUUIDCreateString( nil, puuid );&&
&&&&NSString
* result = (NSString *)CFStringCreateCopy( NULL, uuidString);&&
&&&&CFRelease(puuid);&&
&&&&CFRelease(uuidString);&&
&&&&return
[result autorelease];&&
iOS中获取网卡mac的代码如下：
&sys/socket.h& // Per msqr&
&sys/sysctl.h&&
&net/if.h&&
&net/if_dl.h&&
mark MAC addy&
(NSString *) macaddress
&&&&int&&&&&&&&&&&&&&&&&&&
&&&&size_t&&&&&&&&&&&&&&&
&&&&char&&&&&&&&&&&&&&&
&&&&unsigned
char&&&&&&&
&&&&struct
if_msghdr&&& *
&&&&struct
sockaddr_dl&&& *
&&&&mib[0]
= CTL_NET;
&&&&mib[1]
= AF_ROUTE;
&&&&mib[2]
&&&&mib[3]
= AF_LINK;
&&&&mib[4]
= NET_RT_IFLIST;
((mib[5] = if_nametoindex(&en0&))
&&&&&&&&printf(&Error:
if_nametoindex error/n&);
&&&&&&&&return
(sysctl(mib, 6, NULL, &len, NULL, 0) & 0) {
&&&&&&&&printf(&Error:
sysctl, take 1/n&);
&&&&&&&&return
((buf = malloc(len))
== NULL) {
&&&&&&&&printf(&Could
not allocate memory. error!/n&);
&&&&&&&&return
(sysctl(mib, 6, buf, &len, NULL, 0) & 0) {
&&&&&&&&printf(&Error:
sysctl, take 2&);
&&&&&&&&return
if_msghdr *)
sockaddr_dl *)(ifm + 1);
= (unsigned char
*)LLADDR(sdl);
&&&&NSString
*outstring = [NSString stringWithFormat:@&%02x%02x%02x%02x%02x%02x&,
*ptr, *(ptr+1), *(ptr+2), *(ptr+3), *(ptr+4), *(ptr+5)];
&&&&free(buf);
&&&&return
[outstring uppercaseString];
iOS中获取UUID的代码如下:
-(NSString*)
&&&&CFUUIDRef
puuid = CFUUIDCreate( nil );
&&&&CFStringRef
uuidString = CFUUIDCreateString( nil, puuid );
&&&&NSString
* result = (NSString *)CFStringCreateCopy( NULL, uuidString);
&&&&CFRelease(puuid);
&&&&CFRelease(uuidString);
&&&&return
[result autorelease];
iOS中获取网卡mac的代码如下：
&sys/socket.h& // Per msqr
&sys/sysctl.h&
&net/if.h&
&net/if_dl.h&
mark MAC addy
(NSString *) macaddress
&&&&int&&&&&&&&&&&&&&&&&&&
&&&&size_t&&&&&&&&&&&&&&&
&&&&char&&&&&&&&&&&&&&&
&&&&unsigned
char&&&&&&&
&&&&struct
if_msghdr&&& *
&&&&struct
sockaddr_dl&&& *
&&&&mib[0]
= CTL_NET;
&&&&mib[1]
= AF_ROUTE;
&&&&mib[2]
&&&&mib[3]
= AF_LINK;
&&&&mib[4]
= NET_RT_IFLIST;
((mib[5] = if_nametoindex(&en0&))
&&&&&&&&printf(&Error:
if_nametoindex error/n&);
&&&&&&&&return
(sysctl(mib, 6, NULL, &len, NULL, 0) & 0) {
&&&&&&&&printf(&Error:
sysctl, take 1/n&);
&&&&&&&&return
((buf = malloc(len))
== NULL) {
&&&&&&&&printf(&Could
not allocate memory. error!/n&);
&&&&&&&&return
(sysctl(mib, 6, buf, &len, NULL, 0) & 0) {
&&&&&&&&printf(&Error:
sysctl, take 2&);
&&&&&&&&return
if_msghdr *)
sockaddr_dl *)(ifm + 1);
= (unsigned char
*)LLADDR(sdl);
&&&&NSString
*outstring = [NSString stringWithFormat:@&%02x%02x%02x%02x%02x%02x&,
*ptr, *(ptr+1), *(ptr+2), *(ptr+3), *(ptr+4), *(ptr+5)];
&&&&free(buf);
&&&&return
[outstring uppercaseString];
开发者可以在应用第一次启动时调用一 次，然后将该串存储起来，以便以后替代UDID来使用。但是，如果用户删除该应用再次安装时，又会生成新的字符串，所以不能保证唯一识别该设备。这就需要各路高手想出各种解决方案。所以，之前很多应用就采用MAC Address。但是现在如果用户升级到iOS7（及其以后的苹果系统）后，他们机子的MAC Address就是一样的，没办法做区分，只能弃用此方法，重新使用UUID来标识。如果使用UUID，就要考虑应用被删除后再重新安装时的处理。
一个解决的办法是：UUID一般只生成一次，保存在iOS系统里面，如果应用删除了，重装应用之后它的UUID还是一样的，除非系统重置 。但是不能保证在以后的系统升级后还能用（如果系统保存了该信息就能用）.
由于IOS系统存储的数据都是在sandBox里面，一旦删除App，sandBox也不复存在。好在有一个例外，那就是keychain（钥匙串）。
通常情况下，IOS系统用NSUserDefaults存储数据信息，但是对于一些私密信息，比如密码、证书等等，就需要使用更为安全的keychain了。
keychain里保存的信息不会因App被删除而丢失。所以，可以利用这个keychain这个特点来保存设备唯一标识。
那么，如何在应用里使用使用keyChain呢，我们需要导入Security.framework ，keychain的操作接口声明在头文件SecItem.h里。
直接使用SecItem.h里方法操作keychain，需要写的代码较为复杂，我们可以使用已经封装好了的工具类KeychainItemWrapper来对keychain进行操作。
KeychainItemWrapper是apple官方例子“GenericKeychain”里一个访问keychain常用操作的封装类，在官网上了GenericKeychain项目后，
只需要把“KeychainItemWrapper.h”和“KeychainItemWrapper.m”拷贝到我们项目，并导入Security.framework 。KeychainItemWrapper的用法：
/** 初始化一个保存用户帐号的KeychainItemWrapper */
KeychainItemWrapper *wrapper = [[KeychainItemWrapper alloc] initWithIdentifier:@&Account Number&
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&& accessGroup:@&YOUR_APP_.yourcompany.AppIdentifier&];&
//保存数据
[wrapper setObject:@&&帐号&& forKey:(id)kSecAttrAccount];&&&
[wrapper setObject:@&&帐号密码&& forKey:(id)kSecValueData];&&&
//从keychain里取出帐号密码
NSString *password = [wrapper objectForKey:(id)kSecValueData];&&&&&
//清空设置
[wrapper resetKeychainItem];
其中方法“- (void)setObject:(id)inObject forKey:(id)”里参数“forKey”的值应该是Security.framework 里头文件“SecItem.h”里定义好的key，用其他字符串做key程序会出错！
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：99735次
积分：1634
积分：1634
排名：千里之外
原创：36篇
转载：182篇
(1)(2)(2)(4)(4)(2)(9)(7)(3)(6)(7)(1)(3)(6)(9)(14)(6)(7)(12)(3)(6)(25)(12)(4)(1)(2)(1)(3)(3)(4)(7)(6)(12)(4)(22)iOS-获取设备唯一标识的各种方法 - 简书
iOS-获取设备唯一标识的各种方法
一、UDID (Unique Device Identifier)UDID的全称是Unique Device Identifier，顾名思义，它就是苹果IOS设备的唯一识别码，它由40个字符的字母和数字组成。在很多需要限制一台设备一个账号的应用中经常会用到。在iOS5中可以获取到设备的UDID，后来被苹果禁止了。二、UUID（Universally Unique Identifier）UUID是Universally Unique Identifier的缩写，中文意思是通用唯一识别码。它是让分布式系统中的所有元素，都能有唯一的辨识资讯，而不需要透过中央控制端来做辨识资讯的指定。这样，每个人都可以建立不与其它人冲突的 UUID。在此情况下，就不需考虑数据库建立时的名称重复问题。苹果公司建议使用UUID为应用生成唯一标识字符串。开发者可以在应用第一次启动时调用一 次，然后将该串存储起来，替代UDID来使用。但是，如果用户删除该应用再次安装时，又会生成新的字符串，所以不能保证唯一识别该设备。使用UUID，就要考虑应用被删除后再重新安装时的处理。一个解决的办法是：UUID一般只生成一次，保存在iOS系统里面，如果应用删除了，重装应用之后它的UUID还是一样的，除非系统重置 。但是不能保证在以后的系统升级后还能用（如果系统保存了该信息就能用）。三、MAC Address用来表示互联网上每一个站点的标识符，采用十六进制数表示，共六个字节（48位）。其中，前三个字节是由IEEE的注册管理机构RA负责给不同厂家分配的代码(高位24位)，也称为“编制上唯一的标识符” （Organizationally Unique Identifier)，后三个字节(低位24位)由各厂家自行指派给生产的适配器接口，称为扩展标识符（唯一性）。MAC地址在网络上用来区分设备的唯一性，接入网络的设备都有一个MAC地址，他们肯定都是不同的，是唯一的。一部iPhone上可能有多个MAC地址，包括WIFI的、SIM的等，但是iTouch和iPad上就有一个WIFI的，因此只需获取WIFI的MAC地址就好了，也就是en0的地址。MAC地址就如同我们身份证上的身份证号码，具有全球唯一性。这样就可以非常好的标识设备唯一性，类似与苹果设备的UDID号，通常的用途有：1）用于一些统计与分析目的，利用用户的操作习惯和数据更好的规划产品；2）作为用户ID来唯一识别用户，可以用游客身份使用app又能在服务器端保存相应的信息，省去用户名、密码等注册过程。使用Mac地址生成设备的唯一标识主要分三种：1、直接使用“MAC Address”2、使用“MD5(MAC Address)”3、使用“MD5(Mac Address+bundle_id)”获得“机器＋应用”的唯一标识（bundle_id 是应用的唯一标识）在iOS7之后，如果请求Mac地址都会返回一个固定值。四、IDFA（identifierForIdentifier）广告标示符，适用于对外：例如广告推广，换量等跨应用的用户追踪等。是iOS 6中另外一个新的方法，提供了一个方法advertisingIdentifier，通过调用该方法会返回一个NSUUID实例，最后可以获得一个UUID，由系统存储着的。不过即使这是由系统存储的，但是有几种情况下，会重新生成广告标示符。如果用户完全重置系统（(设置程序 -& 通用 -& 还原 -& 还原位置与隐私) ，这个广告标示符会重新生成。另外如果用户明确的还原广告(设置程序-& 通用 -& 关于本机 -& 广告 -& 还原广告标示符) ，那么广告标示符也会重新生成。关于广告标示符的还原，有一点需要注意：如果程序在后台运行，此时用户“还原广告标示符”，然后再回到程序中，此时获取广 告标示符并不会立即获得还原后的标示符。必须要终止程序，然后再重新启动程序，才能获得还原后的广告标示符。在同一个设备上的所有App都会取到相同的值，是苹果专门给各广告提供商用来追踪用户而设的，用户可以在 设置|隐私|广告追踪 里重置此id的值，或限制此id的使用，故此id有可能会取不到值，但好在Apple默认是允许追踪的，而且一般用户都不知道有这么个设置，所以基本上用来监测推广效果，是戳戳有余了。注意：由于idfa会出现取不到的情况，故绝不可以作为业务分析的主id，来识别用户。代码：
#import &AdSupport/AdSupport.h&
NSString *adId = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];
五、IDFV（identifierForVendor）Vindor标示符，适用于对内：例如分析用户在应用内的行为等。是给Vendor标识用户用的，每个设备在所属同一个Vender的应用里，都有相同的值。其中的Vender是指应用提供商，但准确点说，是通过BundleID的DNS反转的前两部分进行匹配，如果相同就是同一个Vender，例如对于com.somecompany.appone,com.somecompany.apptwo这两个BundleID来说，就属于同一个Vender，共享同一个idfv的值。和idfa不同的是，idfv的值是一定能取到的，所以非常适合于作为内部用户行为分析的主id，来标识用户，替代OpenUDID。注意：如果用户将属于此Vender的所有App卸载，则idfv的值会被重置，即再重装此Vender的App，idfv的值和之前不同。代码:NSString *idfv = [[[UIDevice currentDevice] identifierForVendor] UUIDString];六、OPEN UDID每台iOS设备的OpenUDID是通过第一个带有OpenUDID SDK包的App生成，如果你完全删除全部带有OpenUDID SDK包的App（比如恢复系统等），那么OpenUDID会重新生成，而且和之前的值会不同，相当于新设备；优点是没有用到MAC地址；不同设备能够获取各自唯一的识别码，保证了唯一性，可以用于以往UDID的相关用途；从代码分析OpenUDID的获取，识别码获取方便并且保存谨慎。缺点是当将设备上所有使用了OpenUDID方案的应用程序删除，且设备关机重启，xcode彻底清除并重启，重装应用程序去获取OpenUDID，此时OpenUDID变化，与之前不一样了，所有OpenUDID应用卸载后，由UIPasteboard保存的数据即被清除，重装故会重新获取新的OpenUDID。那么当因为用户干预或者恶意程序，致使UIPasteboard数据清除，从而导致OpenUDID被删除，重装也会获取新的OpenUDID。OpenUDID生成唯一识别码的代码：
unsigned char result[16];
const charchar *cStr = [[[NSProcessInfo processInfo] globallyUniqueString] UTF8String];
CC_MD5( cStr, strlen(cStr), result );
_openUDID = [NSString stringWithFormat:@"%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() % ];