iOS的UDID等取用

在2013年3月21日蘋果已經通知開發者,從2013年5月1日起,訪問UIDID的應用將不再能通過審覈,替代的方案是開發者應該使用“在iOS 6中介紹的Vendor或Advertising標示符”。


unique Identifier即將退出,蘋果給了我們Vendor和Advertising identifier兩個選擇,但應該用哪一個?文檔並沒有給出確切答案,具體使用哪個完全由你根據自己app的目的來決定。下面我將列出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];

示例: bb4d786633053a0b9c0da20d54ea7e38e8776da4

 

OpenUDID
在iOS 5發佈時,uniqueIdentifier被棄用了,這引起了廣大開發者需要尋找一個可以替代UDID,並且不受蘋果控制的方案。由此OpenUDID成爲了當時使用最廣泛的開源UDID替代方案。OpenUDID在工程中實現起來非常簡單,並且還支持一系列的廣告提供商。

NSString *openUDID = [OpenUDID value];

 

OpenUDID利用了一個非常巧妙的方法在不同程序間存儲標示符 — 在粘貼板中用了一個特殊的名稱來存儲標示符。通過這種方法,別的程序(同樣使用了OpenUDID)知道去什麼地方獲取已經生成的標示符(而不用再生成一個新的)。

 

之前已經提到過,在將來,蘋果將開始強制使用advertisingIdentifier 或identifierForVendor。如果這一天到來的話,即使OpenUDID看起來是非常不錯的選擇,但是你可能不得不過渡到蘋果推出的方法。

示例: 0d943976b24c85900c764dd9f75ce054dc5986ff

 

總結
希望上面的信息能夠幫助你在程序使用選擇正確的唯一標示符。在這裏,我創建了一個小的唯一標示符測試程序,你可以運行該程序,並查看一下顯示的內容(包括上面提到的所有標示符)。另外,下面有兩個表,表中描述了兩個內容:在iOS中的可用性,以及什麼時候可以獲得重置的標示符。


 

* 程序必須重啓才能看到改變的效果。
** 刪除了所有相同vendor提供的程序,才能看到改變的值。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章