iOS獲取手機唯一識別符號來判斷不同終端登入（IDFA和UUID分析）

11.13更新

廣告標示符，適用於對外：例如廣告推廣，換量等跨應用的使用者追蹤等。

是iOS 6中另外一個新的方法，提供了一個方法advertisingIdentifier，通過呼叫該方法會返回一個NSUUID例項，最後可以獲得一個UUID，由系統儲存著的。不過即使這是由系統儲存的，但是有幾種情況下，會重新生成廣告標示符。如果使用者完全重置系統（(設定程式 -> 通用 -> 還原 -> 還原位置與隱私) ，這個廣告標示符會重新生成。另外如果使用者明確的還原廣告(設定程式-> 通用 -> 關於本機 -> 廣告 -> 還原廣告標示符) ，那麼廣告標示符也會重新生成。關於廣告標示符的還原，有一點需要注意：如果程式在後臺執行，此時使用者“還原廣告標示符”，然後再回到程式中，此時獲取廣 告標示符並不會立即獲得還原後的標示符。必須要終止程式，然後再重新啟動程式，才能獲得還原後的廣告標示符。

在同一個裝置上的所有App都會取到相同的值，是蘋果專門給各廣告提供商用來追蹤使用者而設的，使用者可以在 設定|隱私|廣告追蹤 裡重置此id的值，或限制此id的使用，故此id有可能會取不到值，但好在Apple預設是允許追蹤的，而且一般使用者都不知道有這麼個設定，所以基本上用來監測推廣效果，是戳戳有餘了。

注意：由於idfa會出現取不到的情況，故絕不可以作為業務分析的主id，來識別使用者。
因此，IDFA就是用來跟蹤廣告推廣的，而UUID雖然每次不同，但是可以自己手動存入Keychain來進行唯一性的確保，這麼說來IDFA就是如果廣告商投放的時候使用，而UUID就是自己後臺來判斷使用者是否換了裝置，或者資訊不一致需要重新登入的業務
知乎上看到一個非常詳細介紹IDFA的文章
IDFA看這個就夠了

IDFA

可以理解為廣告id，apple公司提供的用於追蹤使用者的廣告識別符號。缺點：如果使用者完全重置系統（(設定程式 -> 通用 -> 還原 -> 還原位置與隱私) ，這個廣告標示符會重新生成。
另外如果使用者明確的還原廣告(設定程式-> 通用 -> 關於本機 -> 廣告 -> 還原廣告標示符) ，那麼廣告標示符也會重新生成

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

// 獲取
//需要匯入AdSupport.framework這個庫
#import <AdSupport/AdSupport.h>
NSString *idfa = [[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];

// 判斷是否開啟
// 判斷是否開啟  限制廣告跟蹤選項（該選項在設定-隱私-廣告-限制廣告隱私）
Boolean on = [[ASIdentifierManager sharedManager] isAdvertisingTrackingEnabled];

ios10之前開關限制廣告追蹤選項的確沒什麼用，ios10之後，如果手機開啟限制廣告追蹤的話就不能再得到廣告識別符號，得到的是下面的0。這個開關是一個簡單的boolean標誌，當將廣告標示符發到任意的伺服器端時，你最好判斷一下這個值，然後再做決定。

//開啟的時候
2016-01-05 15:22:19.218 sss[1773:60b] 41B2FD07-695A-4A27-8D26-C30ECE6F7EAD
2016-01-05 15:22:19.233 sss[1773:60b] 0

//關閉的時候
2016-01-05 15:19:57.502 sss[1763:60b] 7773E145-26FF-4304-A60F-60C948D52B40
2016-01-05 15:19:57.516 sss[1763:60b] 1

開啟和關閉切換的話，idfa會變，如果不切換，保持開啟狀態，每次都是不會變的，當切換了下之後就會變，或者還原的話會變

// 獲取IDFA的方法
+ (NSString *)getIDFA
{
    SEL advertisingIdentifierSel = sel_registerName("advertisingIdentifier");
    SEL UUIDStringSel = sel_registerName("UUIDString");

    ASIdentifierManager *manager = [ASIdentifierManager sharedManager];
#pragma clang diagnostic push
#pragma clang diagnostic ignored "-Warc-performSelector-leaks"
    if([manager respondsToSelector:advertisingIdentifierSel]) {

        id UUID = [manager performSelector:advertisingIdentifierSel];

        if([UUID respondsToSelector:UUIDStringSel]) {

            return [UUID performSelector:UUIDStringSel];

        }

    }
#pragma clang diagnostic pop
    return nil;
}

UUID

CFUUID—>2.0出現
NSUUID—>6.0出現
這兩個一個是CF框架下的，一個更加物件導向，獲取的時候更方便而已，其實獲取到的都是同一個東西
針對CFUUID需要注意的是：獲得的這個CFUUID值系統並沒有儲存。每次呼叫CFUUIDCreate，系統都會返回一個新的唯一標示符。如果你希望儲存這個標示符，那麼需要自己將其儲存到NSUserDefaults, Keychain, Pasteboard或其它地方。

由於我們後臺判斷App登入時根據uuid來判斷的在不同終端登入的，雖然上面提到UUID是獲取的時候一直在變化的，而且不是系統級別的儲存，那麼我們就需要自己儲存到系統，用到SSKeyChain，我們自己來保證一個手機理論狀態下對應一個UUID

+ (NSString *)getUUID{
    NSString  *openUUID = [[NSUserDefaults standardUserDefaults] objectForKey:OpenSessionID];
//    NSLog(@"openUUID 一: %@",openUUID);
    if (openUUID == nil) {

        CFUUIDRef puuid = CFUUIDCreate(kCFAllocatorDefault);
        CFStringRef uuidString = CFUUIDCreateString(kCFAllocatorDefault,puuid);
        NSString *udidStr = (NSString *)CFBridgingRelease(CFStringCreateCopy( NULL, uuidString));
        CFRelease(puuid);
        CFRelease(uuidString);
        openUUID =  [udidStr MD5Hash];

//        NSLog(@"openUUID 二: %@",openUUID);
        NSString *uniqueKeyItem = [SSKeychain  passwordForService:kUniqueIdentifier account:kUniqueIdentifierValue];
        if (uniqueKeyItem == nil || [uniqueKeyItem length] == 0) {
            uniqueKeyItem = openUUID;
            [SSKeychain  setPassword:openUUID forService:kUniqueIdentifier account:kUniqueIdentifierValue];
        }
        [[NSUserDefaults standardUserDefaults] setObject:uniqueKeyItem forKey:OpenSessionID];
        [[NSUserDefaults  standardUserDefaults] synchronize];
//        NSLog(@"uniqueKeyItem: %@",uniqueKeyItem);
        openUUID = uniqueKeyItem;
    }
//    NSLog(@"openUUID 三: %@",openUUID);
    return openUUID;
}

1.首先從沙盒獲取，沒有的話就呼叫CF方法獲取，然後再去keychain獲取，如果沒獲取到，把剛才獲取到的UUID儲存到Keychain，由於keychain你不刷機，儲存的東西會一直存在，因此保證了唯一性，每次獲取的都是從keychain獲取到的第一次儲存進去的值，那麼請求的時候，後臺根據使用者主鍵盤點uuid是否更改從而判斷是否換了終端登入，進行彈框提示

總結：
1.idfa在使用者重置廣告標誌符的時候會變化，所以可以把第一次生成的idfa存放到keychain裡面，以後就直接讀取keychain值就可以了，這樣就能避免使用者重置廣告標誌符造成idfa的變化，而keychain的值只有在使用者重置系統的時候才會刪除，所以很適合用idfa+keychain的方案
2.那麼第二種方法也可以用，UUID+Keychain的方式也行，上面介紹了，我們就用的第二種，總之，keychain是個好東西，根據app的鍵，來儲存對應的使用者資訊，密碼等重要資訊還是不錯的，這裡簡單記錄下之前一直疑惑的知識點，方便以後查閱

IDFA提交Appstore選項相關

如何確定是否需要選擇IDFA？？？先看看下面的終端使用判斷是否需要勾選
iOS稽核中如何正確填寫APP廣告識別符號IDFA

1、在 App 內投放廣告

2、將此 App 安裝歸因於先前投放的特定廣告

3、將此 App 中發生的操作歸因於先前投放的特定廣告

4、對使用廣告識別符號做確認

1.serve advertisements within the app

服務應用中的廣告。如果你的應用中整合了廣告的時候，你需要勾選這一項。

2.Attribute this app installation to a previously served advertisement.

跟蹤廣告帶來的安裝。如果你使用了第三方的工具來跟蹤廣告帶來的啟用以及一些其他事件，但是應用裡並沒有展示廣告你需要勾選這一項。

3.Attribute an action taken within this app to a previously served advertisement

跟蹤廣告帶來的使用者的後續行為。如果你使用了第三方的工具來跟蹤廣告帶來的啟用以及一些其他事件，但是應用裡並沒有展示廣告你需要勾選第2項和第3項。

下邊還有一項

4.Limit Ad Tracking setting in iOS

這一項下的內容其實就是對你的應用使用idfa的目的做下確認，只要你選擇了採集idfa，那麼這一項都是需要勾選的。

總結一下，

（1）如果你的應用裡只是整合了廣告，不追蹤廣告帶來的啟用行為，那麼選擇1和4；

（2）如果你的應用裡沒有整合廣告，但是需要追蹤廣告帶來的啟用行為，那麼選擇2,3和4；

（3）如果你的應用裡整合了廣告，而且使用了sdk等用來追蹤廣告帶來的啟用行為，需要選擇1,2,3和4 。

個人理解：當你有用到IDFA的時候，你是必須要勾選YES的，14年的時候很嚴格，剩下四個選項如果你選錯了很容易悲劇，現在感覺如果你選了YES，然後在找個合適的理由勾選，基本上沒問題了，例如你整合了UMENG的IDFA SDK，然後你有啟動廣告，你選1和4，一樣OK了

參考部落格，還介紹了其他識別符號