从 iOS 5 开始,Apple 废弃了设备唯一标识符 API,并没有提供友好的 Obj-C 替代方案,而是推荐使用 CFUUIDCreate
和 NSUserDefaults
。
CFUUIDCreate
并不复杂,NSUserDefaults
也不复杂,但这个解决方案在一些不同的方面失败了
这些问题的解决方案是创建一个充当包装器的类,并通过使用密钥链来改进持久性和共享选项。
在 iOS 中,每个应用程序都拥有自己的密钥链,它可以在其中存储只有该应用程序才能访问的敏感数据,还有一些非常特别的例外。这个密钥链在安装之间是持久化的,并且在用户加密他们的备份时,在恢复之间也是持久化的。完全恢复和作为新设备设置或从未加密的备份恢复将清除密钥链。
这为我们提供了一个地方来存储应用程序(或应用程序套件)特定的 UUID,该 UUID 将持续到给定用户继续使用该设备的时间,但是如果他们进行完全恢复,则会更改。这对于识别设备已在 Web 服务中跟踪的活动的设备等大多数合法跟踪需求来说是一个很好的精度级别。给定设备不会同时有两个 UUID,并且对于大多数用户来说,只有在他们获得新设备时才会更改。
密钥链的另一个有用功能是支持访问组,允许iOS应用程序从同一提供者中选择加入共享公共密钥链。UUID 可以存储在一个所有应用程序都可以访问的密钥链中,因此我们可以知道一个特定的安装集都代表一个设备。
“所以这一切看起来很有趣,但代码在哪里?” - 继续阅读的极客
@interface BPXLUUIDHandler : NSObject
/*
* Retrieve UUID from keychain, if one does not exist, generate one and store it in the keychain.
* UUIDs stored in the keychain will perisist across application installs
* but not across device restores.
*/
+ (NSString *)UUID;
/*
* Remove stored UUID from keychain
/
+ (void)reset;
/*
* Getter/setter for access group used for reading/writing from keychain.
* Useful for shared keychain access across applications with the
* same bundle seed (requires properly configured provisioning and entitlements)
*/
+ (NSString *)accessGroup;
+ (void)setAccessGroup:(NSString *)accessGroup;
@end
BPXLUUIDHandler
是我们创建的一个类,用于封装获取/存储新 UUID 的所有处理,并添加了访问组支持,因为我们的某些客户有应用程序套件。
它支持 ARC 和非 ARC 配置,并隐藏了所有密钥链交互,这样我们就不必一次又一次地编写相同的密钥链查询。
请使用并欣赏,并给出反馈。
[BPXLUUIDHandler UUID]
获取 UUID非 ARC 项目默认支持。
根据 Apache 许可证 2.0 版(简称“许可证”);除非遵守该许可证,否则不得使用此文件。您可以在 https://apache.ac.cn/licenses/LICENSE-2.0 获取许可证的副本。