https://cg2010studio.com/2016/05/31/idfa%E3%80%81idfv%E3%80%81uuid/
https://medium.com/appworks-school/device-check-35556ab74d
https://www.jianshu.com/p/9e885c3e6b0a
https://blog.csdn.net/zhtl3333/article/details/51094381
https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor
每次送審 App，最後 itunes connect 都會問，有沒有使用 IDFA，若沒有正確回答，那麼這個版本就會被拒絕！
想要追蹤、統計、分析用戶，自然離不開用戶唯一識別碼，這是每個公司都會面臨的問題。在歷史上唯一識別碼很多，如 UDID、MAC位址、OpenUDID 等，現在好用的只剩下 IDFA、IDFV、UUID + keyChain。
一開始，Apple 允許開發者取得用戶 Device 的 UDID（Unique Device Identifier），以達成裝置綁定或是追蹤。這個值是唯一且永遠不會變的。
但這其實存在隱私問題，UDID 等同 Device 的身分證字號，如果開發者可以隨意取得 UDID ，代表他們可以透過各種分析來取得『多於開發者應取得的資訊』。
所以這個方法後來被 Apple 禁用了。
其後 Apple 提供了另一種識別方式 — IDFV （Identifier For Vendor）
如果說 UDID 是 Device 的身分證字號， IDFV 比較像是 Device 的『工號』
每個 App 開發商能取到的 Device IDFV 都不一樣。
舉例來說，User 下載了 A 開發商的 a, b 兩款 App，同時下載了 B 開發商的 c App，
A 開發商如果用上面的程式碼取得 IDFV， 在兩款 app 中皆會取到 1234，
而 B 開發商會取到 5678。
而這個 IDFV 既然是 “identifier For Vendor” (IDFV) ，就算刪除 App ，重新下載過後仍然會取到一樣的 IDFV 。
不過，如果將手機內同一個開發商的 App 全數刪除後，這個 IDFV 會被重置，也就是說下次 User 再下載同一個開發商的 App，會拿到不同的 IDFV。
而由於如果用戶卸載又重新安裝同一個 App，其 IDFV 可能會改變，這樣子將無法實現某些促銷活動，比如說 30 天試用，
因此，這時候需要搭配使用另外一個方法：Device Check
舉個例子，今天一個 App 提供了 30 天的免費試用，期限到了之後透過 Device Check 的 API 把裝置從狀態 A（試用中）標註為狀態 B（已過期），之後不論是刪除 App 重新下載，或是系統重置，都不會影響到這個狀態的判定。而這個狀態，其實就是兩個 bit 所組成的，最多四種狀態而已。
接著來看一下 Device Check API 的運作流程：
IDFA（Advertising Identifier）：可以理解為廣告 id，Apple 提供的用於追蹤用戶的廣告識別碼。
在同一個設備上的所有 App 都會取到相同的值，是蘋果專門給各廣告提供商用來追踪用戶而設的，用戶可以在設置 => 隱私 => 廣告追踪裡重置此 id 的值，或限制此 id 的使用，故此 id 有可能會取不到值，但好在 Apple 默認是允許追踪的，而且一般用戶都不知道有這個設置，所以基本上已經足以用來監測廣告效果。
由於 IDFA 可能會出現取不到的情況，所以不可以用來識別用戶。
