㈠ android获取设备唯一ID（优化方案）
最近，因公司产品及客户需要，领导让我研究免存储设备ID，以及给出一个设备ID最佳的方案（可与存储相结合）。在研究过浏览器的fingerprient2js后，颇有心得，并且看网上似乎木有完美的解决方案，于是写了这篇文章，仅供需要的开发者参考。（该算法暂未进行验证，这里先给出一个jar包，后期我会在SDK中加入调查接口，分两个jar包（测试版和正式版），希望开发者能支持测试版，稳定后使用正式版。）
在产品中，首先肯定要尽量避免权限，其次考虑卸载APP后ID不一致的问题，再就是尽量结合存储，降低卸载或重装app时，设备ID改变的概率。最后，设计出合理方案，对造成不利的因素进行列举。
A.android_id:
什么是android_id呢？当设备在第一次启动时，系统会随机产生一个64位的数字，然后以16进制的形式保存在设备上，且API提供了获取这一参数的方法：
这就是android_id,当设备重新初始化或者刷机的时候，会被重置。
除此以外，android_id还有其他的bug，比如：
1.不同的设备可能会产生相同的android_id。
2.有的厂商设备无法获取android_id,会返回null。
3.对于CDMA的设备，ANDROID_ID和TelephonyManager.getDeviceId() 的值相同。
4.不同的android系统版本稳定性不同。
B.硬件序列号(SERIAL)
API给的解释是：
A hardware serial number, if available.（一个硬件的序列码，如果有效的话）
so，虽然我没有用几百台手机测试，也能知道这个值有时候是无效的，说的这么隐晦。
C.指纹
fingerprint:设备的唯一标识。由设备的多个信息拼接合成。
也是在JavaScript才接触到这个单词”fingerprint“，这个词也很生动，意思是能大概的标识一个设备，像指纹一样，但不排除重复的可能性。
理论上讲用这个属性是可以标识一个设备的，但是其实并不是，两台一摸一样的新手机，这个值相同的可能性是很多的。为了更加进一步的精确，后面还会介绍几个属性，并把几个属性结合在一起，生成一个接近100%的UUID。
D.android系统提供了获取android系统版本号，生产厂商，固件版本推出时间的API.
E.android系统提供了当前android设备是12或24小时制显示时间的API，
F.android系统提供了当前android设备的修订版本列表，显示屏，主板等等参数。
G.可以允许用户根据需求用自定义字符串去为FP做贡献，比如IP地址等
方案：
在不需要用户权限的前提下，网上最完美的方案是将android_id和硬件序列号，如果其中任意一种失效就使用另外一种。受FingerPrint2js的启发，我看了Android获取系统硬件相关的API，将所有不经常变化且能代表一定用户群体的属性都取出来进行MD5运算，包含但不限于依据中所述的信息。准确性还需进一步验证，但理论上要比FingerPrint2js准确性高，也在网上给出的比较好的方案基础上进一步缩小了FP可能重复的概率。
1.第一次进入APP时，获取系统相关配置信息生成FP，存入SP。
2.每次访问，先从SP取，没有再通过相关配置信息生成FP，存入SP。
3.封装成jar，只给用户暴露出获取ID的接口、传递自定义信息构建FP的接口以及第一次安装时间戳的接口（或设置标签调用的接口）
单纯对于FP而言，有两个主要问题需要解决，一是FP重复的问题，相同配置的新设备重复可能性极大，增多给FP贡献的因素的数量，可以有效降低重复率。二是FP改变的问题，贡献FP的生成因素的其中一个如果改变，FP就会改变。所以如果FP的贡献因素数量过多，导致FP改变的概率也就变大，所以说客户要在两者之间做一个很好的平衡。
对比：
为android FP做贡献的各配置参数：（示例以6.0的华为荣耀8为例）
1.Android_ID:Settings.System.getString(context.getContentResolver(), Settings.System.ANDROID_ID) //低版本稳定，高版本不稳定 示例：295a4fbf716094ee
2.Build.SERIAL 设备序列号（有的设备无法获取） 示例：WTK7N16923005607
3.Build.FINGERPRINT 设备指纹（同样的新设备该值应该是一样的） 示例：honor/FRD-AL00/HWFRD:6.0/HUAWEIFRD-AL00/C00B171:user/release-keys
4.Build.TIME 固件推出日期 示例：1477442228000
5.Build.VERSION.INCREMENTAL 源码控制版本号 示例： C00B171
6.Build.getRadioVersion() 获取无线电固件版本 示例：21.210.03.00.031,21.210.03.00.031
7.Build.HARDWARE 硬件名称 示例：hi3650
8.Build.VERSION.SECURITY_PATCH 用户可见安全补丁level（这里我得到的是日期，可能是补丁修复的时间）示例：2016-10-01
9.当前设备是12/24时制：Settings.System.getString(context.getContentResolver(), Settings.System.TIME_12_24) 示例：null（有的手机可以获取）
10.Build.VERSION.SDK_INT SDK版本号 （一般讲是与系统版本号一一对应的） 示例：23
11.Build.SUPPORTED_32_BIT_ABIS 支持32位ABIs的列表（数值）示例：[armeabi-v7a,armeabi]
12.Build.SUPPORTED_64_BIT_ABIS 支持64位ABIs的列表（数值）示例：[arm64-v8a]
13.Build.BOOTLOADER 系统启动程序版本号 示例：unknown
14.Build.VERSION.RELEASE 用户可见版本 示例： 6.0
16.Build.BOARD 主板 示例：FRD-AL00
17.Build.BRAND 系统定制商 示例：honor
21.Build.HOST 示例：huawei-RH2288H-V2-12L
23.Build.MANUFACTURER 产品/硬件的制造商 示例：HUAWEI
25.Build.PRODUCT 产品的名称 示例：FRD-AL00
26.Build.TAGS 描述Build的标签（Comma-separated tags describing the build, like "unsigned,debug".） 示例：release-keys
28.Build.USER 描述Build的USER 示例：jslave
31.Build.VERSION.BASE_OS 基带版本 The base OS build the proct is based on. 示例：空值
32.自定义字符串或自定义数组
㈡ 如何确定一台 Android 设备的唯一性
他的MAC码和进网许可证之类的就是唯一的，全世界都不相同
㈢ linux系统中，设备以什么来唯一确定
跟WINDOWS一样吧。硬盘，光盘，软盘，可移动磁盘，鼠标，打印机，网卡,磁盘。。。常见硬件设备在linux中的代号：IDE硬盘/dev/hd[a-d]SCSI硬盘/dev/sd[a-d]光驱/dev/cdrom软驱/dev/fd[0-1]打印机/dev/lp[0-1]鼠标/dev/mouse磁盘/dev/ht0(IDE)/dev/st0(SCSI)网卡/dev/ethn(n由0开始）
㈣ 在前端方面有哪些识别唯一设备或用户的方法
UDID的全称是Unique Device Identifier，顾名思义，它就是苹果IOS设备的唯一识别码，它由40个字符的字母和数字组成。在很多需要限制一台设备一个账号的应用中经常会用到。在iOS5中可以获取到设备的UDID，后来被苹果禁止了。
IDFA（identifierForIdentifier）
广告标示符，适用于对外：例如广告推广，换量等跨应用的用户追踪等。
是iOS 6中另外一个新的方法，提供了一个方法advertisingIdentifier，通过调用该方法会返回一个NSUUID实例，最后可以获得一个UUID，由系统存储着的。不过即使这是由系统存储的，但是有几种情况下，会重新生成广告标示符。如果用户完全重置系统（(设置程序 -> 通用 -> 还原 -> 还原位置与隐私) ，这个广告标示符会重新生成。另外如果用户明确的还原广告(设置程序-> 通用 -> 关于本机 -> 广告 -> 还原广告标示符) ，那么广告标示符也会重新生成。关于广告标示符的还原，有一点需要注意：如果程序在后台运行，此时用户“还原广告标示符”，然后再回到程序中，此时获取广 告标示符并不会立即获得还原后的标示符。必须要终止程序，然后再重新启动程序，才能获得还原后的广告标示符。
在同一个设备上的所有App都会取到相同的值，是苹果专门给各广告提供商用来追踪用户而设的，用户可以在 设置|隐私|广告追踪 里重置此id的值，或限制此id的使用，故此id有可能会取不到值，但好在Apple默认是允许追踪的，而且一般用户都不知道有这么个设置，所以基本上用来监测推广效果，是戳戳有余了。
注意：由于idfa会出现取不到的情况，故绝不可以作为业务分析的主id，来识别用户。
IDFV（identifierForVendor）
Vindor标示符，适用于对内：例如分析用户在应用内的行为等。
是给Vendor标识用户用的，每个设备在所属同一个Vender的应用里，都有相同的值。其中的Vender是指应用提供商，但准确点说，是通过BundleID的DNS反转的前两部分进行匹配，如果相同就是同一个Vender，例如对于com.somecompany.appone,com.somecompany.apptwo
这两个BundleID来说，就属于同一个Vender，共享同一个idfv的值。和idfa不同的是，idfv的值是一定能取到的，所以非常适合于作为内部用户行为分析的主id，来标识用户，替代OpenUDID。
注意：如果用户将属于此Vender的所有App卸载，则idfv的值会被重置，即再重装此Vender的App，idfv的值和之前不同。
㈤ 下列哪些电脑属性或者组合属性是唯一的
这里看不到唯一属性，电脑名都可以修改成相同的，工作组是必须一样的。
只能通过IP或MAC查看内网唯一属性
㈥ iOS获取设备唯一标识的各种方法IDFA，IDFV，UDID分别是什么含义
UDID的全称是Unique
Device
Identifier，顾名思义，它就是苹果IOS设备的唯一识别码，它由40个字符的字母和数字组成。在很多需要限制一台设备一个账号的应用中经常会用到。在iOS5中可以获取到设备的UDID，后来被苹果禁止了。
IDFA（identifierForIdentifier）
广告标示符，适用于对外：例如广告推广，换量等跨应用的用户追踪等。
是iOS
6中另外一个新的方法，提供了一个方法advertisingIdentifier，通过调用该方法会返回一个NSUUID实例，最后可以获得一个UUID，由系统存储着的。不过即使这是由系统存储的，但是有几种情况下，会重新生成广告标示符。如果用户完全重置系统（(设置程序
->
通用
->
还原
->
还原位置与隐私)
，这个广告标示符会重新生成。另外如果用户明确的还原广告(设置程序->
通用
->
关于本机
->
广告
->
还原广告标示符)
，那么广告标示符也会重新生成。关于广告标示符的还原，有一点需要注意：如果程序在后台运行，此时用户“还原广告标示符”，然后再回到程序中，此时获取广
告标示符并不会立即获得还原后的标示符。必须要终止程序，然后再重新启动程序，才能获得还原后的广告标示符。
在同一个设备上的所有App都会取到相同的值，是苹果专门给各广告提供商用来追踪用户而设的，用户可以在
设置|隐私|广告追踪
里重置此id的值，或限制此id的使用，故此id有可能会取不到值，但好在Apple默认是允许追踪的，而且一般用户都不知道有这么个设置，所以基本上用来监测推广效果，是戳戳有余了。
注意：由于idfa会出现取不到的情况，故绝不可以作为业务分析的主id，来识别用户。
IDFV（identifierForVendor）
Vindor标示符，适用于对内：例如分析用户在应用内的行为等。
是给Vendor标识用户用的，每个设备在所属同一个Vender的应用里，都有相同的值。其中的Vender是指应用提供商，但准确点说，是通过BundleID的DNS反转的前两部分进行匹配，如果相同就是同一个Vender，例如对于com.somecompany.appone,com.somecompany.apptwo
这两个BundleID来说，就属于同一个Vender，共享同一个idfv的值。和idfa不同的是，idfv的值是一定能取到的，所以非常适合于作为内部用户行为分析的主id，来标识用户，替代OpenUDID。
注意：如果用户将属于此Vender的所有App卸载，则idfv的值会被重置，即再重装此Vender的App，idfv的值和之前不同。
㈦ 手机上有什么可以作为唯一标识的东西
IMSI国际移动用户识别码（IMSI：International Mobile Subscriber Identification Number）是区别移动用户的标志，储存在SIM卡中，可用于区别移动用户的有效信息。IMSI组成如下图所示，其总长度不超过15位，同样使用0～9的数字。 其中MCC是移动用户所属国家代号，占3位数字，中国的MCC规定为460；MNC是移动网号码，最多由两位数字组成，用于识别移动用户所归属的移动通信网；MSIN是移动用户识别码，用以识别某一移动通信网中的移动用户。)
IMEI(国际移动设备识别码（IMEI：International Mobile Equipment Identification Number）是区别移动设备的标志，储存在移动设备中，可用于监控被窃或无效的移动设备。IMEI组成如下图所示，移动终端设备通过键入“*#06#”即可查得。其总长为15位，每位数字仅使用0～9的数字。其中TAC代表型号装配码，由欧洲型号标准中心分配；FAC代表装配厂家号码；SNR为产品序号，用于区别同一个TAC和FAC中的每台移动设备；SP是备用编码。
ESN （Electronic Serial Numbers）：电子序列号，在CDMA 系统中，是鉴别一个物理硬件设备唯一的标识。也就是说每个手机都用这个唯一的ID来鉴别自己, 就跟人的身份证一样。CDMA中的ESN对应于GSM网络中的IMEI。 一个ESN有32 bits, 也就是 32/4 = 8 bytes。随着CDMA移动设别的增多，ESN已经不够用了，所以推出了位数更多的MEID。ESN用16进制来表示。)
MEID（Mobile Equipment ID）： 由于CDMA移动设备增多，导致原来8位的ESN不够用，所以56bits=（56/4=14bytes）的MEID横空出世。现在的CDMA手机一般ESN/MEID两者都有。MEID也是用16进制来表示。
㈧ 怎么认证安卓设备唯一性
前段时间项目需要一个功能，就是在操作完某一个逻辑之后返回给客户一个红包，安全校验团队需要我们提供android设备的唯一标示，起初直接通过获取设备的imei号传给了server端，后台公司云迹监控发现，有些设备的imei号是0000000000000000，这样失去了设备唯一性验证的功能，第二个版本做了一个修复，除了获取imei号之外还新增了AndrdoiId的处理，不过悲剧的是android 设备实在是太多太杂了，仅仅通过这两个维度去确定设备的唯一性还是有一些漏洞的，最终我们的解决方案是尽量多的获取与设备相关的信息，最后做一个MD5数字加签，基本满足了这个需求 [java] view plain package com.suning.mobile.epa; import java.security.MessageDigest; import java.security.NoSuchAlgorithmException; import android.content.Context; import android.os.Build; import android.provider.Settings.Secure; import android.telephony.TelephonyManager; public class DeviceFactoty { // buildId public String m_szDevIDShortMaker() { String m_szDevIDShort = "35"; m_szDevIDShort += Build.BOARD.length() % 10 + Build.BRAND.length() % 10 + Build.CPU_ABI.length() % 10 + Build.DEVICE.length() % 10 + Build.DISPLAY.length() % 10 + Build.HOST.length() % 10 + Build.ID.length() % 10 + Build.MANUFACTURER.length() % 10 + Build.MODEL.length() % 10 + Build.PRODUCT.length() % 10 + Build.TAGS.length() % 10 + Build.TYPE.length() % 10 + Build.USER.length() % 10 + ""; return m_szDevIDShort; } public String currentDeviceMark(Context context) { final TelephonyManager tm = (TelephonyManager) context .getSystemService(Context.TELEPHONY_SERVICE); final String tmDevice, tmSerial, androidId; tmDevice = "" + tm.getDeviceId(); tmSerial = "" + tm.getSimSerialNumber(); androidId = "" + android.provider.Settings.Secure.getString(EPApp.getApp() .getContentResolver(), Secure.ANDROID_ID); String serial = ""; if (Build.VERSION.SDK_INT > Build.VERSION_CODES.FROYO){ serial = Build.SERIAL; } String m_szLongID = tmDevice + tmSerial + androidId + serial + m_szDevIDShortMaker(); MessageDigest m = null; try { m = MessageDigest.getInstance("MD5"); } catch (NoSuchAlgorithmException e) { e.printStackTrace(); } m.update(m_szLongID.getBytes(), 0, m_szLongID.length()); // get md5 bytes byte p_md5Data[] = m.digest(); // create a hex string String m_szUniqueID = new String(); for (int i = 0; i < p_md5Data.length; i++) { int b = (0xFF & p_md5Data[i]); // if it is a single digit, make sure it have 0 in front (proper padding) if (b <= 0xF) m_szUniqueID += "0"; // add number to string m_szUniqueID += Integer.toHexString(b); } // hex string to uppercase return m_szUniqueID = m_szUniqueID.toUpperCase(); } }
㈨ 漫谈唯一设备ID
设备ID，简单来说就是一串符号（或者数字），映射现实中硬件设备。
如果这些符号和设备是一一对应的，可称之为“唯一设备ID（Unique Device Identifier）”
不幸的是，对于Android平台而言，没有稳定的API可以让开发者获取到这样的设备ID。
开发者通常会遇到这样的困境：
随着项目的演进， 越来越多的地方需要用到设备ID；
然而随着Android版本的升级，获取设备ID却越来越难了。
加上Android平台碎片化的问题，获取设备ID之路，可以说是步履维艰。
关于设备ID的作用，大概可以分为下面几点：
获取设备标识的API屈指可数，而且都或多或少有一些问题。
常规的API有以下这些：
IMEI本该最理想的设备ID，具备唯一性，恢复出厂设置不会变化（真正的设备相关）。
然而，获取IMEI需要 READ_PHONE_STATE 权限，估计大家也知道这个权限有多麻烦了。
尤其是Android 6.0以后, 这类权限要动态申请，很多用户可能会选择拒绝授权。
我们看到，有的APP不授权这个权限就无法使用， 这可能会降低用户对APP的好感度。
而且，Android 10.0 将彻底禁止第三方应用获取设备的IMEI, 即使申请了 READ_PHONE_STATE 权限。
所以，如果是新APP，不建议用IMEI作为设备标识；
如果已经用IMEI作为标识，要赶紧做兼容工作了，尤其是做新设备标识和IMEI的映射。
通过 android.os.Build.SERIAL 获得，由厂商提供。
如果厂商比较规范的话，设备序列号+Build.MANUFACTURER应该能唯一标识设备。
但现实是并非所有厂商都按规范来，尤其是早期的设备。
最致命的是，Android 8.0 以上，android.os.Build.SERIAL 总返回 “unknown”；
若要获取序列号，可调用Build.getSerial() ，但是需要申请 READ_PHONE_STATE 权限。
到了Android 10.0以上，则和IMEI一样，也被禁止获取了。
总体来说，设备序列号有点鸡肋：食之无味，弃之可惜。
获取MAC地址也是越来越困难了，
Android 6.0以后通过 WifiManager 获取到的mac将是固定的：02:00:00:00:00:00 ，
再后来连读取 /sys/class/net/wlan0/address 也获取不到了。
如今只剩下面这种方法可以获取（没有开启wifi也可以获取到）：
再往后说不准这种方法也行不通了，且用且珍惜~
Android ID 是获取门槛最低的，不需要任何权限，64bit 的取值范围，唯一性算是很好的了。
但是不足之处也很明显：
1、刷机、root、恢复出厂设置等会使得 Android ID 改变；
2、Android 8.0之后，Android ID的规则发生了 变化 ：
两个规则导致的结果就是：
第一，如果用户安装APP设备是8.0以下，后来卸载了，升级到8.0之后又重装了应用，Android ID不一样；
第二，不同签名的APP，获取到的Android ID不一样。
其中第二点可能对于广告联盟之类的有所影响。
笔者之前写过一篇文章 《Android设备唯一标识的获取和构造》 , 文中提到设备ID的两个概念：唯一性和稳定性。
唯一性：两台不同的设备获取到的设备ID不相同；
稳定性：同一台设备在不同的时间, 获取到设备ID相同。
分析唯一性，我们可以从ID的分配来入手：
左边第一栏是bit数量，第二栏是对应的取值范围，再后面是元素个数以及对应的冲突概率。
例如，假如有50000个32bit的随机数，则这些随机数中，至少有两个相同数字的概率为25%；
换一种说法，就是假如有四组数，每组都有50000个随机数，则大约其中一组会有重复的数字。
32bit有43亿的取值范围，怎么50000个随机数就有这么高的出现重复的概率？
如果对此感到困惑，可以了解一下 生日悖论 。
Android ID是长度为16的十六进制字符串，其实就是64bit，我们来分析一下其重复的概率：
假如APP累计激活量达到50亿的APP，则每两个这样的APP就大约有一个会有重复的Android ID。
不过这里的“重复”不是大量的重复，而是“至少有两个相同”，也就是，如果设备激活量有50亿（很多APP达不到-_-），那么有可能会有少量的重复的Android ID。
总体而言, Android ID的唯一性还是不错的。
JDK的randomUUID，大致可以认为是128bit的随机数（其中有6bit是固定的），即使到达200亿的数量，有重复的概率也仅仅是10的负18次方，微乎其微。
稳定性有两个层面：
无论是统计需求，还是业务需求，都要求设备ID是唯一的，稳定的。
如果设备ID有重复，则活跃统计，用户画像，定向推送等统统都不准确了；
其中，影响最深是定向推送，送错快递还有可能追回，推送错了就不好说了，如果推送内容又比较重要，后果不堪设想。
如果设备ID不稳定（ID变化），会影响到活跃统计（会认为是新用户），对用户画像也有较大影响（之前的ID关联的行为数据无法跟踪了）。
为此，有必要设计一套方案，提供相对定稳定的，唯一的设备ID。
首先要明确两个前提条件：
前面分析的设备ID中，在可用的前提下，出现重复的概率较小；
如果一定的频率去观察，比如说每天，总体而言，观察到和昨天不一样的概率也是较小的。
如何在本来就较小的概率的前提下，继续降低概率呢？
一种方案是组合设备ID(直接拼接，或者拼接后计算摘要)。
举个例子，假如出现重复的概率和发生变化的的概率都是千分之一，
则对于两台不同设备，两个设备ID同时重复的概率是百万分之一，两个设备ID至少有一个发生变化约为千分之二。
也就是，拼接ID的效果是大大提高唯一性，但是一定程度上降低稳定性（只要其中一个要素变化，拼接的ID就变了）。
但事实上，如今能拿到的设备ID，最突出的矛盾是不稳定，所以，我们不能为了提高唯一性而牺牲稳定性。
要提高稳定性，可以引入容错方案。
容错方案有很多，比如网络传输，用checksum去校验报文，如果出错了则重发；
再如磁盘阵列，数据写入两个磁盘，只有当两个磁盘同时出错时才会丢失数据，从而大大降低丢失数据的概率。
但是对于设备ID，以上两种方案都不合适，因为上面的方案需要通过checksum来确认原信息是否被修改，设备ID没有这样的条件。
所以，可以引入类似虚拟货币用到的"拜占庭容错"方案。
简单地说，就是要采集三个设备ID到云端，如果有两个（包括两个以上）的设备ID和之前的记录相同，则认为是同一台设备。
同样假设出现重复的概率和发生变化的的概率都是千分之一，则：
同一台设备的两次采集，认不出是同一台设备的条件为“至少两个设备ID都和上次不一样”，概率约为百万分之三。
两台不同的设备，认为是同一台的条件是为“三个设备ID中，至少有两个设备ID和另一台设备相同”，概率同样约为百万分之三。
所以，用此方案，唯一性和稳定性都能得到提高。
基本思想是：服务端有一张设备 ID 的表，核心的属性（Column）有：
id | did_1 | did_2 | did_3
客户请求时，上传三个设备 ID，服务端检索:
如果检索到记录，其中至少两个did和上传的相同，则返回 id;
否则，插入上传的三个设备 ID，并将新插入记录的 id 返回。
通常情况下，服务端表的主键为自增序列（为了确保插入的有序性），
所以我们不能直接返回表的主键，否则容易被他人推测其他的设备 ID，以及知晓用户数量。
因此，在主键 ID 之外，我们需要另外一个唯一 ID。
有两种思路：
然后就是，需要三个设备ID……
那么，如果在没有 READ_PHONE_STATE 权限的情况下，以及Android 10.0之后，如何处理？
首先，设备序列号还是要采集的，毕竟还有部分旧版本的设备可以获取到，能区分一点是一点；
然后，采集一些设备相关的信息，机型，硬件信息等（相同的机型，可能有多种配置，所以同时也采集一下硬件信息）。
最终匹配规则如下：
如果没有匹配的设备，则认为是新设备；
此时，生成新的udid返回，同时插入新设备的相关信息（设备ID，硬件信息）。
关于硬件信息，需满足一个要求：在设备重启、恢复出厂设置等操作之后，不会变化。
常规信息有CPU核心数，RAM/ROM大小（以Gb为单位采集，而不是精确到比特，否则容易变化），屏幕分辨率和dpi等，结合机型，保守估计有上千甚至上万种可能性，相对Android ID 的 2^64 当然相差很远了，但是仍可作为辅助的参考信息。
试想在设备序列号获取不到，Android ID 和 MAC 地址其中一个发生变化时，检索到的都是只有Android ID 或者 MAC 其中一个匹配的记录，茫茫机海，说不准就有一两台的Android ID 或 MAC是相同的。
这时候选哪一个呢？ 再加上设备信息，或许就区分开了。
常规的设备信息容易遭到篡改，所以，在常规信息之外，我们可以挖掘一些冷门的设备特征，比如 NetworkInterface 和 传感器 的相关信息。
当常规信息被篡改时，如果冷门的设备信息还没变，仍可识别出是同一台设备。
至于如何挖掘，那就各显神通了，通常做手机硬件或者ROM的朋友可能会知道更多的API。
为了方便检索，我们可以用 MurmurHash 将信息压缩到64bit(Long的长度）。
再者，在获取到udid之后，可以定时（比如每隔两天）就上传udid和设备信息给云端，云端比较一下存储的信息和上传的信息，不相同则更新，这样可以提高udid的稳定性。
比方说，用户在设备是Android 7.0 的时候卸载了APP，在Android 8.0之后安装回来，这时候Android ID 是变化了的，但是凭着MAC和设备信息我们可以认出这台设备，同时更新其 Android ID;
如果哪一天轮到MAC获取不到了，这时候我们仍可以根据 Android ID和设备信息识别出这台设备。
本文介绍了设备ID的用途，现状，并分析了现有设备ID的特性，最后提出了一套设备ID的构造方案。
按照这几年的趋势，各种设备ID的API或许还会越收越紧，仅从客户端去构造可靠的设备ID是比较困难的，而基于信息采集和云端综合计算则相对容易。
具体实现，笔者编写了一个Demo，已发布的到github，谨供参考。
项目地址： https://github.com/BillyWei001/Udid
参考资料：
https://www.jianshu.com/p/9d828d259270
https://www.jianshu.com/p/ad9756fe21c8
https://blog.csdn.net/andoop/article/details/54633077
https://blog.csdn.net/renlonggg/article/details/78435986
https://developer.android.com/about/versions/oreo/android-8.0-changes?hl=zh-cn
https://en.wikipedia.org/wiki/Birthday_attack
㈩ 苹果ios多开怎么识别唯一标识
IOS系统中，获取设备唯一标识的方法有很多：
一.UDID(Unique Device Identifier)
UDID的全称是Unique Device Identifier，顾名思义，它就是苹果IOS设备的唯一识别码，它由40个字符的字母和数字组成。
二.UUID(Universally Unique Identifier)
UUID是Universally Unique Identifier的缩写,中文意思是通用唯一识别码.
三.MAC Address
四.OPEN UDID
五.广告标示符（IDFA-identifierForIdentifier）
六.Vindor标示符 (IDFV-identifierForVendor)
Vendor是CFBundleIdentifier（反转DNS格式）的前两部分。来自同一个运营商的应用运行在同一个设备上，此属性的值是相同的；不同的运营商应用运行在同一个设备上值不同。
经测试，只要设备上有一个tencent的app，重新安装后的identifierForVendor值不变，如果tencent的app全部删除，重新安装后的identifierForVendor值改变。
但是很不幸，上面所有这些表示设备唯一号的标识，在IOS7中要么被禁止使用，要么重新安装程序后两次获取的标识符不一样。
由于IOS系统存储的数据都是在sandBox里面，一旦删除App，sandBox也不复存在。好在有一个例外，那就是keychain（钥匙串）。
通常情况下，IOS系统用NSUserDefaults存储数据信息，但是对于一些私密信息，比如密码、证书等等，就需要使用更为安全的keychain了。
keychain里保存的信息不会因App被删除而丢失。所以，可以利用这个keychain这个特点来保存设备唯一标识。
那么，如何在应用里使用使用keyChain呢，我们需要导入Security.framework ，keychain的操作接口声明在头文件SecItem.h里。
直接使用SecItem.h里方法操作keychain，需要写的代码较为复杂，我们可以使用已经封装好了的工具类KeychainItemWrapper来对keychain进行操作。
KeychainItemWrapper是apple官方例子“GenericKeychain”里一个访问keychain常用操作的封装类，在官网上下载了GenericKeychain项目后，
只需要把“KeychainItemWrapper.h”和“KeychainItemWrapper.m”拷贝到我们项目，并导入Security.framework 。KeychainItemWrapper的用法：
/** 初始化一个保存用户帐号的KeychainItemWrapper */
KeychainItemWrapper *wrapper = [[KeychainItemWrapper alloc] initWithIdentifier:@"Account Number"
accessGroup:@"YOUR_APP_ID_HERE.com.yourcompany.AppIdentifier"];
//保存数据
[wrapper setObject:@"<帐号>" forKey:(id)kSecAttrAccount];
[wrapper setObject:@"<帐号密码>" forKey:(id)kSecValueData];
//从keychain里取出帐号密码
NSString *password = [wrapper objectForKey:(id)kSecValueData];
//清空设置
[wrapper resetKeychainItem];
其中方法“- (void)setObject:(id)inObject forKey:(id)key;”里参数“forKey”的值应该是Security.framework 里头文件“SecItem.h”里定义好的key，用其他字符串做key程序会出错！