Device ID 组件概述（UTDID）——mPaaS 设备唯一标识 原文标题：Overview
内容概要总结
本文是阿里云 mPaaS 官方文档中 Device ID 组件的概述，介绍其为每台移动设备生成稳定的设备级标识 UTDID 的机制与边界。核心结论：应用首次调用 Device ID API 时组件生成 UTDID 并本地存储，之后调用直接返回同一值、无需网络请求；UTDID 是「应用范围（app-scoped）」的——同一台设备上所有集成了 mPaaS SDK 的应用共享同一个 UTDID 值，因此可用于分析、风控、推送定向、A/B 测试等需要跨会话识别设备的场景。
文档用表格说明持久性：应用重启或设备重启、清除应用数据或缓存时可能变化（本地存储的 ID 丢失则重新生成）；卸载重装会改变（存储的 UTDID 被抹除，下次启动重新生成）；用户换设备会改变（每台物理设备各有自己的 UTDID）；同设备多个应用（均用 mPaaS SDK）保持不变。平台差异：Android 存于本地存储，只要设备存储完好即可跨应用更新与重装持久，恢复出厂或手动删除应用数据会重新生成；iOS 存于 Keychain，因 Keychain 数据在卸载后仍保留，UTDID 可在重装后存活，这点与 Android 不同。
文档明确限制：UTDID 不保证在所有设备上始终全局唯一，不应作为金融交易去重、法定身份校验等要求严格唯一性场景的唯一标识；Android 与 iOS 的 UTDID 相互独立、不适用于跨平台追踪；UTDID 标识的是设备而非用户账号，多人共用一台设备会得到同一 UTDID。
翻译内容
原文内容（English）
Device ID 组件为每台移动设备生成一个稳定的、按设备维度的标识符（UTDID），从而实现跨会话一致的设备识别，且无需用户登录或服务端 ID 管理。
应用使用 UTDID 来区分设备，用于分析、风控、推送通知定向，以及其他需要跨会话可靠识别设备的场景。
工作原理
当你的应用首次调用 Device ID API 时，组件会生成一个 UTDID 并将其存储在设备本地。之后的调用会返回同一个 UTDID，且不会发起网络请求。UTDID 是应用范围的（app-scoped）——同一台设备上所有集成了 mPaaS SDK 的应用共享同一个 UTDID 值。
ID 持久性
UTDID 的持久性取决于该 ID 是如何、何时生成的。请用下表判断 UTDID 是否适合你的场景：
应用重启或设备重启
应用数据或缓存被清除
应用卸载并重装
可能变化。如果本地存储的 ID 丢失，会生成一个新的 UTDID。
变化。已存储的 UTDID 会被抹除，下次启动时生成一个新的。
用户换到另一台设备
变化。每台物理设备都有自己的 UTDID。
同一台设备上的多个应用（均使用 mPaaS SDK）
不变——所有应用共享同一个 UTDID。
注意：UTDID 不保证在所有设备上、所有时刻都全局唯一。在要求严格唯一性保证的场景中（例如金融交易去重或法定身份校验），不要把它作为唯一标识符使用。
平台行为
该组件支持 Android 和 iOS。UTDID 的行为在两个平台间存在差异：
UTDID 存储在设备的本地存储中。只要设备存储完好，它就能跨应用更新与重装而持久存在。恢复出厂设置或手动删除应用数据会重新生成 UTDID。
UTDID 存储在 iOS Keychain 中。由于 Keychain 数据在应用卸载后仍然保留，因此在 iOS 上 UTDID 能在重装后存活——这一点不同于 Android，在 Android 上 UTDID 可能在卸载后被重新生成。
使用场景
分析与归因：在无需账号登录的情况下识别同一台设备上的回访用户。
风控：检测与特定设备相关的异常行为模式。
推送通知定向：使用稳定的设备级标识符把通知路由到特定设备。
A/B 测试：跨会话一致地把设备分配到测试分组。
局限
不适用于严格的唯一性要求：UTDID 可能在恢复出厂设置后、或在 Android 上卸载后被重新生成。对于需要永久、不可伪造设备指纹的场景，应将 UTDID 与服务端账号绑定结合使用。
不适用于跨平台追踪：一台设备的 Android UTDID 与 iOS UTDID 是相互独立的值。如果同一用户切换平台，设备 ID 会改变。
不是用户身份：UTDID 标识的是设备，而非用户账号。如果多个用户共用一台设备，他们都会得到同一个 UTDID。
下一步
在 Android 上集成 Device ID 组件
在 iOS 上集成 Device ID 组件
Device ID 的 API 参考
上一篇：Device ID 下一篇：与 Android 集成
The Device ID component generates a stable, per-device identifier (UTDID) for each mobile device, enabling consistent device recognition across sessions without requiring user login or server-side ID management.
Apps use UTDID to distinguish devices for analytics, risk control, push notification targeting, and other scenarios that require reliable device recognition across sessions.
How it works
When your app calls the Device ID API for the first time, the component generates a UTDID and stores it locally on the device. Subsequent calls return the same UTDID without a network request. The UTDID is app-scoped — all apps integrated with the mPaaS SDK on the same device share the same UTDID value.
ID persistence
UTDID persistence depends on how and when the ID was generated. Use the following table to determine whether UTDID suits your scenario:
App restart or device reboot
App data or cache cleared
App uninstalled and reinstalled
May change. A new UTDID is generated if the locally stored ID is lost.
Changes. The stored UTDID is erased and a new one is generated on next launch.
User switches to a different device
Changes. Each physical device has its own UTDID.
Multiple apps on the same device (all using mPaaS SDK)
Unchanged — all apps share the same UTDID.
Note: UTDID is not guaranteed to be globally unique across all devices at all times. Do not use it as the sole identifier in scenarios that require strict uniqueness guarantees, such as financial transaction deduplication or legal identity verification.
Platform behavior
The component supports Android and iOS. UTDID behavior differs between platforms:
UTDID is stored in the device's local storage. It persists across app updates and reinstalls as long as the device storage is intact. A factory reset or manual deletion of app data regenerates the UTDID.
UTDID is stored in the iOS Keychain. Because Keychain data persists across app uninstalls, the UTDID survives reinstallation on iOS — unlike on Android, where the UTDID may be regenerated after an uninstall.
Use cases
Analytics and attribution: Identify returning users on the same device without requiring account login.
Risk control: Detect abnormal behavior patterns tied to a specific device.
Push notification targeting: Route notifications to specific devices using a stable device-level identifier.
A/B testing: Assign devices to test groups consistently across sessions.
Limitations
Not suitable for strict uniqueness requirements: UTDID can be regenerated after a factory reset or, on Android, after an uninstall. For scenarios requiring a permanent, unforgeable device fingerprint, combine UTDID with server-side account binding.
Not suitable for cross-platform tracking: A device's Android UTDID and iOS UTDID are independent values. If the same user switches platforms, the device ID changes.
Not a user identity: UTDID identifies a device, not a user account. If multiple users share a device, they all receive the same UTDID.
What's next
Integrate the Device ID component on Android
Integrate the Device ID component on iOS
API reference for Device ID