fir.im 怎么获取uuid

次很偶然的机会知道FIRim，这家公司主要的产品就是帮助开发者方便便捷地发布iOS或者Android应用的。今天我就聊聊如何在FIRim中发布自己的APP，然后让加入UUID的设备通过网页直接下载安装。这样做的好处就是不用傻呵呵的每次插入USB，通过XCode去生成APP啦。毕竟有时候带根线是挺麻烦的事情，最关键的是团队成员一多，你总不能把设备一个个拿过来去更新，多么笨拙的事情啊。所以我觉得FIRim这事干得漂亮，下面就让我们看看如何发布一个APP的过程吧。

第一步：登录苹果开发者网站，添加想要安装测试应用的设备UDID，只有加入UDID的设备才可以通过浏览器去下载APP。FIRim 提供了一个快速获取UDID的方法，点击链接访问（需通过手机访问）。将获得的UDID添加到下图所示的iOS Devices里面。

第二步：制作一个发布证书，证书的发布是在Provisioning Profiles，下图已经将详细的发布证书步骤演示了一遍。

在添加页面选择Ad Hoc

进入选择App ID页面：

选择开发者

添加测试设备

最后就会跳转到信息页面，给这个证书之后就可以点击生成，下载就可以了。

下面我们就进入XCode对刚才生成的证书进行配置

在 Xcode 中点击Project图标，在Info这个tab下找到configuration设置，里面默认的是Debug和Release。点击+，选择Duplicate the “Release configuration”，给生成的新东西起个名字，推荐使用ad hoc distribution

点击Targets图标，在Build Settings这个Tab下，找到Code Signing部分。将Code Signing Identity中的ad hoc distribution证书设置为刚刚导入到 Xcode 中对应测试应用的证书。注意不要改动Debug和Release中的证书。

保证Target中Info这个tab下的Bundle Indentifier里面有预设值，其必须和Provision Portal输入匹配。这个很重要，否则将来会出错。

在Xcode左上角Run按钮右侧有一个下拉菜单，选择Device或者Simulator，点击菜单下方的Edit Schema。保证Archive中Build Configuration中的值是ad hoc distribution

至此配置以Ad Hoc Develoyment方式发布APP的工作就结束啦，下面就是进行程序编译，点击Product中的Archive，编译完成后d出设置框，点击Export选择Save for Ad Hoc Develoyment就会生成一个ipa文件，这个文件就是用于发布FIRim所用到的文件。

最后就是将这个生成的ipa文件上传到FIRim,点击发布链接进入发布页面，

走到这一步，就说明你大功告成啦，需要测试的手机设备通过浏览器访问这个APP地址就可以安装啦。而且FIRim还对APP的状态进行了设置，可以分为公开或者私密的状态来限制下载。总之，通过FIRim再也不用为了测试APP而使用XCode进行一个一个设备生成APP啦。

UDID本来是为了方便一个应用来统计用户行为的，但是因为是一个唯一ID，而且直接看不到跟用户隐私的关系，所以是开放出来的。但是，当有大量的app在市场中，而UDID对于每个app都是一样的时候，用户的隐私其实受到了一定程度的侵犯。假设有很多app联合在一起，因为UDID是统一的，那么他们就可以拼凑出用户的隐私出来。所以从这个角度苹果去掉了UDID的支持，而每个应用可以自行生成自己的UUID，所以，单一app的统计仍旧不会发生问题。

无法做到，包括后端语言也无法在 Web 中获取 UUID。

基于安全问题，JavaScript 无法获取到设备的 UUID，也没有接口可以获取 UUID。

如果 JavaScript 可以轻松做到，安卓设备的 APP 权限岂不是花瓶？！

简介：UDID的全称是Unique Device Identifier，顾名思义，它就是苹果IOS设备的唯一识别码，它由40个字符的字母和数字组成。在很多需要限制一台设备一个账号的应用中经常会用到。在iOS5中可以获取到设备的UDID，iOS7中已经完全的禁用了它。iOS7之前的使用了的app如果在iOS7上运行，它不会返回设备的UDID，而是会返回一串字符串，以FFFFFFFF开头，跟着identifierForVendor的十六进制值。

获取：[[UIDevice currentDevice] uniqueIdentifier]

废弃：iOS6

简介：iOS 60系统新增用于替换uniqueIdentifier的接口。是给Vendor标识用户用的，每个设备在所属同一个Vender的应用里，都有相同的值。其中的Vender是指应用提供商，但准确点说，是通过BundleID的DNS反转的前两部分进行匹配，如果相同就是同一个Vender，例如对于comsomecompanyappone,comsomecompanyapptwo这两个BundleID来说，就属于同一个Vender，共享同一个idfv的值。和idfa不同的是，idfv的值是一定能取到的，所以非常适合于作为内部用户行为分析的主id，来标识用户，替代OpenUDID。如果用户将属于此Vender的所有App卸载，则idfv的值会被重置，即再重装此Vender的App，idfv的值和之前不同。

获取：[[[UIDevice currentDevice] identifierForVendor] UUIDString]

适用：iOS60+

例子：95955F33-BFBD-48BA-A630-866D2DAE482D

简介：广告标示符，适用于对外：例如广告推广，换量等跨应用的用户追踪等。但如果用户完全重置系统（(设置程序 -> 通用 -> 还原 -> 还原位置与隐私) ，这个广告标示符会重新生成。另外如果用户明确的还原广告(设置程序-> 通用 -> 关于本机 -> 广告 -> 还原广告标示符) ，那么广告标示符也会重新生成。注意：如果程序在后台运行，此时用户“还原广告标示符”，然后再回到程序中，此时获取广 告标示符并不会立即获得还原后的标示符。必须要终止程序，然后再重新启动程序，才能获得还原后的广告标示符。在同一个设备上的所有App都会取到相同的值，是苹果专门给各广告提供商用来追踪用户而设的，用户可以在 设置 -> 隐私 -> 广告追踪 里重置此id的值，或限制此id的使用。

获取：[[[ASIdentifierManager sharedManager] advertisingIdentifier] UUIDString];

适用：iOS60+

例子：9C287922-EE26-4501-94B5-DDE6F83E1475

简介：MAC地址在网络上用来区分设备的唯一性，接入网络的设备都有一个MAC地址，他们肯定都是不同的，是唯一的。一部iPhone上可能有多个MAC地址，包括WIFI的、SIM的等，但是iTouch和iPad上就有一个WIFI的，因此只需获取WIFI的MAC地址就好了，也就是en0的地址。MAC地址就如同我们身份z上的身份z号码，具有全球唯一性。但在iOS7之后，如果请求Mac地址都会返回一个固定值。

废弃：iOS70+

获取：

简介：iOS整个系统有一个KeyChain，每个程序都可以往KeyChain中记录数据，而且只能读取到自己程序记录在KeyChain中的数据。而且就算我们程序删除掉，系统经过升级以后再安装回来，依旧可以获取到与之前一致的UDID（系统还原、刷机除外）。因此我们可以将UUID的字符串存储到KeyChain中，然后下次直接从KeyChain获取UUID字符串。（本示例中使用KeychainItemWrapper工具类）

获取：

简介：虽然苹果在iOS6中禁用了获取uuid的方式，但是只要你研究下就知道这个API只是私有化了，使用私有API还是可以获取设备的uuid。但是这个方面也面临着风险：比如API变更以及AppStore审核问题，但是在越狱设备上你还是可以尽情享用的。

类：AADeviceInfo（dump出头文件）

获取：[AADeviceInfo udid]

使用方法：在项目中将真机上的AppleAccountframework框架导出，引入Xcode工程中，利用runtime或者直接使用该类就行。（细节补充：导出AppleAccountframework后，进入AppleAccountframework的根目录，新建Headers文件夹，然后将dump出的头文件放在Headers目录，就可以像引用第三方framework一样在项目中使用）

在之前的版本是可以使用UDID获取iOS设备唯一标识：

但是iOS5及以后，被苹果禁止使用了（弃用了）

而直接获取的UUID系统不会存储，每次调用的时候都会获得一个新的UUID标示符

一般获取UUID的方法如下

我们可以通过持久存储这个标识符，来保证即使重新加载，删除后重装应用都能够唯一标识，以下的方式通过获取到UUID后存入系统中的keychain中，来保证以后每次可以得到相同的唯一标志。

project -》Capablities-》打开Keychain Sharing开关

1、点击XCode的菜单-Windows->Organizer。

2、直接复制、粘贴，就可以得到iPhone手机的UUID了。

UUID (Universally Unique Identifier)是一个软件建构的标准，是通用唯一识别码的意思。UUID被开源软件基金会 (Open Software Foundation, OSF) 的组织应用在分布式计算环境 (Distributed Computing Environment, DCE) 领域的一部分。

UUID的目的，是让分布式系统中的所有元素，都能有唯一的辨识资讯，而不需要透过中央控制端来做辨识资讯的指定。如此一来，每个人都可以建立不与其它人冲突的UUID。在这样的情况下，就不需考虑数据库建立时的名称重复问题。

目前最广泛应用的UUID，即是微软的Microsoft'sGloballyUniqueIdentifiers(GUIDs)，而其他重要的应用，则有Linuxext2/ext3档案系统、LUKS加密分割区、GNOME、KDE、MacOSX等等。

以下获取 uuidString 的方法，每次重启都会改变。

但是项目的要求是不变，并且删除app 只有也有有保留的需求。显然这个无法满足我们的需求。

使用KeyChain保存到系统钥匙串中，然后再去获取相应的值，就可以保证删除app新装的app也能获取到第一次安装存储的值。显然是可以满足我们的需求的。

下面使用 KeychainAccess 的第三方类库来实现。

开箱即用！

使用方法：

大功告成！

最近，因公司产品及客户需要，领导让我研究免存储设备ID，以及给出一个设备ID最佳的方案（可与存储相结合）。在研究过浏览器的fingerprient2js后，颇有心得，并且看网上似乎木有完美的解决方案，于是写了这篇文章，仅供需要的开发者参考。（该算法暂未进行验证，这里先给出一个jar包，后期我会在SDK中加入调查接口，分两个jar包（测试版和正式版），希望开发者能支持测试版，稳定后使用正式版。）

在产品中，首先肯定要尽量避免权限，其次考虑卸载APP后ID不一致的问题，再就是尽量结合存储，降低卸载或重装app时，设备ID改变的概率。最后，设计出合理方案，对造成不利的因素进行列举。

Aandroid_id:

什么是android_id呢？当设备在第一次启动时，系统会随机产生一个64位的数字，然后以16进制的形式保存在设备上，且API提供了获取这一参数的方法：

这就是android_id,当设备重新初始化或者刷机的时候，会被重置。

除此以外，android_id还有其他的bug，比如：

1不同的设备可能会产生相同的android_id。

2有的厂商设备无法获取android_id,会返回null。

3对于CDMA的设备，ANDROID_ID和TelephonyManagergetDeviceId() 的值相同。

4不同的android系统版本稳定性不同。

B硬件序列号(SERIAL)

API给的解释是：

A hardware serial number, if available（一个硬件的序列码，如果有效的话）

so，虽然我没有用几百台手机测试，也能知道这个值有时候是无效的，说的这么隐晦。

C指纹

fingerprint:设备的唯一标识。由设备的多个信息拼接合成。

也是在JavaScript才接触到这个单词”fingerprint“，这个词也很生动，意思是能大概的标识一个设备，像指纹一样，但不排除重复的可能性。

理论上讲用这个属性是可以标识一个设备的，但是其实并不是，两台一摸一样的新手机，这个值相同的可能性是很多的。为了更加进一步的精确，后面还会介绍几个属性，并把几个属性结合在一起，生成一个接近100%的UUID。

Dandroid系统提供了获取android系统版本号，生产厂商，固件版本推出时间的API

Eandroid系统提供了当前android设备是12或24小时制显示时间的API，

Fandroid系统提供了当前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做贡献的各配置参数：（示例以60的华为荣耀8为例）

1Android_ID:SettingsSystemgetString(contextgetContentResolver(), SettingsSystemANDROID_ID) //低版本稳定，高版本不稳定 示例：295a4fbf716094ee

2BuildSERIAL 设备序列号（有的设备无法获取） 示例：WTK7N16923005607

3BuildFINGERPRINT 设备指纹（同样的新设备该值应该是一样的） 示例：honor/FRD-AL00/HWFRD:60/HUAWEIFRD-AL00/C00B171:user/release-keys

4BuildTIME 固件推出日期 示例：1477442228000

5BuildVERSIONINCREMENTAL 源码控制版本号 示例： C00B171

6BuildgetRadioVersion() 获取无线电固件版本 示例：212100300031,212100300031

7BuildHARDWARE 硬件名称 示例：hi3650

8BuildVERSIONSECURITY_PATCH 用户可见安全补丁level（这里我得到的是日期，可能是补丁修复的时间）示例：2016-10-01

9当前设备是12/24时制：SettingsSystemgetString(contextgetContentResolver(), SettingsSystemTIME_12_24) 示例：null（有的手机可以获取）

10BuildVERSIONSDK_INT SDK版本号 （一般讲是与系统版本号一一对应的） 示例：23

11BuildSUPPORTED_32_BIT_ABIS 支持32位ABIs的列表（数值）示例：[armeabi-v7a,armeabi]

12BuildSUPPORTED_64_BIT_ABIS 支持64位ABIs的列表（数值）示例：[arm64-v8a]

13BuildBOOTLOADER 系统启动程序版本号 示例：unknown

14BuildVERSIONRELEASE 用户可见版本 示例： 60

16BuildBOARD 主板 示例：FRD-AL00

17BuildBRAND 系统定制商 示例：honor

21BuildHOST 示例：huawei-RH2288H-V2-12L

23BuildMANUFACTURER 产品/硬件的制造商 示例：HUAWEI

25BuildPRODUCT 产品的名称 示例：FRD-AL00

26BuildTAGS 描述Build的标签（Comma-separated tags describing the build, like "unsigned,debug"） 示例：release-keys

28BuildUSER 描述Build的USER 示例：jslave

31BuildVERSIONBASE_OS 基带版本 The base OS build the product is based on 示例：空值

32自定义字符串或自定义数组

以上就是关于fir.im 怎么获取uuid全部的内容，包括:fir.im 怎么获取uuid、苹果为什么开始拒绝 iOS 应用获取设备的 UDID 之前为什么允许、H5用户在手机浏览器访问网站页面，如何获取用户当前设备的信息uuid等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！