關于設備唯一標識

原文連接

什么是設備唯一標識?

設備的唯一標識,當前設備的生成字符串,保證與其他設備相比唯一且不變,一版利用于產(chǎn)品的統(tǒng)計的訪問次數(shù)或用戶操作的統(tǒng)計.

設備唯一標識的獲取:

在IOS5.0之前:使用UDID(Unique?Device?Identifier),是蘋果IOS設備的唯一識別碼,它由40個字符的字母和數(shù)字組成,生成方法:

1NSString?*uuid?= [[UIDevice currentDevice] uniqueIdentifier]

IOS5.0之后,蘋果不建議開發(fā)者使用UDID,并且獲取設備UDID的方法已經(jīng)被蘋果的SDK中標識為棄用,又有人爆出蘋果App?Store禁止訪問UDID的應用上架,許多開發(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];???

}

蘋果公司建議采用上述代碼為應用生成唯一標識字符串。開發(fā)者可以在應用第一次啟動時調(diào)用一次,然后將該串存儲起來,以便以后替代UDID來使用。顯而易見,這種方法問題很多。如果用戶刪除該應用再次安裝時,又會生成新的字符串,所以不能保證唯一識別該設備;如果你從一臺舊設備中備份文件到新設備中,兩臺設備就擁有相同的CFUUID;如果你從臨時文件中備份操作系統(tǒng),就會出現(xiàn)一個設備里存在不同CFUUID的情況.

2.?開源方案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類,為了于UDID40位長度相同,后面還添加了8為的隨機數(shù),主要就是把當前生成的字符串存在NSUserDefults里面,以供程序使用,還把當前生成的字符串存進UIPasteboard類(設備剪切板)代碼如下:

UIPasteboard* slotPB = [UIPasteboardpasteboardWithName:availableSlotPBid create:YES];?????

[slotPB setData:[NSKeyedArchiver?archivedDataWithRootObject:dict] forPasteboardType:kOpenUDIDDomain];

如果設備上安裝了第二個使用OpenUDID解決方案的應用,當應用調(diào)用生成OpenUDID的方法時,將會從UIPasteboard中獲取唯一識別碼,這里取到的就是之前第一個應用保存到UIPasteboard中的。也就是說,只要用戶設備上有一個使用了OpenUDID的應用存在時,其他后續(xù)安裝的應用如果獲取OpenUDID,都將會獲得第一個應用生成的那個。

看起來似乎很好,很復雜。但是仔細想想,還是有問題,如果把使用了OpenUDID方案的應用全部都刪除,再重新獲取OpenUDID,此時的OpenUDID就跟以前的不一樣了(本人測了一下,確實如此)。可見,這種方法還是不保險。

3.?開源方案SecureUDID:

稍微看了下SecureUDID源碼,發(fā)現(xiàn)其與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.

我發(fā)現(xiàn),其實前面的OpenUDID也基本存在以上問題,只是作者沒寫出來。看來還是SecureUDID的貢獻者比較厚道。

4.?與WIFI?MAC地址相關

網(wǎng)上同樣有一些與WIFI?MAC地址相關的替代方案,主要分三種:第一種直接使用“MAC?Address”;第二種,使用“MD5(MAC?Address)”;第三種,“MD5(MAC?Address+CFBundleIdentifier)”。github上有個開源項目(UIDevice-with-UniqueIdentifier-for-iOS-5)實現(xiàn)了這幾種方法。

使用這種方法也存在問題:1、市面上有部分機器(雖然數(shù)量極少,但是本人在使用過程中確實發(fā)現(xiàn)過這種情況)無法獲得MAC地址,有人說這部分機器是聯(lián)通閹割無WIFI版的,具體不得而知了。2、MAC地址跟UDID一樣,存在隱私問題。

在IOS7.0之后有一些變動?:?

1.?蘋果在新的SDK中把獲取UDID的API刪除,iOS7之前的使用了-[UIDevice?uniqueIdentifier]?的app如果在iOS7上運行,它不會返回設備的UUID,而是會返回一串字符串,以FFFFFFFF開頭,跟著-[UIDevice?identifierForVendor]的十六進制值?;?

2.?UIPasteboard由共享變?yōu)樯澈谢耍@樣一來以上使用的UUID可能不像以前那么強大了?;?

3.?MAC地址不能再用來設別設備,蘋果并不希望有人通過MAC地址來分辨用戶,所以如果你在iOS7系統(tǒng)上查詢MAC地址,它現(xiàn)在只會返回02:00:00:00:00:00

現(xiàn)在蘋果明確的表明你應該使用-[UIDevice?identifierForVendor]或是-[ASIdentifierManager?advertisingIdentifier]來作為你框架和應用的唯一標示符。坦白的來說,應對這些變化也不是那么的難,見以下代碼片段:

NSString?*identifierForVendor = [[UIDevice currentDevice].identifierForVendor UUIDString];

NSString?*identifierForAdvertising = [[ASIdentifierManager sharedManager].advertisingIdentifier UUIDString];

每種方法都適配一種特別的用法:

identifierForVendor對供應商來說是唯一的一個值,也就是說,由同一個公司發(fā)行的的app在相同的設備上運行的時候都會有這個相同的標識符。然而,如果用戶刪除了這個供應商的app然后再重新安裝的話,這個標識符就會不一致。

advertisingIdentifier會返回給在這個設備上所有軟件供應商相同的?一個值,所以只能在廣告的時候使用。這個值會因為很多情況而有所變化,比如說用戶初始化設備的時候便會改變。

?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
  • 序言:七十年代末,一起剝皮案震驚了整個濱河市,隨后出現(xiàn)的幾起案子,更是在濱河造成了極大的恐慌,老刑警劉巖,帶你破解...
    沈念sama閱讀 227,488評論 6 531
  • 序言:濱河連續(xù)發(fā)生了三起死亡事件,死亡現(xiàn)場離奇詭異,居然都是意外死亡,警方通過查閱死者的電腦和手機,發(fā)現(xiàn)死者居然都...
    沈念sama閱讀 98,034評論 3 414
  • 文/潘曉璐 我一進店門,熙熙樓的掌柜王于貴愁眉苦臉地迎上來,“玉大人,你說我怎么就攤上這事。” “怎么了?”我有些...
    開封第一講書人閱讀 175,327評論 0 373
  • 文/不壞的土叔 我叫張陵,是天一觀的道長。 經(jīng)常有香客問我,道長,這世上最難降的妖魔是什么? 我笑而不...
    開封第一講書人閱讀 62,554評論 1 307
  • 正文 為了忘掉前任,我火速辦了婚禮,結(jié)果婚禮上,老公的妹妹穿的比我還像新娘。我一直安慰自己,他們只是感情好,可當我...
    茶點故事閱讀 71,337評論 6 404
  • 文/花漫 我一把揭開白布。 她就那樣靜靜地躺著,像睡著了一般。 火紅的嫁衣襯著肌膚如雪。 梳的紋絲不亂的頭發(fā)上,一...
    開封第一講書人閱讀 54,883評論 1 321
  • 那天,我揣著相機與錄音,去河邊找鬼。 笑死,一個胖子當著我的面吹牛,可吹牛的內(nèi)容都是我干的。 我是一名探鬼主播,決...
    沈念sama閱讀 42,975評論 3 439
  • 文/蒼蘭香墨 我猛地睜開眼,長吁一口氣:“原來是場噩夢啊……” “哼!你這毒婦竟也來了?” 一聲冷哼從身側(cè)響起,我...
    開封第一講書人閱讀 42,114評論 0 286
  • 序言:老撾萬榮一對情侶失蹤,失蹤者是張志新(化名)和其女友劉穎,沒想到半個月后,有當?shù)厝嗽跇淞掷锇l(fā)現(xiàn)了一具尸體,經(jīng)...
    沈念sama閱讀 48,625評論 1 332
  • 正文 獨居荒郊野嶺守林人離奇死亡,尸身上長有42處帶血的膿包…… 初始之章·張勛 以下內(nèi)容為張勛視角 年9月15日...
    茶點故事閱讀 40,555評論 3 354
  • 正文 我和宋清朗相戀三年,在試婚紗的時候發(fā)現(xiàn)自己被綠了。 大學時的朋友給我發(fā)了我未婚夫和他白月光在一起吃飯的照片。...
    茶點故事閱讀 42,737評論 1 369
  • 序言:一個原本活蹦亂跳的男人離奇死亡,死狀恐怖,靈堂內(nèi)的尸體忽然破棺而出,到底是詐尸還是另有隱情,我是刑警寧澤,帶...
    沈念sama閱讀 38,244評論 5 355
  • 正文 年R本政府宣布,位于F島的核電站,受9級特大地震影響,放射性物質(zhì)發(fā)生泄漏。R本人自食惡果不足惜,卻給世界環(huán)境...
    茶點故事閱讀 43,973評論 3 345
  • 文/蒙蒙 一、第九天 我趴在偏房一處隱蔽的房頂上張望。 院中可真熱鬧,春花似錦、人聲如沸。這莊子的主人今日做“春日...
    開封第一講書人閱讀 34,362評論 0 25
  • 文/蒼蘭香墨 我抬頭看了看天上的太陽。三九已至,卻和暖如春,著一層夾襖步出監(jiān)牢的瞬間,已是汗流浹背。 一陣腳步聲響...
    開封第一講書人閱讀 35,615評論 1 280
  • 我被黑心中介騙來泰國打工, 沒想到剛下飛機就差點兒被人妖公主榨干…… 1. 我叫王不留,地道東北人。 一個月前我還...
    沈念sama閱讀 51,343評論 3 390
  • 正文 我出身青樓,卻偏偏與公主長得像,于是被迫代替她去往敵國和親。 傳聞我的和親對象是個殘疾皇子,可洞房花燭夜當晚...
    茶點故事閱讀 47,699評論 2 370

推薦閱讀更多精彩內(nèi)容