什么是設(shè)備唯一標(biāo)識(shí)蘸秘？
設(shè)備的唯一標(biāo)識(shí)，當(dāng)前設(shè)備的生成字符串，保證與其他設(shè)備相比唯一且不變痹换，一版利用于產(chǎn)品的統(tǒng)計(jì)的訪問次數(shù)或用戶操作的統(tǒng)計(jì).
設(shè)備唯一標(biāo)識(shí)的獲取：
在IOS5.0之前：使用UDID(Unique?Device?Identifier),是蘋果IOS設(shè)備的唯一識(shí)別碼都弹，它由40個(gè)字符的字母和數(shù)字組成娇豫，生成方法：
1NSString?*uuid?= [[UIDevice currentDevice] uniqueIdentifier]
IOS5.0之后，蘋果不建議開發(fā)者使用UDID,并且獲取設(shè)備UDID的方法已經(jīng)被蘋果的SDK中標(biāo)識(shí)為棄用畅厢，又有人爆出蘋果App?Store禁止訪問UDID的應(yīng)用上架冯痢，許多開發(fā)者都棄用UDID，去尋找另外的替代方案.?分別有以下幾種：
1.?蘋果公司建議的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];???
}
蘋果公司建議采用上述代碼為應(yīng)用生成唯一標(biāo)識(shí)字符串。開發(fā)者可以在應(yīng)用第一次啟動(dòng)時(shí)調(diào)用一次浦楣，然后將該串存儲(chǔ)起來袖肥，以便以后替代UDID來使用。顯而易見振劳，這種方法問題很多椎组。如果用戶刪除該應(yīng)用再次安裝時(shí)，又會(huì)生成新的字符串历恐，所以不能保證唯一識(shí)別該設(shè)備寸癌；如果你從一臺(tái)舊設(shè)備中備份文件到新設(shè)備中，兩臺(tái)設(shè)備就擁有相同的CFUUID夹供；如果你從臨時(shí)文件中備份操作系統(tǒng)灵份，就會(huì)出現(xiàn)一個(gè)設(shè)備里存在不同CFUUID的情況.
2.?開源方案OpenUDID.
其生成標(biāo)識(shí)的代碼為：
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類，為了于UDID40位長(zhǎng)度相同哮洽，后面還添加了8為的隨機(jī)數(shù)填渠，主要就是把當(dāng)前生成的字符串存在NSUserDefults里面，以供程序使用鸟辅，還把當(dāng)前生成的字符串存進(jìn)UIPasteboard類（設(shè)備剪切板）代碼如下：
UIPasteboard* slotPB = [UIPasteboardpasteboardWithName:availableSlotPBid create:YES];?????
[slotPB setData:[NSKeyedArchiver?archivedDataWithRootObject:dict] forPasteboardType:kOpenUDIDDomain];
如果設(shè)備上安裝了第二個(gè)使用OpenUDID解決方案的應(yīng)用氛什，當(dāng)應(yīng)用調(diào)用生成OpenUDID的方法時(shí)，將會(huì)從UIPasteboard中獲取唯一識(shí)別碼匪凉，這里取到的就是之前第一個(gè)應(yīng)用保存到UIPasteboard中的枪眉。也就是說，只要用戶設(shè)備上有一個(gè)使用了OpenUDID的應(yīng)用存在時(shí)再层，其他后續(xù)安裝的應(yīng)用如果獲取OpenUDID贸铜，都將會(huì)獲得第一個(gè)應(yīng)用生成的那個(gè)。
看起來似乎很好聂受，很復(fù)雜蒿秦。但是仔細(xì)想想，還是有問題蛋济，如果把使用了OpenUDID方案的應(yīng)用全部都刪除棍鳖，再重新獲取OpenUDID，此時(shí)的OpenUDID就跟以前的不一樣了（本人測(cè)了一下碗旅，確實(shí)如此）渡处。可見祟辟，這種方法還是不保險(xiǎn)医瘫。
3.?開源方案SecureUDID:
稍微看了下SecureUDID源碼，發(fā)現(xiàn)其與OpenUDID其實(shí)差不多川尖，只是初始獲取的唯一識(shí)別碼稍有不同登下。同時(shí)茫孔，從作者的Readme文檔中可見叮喳，這個(gè)方案同樣存在很多問題被芳。如原文：
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.
我發(fā)現(xiàn)，其實(shí)前面的OpenUDID也基本存在以上問題馍悟，只是作者沒寫出來畔濒。看來還是SecureUDID的貢獻(xiàn)者比較厚道锣咒。
4.?與WIFI?MAC地址相關(guān)
網(wǎng)上同樣有一些與WIFI?MAC地址相關(guān)的替代方案侵状，主要分三種：第一種直接使用“MAC?Address”；第二種毅整，使用“MD5(MAC?Address)”趣兄；第三種，“MD5(MAC?Address+CFBundleIdentifier)”悼嫉。github上有個(gè)開源項(xiàng)目（UIDevice-with-UniqueIdentifier-for-iOS-5）實(shí)現(xiàn)了這幾種方法艇潭。
使用這種方法也存在問題：1、市面上有部分機(jī)器（雖然數(shù)量極少戏蔑，但是本人在使用過程中確實(shí)發(fā)現(xiàn)過這種情況）無法獲得MAC地址蹋凝，有人說這部分機(jī)器是聯(lián)通閹割無WIFI版的，具體不得而知了总棵。2鳍寂、MAC地址跟UDID一樣，存在隱私問題情龄。
在IOS7.0之后有一些變動(dòng)?:?
1.?蘋果在新的SDK中把獲取UDID的API刪除迄汛，iOS7之前的使用了-[UIDevice?uniqueIdentifier]?的app如果在iOS7上運(yùn)行，它不會(huì)返回設(shè)備的UUID骤视，而是會(huì)返回一串字符串鞍爱，以FFFFFFFF開頭，跟著-[UIDevice?identifierForVendor]的十六進(jìn)制值?;?
2.?UIPasteboard由共享變?yōu)樯澈谢松邪@樣一來以上使用的UUID可能不像以前那么強(qiáng)大了?;?
3.?MAC地址不能再用來設(shè)別設(shè)備,蘋果并不希望有人通過MAC地址來分辨用戶硬霍，所以如果你在iOS7系統(tǒng)上查詢MAC地址，它現(xiàn)在只會(huì)返回02:00:00:00:00:00
現(xiàn)在蘋果明確的表明你應(yīng)該使用-[UIDevice?identifierForVendor]或是-[ASIdentifierManager?advertisingIdentifier]來作為你框架和應(yīng)用的唯一標(biāo)示符笼裳。坦白的來說唯卖，應(yīng)對(duì)這些變化也不是那么的難，見以下代碼片段：
NSString?*identifierForVendor = [[UIDevice currentDevice].identifierForVendor UUIDString];
NSString?*identifierForAdvertising = [[ASIdentifierManager sharedManager].advertisingIdentifier UUIDString];
每種方法都適配一種特別的用法：
identifierForVendor對(duì)供應(yīng)商來說是唯一的一個(gè)值躬柬，也就是說拜轨，由同一個(gè)公司發(fā)行的的app在相同的設(shè)備上運(yùn)行的時(shí)候都會(huì)有這個(gè)相同的標(biāo)識(shí)符。然而允青，如果用戶刪除了這個(gè)供應(yīng)商的app然后再重新安裝的話橄碾，這個(gè)標(biāo)識(shí)符就會(huì)不一致。
advertisingIdentifier會(huì)返回給在這個(gè)設(shè)備上所有軟件供應(yīng)商相同的?一個(gè)值，所以只能在廣告的時(shí)候使用法牲。這個(gè)值會(huì)因?yàn)楹芏嗲闆r而有所變化史汗，比如說用戶初始化設(shè)備的時(shí)候便會(huì)改變。
