iOS开发：设备检查

作为一个iOS开发者，如何识别始用者装置可以说是基本功课，最近正好被老板开了一个帐号绑定Device的需求，整理了过往的几种作法，跟各路iOS新手分享一下，重点在最后2017 WWDC最新推出的Device Check，也有实作的程式码。

话不多说，就从最初的UDID开始吧！

在iOS 5之前，如果要辨认使用者的设备，可以利用以下程式码：

  [[UIDevice cuurrent] uniqueIdenfier] 

来获得设备的UDID（唯一设备标识符），以达成装置绑定或追踪。这个值是唯一且永远不会变的。

而是实际上存在有隐私问题，UDID等于设备的身分证字号，如果开发者可以随意获取UDID，代表他们可以通过各种分析来获取『多于开发者应获取的资讯』。

UDID这么潮的功能，注重专有权的Apple当然不会让我们一直使用。其后Apple提供了另一种识别方式— IDFV（供应商标识符）

 让id = UIDevice.current.identifierForVendor 

如果说UDID是Device的身分证字号，IDFV比较像是Device的『工号』
每个应用开发者能取到的设备IDFV都不一样。

举例来说，用户下载了A开发商的a，b两款App，同时下载了B开发商的c App，A开发商如果用上面的程序代码获取IDFV，在两款app中皆会取到1234 ，而B开发商会取到5678。

而这个IDFV既然是“ identifierForVendor”（IDFV），就算删除App，重新下载过后仍然会取到一样的IDFV。
不过！如果将手机内同一个开发商的App全数删除后，这个IDFV将会重置，随后再次用户再次下载同一个开发商的App，会拿到不同的IDFV

另外，还有UUID（）这个识别方式

 让uud = UUID（） 

UUID是一个128位的数值，里面加入了产生UUID当下的时间去计算出来，不过UUID就是一个几乎不可能重复的随机数值而已，其中也不会有什么开发商或装置的识别方法。

我们透过将UUID存放在Keychain中基本上也可以达到我们对于绑定装置的需求。存储于Keychain的方法可以参考介绍：
http://www.jianshu.com/p/9e885c3e6b0a

而在2017年的WWDC上，苹果推出了另外一种装置识别的API — Device Check。我们先来看一下官方说明Device Check的使用情境：

举个比较易懂的例子，今天一个App提供了30天的免费试用，期限到了之后透过Device Check的API把装置从状态A（试用中）标注为状态B（已过期），之后却是删除App重新下载，或者系统重置，都不会影响到这个状态的判定。而这个状态，其实就是两个位所组成的，最多处于状态而已。

接着来看一下Device Check API的运作流程：

上图可以看到，先在客户端端生成令牌，然后丢给服务器，服务器可以再针对以下几种属性传给Apple，让资料保存在Apple端。

  “ device_token” => $ deviceToken，
  “ transaction_id” => Uuid :: uuid4（） -> toString（），
  “时间戳” => ceil（microtime（ true ） * 1000），
  “ bit0” => true ，
  “ bit1” => 否 

当今天想要判定这个装置的状态时，运作流程以下：

在客户端端用Device Check API拿到令牌，然后，请服务器去跟Apple要这个Device目前的状态，再回来做处理。

范例程式码如下：

实际去把令牌印出来之后发现超长的XD

用Device Check的方法，规模程度的保护用户的专有权，因为Device Check取到的令牌甚至连『工号』的程度都算不上。也因为Device的状态交由Apple管理，无论用户是重置系统或重安装App，这个状态都不会改变，除非开发者主动改变。

以上，小小的跟大家分享一下最近的工作笔记。建议大家可以看一下WWDC 2017这个Session的影片或投影片
https://developer.apple.com/videos/play/wwdc2017/702/

欢迎各路大牛指点其他使用技巧或经验！

参考：
https://qiita.com/owen/items/85dff1e45083d2805140
https://developer.apple.com/documentation/uikit/uidevice/1620059-identifierforvendor