首先,简单介绍一下UDID这个东西:
UDID是Unique Device Identifier的简称,也就是唯一设备标识的意思。于iOS SDK中取得的方法是UIDevice的一个叫uniqueIdentifier的NSString*,由于这个ID字符串是基于设备的,应用开发人员可以通过获取此ID来用于记录区分设备。正是由于这个特性,可能会导致一些隐私等等相关的问题,Apple于iOS5中将这个UDID废掉了,SDK中被标记为了Deprecated,虽然为了兼容低版本的源代码而继续存在,但并不会再返回任何有实际意义的东西。
最近在做Flurry的统计功能时,发现还是需要用到可以识别设备的东西的,好方便分析数据,经过一段时间的研究、试验,发现了这个应该还算是比较靠谱的方法……
其实早在UDID被deprecated的消息刚出来时,就已经有很多人开始研究对策了,我也google到了各种五花八门的解决方案,最后还是觉得这个UUID的方案比较合适,毕竟是苹果官方文档里推荐的替换UDID的方法。
关于UUID的具体说明可以查看下面参考文章中给出的苹果官方文档链接。简单来说,UUID就是一个随机序列字符串生成器,有点像Microsoft Windows的COM GUID生成器的作用,比起自己随机一个字符串的好处就是这东西能够保证唯一性,适用于标记。调用方法如下:
1 |
CFUUIDRef uuidRef = CFUUIDCreate(kCFAllocatorDefault); |
2 |
NSString * uuid = (NSString *)CFUUIDCreateString (kCFAllocatorDefault,uuidRef); |
然后呢,官方建议的做法是用:
1 |
NSUserDefaults *userDefaults = [ NSUserDefaults standardUserDefaults]; |
2 |
[userDefaults setObject: uuid forKey:@"UUID"]; |
这样的做法把生成的ID保存起来,下次再用的时候就直接读取已经保存的ID了。显然,那个UUID生成只是个“随机字符串”生成器,并不能像UDID那样保证每次取得的串都一样!保存起来虽然能保证用户再次打开这个应用时,能够获得一致的标识ID,但不能保证用户删除应用重新安装后这个ID的一致性,因为NSUserDefaults只是个像游戏存档一样的东西,游戏删了,存档也就跟着一块删了。所以,这个“存存档”的方法并不是一个比较完善的解决方案,一个更好的做法是利用keychain保存这个生成的UUID。
关于keychain这个东西的概念可以到这里学习:https://developer.apple.com/library/ios/#documentation/Security/Conceptual/keychainServConcepts/01introduction/introduction.html,简言之就是每个应用程序都有一个可以用于安全保存一些如密码、认证等信息的keychain,通过对应用签名时的一些设置,还可以利用keychain的方式实现同一开发者签证(就是相同bundle seed)下的不同应用之间共享信息的操作。比如你有一个开发者帐户,并开发了两个不同的应用A和B,然后通过对A和B的keychain access group这个东西指定共用的访问分组,就可以实现共享此keychain中的内容。而且,对比NSUserDefaults的一点不同之处就是此信息不会随应用的删除而消失!
关于Keychain的应用,Apple提供了一个叫GenericKeychain的例子程序,在这里:http://developer.apple.com/library/ios/#samplecode/GenericKeychain/Listings/Classes_KeychainItemWrapper_h.html#//apple_ref/doc/uid/DTS40007797-Classes_KeychainItemWrapper_h-DontLinkElementID_9,其中封装了一个简化Keychain操作的类:KeychainItemWrapper,可以拿来直接使用,记得加入Security.framework!
参考代码如下:
1 |
KeychainItemWrapper *keychainItem = [[KeychainItemWrapper alloc] |
2 |
initWithIdentifier: @"UUID" |
3 |
accessGroup: @"YOUR_BUNDLE_SEED.com.yourcompany.userinfo" ]; |
4 |
NSString *strUUID = [keychainItem objectForKey:( id )kSecValueData]; |
5 |
if ([strUUID isEqualToString: @"" ]) |
6 |
{ |
7 |
CFUUIDRef uuidRef = CFUUIDCreate(kCFAllocatorDefault); |
8 |
strUUID = ( NSString *)CFUUIDCreateString (kCFAllocatorDefault,uuidRef); |
9 |
[keychainItem setObject:strUUID forKey:( id )kSecValueData]; |
10 |
} |
11 |
[FlurryAnalytics setUserID:strUUID]; |
12 |
[keychainItem release]; |
关于keychain access groups的设置,传统方法是在Xcode项目target的Build Settings的Code Signing段中加入Code Signing Entitlements的配置文件,加入group信息,详细操作搜索一下就能找到。新版本的Xcode直接整合了生成Entitlements的功能,在指定target的Summary的最后一个段Entitlements中勾选Enable Entitlements,然后在下面的Keychain Access Groups中加入”com.yourcompany.userinfo”类的共享group名。这里要注意一点,参考IDE默认生成的对应app自身id名的group可以发现,这里的group并没有加入bundle seed,看一下生成的entitlements文件中的内容可以发现group名头部被自动添加了“$(AppIdentifierPrefix)”这种替换变量!
在最开始测试Keychain读写时,参考下面”如何解决苹果公司禁止用UUID的方法”这篇文章中的方法,一直在keychainItem setObject时报异常,断点跟踪了一下,发现是封装类的writeToKeychain函数中的SecItemAdd函数返回
errSecParam = -50, /* One or more parameters passed to a function where not valid. */
这个错误,最初以为是access group设置的问题,替换参数为nil后报错依旧.最后google到stack overflow上的”Storing keys in KeyChain with KeyChainItemWrapper”这篇问答后意识到原来setObject的key不能随意指定任意的string,而必须使用预定义好的一些key,替换key为kSecValueData后,问题解决。
参考文章:
Deprecated UIDevice Methods https://developer.apple.com/library/ios/#documentation/UIKit/Reference/UIDevice_Class/DeprecationAppendix/AppendixADeprecatedAPI.html#//apple_ref/occ/instp/UIDevice/uniqueIdentifier
CFUUID https://developer.apple.com/library/ios/#documentation/CoreFoundation/Reference/CFUUIDRef/Reference/reference.html#//apple_ref/c/func/CFUUIDCreate
如何解决苹果公司禁止用UUID的方法。 http://blog.csdn.net/mengtnt/article/details/7410373
Storing keys in KeyChain with KeyChainItemWrapper http://stackoverflow.com/questions/7117885/storing-keys-in-keychain-with-keychainitemwrapper