iOS 11 Device Check API：双比特与transaction ID使用及设备识别咨询

我来帮你拆解这些问题，结合你提到的「应用重装时替换FCM ID」的业务场景，会更容易理解：

一、如何在iOS 11的Device Check API中使用双比特与Transaction ID？ #

Device Check的核心是让你的服务器能和苹果服务器交互，读取/修改绑定到设备的两个布尔值（也就是双比特），整个流程大概是这样：

1. iOS端获取Device Token #

首先在App里集成DeviceCheck框架，生成唯一的设备Token（这个Token和设备绑定，应用重装后重新生成的Token依然对应同一个设备）：

import DeviceCheck

func fetchDeviceCheckToken() {
    let dcDevice = DCDevice.current
    guard dcDevice.isSupported else {
        // 模拟器、iOS10及以下系统不支持，需要做兼容处理
        return
    }
    
    dcDevice.generateToken { token, error in
        guard let tokenData = token, error == nil else {
            // 处理生成失败的情况，比如网络问题
            return
        }
        let tokenString = tokenData.base64EncodedString()
        // 将这个tokenString发送到你的后端服务器
    }
}

2. 服务器端与苹果API交互（操作双比特） #

你的服务器需要先获取苹果的认证令牌（通过开发者账号的密钥生成），然后调用苹果的Device Check API来读取或设置双比特，这里就会用到Transaction ID：

设置双比特的示例（用curl模拟）

curl -X POST "https://api.devicecheck.apple.com/v1/update_two_bits" \
-H "Authorization: Bearer YOUR_SERVER_AUTH_TOKEN" \
-H "Content-Type: application/json" \
-d '{
    "device_token": "IOS_CLIENT_SENT_TOKEN",
    "transaction_id": "YOUR_UNIQUE_TRANSACTION_ID",
    "bit0": true,  // 自定义状态，比如标记是否已绑定FCM ID
    "bit1": false  // 另一个自定义状态，比如标记是否领取过新人福利
}'

查询双比特的示例

curl -X POST "https://api.devicecheck.apple.com/v1/query_two_bits" \
-H "Authorization: Bearer YOUR_SERVER_AUTH_TOKEN" \
-H "Content-Type: application/json" \
-d '{
    "device_token": "IOS_CLIENT_SENT_TOKEN"
}'

Transaction ID的使用要点 #

每次调用update_two_bits接口时，必须传入一个唯一的Transaction ID（比如UUID），苹果服务器会记录这个ID：如果同一个ID的请求重复发送，苹果会直接返回上次的处理结果，不会重复修改比特状态——这能有效避免网络重试、客户端重复提交导致的状态混乱。

二、双比特识别设备、重装行为及业务场景适配 #

1. 如何利用双比特识别唯一设备？ #

划重点：双比特本身不能直接用来唯一识别设备，它只有4种状态组合（00/01/10/11），没法区分海量设备。真正用来关联设备的是Device Token对应的苹果内部设备标识符，这个标识符是和设备绑定的，即使应用卸载重装，只要设备不变，通过新生成的Device Token依然能查询到之前设置的双比特状态。

你可以用双比特来标记设备的业务状态，比如：

• 用bit0标记「是否已经绑定过FCM ID」
• 用bit1标记「是否是首次安装用户」

2. 应用重装时，苹果服务器会自动修改比特值吗？ #

不会！双比特的状态完全由你的服务器通过API主动修改，苹果不会自动变更。应用重装后，你的App重新获取Device Token并发送给服务器，服务器可以调用query_two_bits接口查询之前的状态，再根据业务逻辑决定是否修改。

3. Transaction ID的核心作用 #

刚才提到了防重复提交，再结合你的场景补充：当用户重装App后，你的服务器需要把新的FCM ID替换掉旧的，这时候如果因为网络波动，客户端重复发送了两次请求，Transaction ID就能确保苹果只处理一次双比特的更新（比如把bit0设为true，标记已绑定），避免服务器重复执行FCM ID替换操作。

4. 适配你的「重装替换FCM ID」业务场景 #

完整流程建议是这样：

• 用户重装App后，App启动时调用fetchDeviceCheckToken获取新的Device Token
• App将Device Token和新生成的FCM ID一起发送到你的服务器
• 服务器先调用苹果的query_two_bits接口，查询该设备的bit0状态：
  • 如果bit0为false：说明是首次绑定，直接存储FCM ID，然后调用update_two_bits把bit0设为true，同时传入唯一的Transaction ID
  • 如果bit0为true：说明是重装用户，用新的FCM ID替换服务器上存储的旧ID，同样可以用Transaction ID确保这次替换操作不会重复执行
• 后续服务器推送消息时，就用最新的FCM ID发送

内容的提问来源于stack exchange，提问作者Jeeva