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了
