iOS不靠谱的KeyChain数据存储

背景：

最近分析BI数据，发现我们数据出现了一部分idfa对应多个UUID的情况。当然这个问题，早已存在，只是我们才暴露出来而已。

标记设备

相信很多朋友都不陌生，应该都会选择OpenUDID:https://github.com/ylechelle/OpenUDID,配合keyChain来实现，我们也是，但是有个区别是我们增加了配置文件的概念，也就是OpenUDID+keyChain+localPlist,localPlist和keyChain一样，保存相同OpenUDID。可以认为是keyChain的备份吧，只有当keyChain和localPlist都里面找不到UUID的时候才会生成新的，并分别更新到keyChain和localPlist。这样就算keyChain中UUID丢失了，localPlist也能找到UUID，但是如果是删除APP的同时又刷系统了，那这种情况还是都找不到，会重新生成UUID。

KeyChain变化的几种情况

1. 越狱刷机

2.部分操作系统的bug

如，iOS 10.3 ,OS 10.3 deletes keychain items when an app is deleted. This means there's no good way to detect a specific device.
https://twitter.com/ericshapiro/status/833685944477818882;按业内大佬的话来说10.3后不再相信KeyChain。

3.应用卸载后，升级iOS系统

我们分析数据发现，有一部分用户是曾经安装过我们的应用，后来他卸载了，再后来，升级到了iOS11.4.1，然后又重新安装了我们的新版本应用，这时候发现两个版本采集到的UUID是不同的。目前我们没有本地复现，但是我们通过后台统计数据分析得出，应该算靠谱。我们可以推测苹果这样做也是合情合理，既然用户很久一段时间内都没安装我们的应用，也没必要给我们应用保留KeyChain。这个有点类似identifierForVendor,只不过identifierForVendor一卸载应用重新安装，不管间隔时间多久都变化，只不过KeyChain时间间隔长一点，还可能是要是特定版本之间系统升级。

解决方案

我暂时没有想到，有大佬可以不吝赐教！还好的是，目前我们这类数据占比不是很大。

备注:

IDFA,也是变化的。
to each device, used only for serving advertisements.
Unlike the identifierForVendorproperty of the UIDevice, the same value is returned to all vendors. This identifier may change—for example, if the user erases the device—so you should not cache it.

如果有所启发的话，帮本菜鸟点个赞！