uni-app获取设备唯一标识 uni-app App如何获取UUID/OAID

3次阅读

uni.getSystemInfoSync() 不返回 UUID，需首次启动时生成并三重存储（文件 /plus.storage/uni.setStorageSync），Android 优先 OAID，iOS 只能自建 UUID 并持久化，所有前端 ID 须服务端校验。

很多人以为调用 uni.getsysteminfosync() 就能顺手捞出设备 id，结果发现返回对象里压根没有 uuid 字段——没错，它只给设备信息，不生成也不持久化标识。真正可用的 plus.device.uuid 是 dcloud 原生层提供的，但它有硬伤：应用卸载重装后会变，而且在部分 android 12+ 设备上（尤其厂商定制系统）可能返回空或固定值。

必须首次启动时主动生成并写入本地存储，否则每次冷启都“失忆”
uni.setStorageSync('device_uuid', uuid) 是最简方案，但注意 iOS 17+ 对 uni.setStorageSync 的沙盒限制变严，偶尔写失败
更稳的做法是用文件系统存：封装一个 DeviceStorage.js，先尝试写文件，失败再 fallback 到 storage
别用时间戳 + 随机数拼接当 UUID——不同设备可能撞车，要用 Math.random().toString(36).substr(2, 9) 这类带熵的生成逻辑

在 Android 10+，READ_PHONE_STATE 权限基本拿不到 IMEI，即使你在 manifest.json 里写了 "READ_PHONE_STATE"，用户授权后也大概率返回空或 "000000000000000"。华为、小米、OPPO 等厂商系统还会主动拦截，不是你代码写错了，是系统不让。

优先走 com.uuzuo.oaid 这类成熟原生插件，它会自动降级：先试 OAID → 再试 ANDROID_ID → 最后 fallback 到自定义 UUID
OAID 可被用户手动重置（设置 → 广告与隐私 → 重置广告 ID），所以它适合做统计 / 推送，不适合做账号绑定
别自己用 Native.js 调 Settings.Secure.getString(……, 'android_id') —— Android 8.0 后该值对非系统 App 已变为 null 或常量，实测在 vivo 和 realme 上 100% 失效

iOS 完全不提供类似 OAID 的机制，deviceToken 是 APNs 推送专用凭证，和设备唯一性无关；而 aliyunpush.getDeviceId() 返回的 deviceId 是阿里云 SDK 自己生成的、仅限该推送通道内有效的 ID，换一个推送服务（比如个推、极光）就完全不一样。

想在 iOS 上稳定识别设备，唯一靠谱路径就是：App 启动时生成 UUID → 存到 uni.setStorageSync → 后续所有请求带上这个值
别试图用 plus.device.udid（已废弃）或 identifierForVendor（iOS 原生），uni-app 未暴露该能力，强行桥接风险高且审核可能被拒
如果业务强依赖设备一致性（比如防刷、设备锁），必须配合服务端校验：同一个 UUID 频繁出现在不同 IP 或 UA 下，就得触发二次验证

你以为存进 uni.setStorageSync 就万事大吉？现实是：某些低端 Android 机型（如传音 Tecno）会因内存紧张自动清空 storage；iOS 16.4 后部分企业签名包也会触发沙盒清理；而 plus.storage 在 HBuilderX 3.9+ 版本中又存在跨进程读写异常。

推荐三重落盘：先写 uni.setStorageSync，再写 plus.io.resolveLocalFileSystemURL 文件，最后用 plus.storage.setItem 备份一份
读取时按顺序尝试：文件 → plus.storage → uni.getStorageSync，任一成功就立刻返回，避免卡顿
生成 UUID 的时机必须是 onLaunch 里，且加个防重逻辑：先读，读不到再生成，生成完立刻存，不要等页面 ready 或网络就绪后再操作

实际跑通的关键，是接受“没有银弹”。OAID 会重置，UUID 会丢失，IMEI 已失效——你得按场景组合使用，再靠服务端兜底校验。最常被忽略的一点：前端生成的任何 ID，都必须和服务端下发的设备指纹做双向比对，否则单侧信任等于裸奔。

发表于：前端

近一天内