请选择 进入手机版 | 继续访问电脑版

雨林木风

 找回密码
 立即注册

QQ登录

只需一步,快速开始

搜索
查看: 24|回复: 0

漫谈唯一设备ID

[复制链接]

1万

主题

1万

帖子

3万

积分

管理员

Rank: 9Rank: 9Rank: 9

积分
32197
发表于 2021-1-19 15:34:04 | 显示全部楼层 |阅读模式
  假设这些符号和实际中的修筑是逐一对应的,可称之为“独一修筑ID(Unique Device Identifier)”。
  不幸的是,对付Android平台而言,没有安靖的API能够闪开发者获取到云云的修筑ID。
  加上Android平台碎片化的题目,获取修筑ID之途,能够说是行径维艰。
  统计需求是修筑ID最常睹的用处,网罗DAU, MAU的统计,行动统计,广告激活的统计等。
  例如维系行动统计做用户画像,认为用户供给本性化的任职,专家感想比力分明的便是讯息类和电商类的APP了。
  又如,定向推送,不必定是广告推送,过失修复,内测推送等也会用到修筑ID。
  IMEI本该最理念的修筑ID,具备独一性,规复出厂成立不会蜕化(真正的修筑闭连)。
  然而,获取IMEI需求 READ_PHONE_STATE 权限,测度专家也清晰这个权限有众费事了。
  越发是Android 6.0自此, 这类权限要动态申请,许众用户或许会挑选拒绝授权。
  咱们看到,有的APP不授权这个权限就无法应用, 这或许会下降用户对APP的好感度。
  假设一经用IMEI举动标识,要马上做兼容办事了,越发是做新修筑标识和IMEI的映照。
  假设厂商比力类型的话,修筑序列号+Build.MANUFACTURER应当能独一标识修筑。
  Android ID 是获取门槛最低的,不需求任何权限,64bit 的取值局限,独一性算是很好的了。
  对付升级到8.0之前安置的行使,ANDROID_ID会维持稳定。假设卸载后从头安置的话,ANDROID_ID将会蜕变。
  对付安置正在8.0体系的行使来说,ANDROID_ID遵循行使具名和用户的分别而分别。
  第一,假设用户安置APP修筑是8.0以下,厥后卸载了,升级到8.0之后又重装了行使,Android ID不相似;
  此中第二点或许对付广告同盟之类的有所影响(假设互相是用Android ID比拟数据的话),以是Google文档中说“请应用Advertising ID”,不外专家都清晰,Google的任职正在邦内用不了。
  对Android ID做了管制,对隐私爱戴起到必定效力,而且用来做APP自身的生动统计也仍然没有题目的。
  笔者之前写过一篇著作《Android修筑独一标识的获取和构制》, 文中提到修筑ID的两个观点:独一性和安靖性。
  例如自增ID(网罗分步自增),分段构制的ID(如snowflake算法)等,此类ID能确保独一性。
  修筑ID中的IMEI,修筑序列号,MAC等,都是依据轨则构制的,外面上能确保独一性。
  修筑序列号是对厂商自己独一,整体独一需求正在加上 Build.MANUFACTURER。
  但随下手机物业的日渐成熟,古板事理上的盗窟修筑已越来越少,以是大大都处境下仍然独一的。
  例如UUID和Android ID,这类ID有必定的概率会反复,闭头是看ID的长度(有众少bit)。
  左边第一栏是bit数目,第二栏是对应的取值局限,再后面是元素个数以及对应的冲突概率。
  比方,要是有50000个32bit的随机数,则这些随机数中,起码有两个雷同数字的概率为25%;
  换一种说法,便是要是有四组数,每组都有50000个随机数,则大约此中一组会有反复的数字。
  32bit有43亿的取值局限,若何50000个随机数就有这么高的闪现反复的概率?
  Android ID是长度为16的十六进制字符串,原来便是64bit,咱们来领会一下其反复的概率:
  要是APP累计激活量抵达50亿的APP,则每两个云云的APP就大约有一个会有反复的Android ID。
  不外这里的“反复”不是洪量的反复,而是“起码有两个雷同”,也便是,假设修筑激活量有50亿(许众APP达不到-_-),那么有或许会有少量的反复的Android ID。
  JDK的randomUUID,大致能够以为是128bit的随机数(此中有6bit是固定的),纵然抵达200亿的数目,有反复的概率也仅仅是10的负18次方,微乎其微。
  Android ID则安靖性较弱,规复出厂成立和刷机城市蜕变Android ID。
  获取修筑ID的API,要么收起不给用(IMEI), 要么获取变得贫困(SERIAL ),要么分别具名的APP获取的值不相似(Android ID)。
  同时,Android 10中存储权限也压缩了,之前的那种天生独一ID写到SD卡的某个角落的,以求卸载重装后读之前的ID等形式也不收效了。
  越发是有的API从来能够用,升级后就获取不到了,这种断崖式的蜕化,或许会对数据统计形成影响。
  此中,影响最深是定向推送,送错速递再有或许追回,推送错了就欠好说了,假设推送实质又比力紧急,后果不胜设念。
  假设修筑ID担心靖(ID蜕化),会影响到生动统计(会以为是新用户),对用户画像也有较大影响(之前的ID闭系的行动数据无法跟踪了)。
  假设必定的频率去阅览,例如说每天,总体而言,阅览到和昨天不相似的概率也是较小的。
  则对付两台分别修筑,两个修筑ID同时反复的概率是百万分之一,两个修筑ID起码有一个爆发蜕化约为千分之二。
  也便是,拼接ID的成绩是大大提升独一性,然则必定水准上下降安靖性(只消此中一个因素蜕化,拼接的ID就变了)。
  但真相上,而今能拿到的修筑ID,最越过的抵触是担心靖,以是,咱们不行为了提升独一性而亡故安靖性。
  容错计划有许众,例如搜集传输,用checksum去校验报文,假设堕落了则重发;
  再如磁盘阵列,数据写入两个磁盘,唯有当两个磁盘同时堕落时才会失落数据,从而大大下降失落数据的概率。
  然则对付修筑ID,以上两种计划都不符合,由于上面的计划需求通过checksum来确认原讯息是否被修削,修筑ID没有云云的条款。
  浅易地说,便是要采撷三个修筑ID到云端,假设有两个(网罗两个以上)的修筑ID和之前的记实雷同,则以为是统一台修筑。
  统一台修筑的两次采撷,认不出是统一台修筑的条款为“起码两个修筑ID都和前次不相似”,概率约为百万分之三。
  两台分别的修筑,以为是统一台的条款是为“三个修筑ID中,起码有两个修筑ID和另一台修筑雷同”,概率同样约为百万分之三。
  根基思念是:任职端有一张修筑 ID 的外,中枢的属性(Column)有:
  大凡处境下,任职端外的主键为自增序列(为了确保插入的有序性),以是咱们不行直接返回外的主键,不然容易被他人推度其他的修筑 ID,以及知道用户数目。
  这种计划好处是具有藏匿性,从UUID全部不或许得知主键ID,然则占空间,检索效果日常。
  此计划好处是省俭空间,检索速,然则条件和主键ID逐一映照,以确保不会反复,同时条件揣度结果有离散性(揣度结果和原ID,以及原ID较少的蜕变,比喻说+1,会惹起结果的庞大蜕化)。
  Android ID 和 MAC地点都还能够取到,假设有 READ_PHONE_STATE 权限,那么修筑序列号也有了,践诺计划的条款就凑齐了。
  最初,修筑序列号仍然要采撷的,事实再有一面旧版本的修筑能够获取到,能区别一点是一点;
  然后,采撷极少修筑闭连的讯息,机型,硬件讯息等(雷同的机型,或许有众种修设,以是同时也采撷一下硬件讯息)。
  假设修筑序列号、Android ID、MAC全都不等,则前面的SQL查问不会返回记实(也便是没有成婚的修筑)。
  不然,给deviceId分派优先级,然后放入优先队伍(最大堆),遍历列外竣事后,取优先级最高的deviceId(堆顶元素)返回。
  假设唯有Android ID 或 MAC 之一相当,然则修筑讯息都成婚不上的话,也以为不是统一个修筑。
  此时,天生新的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 是比力贫困的,而基于讯息采撷和云端归纳揣度则相对容易。
回复

使用道具 举报

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

|appname
快速回复 返回顶部 返回列表