在2013年3月21日蘋果已經通知開發者，從2013年5月1日起，，替代的方案是開發者應該使用“在iOS 6中介紹的Vendor或Advertising標示符”。

蘋果已經警告過我們uniqueIdentifier將不能再使用了，並且提供了另外兩個可選的。但是在程式中該選擇使用哪個呢？本文不會回答這個問題，具體用哪個是由你來根據程式的目的來做決定的。

下面我將列出iOS中目前支援的，以及被廢棄的唯一標示符方法，並對其做出相應的解釋，希望你看了以後針對唯一標示符的使用上，能夠做出正確的確定。

CFUUID

從iOS2.0開始，CFUUID就已經出現了。它是CoreFoundatio包的一部分，因此API屬於C語言風格。 方法用來建立CFUUIDRef，並且可以獲得一個相應的NSString，如下程式碼：

1. CFUUIDRef cfuuid =CFUUIDCreate(kCFAllocatorDefault);
2. NSString *cfuuidString =(NSString*)CFBridgingRelease(CFUUIDCreateString(kCFAllocatorDefault, cfuuid));

獲得的這個CFUUID值系統並沒有儲存。每次呼叫CFUUIDCreate，系統都會返回一個新的唯一標示符。如果你希望儲存這個標示符，那麼需要自己將其儲存到NSUserDefaults, Keychain, Pasteboard或其它地方。

示例: 68753A44-4D6F-1226-9C60-0050E4C00067

NSUUID

在iOS 6中才出現，這跟CFUUID幾乎完全一樣，只不過它是Objective-C介面。+ (id)UUID 是一個類方法，呼叫該方法可以獲得一個UUID。通過下面的程式碼可以獲得一個UUID字串：

1. NSString *uuid =[[NSUUID UUID] UUIDString];

跟CFUUID一樣，這個值系統也不會儲存，每次呼叫的時候都會獲得一個新的唯一標示符。如果要儲存的話，你需要自己儲存。在我讀取NSUUID時，注意到獲取到的這個值跟CFUUID完全一樣（不過也可能不一樣）：

示例: 68753A44-4D6F-1226-9C60-0050E4C00067

廣告標示符（IDFA-identifierForIdentifier）

這是iOS 6中另外一個新的方法， 是新框架AdSupport.framework的一部分。ASIdentifierManager單例提供了一個方法advertisingIdentifier，通過呼叫該方法會返回一個上面提到的NSUUID例項。

1. 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物件。

1. 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的方法如下：

1. NSString *udid =[[UIDevice currentDevice] uniqueIdentifier];

示例: bb4d786633053a0b9c0da20d54ea7e38e8776da4

OpenUDID

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

1. NSString *openUDID = [OpenUDID value];

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

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

示例: 0d943976b24c85900c764dd9f75ce054dc5986ff

總結

希望上面的資訊能夠幫助你在程式使用選擇正確的唯一標示符。在這裡，我建立了一個，你可以執行該程式，並檢視一下顯示的內容（包括上面提到的所有標示符）。另外，下面有兩個表，表中描述了兩個內容：在iOS中的可用性，以及什麼時候可以獲得重置的標示符。

* 程式必須重啟才能看到改變的效果。

** 刪除了所有相同vendor提供的程式，才能看到改變的值。